Programmer Musings

On-site at YAPC::NA 2007

As a short break from my normal programming oriented blog entries, I figured I should comment about YAPC::NA 2007 which we (Houston.pm) are hosting. The conference is currently running (June 25 - 27) at University of Houston, Central Campus.

Eight-ish months ago, Jeremy Fluhmann talked us into putting in a bid for YAPC. Despite quite a bit of work it has turned into an amazing learning experience, even before the conference started.

As you might be able to tell from my site, I'm a stereotypical programmer-type. In the process of preparing for the conference, I had to work to learn to deal with people much better than I normally do. It is a lot of work. There were stressful situations. Things went wrong. Things went right. We were stretched and we learned. On top of everything, I had a real chance to meet and work with people just outside my normal comfort zone.

If you ever get an opportunity to run a conference or help organize a conference, I would highly recommend taking that opportunity. If you are like me, you will find this to be much different than you expect and a really good opportunity to work on skills that you may not normally exercise.

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.