Jeff Atwood’s recent post on the The Ferengi Programmer may be my favorite so far this year. Jeff posits that some programmers fall into a trap where they attempt to define a large set of rules for programming, similar to the Ferengi rules of acquisition. I think the comparison to the rules of acquisition is a bit flawed, since none of the Ferengi in Star Trek seem to be overly burdened by the rules like the programmers Jeff describes. Instead I would argue these programmers are bureaucrats, like the Vogons in the Hitchhiker’s Guide to the Galaxy.
Of course it all begins innocently enough. It starts with a bad project. The project goes wrong somehow – impossible deadlines, miscommunication, poor architecture, something. And it is painful. Afterward the programmers, project manager, customer, whoever, thinks “there must be a better way”. They make a list of what they would do differently. They have a post mortem meeting to discussion where things went wrong. And next time they try to do better, using the lessons they learned from the first project.
Except the next time, new problems are encountered. Users keep changing their minds. The design is flawed. Or whatever. So there is another post mortem, and they add to the list. Lather, rinse, repeat.
And this is okay. In fact it is good. We should learn from our mistakes. We should try to improve. All good.
There is a belief by some that if we just enforced a set of rules, a collection of standards, best practices, on our programming staff, we could eventually hit some kind of programmer nirvana where nothing would ever go wrong.
Not gonna happen.
Why? First, as the rules get longer and more complex, no one can remember them. And no one follows them. They become a joke. And second, the rules depend on the presence of smart people who care about what they are doing. It doesn’t matter how many rules you have in place – if your people are crap and don’t care about what is going on around them, 1 rule or 100 won’t make any difference.
The bureaucrats think they can prevent problems and chaos with more bureaucracy.
This is mistaken. Rules and standards are useful tools, but they alone cannot prevent problems with software projects. Only smart people who care about the craft make a real difference.