The Joel Test Really is Meaningful -

Well, it’s been nearly 2 months since my last post… I’m learning that if you want a blog to be successful, you have to carve time out of your busy life and make it happen. So, with renewed focus, I re-enter the fray.

The Joel Test is a curious and honest thing. It has been around since the year 2000 and was invented by a guy named Joel Spolsky, as the name might imply. In short, it’s a very brief questionnaire that evaluates the quality of your software development team, and implicitly their happiness as well.

There are 12 questions. A score of 12 is perfect, 11 is good, 10 or lower and your team has serious problems. The questions are simple and in the format of yes/no. The Joel Test is as follows:

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?

For those who have never heard of hallway usability testing, I offer Joel’s definition: “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.”

The Joel Test has been in and out of my life for quite some time. Every now and then I remember that it exists, and then I evaluate my current employer on it. My current company is suffering in the programming department; we are losing people like crazy and are having a hard time hiring good folks, despite offering reasonably competitive salaries and benefits… So, realizing that we have some issues, I conducted The Joel Test on a whim. Here’s how we did:

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?

We scored 4. 4 out of 12. Recall that 10 or worse means that you have a serious problem. Yeah.

So, what did I learn? I learned that part of the reason that we are losing people is that our programming practices and team environment lack something to be desired, and thus people are not happy. This isn’t really news to me, however, since the people that have quit recently have all cited these things as some of the main reasons.

What’s the next play? We need to improve the aspects of our environment and team that failed the test. The question then becomes: will management improve these things, or will they choose to ignore our suggestions because most of them (using the best tools that money can buy, quiet working conditions) cost money, and the rest of them are process changes? In fact, I’d go so far as to say that for my current company, they’d be significant process changes… And if there’s one thing that I’ve learned in my career as a programmer so far, it’s that businesses love to stay in familiar territory, clinging to what they already know and feel experienced in, and are generally afraid of significant change.

As a result of the change not being delivered, the motivated individual realizes that change must then come from within… People quit to change the negative environment for themselves (by joining a more positive one).

I encourage you all to conduct The Joel Test in your environments, and to try and improve your team with the results. What have you got to lose? Oh yeah, more developers.

analysis career culture interviews mistakes workplace

See also