What do developers want for working conditions?

There's a great article by Joel Spolsky titled The Joel Test: 12 Steps to Better Code. This article talks about how to write better code, but it's equally relevant to building an environment where software developers want to work.

The article hits home for me because, in the mid-90s, I worked for a company that was developing software for Microsoft. By requirement, we adopted methodologies that Joel talks about, like the "zero defect methodology." This had an almost miraculous effect on our ability to ship stable software on time. Even today, I can tell with frightening accuracy when a project will ship by doing nothing more than looking at the bug database statistics. The last person to argue with me on the subject was the president of a $50M company. I said they'd ship in 2 to 3 years - if they were lucky. He said I had no idea what I was talking about because I was just a lowly engineer and he was certain that they'd ship in three months. Two years later, I was still waiting for the initial release.

We also adopted other Microsoft techniques, such as the 1 to 3 ratio of testers to developers. This change also had a dramatically positive effect, both on the ship schedule and on the morale of the developers. Consider that developers spend 80% of their time on the "normal" case. Testers spend 80% of their time on the boundary cases, thereby acting like customers who abuse the software right out of the box. If you really want to make a developer unhappy, tell him to spend 80% of his time testing (as opposed to developing) obscure boundary cases, like whether the software correctly handles 260 character filenames on multibyte character systems. Most developers will just read Slashdot instead.

Joel also talks about quiet working conditions, which is one of my pet peeves. The last five companies I worked for all had overhead intercom systems that would be used to page people throughout the day. Every time one of those pages came on, it interrupted six to twenty developers and broke them out of "the zone". Aggravated me no end.

The final point that Joel talks about is Netscape. Everyone says that Microsoft put Netscape out of business. However, Netscape did far more damage to themselves than Microsoft ever did. Netscape released version 4.5 in October, 1998. They didn't release a stable upgrade (7.0) until five long years later. This means that, for all intents, Netscape completely sat out the second half of the DotCom era. They tried to start fresh on an entirely new project, but their cadre of 20-something programmers simply didn't have the project management and large-scale software development experience to pull it off.

In summary, Joel's article is now eight years old, but many of the points discussed in the article, such as continuous builds, are now considered de riguer of any software development effort with any self respect. It's worth your time to read.