TRENDING

The good, the bad and the ugly of agile programming

May 11, 2010

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.

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.

inside gcn

Reader Comments

Wed, Jan 26, 2011

Software build with the agile methodology are a hacker's dream.

Last agile program I touched, the leadership threw all of the security functionality off the raft and expected the Information Assurance engineers to come back later and do the "paperwork" to get the product certified and accredited.

Needless to say, that piece of software was penetrated over and over and over and ...

Tue, May 25, 2010

agile development is a code word for avoiding all the obstacles in software development starting with CMMI. the problem is not with the software developers necessarily it's with the program managment people. the DoD continues to deliver poor quality systems, that don't meet performance specs, behind schedule and overbudget -- by the same companies that purport themselves to be CMMI level 3, 4, or 5 it doesn't matter. Agile is just a codeword for teams to cut out all the obstacles that don't add value... it's a software ideology

Fri, May 21, 2010

If you want to add something useful to this article’s philosophy , you might try following an actual project utilizing Agile development and document the pitfalls and paybacks of using the approach. That way you can provide something more valuable then just your stand up philosophy, no value in that! Agile is not just about the word, its all in how you apply it. Be wary of managers bearing SOW’s and journalist bearing knowledge, it may result in a waste of money.

Wed, May 12, 2010
FrAgile
NoVa

Michael Daconta is absolutely correct and has the moral courage to mention the flaws in 'Agile' methodology.
I have been in the IT industry for more years than I care to count and the drawbacks of Agile are numerous, especially in the Govt environment.

Please post your comments here. Comments are moderated, so they may not appear immediately
after submitting. We will not post comments that we consider abusive or off-topic.