Newsflash. I own four small apartment buildings (well, for now, the banks own them, my wife manages them, and I’m legally and financially on the hook when bad things happen). For me, managing rental property and software development teams are not nearly as disjointed activities as they may seem. A tragedy of the commons, for example, can happen in either place.
A tragedy of the commons occurs when a public resource is overused or misused by individuals each acting in their own interest, where each instance of overuse or misuse has a greater benefit to the individual than the incremental harm it does to the public resource. Eventually, however, this can cause the resource to be spoiled beyond recovery. Hence the tragedy. For concrete examples, think overfishing or global warming.
My wife and I differentiate our properties by keeping them well-maintained. We pile on the amenities (AC, dishwashers, hardwood floors, rehabbed kitchens and baths). And, initially, we threw in freebies (free Internet access, free laundry, free applications). Well, applications are no longer free, and neither is the laundry.
We put free laundry in the buildings thinking tenants would appreciate it being free and not misuse it. Misuse, you know, like leaving half-dollars in their pockets, never ever clearing the lint filters, spilling detergent and not cleaning it up, leaving unmentionables on the machines for days, tossing fabric softener sheets on the floor, letting empty bottles pile up in the corner. You know, misuse.
So, this year, we gated off the commons. In order to cover the cost of machine repair and cleaning services we switched over to coin-operated laundry machines. $1.25 a machine, less than the local laundromat. No one complained, but in each building when we did this an amazing thing happened. Use of the laundry machines fell by two-thirds (estimated, of course). Whether it was the availability of free laundry at a friend’s place or anger at the jackass landlord, many of the tenants suddenly began doing their laundry somewhere else. The same people who couldn’t reach over and drop a dryer sheet and a fistful of lint in a wastecan that sat right next to the dryer were now piling all their laundry into a basket, dragging it to their cars or walking it blocks down the street, and spending two hours somewhere else just to not pay the two-fifty to us. Well worth it from our point of view since we don’t have to clean up after them and the machines still bring in more than enough money to cover their costs.
The tragedy here is that, after we gated off the commons, the tenants clearly demonstrated that they could have spent the effort to keep the area clean and not have caused it to be gated off in the first place. We did try signs to encourage them to do this, but even the pleas to “clean the lint filter so that you don’t cause a fire and burn the house down” were ignored.
I don’t mean to compare software developers to tenants — not by a longshot — but we have lots of public commons in software development. Open source projects, unit test suites, collectively-owned code, wikis, test environments, shared components–if you start digging in detail the list is potentially endless. I could argue that self-managed teams (a major tenant of agile development) in many ways work like a public commons. I have seen tragedy strike in many of these environments. Individuals stop adding new tests to the test suite, or stop fixing tests that they break. Individuals apply hack after hack on shared code instead of taking the extra effort to refactor and enforce simple design. Wikis prosper without any notion of gardening and devolve into a weed-infested common-area surrounded by a cluster of walled personal gardens.
I intended this blog as a cautionary tale, but I do want to wrap up with a bit of hope. How do we avert a tragedy of the commons on a software development team, or within an entire organization? Two immediate answers come to mind.
First, make it easier for people to do the right thing than the wrong thing. I’ve preached this solution for years, and it really is a theme buried throughout agile development. Agile approaches that encourage the right behavior include: making build times fully-automated and ultra-fast, publicizing failed test suite runs to management, and collocating the whole team. Automation (to take the pain out of doing the right thing) and individual empowerment (to encourage ownership, a sense of responsibility, and clear accountability) are our best tools here.
Second, enforce a no broken windows policy. Again, I’ve spoken and written on this previously. Simply put, if the team agrees as a whole not to tolerate small infractions–such as a failing test that continues to fail through successive check-ins–it will discourage more of the same or larger infractions. New members joining the team will see how serious everyone is about the team’s simple set of rules and will fall in line without a lot of extra attention.
Ok. There’s the hopeful ending. Now on with my day.