The Joel Test: 12 Steps to Better Code

A few years ago an internal initiative on software quality launched at the Research and Development Department. There is always room for improvements and some guidance can help implement best practices for better workflows and for better code. The very first stop on our ride was at Joel`s Test for better code, published 24 years ago.

It is time for a review — again.

Do you use source control?

Who doesn’t?

Can you make a build in one step?

We were not sure about the scope of this question. Does it refer to local or remote builds? Only one component or the whole software system?

Since we build on remote commits, you could consider this as “building in one step”. Pushing to remote triggers a working build which is then being deployed on a server.

Do you make daily builds?

No. We build on each commit. Since we work in projects, daily builds aren’t as relevant for us since we might not work for a project every day.

The purpose of this is probably to ensure dependencies work and changes don’t break the product. We ensure this with our build-on-commit policy.

A drawback here is that we might not be able to build a software that is not touched for a longer period.

Do you have a bug database?

We have too many, in fact! Each project chooses their own platform, so we have an annoying switch between OpenProject/Jira/GitHub/GitLab.

Do you fix bugs before writing new code?

No. And that’s a problem. We tend to ignore bugs to a certain point in favour of writing new features.

Sometimes it’s also hard to find a balance between extensive refactoring and bugfixing: You encounter a bug, notice that certain changes are needed and start refactoring. At this point it’s sometimes hard to stop.

Do you have an up-to-date schedule?

Each project has prioritized tasks. Sometimes there are deadlines, but usually we just tackle the task with the highest priority next.

Do you have a spec?

This requirement / question might a bit outdated question? We still have to think about how this is going together with agile work.

The specification we miss the most is the definition of done.

Do programmers have quiet working conditions?

It depends on the office. Some offices are really quiet while there is a lot of pair programming / discussions in others. While this is most welcome, it might also disturb colleagues that are not involved.

Do you use the best tools money can buy?

Mostly, when it comes to hard- and software. We are still upset about not having GitLab Premium anymore, though.

While we are always in favor of FLOSS there are a few commercial products around.

Do you have testers?

lol

Do new candidates write code during their interview?

Yes.

Do you do hallway usability testing?

No. Most frameworks provide substantial ground for good usability. Of course we have to do better and double/triple check certain criteria but a hallway usability test requires a space/format, and maybe even a time slot.

We can give it a try, though.

Conclusion

After all, everything can get better and this is always case. Facebook guys used to say “[Things] can always be better, and that nothing is ever complete.”