Checklist

I stumbled across The Joel Test some time ago. An adaptation from a process a major company developed, the Joel test is a quick and dirty, 12 step “yes or no” questionnaire. It works well for just about any type of development, as well as any size company. Here are the 12 Joel Test questions, as well as thoughts on how to implement them.

1. Do you use source control?

Source control allows developers to save, track, review and roll back changes to source code. Source control may range from simply emailing a copy of a file to yourself, or a full scale code management program. Good source control does not slow down development, but rather speeds it up.

2. Can you make a build in one step?

Depending on the type of development, this step may present the biggest challenge. Mastery of making builds in one step will drastically reduce development time. Begin the endeavor by automating small steps and then compounding them. Before long, you’ll be creating full builds from one step.

3. Do you make daily builds?

Crafting daily builds facilitates source control, but also naturally lends to having achievable goals. Daily builds also fold into larger term schedules and help to keep scope creep in check.

4. Do you have a bug database?

Searchable user friendly bug databases make every developer on staff as good as the best developer on staff. Wiki’s deploy quickly and serve the purpose very well.

5. Do you fix bugs before writing new code?

Always, always, always fix known errors before writing any new code. Looking for bugs remains the key to correcting bugs. Use code validators regularly, but also build in milestones that require stopping and examining the code as well as the product it renders.

6. Do you have an up-to-date schedule?

A well written SOW (statement of Work) details the schedule and the specifications and always deters scope creep. I use a version of the Unified Process which lends itself to having an up to date schedule.

7. Do you have a spec?

Specifications serve as the blueprint to what we build. I use a combination of Unified Process and the MoSCoW (Must Should Could Won’t) approach to generate a SOW. If it is not specifically detailed in my SOW, I do not build it.

8. Do programmers have quiet working conditions?

Quiet working conditions should be available but not required. Collaborate liberally when applicable, and code in silence when it’s time to get ill.

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

The best tools money can buy, does not equate to the most expensive tools money can buy. I source used machines for Cross browser and legacy testing. There are numerous free tools one can use that will achieve all your needed functions. At the end of the day, the tools do make the job and finding quality tools always yields better results.

10. Do you have testers?

Testers are very important, but do not have to be people. The are many free tools for testing code.

11. Do new candidates write code during their interview?

Absolutely, no question, yes.

12. Do you do hallway usability testing?

Hallway testing takes little to no time, but reveals more information than few can imagine. Not only will fresh views on the product surface, but the time away from the code often revitalizes efforts.

It isn’t easy getting to 12 out of 12, but it is easy to score 8 to 10. I have seen companies that run at a 2 or 3, and they are truly brutal to work with. Whether a lone developer, or a cog in a machine of 1,000 developers, this approach works.