The basics of Joel’s test
The rules for developing good software are sometimes plain common sense and are within reach of almost anyone who sets out to do their job properly.
Not long ago, I rediscovered a set of simple questions that tell us whether we have a good team and whether we develop software to a basic standard of quality: the Joel Test. Here is my summary. It is nothing more than common sense applied to our daily work:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug-tracking system?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a specification?
- Do programmers have suitable working conditions?
- Do you use the best tools your budget can afford?
- Do you have testers on the team or, at the very least, someone in that role?
- When interviewing new candidates, do they write code?
- Do you check the usability of your code by getting feedback from other developers?
According to the author of this simple test, the ideal answer to every question is YES. If we answer yes to ten or fewer, however, then we have serious problems with our approach to software development.
We may meet some of the test’s criteria, or meet them terribly, and still deliver an application that works. Our boss will be happy, and our client probably will be too, but at what cost? How much time will we have wasted fixing broken builds? How much time will we have spent resolving a bug that appeared two weeks ago? Will our code be maintainable when the same client asks us for new functionality? Can we recover version X of a class after introducing disastrous changes? Can we work efficiently without even minimal planning? Do we know exactly what needs to be done if there is no clear specification? Are we productive if we do not have a productive working environment?
Most of these questions should be addressed and answered by the developers’ managers, coordinators, and team leads, not by the developers themselves. Still, it is essential for programmers to alert their team leads to these shortcomings.
In addition to the questions in Joel’s classic test, I would add the following:
- Is the code adequately backed by tests?
- Is configuration management handled properly?
- Does the team follow some kind of methodology?
- Does the team make an effort to simplify and continuously improve the application’s structure and design?
- Is the code being developed simple enough?
- How little effort would it take a new team member to write new production code?