I don’t remember exactly when I first stumbled across Joel Spolsky’s blog Joel on Software, but it was at some point late in high school.

I didn’t know enough about the whole software development process to get a lot of what he was talking about really, but I enjoyed his writing style, and I enjoyed what he had to say.

Writing Better Code

In fact, I was such a fan that when I graduated, I went on to buy his books (which were collections of the articles on his site) and read them cover-to-cover. I kept copies of them on my desk at work, and I used one of his books – Smart and Gets Things Done – when I was a team lead.

The articles that stuck out the most to me, though, were those that were about writing better code. Here’s the thing, though: Those articles included nothing about actually writing code.

Writing Better Code

Instead, it was all about the processes around better code. And I stumbled across an article – 16 years old, nonetheless – and I still find it as relevant today as I did when I first found it.

Except now, I find it myself wondering how it applies to my current development gig.

The Joel Test

First, the article in question is one that I find myself reading at least once a month – if not at least once a week – and I all revolves around what he calls The Joel Test. It’s twelve questions that you apply to your current development team.

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a specification?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Given that these questions were written 16 years ago and are largely based on compiled code, some of the terminology might need to be adjusted.

The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. You don’t have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each “yes” answer.

For example, rather than asking if you can make a build a one step, perhaps we should ask if we can make a deployment in one step. You know what I mean – making adjustments to things like that.

Secondly, some of the questions have to be adapted to remote teams because we’re not all in the same office anymore. That is, rather than doing hallway usability testing, you may need to grab someone that you know online, send them to your testing environment, and ask them about the project.

The Joel Test For WordPress

Maybe, for those of us using WordPress as our development foundation, our set of questions would look something like this:

  1. Do you use source control?
  2. Can you make a deployment in one step?
  3. Do you make daily deployments?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have requirements and mockups?
  8. Do programmers have quiet working conditions? Or, if remote, are programmers permitted to go into “Do Not Disturb” mode?
  9. Do you use the best tools on the market, either something free and open source or something premium?
  10. Do you have testers? (And I might ask if the budget for the project allows for time to write unit tests for automated testing, as well)?
  11. Do candidates have code samples available on GitHub, a blog, or a publicly available location that can be reviewed?
  12. Do you have a group of people from which you can pull to test your work-in-progress?

Again, this is largely based on the idea of a small, remote team rather than a large, enterprise-level product company or agency. But it’s something that I still come back to every now and again and wonder how other shops stack up against one another.

Oh, and the whole scoring thing?

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help…

We’ve all got something for which to aim, right?

For The Next Decade?

It’s not so much that I think it’s a competition, but I know I’d like to be able to answer yes to most of these questions for myself and for those with whom I work.

But at the time of this article, I can say that I can’t say yes to all of these, let alone maybe half of them. Perhaps by the end of the year, I can, though.

And maybe the rest of us working in the industry can evaluate our teams against these questions. Although the Internet and related technologies move fast, these questions have held up well for over a decade.