Programmer Musings

Diets, Analogies, and Agile Programming

I enjoy reading the Worse Than Failure site as an antidote for programmer arrogance. While a junior programmer might look down on the people who made the reported mistakes, those of us who have been in the business for a while can recognize many of the mistakes. They still make a good laugh.

A few days back, the article The Great Pyramid of Agile surprised me with a bad analogy. I recommend that you read the article first, so that I don't accidentally misrepresent Alex's position. The article compares new programming methodologies to fad diets. Unfortunately, an analogy does not always show what you intend it to show. In this case, I feel the analogy is a clean miss.

Alex refers to the Agile methodologies as the new fads and declares that they all generally fail to deliver. He then goes on to prove that Agile doesn't work based on two arguments:

• a bad Agile analogy based on building pyramids
• a comment by evangelists for Agile methodologies

I agree with Alex that the pyramid analogy is ridiculous. But, a bad analogy does not mean that the thing being described is ridiculous. Unfortunately, when most of the anti-Agile people use building-based anologies they fail just as badly. Writing software really isn't much like building bridges or skyscrapers any more than it is like building pyramids.

His other argument is based on the fact that when an Agile project fails, the evangelists often say that it failed because there were not enough good people on the project. Whether true or not, this argument serves no purpose in proving that Agile is a good idea. In fact, when a traditional project fails, the programmers are normally blamed for not following the process. This argument also does not prove that the traditional process is a good idea.

A Tale of Two Diets

So let's go back to Alex's analogy with a twist. Say we have two people trying to lose weight: Bob and Carl. Bob starts the new French Fry fad diet. Carl starts a new program involving reducing his calorie intake, walking every morning, and going to the gym three times a week. Both Bob and Carl start off well and after a week they are enthusiastic and telling all of their friends. After a month, they are losing weight and going strong. After six months, the enthusiasm is wearing off and they are starting to backslide. After a year, they are both back to their old ways. In both cases, the evangelists for the method, say that the problem is that they didn't stick with the program, not that the program didn't work.

Based on most of the research, the reduced calorie and increased exercise approach will really have long term benefits, if you can maintain the discipline to stay with the program. Unfortunately, from this example, you cannot tell which is the real thing and which is the fad.

Back to Software

I see Agile programming practices in much the same way. Shortly after the Extreme Programming books started coming out, I started researching the process with a skeptical eye. I tried a pilot program working with XP and was impressed with the benefits we saw. I also noticed how hard it was to keep up with the practices, even when we could see tangible benefits.

Over time, the industry has seen many variations of Agile methodologies. What many people on both sides of the argument seem to miss is a side effect of the Agile methodologies. When practiced carefully, many of the Agile practices improve an individual's software development skills. This is the whole people over process thing.

There is a large body of evidence that suggests that the number one indicator of the success of a development process is the quality of the people working on it. If the Agile practices can really improve the quality of our developers, they may actually be on to something. The problem is developing software is like just about anything else, improving your ability requires discipline and hard work. Not everyone is willing to put in that kind of effort, no matter what we call the approach.

I think most people will agree that we have shown repeatedly in our industry that a new great, whizbang process will not turn a group of people who can barely type into a productive, professional development team. Despite this fact, many companies (and managers) seem to feel that if they just sprinkle on the right methodology, the people they have writing code will become a world-class development group. This is somewhat akin to suggesting that giving me the right checklist of steps to apply would make me into an Olympic athlete.

To be honest, I don't know if the Agile practices will have long term benefits. I have found some of practices to help improve my personal programming skills, at least in the short term. I have not seen enough benefit from some of the other practices to be able to keep doing them. That may be a failing of the practice or my own discipline. I find that I like the idea of improving my personal skills as a way of improving development on my projects. As a pretty good programmer with a fair number of years of experience, I would like to believe that improving my skills would be more effective than applying some magic methodology to a random group of people off the street.

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 recognise 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.