HACKER Q&A
📣 dcminter

What woud you substitute for the Joel Test 25 years later?


Near enough 25 years ago Joel Spolsky put forward "The Joel Test: 12 Steps to Better Code" - a list of questions to rate the quality of a software team.

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

The key questions (more "yes" answers being better) were:

• 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?

A quarter of a century later, are these still a good test? Were they even back then? Which ones do your teams honor and what might you choose to replace or supplement them with today?

  👤 dcminter Accepted Answer ✓
I think even back then the "Do you have an up-to-date schedule?" was a bit self-serving (Fog Creek had a related product).

On the other hand things like source control really weren't ubiquitous at that time and yet nowadays it would be a very poor engineering culture that didn't use something for source control.

👤 PaulHoule
You could find places that didn't use source control 25 years ago. Undergraduates didn't know how to use it. In the age of git, however, not using version control makes you seem to be 25 years in the past.

Yay for one step build. I have a script that makes one, merges changes from development, manages database schemas, all of that. Many places have a difficult build process and that's one of the best reasons to not take a job.

When I think daily build, I think about Windows NT back in the 1990s, but they had a build that takes hours. Today the daily build is too slow of a cadence, people do continuous integration, usually at every check-in.

Today bitching about JIRA is one of the favorite pastimes of software devs, although our JIRA is just fine.

Some bugs are low severity and can be worked around, particularly in web-based systems that are administered by professionals. It's OK to defer working on some bugs.

For side projects my practice is Kanban, where I have a limited number of commitments that I'm working on so I am always making forward progress, I don't set schedules, though maybe I should. In many places programmers are loathe to make estimates but it's clear what the product is, so "it's done when it's done" isn't necessarily a bad idea.

In modern development, you revise the spec as you go along. See Agile.

Quiet: hell yeah!

Testers: hell yeah!

Writing code in the interview isn't necessarily realistic. Personally I shine in whiteboard interviews (Physics PhD) but other people choke and hate them.

At least where I work, we put more effort into accessibility than usability, but our usability story is good (our competitor sites are awful) and our customers demand accessibility.