Is the "Joel Test" still relevant?
I ended up having an extremely brief chat with Joel Spolsky recently in one of the Stack Exchange chat rooms. We learned, among other things that he'll only return to Dublin when "the heroin addicts promise not to yell at him for eating fish and chips in a park near Christchurch" and that he'd like to "sing a duet of 'Anything You Can Do, I Can Do Better' from 'Annie get your gun' with Jeff Atwood". But probably of more relevance to technology & programming, I was asking him did he still consider The Joel Test an accurate barometer for grading a software development team.
The joel test is still a pretty good test; there's not much in there I would change.
--Joel Spolsky, March 2011
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?
My gut reaction when reviewing it was, he must be wrong, it's 11 years out of date, but to be honest it's still pretty bang on. Surprisingly the company, I work for scores reasonably OK on it. (8/12). (for the record, we fail on 5, 6 & 8, and I'm only giving half marks on 7 & 9). Getting new hires to write code is still important; hauling marketeers away from their desks for a few minutes to see if the nerds are on the right track with something still makes sense; we don't always fix bugs on the next scrum iteration, but it invariably bites us in the ass as some point down the road.
I guess instead of changing it, maybe it could be added to & extended based on 11 years of experience & new developments in the industry. In this day and age any software development team not using Source/Version control should be taken out and shot. But that's not to say that those who are using a (D)VCS are using it correctly or using the best tools for their needs.
1. Do you manage your source code, version branches & release cycles using a (D)VCS?
Similarly any half decent IDE these days will do most of the heavy lifting when it comes to building your application (or multiple parts thereof) and managing your libraries/dependencies, scripts etc... However where most of the work comes from in our situation is the release process for a distributed platform of WebApps, Libraries & Windows Services to a number of different machines. With cloud based hosting solutions becoming more prominent, and automated release/deployment tools now part of the IDE itself (e.g. the Windows Azure deployment package manager in Visual Studio 2010), it's not just about the build, it's about the deployment. Similarly, it's not about an end-of-the-day deployment/release, it about always knowing that your developers are checking in code that never impacts the build or the rest of the team
2. Can you do a deployment in one step?
3. Do you use a continuous integration & automated testing platform?
Outside of that I think he's right. Perhaps a question asking do they have multiple environments for Dev, QA, Staging, Production. (Nothing as exciting as releasing production code directly from your local PC). You can take your pick of Development Methodologies these days as well, be it SCRUM, Agile, XP, etc... but as long as development cycles are conducted in a sensible/structured manner. That being said, I think it's stood the test of time pretty well. Kudos Joel.
~Eoin Campbell
