Are Agile Methods and Reusable Components Incompatible?

© Conrad Weisert, Information Disciplines, Inc., 2 October, 2010

This article may be circulated freely as long as the copyright notice is included.

The long struggle

A number of middle-aged colleagues have retired from the computer field because they're burned out, "I'm sick of fighting the same battles year after year with new crops of people," one of them recently confided.

One of those never-ending battles is about re-usable components. Every time we're sure that the software development field has finally grasped the huge advantages offered by component libraries, we discover more programming organizations where the concept is virtually unknown.

Most valuable methdology

Of all the decades-long series of major dramatic breakthroughs in software development methodology, a case can be made that re-usable components make the greatest contribution to both productivity and quality. In an organization that supports a mature component library, each project should draw upon that library for more than 30% of the code in a new application. That's code that doesn't have to be written and that is likely to be bug-free and acceptably efficient.

Furthermore, programmers working in such an organization form the habit of thinking in terms of highly modular program structures. They're likely to contribute new components to the library, and they're inclined to avoid redundant coding within their own projects.

Enlightened organizations have known that since the 1960s. At first, the library components were mostly individual subroutines. When object-oriented programming became the mainstream, complete class definitions became common library items. Yet after a half-century only an elite minority of software development organizations support a reusable component library and encourage its use.

Impact of agility

In my consulting work I've visited a few organizations that practice so-called agile development methods, I've examined software that's been developed through agile methods, and I've heard dozens of presentations by enthusiastic extremos1 about the wonders of agility. So far, not a single one of those organizations has supported a component library, not a single one of those projects has drawn upon an in-house component library, and not a single one of those enthusiastic presentations has mentioned component re-use.

Is that coincidence? Does "agility" discourage re-use? Does re-use discourage agile methods?

Although I don't have enough data to answer those questions with confidence, a few relationships are clear:

  1. We noted back in 2002 that the extremos' YAGNI (You Aren't Going to Need It) notion promotes the development of modules having incomplete functionality. While such modules might serve the immediate need of a single project, they would hardly be suitable as contributions to a re-usable component library.

  2. The extremos' notion of emergent specifications, where a programmer in consultation with a sponsoring user alternates between doing a little coding & testing and refining the problem definition, makes it easy to overlook opportunities to use existing components that might have been obvious during a thorough design.

  3. The extremos' need for frequent refactoring (tidying up a sloppy premature design) may distract the designer-programmer from perceiving opportunities either to use existing code or to contribute useful new components.

Note that I am not claiming that agile methods preclude exploitation of re-usable components or vice versa, so please don't fire off angry notes citing counter examples. I'm sure that it's possible to combine the two practices in a disciplined and effective manner. I just wonder why hardly anyone does.

Running out of patience

Unlike my colleagues who've given up after a long struggle, I'm not ready to concede. A library to which programmers can contribute and from which they can retrieve re-usable components is an absolutely essential part of the infrastructure of any serious software development organization, regardless of the organization's other methodology choices.

If your programming organization hasn't established one with clear procedures for accepting contributions and disseminating access, and if your organization's software development methodology doesn't strongly encourage using it, then your orgnization can't claim to be in the forefront of enlightened professionalism. It's not hard and it's not expensive.

1—The term used by some insiders for committed practitioners of agile methods. See this book review.

Return to IDI home page
technical articles
methodology information.

Last modified 8 October, 2010