Do You Pass The Joel Test?

Do you work for a Tech company? Are you part of a software team?

Does your team pass the "Joel Test"?

Seven years ago, Joel Spolsky (Joel on Software) created "The Joel Test: 12 Steps to Better Code". He calls this his "own, highly irresponsible, sloppy test to rate the quality of a software team".

The neat thing about The Joel Test is that it's easy to get a quick yes or no to each question. You don't have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each "yes" answer. The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, ...

A friend of ours recently pointed out that the Joel Test is part of the submission form for job postings to jobs.joelonsoftware.com. I think this is great. However, I would add three more steps.

13. Are candidates asked to submit code samples before the interview, bring them to the interview, walk through one or more and explain it?
14. Do you do code reviews? These don't need to be full-team meetings. Does even One Other Person review new code?.
15. Documentation. Do you have it? Do you care?

I switch back and forth between prograqmming and technical writing jobs. As a writer, I'm used to submitting writing samples, both before an interview and at the interview itself. As a programmer, I've been asked for code samples exactly once.

As a writer, I'm used to being proofread, reviewed, and edited. As a programmer, I've found this to be rare.

As a writer, I'm responsible for documentation! As a programmer, I often see documentation taking a back seat to features; heck, it's in another vehicle altogether, maybe not even on the same road! Instead of being considered as an equal part of any project, documentation is often way below code in priority.

Yet prose is less likely than code to cause bugs, mismatches between assumed API and reality, tech support calls, or system crashes. Why aren't programmers held to the same standards as "other" writers?

Bring code samples
Get reviews.
Document.
Improve.