Programmer Musings

The Fallacy of the One, True Way of Programming

What is it about programmers that cause them to latch onto one approach and try to apply it to every problem? Maybe it's a characteristic of people in general. Each new paradigm, methodology, or even language seems to grab hold of many programmers and make them forget anything they ever knew. They seem to develop an overwhelming need to re-implement and replace all that came before the new tool.

This isn't always a bad idea. Done deliberately, this technique can help you evaluate a new methodology or language by comparing the solution of a known problem with a previous solution of that problem. Unfortunately, many of us seem to assume that the new way is better and apply the new approach despite any evidence that it does not solve the problem more effectively.

Over time, I've come to the conclusion that there is no One, True Way of Programming. This is not my own insight. I have read this and heard this from numerous people with more experience. Earlier in my career, I did not believe them. I didn't disagree, I just didn't believe. Through experience with multiple paradigms, languages, and methodologies, I've finally come to understand what those senior people were trying to say.

Multiple paradigms are different tools in my bag of tricks. Each language is another tool that I can apply to a problem. Different methodologies give me different approaches to solving a problem. But, in the end, no single set of these tools can help me solve all problems. Each combination has strengths and weaknesses. One of the most important skills we can develop is the ability to recognize the right tool for the job.

Many years ago, I saw this point made in a book. (One day I'll remember which book.) The author pointed out that very different techniques and processes are needed when you are building a skyscraper and when you are building a doghouse. The author pointed out that the techniques that would be used to architect a skyscraper are not cost-effective when building a doghouse. I think I would now go a little further and suggest that the techniques are not appropriate, and that cost is one easy measure of why they are not appropriate.

A Report on UML Fever

ACM Queue often has very insightful articles, and this one is no exception. The article ACM Queue - Death by UML Fever - Are you (or your developers) sick? covers a major problem in software development in a somewhat humorous fashion. I've seen several variations of this problem, but I never thought of it as an illness.

For those who are appalled at the article and who consider the author to be a heretic, you might to step over to another article in the same issue. In ACM Queue - The Fever is Real -, Grady Booch comments on the UML Fever, both the article and the affliction.

Another good piece of commentary on the subject is java.net: Death by UML-more [April 23, 2004].

The most important thing to take away from all of these articles is that UML is a tool (or a set of tools), not a life style, not a religion, and certainly not a solution to all problems everywhere. I'll be glad when more people use the tool was it was intended, instead of using in yet another round of holy wars.