PKB

programming.TwelveStepsToBetterCode

The Joel Test: 12 Steps to Better Code by Joel Spolsky Wednesday, August 09, 2000

The Joel Test Do you use source control? Can you make a build in one step? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing new code? Do you have an up-to-date schedule? Do you have a spec? Do programmers have quiet working conditions? Do you use the best tools money can buy? Do you have testers? Do new candidates write code during their interview? Do you do hallway usability testing?

1. Do you use source control? Programmers have no way to know what other people did. Mistakes can't be rolled back easily. The other neat thing about source control systems is that the source code itself is checked out on every programmer's hard drive. I've never heard of a project using source control that lost a lot of code.

2. Can you make a build in one step? How many steps does it take to make a shipping build from the latest source snapshot? If the process takes any more than one step, it is prone to errors. And when you get closer to shipping, you want to have a very fast cycle of fixing the "last" bug, making the final EXEs, etc.

3. Do you make daily builds? When you're using source control, sometimes one programmer accidentally checks in something that breaks the build. Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed.

4. Do you have a bug database? If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Bug databases can be complicated or simple. A minimal useful bug database must include the following data for every bug: complete steps to reproduce the bug expected behavior observed (buggy) behavior who it's assigned to whether it has been fixed or not

5. Do you fix bugs before writing new code? In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix. That's one reason to fix bugs right away: because it takes less time. There's another reason, which relates to the fact that it's easier to predict how long it will take to write new code than to fix an existing bug. What this means is that if you have a schedule with a lot of bugs remaining to be fixed, the schedule is unreliable. But if you've fixed all the known bugs, and all that's left is new code, then your schedule will be stunningly more accurate. Another great thing about keeping the bug count at zero is that you can respond much faster to competition. Some programmers think of this as keeping the product ready to ship at all times.

6. Do you have an up-to-date schedule? The other crucial thing about having a schedule is that it forces you to decide what features you are going to do, and then it forces you to pick the least important features and cut them rather than slipping into featuritis (a.k.a. scope creep).

7. Do you have a spec? At the design stage, when you discover problems, you can fix them easily by editing a few lines of text. Once the code is written, the cost of fixing problems is dramatically higher, both emotionally (people hate to throw away code) and in terms of time, so there's resistance to actually fixing the problems. Software that wasn't built from a spec usually winds up badly designed and the schedule gets out of control.

8. Do programmers have quiet working conditions? We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. The trouble is, getting into "the zone" is not easy. The other trouble is that it's so easy to get knocked out of the zone. With programmers, it's especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down.

9. Do you use the best tools money can buy?

10. Do you have testers? If your team doesn't have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you're wasting money by having $100/hourprogrammersdoworkthatcanbedoneby$30/hour testers.

11. Do new candidates write code during their interview?

12. Do you do hallway usability testing? A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code. But the most important thing about user interfaces is that if you show your program to a handful of people, you will quickly discover the biggest problems people are having.