1. Do you use source control? [1 point]
2. Can you make a build in one step? [.6 points for modernized version of this]
3. Do you make daily builds? [1 point]
4. Do you fix bugs before writing new code? [1 point]
5. Do you fix bugs before writing new code? [1 point]
6. Do you have an up-to-date schedule? [0 points]
7. Do you have a spec? [.9 points]
8. Do programmers have quiet working conditions? [.5 points]
9. Do you use the best tools money can buy? [.5 points]
10. Do you have testers? [0 points]
11. Do new candidates write code during their interview? [1 point]
12. Do you use hallway usability testing? [.8 points]
Details at https://forum.beeminder.com/t/20th-anniversary-of-the-joel-t...> Do you use the best tools money can buy?
This is just unrealistic, and actually not required - the tools do not have to be the best, they should be adequate. Which author kind of confirms discussing his #1: "I’ve used CVS, which is free, and let me tell you, CVS is fine."
> Do you do hallway usability testing?
Usability testing is important, of course, but IMHO it should not be done in hallway, but rather among the target audience. Otherwise you'll end up with UI that is easy to do some basic things with, but very inconvenient for real work, in real workflow that is not possible to test in hallway (not providing any examples to not hurt anybody feelings by accident, but from my experience this is quite common, unfortunately).
I don't have a strong opinion about buying the best tools money can buy but it seems fair enough to include tool quality as a factor in how good a software team is. You might be right that adequate is adequate but it's not binary. Better is better.
As for your point about hallway testing, I think the point is that that's a bare minimum. Deeper testing with the target audience is even better but it's amazing how common it is to never watch over a real user's shoulder (screencast, whatever) as they try to actually use your thing.