The Joel test

Yesterday I got asked my thoughts on the “Joel test”, as a good friend of mine got the bad news that his development team is scoring just a 7 on the Joel test. He wanted to know what it is and “Is that score a cause for concern?”

This post is going to be a little tech focussed as I am sure you are guessing, but if you are a CEO/CFO and want to know what’s going on (what you’re spending your money on in an IT development team), then you will find this post of value.

Now, I’m not a strong believer in trying to measure your development team success or their strengths by any means other than, are you happy with the product being delivered? All too often we get caught up in some form of metric for measuring just how good something is, and while we are doing that and maybe getting great “scores” we seem to lose sight that the product being delivered is actually poor. However, that being said, I think the Joel test is a good indication of your software development environment, and if that is in good working order you are at least giving them the best chances to succeed.

The Joel test is dead simple, and though I’ve read lots of opinion on it not working for Agile, I simply have to say – use a bit of common sense and apply it in the correct fashion to your preferred development methodology. I am a strong believer in agile and SCRUM, we operate that here religiously, and I would say our Joel score is at 11. Not the perfect 12, simply because I don’t always fix bugs before continuing on with new development work, I personally prefer to address bugs towards the end of a development cycle.

So here we go, the Joel test:

Do you use source control? You must be saying YES to this, simple as that. Good source control will also provide you with build services for continuous builds, see a later question.

Can you make a build in one step? Should be a YES. Builds or build scripts or continuous build services ensure your code is at least always able to build and run. When a build is broken, you have to fix that before anything else, and what’s great about a continuous build is you find these problems out sooner rather than later.

Can you make daily builds? See above I would say

Do you have a bug database? You MUST have something like this otherwise you have no hope tracking issues and fixing them. You don’t even need to be that sophisticated, though I like my UAT testers to push bug issues into the same control we use for specifying out storyboards (SCRUM).

Do you fix bugs before writing new code? This is the one I let slide. I make sure everyone is aware of them, and if they are in an area of the system that will be worked on then YES, let’s do that. However, often bugs are not in the same areas, and in such cases I prefer to keep the development velocity up and come back to those bugs at a specified date and time (typically the start of the following development SCRUM).

Do you have an up-to-date schedule? Now some will say NO to this as they use XP or something. Personally XP is hit and miss. SCRUM lets me specify out what storyboards we need to work on, and then we work on them. We don’t have an old fashion specification as such, nor an old fashion schedule, rather we have lightweight roadmaps and storyboards, because that is what SCRUM needs. So I still answer YES to this question, though we use SCRUM.

Do you have a spec? You need to have some spec, so if you answer no to this, then your development efforts will fail. SCRUM provides developers with a spec in terms of the storyboards they follow with the identified tasks. Without them, you have no hope.

Do programmers have quiet working conditions? This should be a yes, even if you are using XP. Collaboration is always ok, but the conditions will on the whole be conducive to concentration.

Do you use the best tools money can buy? We do, but I don’t think this is the end of the world if you write no to this. I personally like to push the team forward as the best tools typically help productivity.

Do you have testers? I hope you answer YES to this.

Do new candidates write code during their interview? This is harsh, but I insist on this, and what’s worse I insist it be done with just a pen and paper. I’m not looking for syntax, rather a good understanding of OOP and problem solving.

Do you do hallway usability testing? Not sure many people do this, but I do like it. I especially like expanding this out to focus groups if and when you get the chance. If you don’t have resources for this, hallway testing can be easily completed, just get some friends and family involved J

Anyway, that’s my take on the Joel test, don’t get too hung up on your score, but like Joel states, a score lower than 10 indicates serious development problems…I would probably say lower than 9 is big trouble…