The Joel Test Revisited

The ubiquitous Joel Test: 12 Steps to Better Code is almost 20 years old. It was a great foundation, but with the past two decades, is it still relevant? Here’s my review.

1. Do you use source control?

Still valid and vital. But good source control practices are required. Have a master and a staging branch that can’t be pushed to directly. Do pull requests (i.e. peer reviews). Don’t push passwords, put that in a secure vault, scan for personal emails.

2. Can you make a build in one step?

This needs to be broadened to encompass all of CD/CI. Building, testing, and deployment should be one step in a dedicated setup. I’m currently using Codeship for that and loving it!

3. Do you make daily builds?

Again, CD/CI makes this better: build on every change. Less than this is too risky. And days without changes don’t need a build. Come on.

4. Do you have a bug database?

Yes! Essential. But it needs to be curated. If clients can add to it the bug descriptions might be too broad or too vague. Great clients will get that and learn to formulate bug reports correctly.

5. Do you fix bugs before writing new code?

My heart bleeds for this one. Reality will make you classify the bug from trivial to blocking, and bugs that can be worked around will be pushed aside to favour newer features. Fixing bugs first is good advice, but not always workable. But if our aim is the original “better code”, this is a sound practice.

6. Do you have an up-to-date schedule?

Still relevant, knowing that schedules will change on a daily basis. Agile has impacted this greatly. Devs see one sprint ahead, which might be a boon for when it comes to stress management.

7. Do you have a spec?

Specs are so volatile… Needs change fast. Write them down but keep updating them. And how about adding : do you have architectural documentation for when the project is done and slides towards long term maintenance?

8. Do programmers have quiet working conditions?

The first question that’s about the worker building the product. This one could be the toughest in some contexts. And silence isn’t the only factor. We work sitting down. The body takes a toll. Ergonomics are vital. And many programmers don’t like basements, contrarily to some rumours.

9. Do you have the best tools money can buy?

Be smart about this one. So many good tools are free now. And so many essential (and admittedly non-essential) tools are costly. Having to support software using an SDK without access to documentation shouldn’t be an assignment. Machines should be able to be up 100% of the time and perform adequately. Anything too old and slow should be replaced. Fast and stable Internet is vital too. This is what’s running the world now. Everyone should know.

10. Do you have testers?

Yes! Still valid! Programmers 👏 Aren’t 👏 Testers 👏!

11. Do new candidates write code during their interview?

Still valid. Interview questions shouldn’t be gotchas, ever. But problem solving is essential. Just don’t look for syntax errors. That’s not what handwritten coding is for.

12. Do you do hallway usability testing?

If the list was “12 steps to better products”, this would make sense. But this is for better code. A better question would be: Do you have unit tests? Doesn’t have to be TDD. Doesn’t have to be 100% coverage. But more than 0%.

Other questions for better code:

There are other questions that can lead to better code. Here are my additions:

13. Do you use design patterns?

There is such a thing as too much of a good thing though. A metric that could help: Ratio of singletons to other regular classes. Too many singletons means the developers just don’t know when to use them.

14. Do you upkeep the code?

When code is revisited, is it updated to meet new standards? Think ECMAScript 6 and what it brought. Were Promises revised (when appropriate) with the new async/await patterns?

15. Are programmers encouraged to explore new technologies?

This can be facilitated in a few ways. It doesn’t need to be paid time (but it can and boy does this make a company stand out!) If paying for this time as work hours isn’t possible, there are other ways. This is the sort of thing for which you bring out pizza, not at crunch time. Work isn’t a hackathon. If there’s crunch time, meals aren’t an incentive, they’re a facilitator, and extra time means extra pay. No exceptions, unless you want to compromise quality.

16. Is pair programming encouraged?

Some places consider this to be a net loss. Two programmers working on one feature together or two programmers working on one feature each? That’s easy to figure out! Well, no, not so much. If code quality matters, encourage occasional pair programming, and try to mix up the teams.