Corollary to the Joel Test
Everyone knows the Joel Test. I think it gets used mostly for whining about how one’s organization isn’t “doing it right”, but ostensibly it is a way to measure your software development capability. You could think of it as the CMM writ small.
I’ve worked in quite a few shops over the years and I doubt any of them – including the mega corps – have scored higher than a 7. This leads me to suspect that damned few organizations actually score 11 or better, which Joel considers the minimum acceptable score.
Joel’s high standards aside, the strength of the Joel Test isn’t in the questions, it’s in the areas the questions cover. With 12 quick questions you can get a rough idea of how an outsider would view your competence in many areas of software development. Very handy.
The downside of the Joel Test – and any metric of anything, ever – is that over time people align themselves to the metric, instead of the spirit of the metric. To put it another way, the Joel Test has some leaks.
Here’s my corollary to the Joel Test. Just like the original, each is a simple yes/no question. The difference is that for each “yes” on my list, you subtract one from your Joel Score.
- Do you use more than one kind of version control system?
- Is there anyone on your team who can’t build in one step?
- Are specs developed without programmer input?
- Do you write new code the day before a deadline?
- Does your team regularly work more than 40 hour weeks?
How did you do? Did you go negative? I hope not, but I bet a lot of shops would.
Here’s my explanation for each item:
1. Do you use more than one kind of version control system?
Do you have several older projects in cvs but everything new is in Git? Why? Don’t get me wrong – there could be a damned good reason that is tied directly to your company’s bottom line. But I kind of doubt it.
Certainly your team is full of smart people that can manage more than one vcs. That isn’t the point. The point is that it is hard to have a unified approach to problems that everyone on the team uses when you’re all using different tools. This also creates a bus factor problem when Bob – the main dev on your legacy Zapruder project – goes on vacation. After all, he’s the last one on the team that uses VSS regularly and no one can figure out what the hell brand of crack he was smoking before he left. And those Zapruder people are getting pissed!
2. Is there anyone on your team who can’t build in one step?
This goes along with the idea of everyone using the same tools. Can everyone deploy the latest rev of the Zapruder project to the dev server with one click? Including off-site developers? Your team in India? That one guy in Fresno who works remotely? Your graphic designer who wants to update some templates and see the results?
3. Are specs developed without programmer input?
When you leave a programmer out of the specification process, you get airbags on guard rails.
4. Do you write new code the day before a deadline?
I maintain that at least 80% of deadlines are macho bullshit, usually generated upstream from the software development process. Even so, deadlines happen. What you don’t want to find yourself doing is writing code for new features the day before a deadline. That’s just not responsible development. Notice how I emphasize the word “new“. Certainly if you find a bug during your final testing, you’re going to fix it. Duh. But if you’re still cranking out features the day before a deadline, how in the hell are you going to test what you’ve written? The honest answer is that you’re not. Not in any meaningful way. You’re going to cross your fingers and hope.
5. Does your team regularly work more than 40 hour weeks?
This one is straight out of the Agile playbook and revolves around technical debt. It’s also a responsibility thing. People can only do so much work in a given amount of time. That’s just a fact of life, despite what the stereotypical programmer “caffeine == code” culture says. (More macho bullshit.) There will always be special times when more work is required, but those should be exceedingly rare.
These questions only scratch the surface, but hopefully they plug a few leaks. (How’s that for a mixed metaphor?)