Ken Orr wrote ( in Cutter IT Journal Vol.3, No. 7 ):

Agile . since Jun 23 . Index . DOCs TOP TOC

Comments on Minimalist Design and Refactoring


Deliver quickly. Change quickly. Change often. These three driving forces compel us to rethink traditional software engineering practices.

-- Jim Highsmith

One of the more controversial concepts underlying all of agile development is the idea that the product (prototype) should be developed by taking into account only those things the user currently wants and are specified for the current release. This is a controversial idea because it seems to many experienced managers and developers as simply an extreme form of hacking. Rather than see this as an essential ingredient within an overall project philosophy, many managers see this as simply a way to avoid real, long-term requirements and design consideration.

The defense that the application developers give for working only on the things that they know right now is that if one begins to consider future (unknown) requirements rather than current (known) requirements, there is no easy place to stop. When you're thinking about all the different ways this product may be used in the future, do you stop at three, five, or 10 years in the future? And since you are, after all, guessing about what those future requirements might be, there is a good chance that you will guess wrong. Agile developers maintain that it is better to focus on what you know, and be prepared to change.

Personally, I have always favored a minimalist approach. As it turns out, the methodology that my colleagues and I evolved back in the distant past worked in large part because, like agile development, it was both minimalist as well as highly incremental. So an approach that involves designing each increment just for what you know at that particular point in time has special appeal. Over the years, this design strategy has helped my colleagues and me create systems that are much easier to understand, design, and implement.

Our approach, like that of agile development, is that when you develop the next increment of an incremental project, you take the new, modified requirements and do a complete redesign, integrating the new requirements with the old. In agile development, this is not called redesign, it is called refactoring, but it amounts to the same thing. Clearly, then, whether this approach is successful over the duration of a large project is a function of how good you are at refactoring.

The trick to having a clean, elegant design in an agile development environment is to build things in, not add things on. In practice, this grows more and more difficult as the size of the program gets bigger and bigger and pressures to finish the product/system grow.

Agile . since Jun 23 . Index . DOCs TOP TOC

Comments on the Agile Manifesto


If you talk to the people who signed the Agile Manifesto, you will find that they are by and large proud it. They might not be as committed as say the framers of the US Declaration of Independence, but the statement reflects what they think is important.

On a second level, the Agile Manifesto achieved another, perhaps unstated goal, which was to draw a line in the sand. Here, the authors said, we're in favor of people, working software, customer collaboration, and responding to change -- take that all you folks using heavy, rigorous management methods (e.g., users of CMM)! It was clearly a way of getting people's attention -- and it worked. Like everything else involved with agile development, I think that it was very carefully thought out, but as a propaganda piece, it may go down with "loose lips sink ships."

My quarrel with the Agile Manifesto is that, in the long run, it creates, or seems to create, artificial barriers to future improvements in the software development process. I believe, for example, that for something like agile development to be adopted widely and really affect software productivity and quality, it will be necessary to place as much emphasis on rigor, documentation, and tools as we do on people, collaboration, and working software.

Some forms of refactoring, namely data refactoring, are simply too complex to be done by hand, no matter how skilled the practitioners or how good the team. Saying that we value people over tools deemphasizes the development of tools that make agile development work better, faster, and cheaper.

Tactically, I think that issuing the Agile Manifesto was a good idea. Strategically, I think that having drawn a line in the sand, the agile development folks may have to stand on the wrong side. Over the long haul, individuals and interactions are not opposed to process and tools. Neither is working software necessarily at odds with comprehensive documentation -- documentation using the right tools should be a byproduct of producing working software. Neither is customer collaboration necessarily at odds with contract negotiation, though here I'm inclined to give the agile developers some slack on this issue -- contract negotiation is usually a lose-lose activity. Finally, responding to change is not fundamentally opposed to following a plan.

Now the agile development folks will say that they never said they were against tools and processes, just that individuals and interactions are more important. Granted! But there are few generals in the world who wouldn't rather have a group of relatively untrained recruits with rifles against the most skilled folks with bows and arrows. Civilization and software operate at many levels; major advances in civilization often result from seemingly simple advances in technology.

Agile . Index . DOCs . TOC