Readers expound on the pro and cons of agile development

GCN’s Reality Check columnist Michael Daconta created a bit of a stir this week with his column, “6 IT trends government IT managers should be wary of.” The majority of comments posted to GCN concerned No. 3 on Daconta’s list:

“3. Agile development is a programmer’s fantasy and a manager’s nightmare. In my more than 20 years of software development experience, I have never met a government program manager who is available on a daily or even weekly basis to help design an application on the fly. Extreme iteration and pair programming are almost exclusively programmer perks and not in the best interests of government IT. Please don’t build the next space shuttle that way.”

Agile development is a term coined in 2001 by a group of 17 developers in the Agile Manifesto. The group defined the approach in the 12 “Principles of the Agile Manifesto,” among them: “Simplicity -- the art of maximizing the amount of work not done -- is essential.”

A hard-and-fast definition isn’t so simple, however. According to a definition on the Agile Modeling Web site, “Many people will correctly say that agile software development conforms to the values and principles of the Agile Manifesto, and those sites are clearly great resources. But, if you're looking for a 'sound bite' definition of agile software development, that's a little harder to come by.”

TechTarget’s definition includes: “Agile software development focuses on keeping code simple, testing often and delivering functional bits of the application as soon as they're ready.”

And the site Loosely Coupled explains: “In contrast to traditional software development methods, agile developers liaise continuously with business clients, aiming to deliver working software as frequently as every two weeks during a project, and welcome changes to the requirement in response to evolving business needs.

Definitions aside, readers had their own ideas about the value of agile development.

One veteran programmer wrote: “This is a new buzzword for an old concept. We called it ‘Rapid Prototyping,’ and that was a buzzword, too. The idea is that, unlike building a bridge, software engineering acknowledges its use in a changing environment. The idea is to incorporate cyclic development with a pace comparable to the aggregate of change in the particular application area. Engineers constantly bemoan ‘requirements slip’ and the idea that the world won't freeze while they take their time building a ‘perfect’ application. By the time that happens, the world has moved on. Requirements have to reflect that fact just as they need to reflect the constraints of the technology and the needs of the user. AND, BTW -- none of that is static, so your meta-process needs to allow for constant drift and adjustment as you build your system. The alternative is stasis, and trust me, you wouldn't like it. ...”

Another wrote: “Agile Development is just a name for the test-driven development model and that type of approach is the current standard, not a programmers dream. Maybe your team is not as advanced and into development. You may have consultants cook your sausage for you, but those developers that are being contracted to do your dirty work are using Agile Development, and if you brought it into your shop, you might save some money.”

One reader brought up a potential flaw with agile development: “If I may continue the Agile thread, there is one significant problem with this kind of development: it leaves little documentation. The Agile Manifesto puts software delivery first. Documentation and management are considered hindrances. I have worked with some of the earlier buzzwords, too. There are good points to all, but they have mostly fallen by the way-side. Agile will go too in the government sector when many agencies fail the new FISCAM audits. This new standard for security audits almost forbids some Agile practices and requires standard SDLC and governance. Its a big document but worth a read.”

Wrote another: “Developers don't bemoan when the project management is able to run a nice fence around the requirements and only simple and quick and easy inclusions can be made, that maybe where most projects have problems. You must wrap up the project and move to production when requirements have been met and maybe one or two short follow up releases to plug up the holes. Thats it, no cyclical or enhancements unless there is a justified ROI (Get value from the App). There must be a good working relationship between developers and management and the less chiefs, the better.”

This reader defended the approach: “Obviously Mike is not from Silicon Valley these days. Cisco now has a six-week development cycle for many products. BTW, if you recall, the traditional way also lead to a very expensive spacecraft hurling into a planet at high speed instead of landing on it due to a metric conversion error. May be the wisdom of the crowds approach would have prevented this.”

And finally, one reader addressed the entire column’s look at current trends: “Superb! Finally a GCN contributor that sees past the fanatic hype and gets to the objective facts of the mission of the gov and what is required to support it. I sincerely appreciated the comparison between the government and a Web start up. The startup can afford to fail; the government cannot.”