In-Depth

It takes agility to mash monster apps

• By Stephen Swoyer
• April 1, 2005

Proponents say agile promises to reduce creation of Frankenapps because the requirements of an agile app aren’t defined ahead of time, as they are in the traditional waterfall approach. Instead, agile programmers typically solicit feedback from customers on a periodic (daily, weekly, or bi-weekly) basis, which lets them incorporate new features as customers demand them—or change features based on feedback from users.

This means there’s a good chance the final software deliverable will address the timely business requirements of the customer. The same can not be said for waterfall, largely because there’s often a gulf—what T.S. Eliot might call a shadow—between a developer’s idea and a customer’s reality.

“The way most software projects run, the only tool they give management is control,” says Roy Miller, XP programming consultant, XP enthusiast, and author of Managing Software for Growth. “We’re going to start with this plan. We’re going to control things to stick to the plan, but that’s like trying to put your software development on rails, like a train. You’re going to get from point A to point B, but what happens—when you’re halfway to point B—you see where you really want to go is 100 yards over to the right?”

Not all programs begin as Frankenapps. Most Frankenapps gestate over time, growing additional heads each time someone—a line-of-business customer, a C-level executive, a third-party customer—requests a new feature, function, or service. So even if the agile methods help Franken-proof apps near term, they by no means insulate them against future unwieldiness.

At the same time, most agile methods have built-in assumptions about the software maintenance lifecycle. In this respect, even non-agile practitioners agree, conventional methodologies could learn from agile’s insistence on frequent or periodic code refactoring. “I’d prefer to rewrite things every three to five years, because after five years, your requirements for the original situation must have changed or you’re living on an island somewhere,” says Peter Scott, president of software development consultancy Pacific Systems Design Technologies, and author of Perl Medic: Transforming Legacy Code. Adds Scott: “And when you design, always design with the expectation that you’re going to have to refactor, and also that there will be better tools available to you within a year.”

Ron Jeffries, an XP enthusiast and programming consultant with Object Mentor, is by no means an agile champion when it comes to Frankenapps. Nevertheless, he believes the use of agile methods can help mitigate the severity of application unwieldiness over time.

“Any process that keeps the design clean will result in a design that can be more easily improved,” he says. “Agile methods, used appropriately, will, by definition, keep the design cleaner than the one-stop design approach conventionally recommended by waterfall-ish folks,” he argues. “So yes, agile methods properly applied will produce code that is more readily improved than will an approach that does design at the front.”

Even so, Jeffries acknowledges, an agile approach to solving legacy code problems may not be for everyone. “A random team out of the blue can’t just do agile. Agile requires technical skill, management skill, organizational commitment, [and] a whole host of things that people must know and do,” he stresses. “It’s a good way, but it’s not a magic wand.”

Back to feature: It's Alive! The Frankenapp Runs Amok!