It may be hard to believe it was that long ago, but it was indeed on August 9, 2000 that Joel Spolsky wrote his famous article, The Joel Test: 12 Steps to Better Code
The test is based on a simple idea: answer 12 yes-or-no questions and if you answered “Yes” 12 times or close to that, you have a very mature and effective software engineering organization. If most of your answers were “No”, then you’re in serious trouble, or you will be when your hero programmer decides to leave. Regardless of how you score on this test, the questions you answered “No” tell you how you can improve.
Before you begin to criticize this test, consider that it was written a very long time ago and in what was a really a different era (the Agile Manifesto was published only the following year and we think Agile has been around for a while).
Over the last ten years, countless software developers asked themselves these questions, thought “we should really be doing this this…”, and then actually did it. At the same time, advancements in our profession were taking place and chipping away at the relevance of these questions.
Do you use source control? Is that even a question?
Do you make daily builds? Here, there may be a big difference between two ways to answer “yes”, for instance, between running a script every 24 hours just to build the thing and improvement based on continual feedback from a continuous integration system.
Do you have a spec? “No” may now even be the preferred answer. Imagine an awkward scene: someone walks into a room full of Agile Manifesto signatories and asks, “Do you guys have a spec?” True, there is an important place for specification in agile software development (such as executable specifications used in agile acceptance testing), but the spec described in the Joel Test is of a different kind, the big one written up-front and before everything else.
Do you do hallway usability testing? Okay, if you are a software developer and you never leave your desk and expect your manager to give you tasks, then you are probably developing something unusable. (Mike Cohn wrote in User Stories Applied that software development managers are some of the worst user proxies.) If that is your situation, you can discover a lot by stepping outside the cubicle and asking someone to use your program. But your team can probably discover the same insights, only earlier, by applying user stories and engaging in conversations with more relevant user proxies.
