Jul 15, 2012

The Foosball Factor

It is no grand secret that I have been job hunting: in this modern world, every job is simply what you do until you find your next job. When there is no pressure to find employment, one tends to become picky, and certain warning signs are no longer ignored.

One of the signs I have been heeding is the foosball factor. I have observed that:

(code base quality) × (1 + gaming tables in break room) = constant.

Gaming tables and other distractions are a band-aid, an unguent applied to relieve a symptom while the primary causes remain untreated. The problem is that handing out toys is addictive. Rather than hunkering down and repairing what is defective, management relies on the short-term solution of distracting the developers with a “fun” environment, where they can take gaming breaks between periods of miserable drudgery.

This has devastating long-term effects. It initiates a vicious circle. A bad code base — one that either started badly or fell into disrepair because too many short-cuts were taken — results in discouragement among the better engineers in the company. They leave and the less experienced coders remain. Their lack of skills contribute to the further decline in quality, and the cycle repeats until the system is so unstable that the company has no choice but to do a full reboot or go bankrupt (or both).

A full reboot rarely works: at this point the entire work-force consists of unskilled engineers. Few remaining staff members have the ability to do a proper redesign of the system: those that do are so bitter that the second-system effect kicks in and the redesign plan is over-engineered and completely unachievable. We’ve seen this time and time again: Apple’s Copland fiasco and Microsoft’s Vista debacle immediately spring to mind.

So what does management need to understand about the foosball factor? The most obvious lesson is that you cannot bribe developers: good developers are going to leave no matter how many foosball tables you install in the break room, and bad developers are going to remain because of the “fun” environment.

The next lesson is that code base repair will be painful for everyone. Management is no exception. If anything, they will have the most difficult job of all: explaining to customers and stakeholders why no new features will be added to a release save for a few critical bug fixes. Having to say “No” is the hardest job of all.

The least obvious conclusion is that a good manager needs to put the brakes on when developers become enthusiastic about the code base. Developers will want to work on a healthy code base. Productivity will increase, and they will be tempted to take advantage of this burst of newfound energy by removing the restraints on the developers. This is the worst thing that can be done: months of careful repairs can be undone in a matter of days.

Software development is a marathon, and keeping an even pace throughout is the only way to achieve victory. Foosball tables are indicative of unnecessary sprinting, burnout, and eventual collapse.