I just came across a simple test (follow the link for a more thorough write up) to ascertain whether an organization (which writes codes) is writing good code, or not. Yes, it’s rather simple but that doesn’t mean it doesn’t work. In fact, from what I can tell, I’d love to implement all of those in my work place because I’m sure they’ll make a difference. In fact, I’m gonna make it a point to get both 12 implemented in current and future projects. But before that, let’s see what are these 12 tests.

The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

Now let’s see how the organization I’m working in score:

1. Using source control? Yes
2. Make daily builds? No
3. Maintain a bug database? No
4. Fix bugs before writing new code? Yes
5. Have an up-to-date schedule? Yes
6. Have a spec? Yes
7. Work in a quiet condition? No
8. Use the best tools money can buy? No
9. Have testers? No
10. Make new candidates write code during interviews? No
11. Do hallway usability testing? No

4 / 12, which is pretty sad. Compared to other heavy weight methodologies, this 12 tests must look like a joke, yet we scored 4/12. I reckon I’ll be able to suggest so that these will be implemented as soon as possible. With a link back to Joel’s website, of course.