The usual suspects
Whenever I’m presenting anything, I try to start off showing the “Top 20 replies from a programmer when their programs doesn’t work”. In case you’ve never seen it, here it is:
- It works on my machine.
- Where were you when the program blew up?
- Why do you want to do it that way?
- You can’t use that version on your system.
- Even though it doesn’t work, how does it feel?
- Did you check for a virus on your system?
- Somebody must have changed my code.
- It works, but it hasn’t been tested.
- THIS can’t be the source of THAT.
- I can’t test everything!
- It’s just some unlucky coincidence.
- You must have the wrong version.
- I haven’t touched that module in weeks!
- There is something funky in your data.
- What did you type in wrong to get it to crash?
- It must be a hardware problem.
- How is that possible?
- It worked yesterday.
- It’s never done that before.
- That’s weird…
I’m not quite sure who wrote it originally, but I was given a paper copy several years ago. I must admit I had a good laugh at the time, as I could relate to most of the replies.
So whenever I’m presenting this list, there’s a giggle and a great deal of nodding and smiling going on in the audience. Then I go on to present something that will alleviate one or more items in this list.
But it’s not a laughing matter! It’s the sad state of our beloved profession we’re laughing at. It’s not supposed to be like this.
When I’m presenting the list in 10 years from now, there’s not a giggle. Not a smile. Just silent shame of times past or loud laughter at good ol’ days. Hopefully no one doesn’t even recognize the items on the list.
I might have a different kind of list. But not this one. We have made progress.
What to do next
So I propose this list as the metric for how mature your development organization is. Same rules apply as in the wtf code review metric. Less is better. Drop the Joel test. Drop the Nokia test. Drop test X. Use this. Now!
The worst part of this is that most of these are solved problems. Test Driven Development, Continuous Integration, and Pair Programming have existed a decade. Their poorer, but still useful cousins, Unit Testing, Automatic Builds, and Code Reviews have been around the block even longer. Iterative and Incremental development, Miniature Milestones, and Review and Adapt has been grown ups for a while as well.
So there is no excuse. The answers are at your doorstep. But it takes discipline. And time.
But you’re not alone. I’m off trying to do my part. Our mission is clear. Will you do yours?