The Joel Test for Web Development - Conclusions
These are the closing notes of a three part series looking at applying The Joel Test to a web development setting. You should really read the whole thing through from the first post before continuing, else your eyes will glaze over, catapulting you into a trance not seen since the finale of the American/Pop Idol was aired.
The point of translating The Joel Test into web development terms was to find out if there are any useful lessons web developers can learn from the traditional software industry. By asking if the test easily translates into terms and principals that are meaningful to us, we are not only forced to analyse the questions, but also look long and hard at the way we work and identify where improvements can be made.
Rate Your Team
The first thing to do is to take the test yourself for the team you work in (even if that’s a team of one) and see how you score. If you score 12 you get a lollipop. If you score less you get some fun new challenges to think about.
Here’s how I score:
- Do you use source control? Yes
- Can you make a build in one step? Not quite!
- Do you make daily builds? No
- Do you have a bug database? Yes
- Do you fix bugs before writing new code? From today, Yes. See, improvement already!
- Do you have an up-to-date schedule? Yes
- Do you have a spec? Yes
- Do programmers have quiet working conditions? No, at least not consistently.
- Do you use the best tools money can buy? No
- Do you have testers? Yes but I think we need more.
- Do new candidates write code during their interview? Yes
- Do you do hallway usability testing? Yes
So that’s 8/12 which isn’t too shabby, but we have room for improvement. It’s dirty-laundry-in-public time, leave your scores in the comments below. Be honest.
What can we learn?
Well, aside from the twelve questions in the test, one of the important points this highlights is the fact that these principals do translate easily to web development. And if this little test can produce so much helpful wisdom, imagine what can be learned from all the rest of the stuff on software development out there.