"Joel test" for B2B hardware/software developers

Question

I discovered the Joel test recently and applied it to my team. However, I but found hard to apply some points to my company since we are developing small chips with both "wired" and programmable algorithm.

5: Do you fix bugs before writing new code?

Since we cannot patch the hardware/software once delivered, we cannot tolerate any know bug, and a whole team of senior developer are building tools used for tracking them. This point should be for example "do you have 2 different implementations for each of your products, and are you testing test against each other?"

12: Do you do hallway usability testing?

We don't develop UI. This point seems irrelevant.

How can we adapt this test to the kind of development we do?

Answer 1

Joel's test is a good rule of thumb, but is not sacred. For example, the rule number 5 you quoted is a bit problematic. Yes, it is desirable to fix bugs before writing new code. No, these are not mutually exclusive activities.

There's a "revised" version that you might want to take a look at here. I like it much more than the original.

Answer 2

12: Do you do hallway usability testing?

Is still relevant even if you don’t develop a UI. At its heart this is about addressing the curse of knowledge.

The more familiar you are with any system the less trust worthy your judgment is about how usable it is. That system can be a UI, code, documentation, even floor plans.

You need to watch how someone brand new to it experiences it to understand. Don’t tell them how to use it. Just watch. And maybe you’ll learn that a change will make it easier to use.

Don’t think this was ever just about UIs. Anything you create that others have to deal with deserves this kind of testing.