Is Extreme Programming an Overreaction? (Part 2)

Although it may be an overreaction, what is it a reaction to? Many statistics show that even today, most software projects fail. It seems reasonable to believe that many companies are looking for a new way of doing things. From the programmer's point of view, it probably seems like it is a failure of management and a lack of proper tools to get the job done. If that's the case, it would make sense to try to minimize management and throw out the old tools.

On the other hand, there's the famous adage that managing programmers is like herding cats. From a management perspective, it can be frustrating as well: "why don't the programmers understand how important it is to get feature XYZ completed by the deadline?"

I think the truth is probably a combination of things; insufficient understanding by management of the complexities of software development, lack of reliable visibility into the plan and current status, overly complex and insufficient tools, insufficient understanding by programmers of the complexities of business realities, and lack of information in the trenches about how the current development plan is connected to the business plan.

It seems to me that part of the problem is plain and simple education. Having been in both camps, often simultaneously, I can shed some light on this subject, but my favorite part and the part I think tool vendors can help the most with is providing tools that provide high visibility of all aspects of the software development process to all stakeholders in real time.

After all, isn't the fundemental reason for software the automation of manual processes? Why in the world should software developers ever have to resort to keeping track of things with 3x5 cards or spreadsheets that provide only a modest benefit over paper and pencil compared with using a software tool that has been tailor made for tracking software development activities? What's next? A return to punch cards?!

As a software development tool vendor, I believe we are obligated to sit up, take notice, and do something about this situation. Otherwise, it seems that we can look forward to state of the art software being created with the software equivalent of sharp sticks and stone knives.

One company that has started to respond to this challenge is the Rally software company with their Rally software product. It automates many of the tasks associated with Agile development. I salute their efforts and hope that all tool vendors will respond in kind. I know that I'll be doing my utmost to make sure that AccuRev takes heed.

Is Extreme Programming an Overreaction? (Part 1)

I've been doing a lot of research and thinking about methodology recently. I also went to SD East this week (great show, great conference) where I was overloaded by Agile this and Extreme that. I guess I was lucky though. I joked to one speaker that I figured I'd made a mistake by leaving out the word "Agile" from my presentation title since it was in practically every other presentation title. He shrugged and said "it seems less here than at other conferences." I can only imagine which conference he recently attended. It must have been called something like "Going Beyond Extreme Programming" or "Lighting Methods for Legacy Agile Developers".

I've read up on Agile methods and Extreme Programming, read articles, talked with prospects and customers about it, and used many of the ideas over the years. For the most part I had heard about those ideas or learned about them prior to having heard of either "Agile" or XP, so I never really thought of myself as an Agile person or an XP person.

I also heard about pair programming, but outside of frequent code reviews, haven't actually done true pair programming. It doesn't strike me as my cup of tea.

In any case, I guess I had subconsciously formed an opinion about Agile methods and then began filtering out new information. After all, I "knew" what it was, so now I could think about other things.

But then I did some more in-depth research on modern methodologies in general, spent some time at a customer that is "going Agile" and followed that up with a week at SD East. I was forced to realize that I had not fully appreciated what it meant to be "Agile."

I can't help but thinking: "is this an overreaction to something?" I've heard things like "but isn't extra training contrary to the manifesto that says 'the only measure of success is creating working code?'" and "keep track of the project with a stack of 3x5 cards." You might say that I'm the one that is overreacting, that I'm only picking up on "the extremes." I don't generally react so strongly to an extreme comment here and there, so I'm pretty sure it is the steady drumbeat that I'm reacting to. By the way, how do you Google a stack of 3x5 cards?

My gut tells me that Agile is a programmer-centric reaction to a feeling that there is too much bureacracy keeping the programmer down; mangement is too heavy-handed, and the development tool stack is too hard to use. If only the programmers were in charge, everything would be better. And to top it all off, the guiding principles are set out in a Manifesto. I agree with some of the principles in the Manifesto, but to me it seems to go a bit too far.

For instance, take the principal that "Working software is the primary measure of progress." That seems far too programmer-centric to me. I agree, there's nothing quite like the rush of seeing a newly implemented feature in action, or the satisfaction of squashing a clever bug. I could spend all day implementing cool features and squashing bugs. But outside of personal hobbies and coursework, isn't the point of developing software to maximize customer happiness and new customer acquisition? At the end of the day, isn't software development a tool for achieving success in business?

Now that I have your attention, stay tuned for Part 2!