The good, the bad and the ugly of agile programming
Connecting state and local government leaders
Agile software development has strong defenders, but Reality Check columnist Michael Daconta still contends that government information technology managers should be wary.
Michael Daconta (mdaconta@acceleratedim.com) is chief technology officer at Accelerated Information Management and former metadata program manager at the Homeland Security Department. His latest book is titled “Information as Product: How to Deliver the Right Information to the Right Person at the Right Time.”
Discussing your favorite development methodology is similar to discussing your favorite religion — you are guaranteed to raise the ire of someone. In a previous article, I stated that “agile development is a programmer’s fantasy and a manager’s nightmare.” Some people disagreed with that analogy, and I have talked to good developers, ones I respect, who have strongly defended agile devleopment.
I certainly did not intend to throw the baby out with the bathwater. However, I still contend that government information technology managers should be wary of agile development, and here’s why.
Related story
Agile development is an umbrella term for a number of lightweight development processes, such as scrum and extreme programming (XP). In general, it is safe to say that these approaches mostly grew up in reaction to heavyweight development processes, especially the traditional waterfall development model.
The waterfall development model consists of a single, sequential set of phases, such as requirements, design and construction. The problem with the waterfall method is that it assumes each phase is perfect and complete before the next one starts. That assumption caused large — and expensive — project failures. Thus, lightweight processes arose in response to those failures.
It is a common phenomenon that when you violently — or extremely — react to something, the pendulum tends to swing too far. In essence, you overcompensate. I believe this is the case with XP and most agile methodologies, causing them to be unbalanced.
For example, the book “Professional Java Tools for Extreme Programming” states that “XP is a lightweight methodology that focuses on coding as the main task.” This is also reflected in the Agile Manifesto when it states that “working software is the primary measure of progress.”
Consider those two statements carefully in light of your software development life cycle. Do you focus only on coding? Does that not seem unbalanced? Of course, from a programmer’s perspective — or fantasy — that is exactly the right approach. Many programmers avoid design, documentation and testing. But I believe this focus on only one aspect of the development life cycle is agile’s Achilles' heel. It is akin to saying that civil engineering should be only about building construction. Forget site preparation, impact studies, blueprints, drainage, zoning and building codes — just build!
Now, before the fans of agile blow a gasket, this focus on coding has also produced some significant benefits. Techniques such as refactoring, test-driven design and continuous integration are considered best practices. So can you use agile development successfully? Absolutely. But only if you are a good fit for the method.
And here is the crux of my argument: You must fit agile; agile doesn’t fit you. That is the bottom line for agile success given its steep requirements for real-time customer input, minimal design and extreme iteration. So if you, as a government program manager, have ill-defined, “I’ll know it when I see it” requirements and can sit with the development team on a daily basis, you fit the agile profile.
Before closing this topic, let me briefly address two agile practices that exemplify its extremism: no upfront design and pair programming.
As we stated before, agile development uses extreme iterations to create the “simplest thing that could possibly work.” Like Joel Splosky, I am a fan of Big Design Up Front and have witnessed firsthand its benefits. Again, consider civil engineering: Do you want to drive across a bridge created without blueprints? Pair programming is a practice in which two developers work together with one person driving and the other observing. Although there are some cases in which this extra expense would be worthwhile, I would consider it a waste 80 percent of the time. And that brings us full-circle back to the concept of programming fantasies.
A software development methodology should not be self-serving. Instead, it should be balanced and fit a variety of IT projects. Thus, as I said before, be wary of programmers bearing gifts.
NEXT STORY: Agencies sponsor $12M IT innovation contest