Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Sunday, July 17, 2005

How much design is enough?

The death of design in agile development projects has been greatly exaggerated.

Although there are new and interesting schools of thought on how and when design gets done, rest assured, agile projects still do design, at least if they expect to succeed. Martin Fowler writes on this subject, and concludes that it's just complete design up front that's fallen on hard times in the agile movement.

The so called "Big Design Up Front" approach to projects is the idea that everything about a software effort can be planned and designed before any coding begins. This model compares software to building construction or electronics. The problem with this approach is that even building and electronics manufacturers run into problems well after the "perfect" design has been handed down. The reason these other industries try to get the design close in the beginning has more to do with the timing and cost structure of mass producing or working with multiple subcontractors. Changing requirements, advances in technology, and the makeup of a team can all affect your system design over the course of a project.

XP and other agile methodologies argue that software is "soft", and can benefit from this by allowing more iterations, gathering feedback, and improving the design incrementally. Why pretend to know all of the answers today, when you'll know more tomorrow?

So does this mean that we shouldn't do any design when working in an agile environment? Of course not. It just means that we can design for what we know about today, and stay disciplined enough to go back and modify the design if we learn something new tomorrow. If we rapidly iterate, then the temptation to add extra layers and extension points before they are needed is reduced, and we'll wind up with less code to maintain when we're done.

As an example of the forces involved, consider a development environment that requires a 4 hour compile before letting you test the code you've written. Developers in this environment will naturally try to do multiple things at once, and to get it right the first time to avoid a long wait. Now if the software finally starts working after several dozen of these cycles, is it more or less likely that the developer will go back to clean up minor internal problems?

Imagine also a software lifecycle that dictates 2 years between releases. Customers in this scenario become very demanding for their pet feature, since they know it will be a long time if they miss the window of opportunity. Are they more likely to be willing to wait if they know they've got another chance in 6 months? Or even in 3 months?

Design works the same way. If we as developers are expected to "get it right the first time", we're more likely to add every bell and whistle (architecturally speaking) possible, even if we probably won't need it (I can hear the discussion now: "But what if one of our beginning users wants to integrate our word processor with his dishwasher...we should add a macro language and an X10 interface just in case that ever happens"). So we want to just design the feature we're working on today, keeping the big picture of the system in mind. At any time the system design should reflect what the system actually does, not what it might need to do someday.

Now, this isn't an excuse to avoid designing at all and just hacking together a sloppy program. XP talk about merciless refactoring to keep the code as elegant as possible the entire time, but incrementally so. So that's really a way of doing incremental design once you know more about the problem. The refactoring step is absolutely critical to supporting an incremental design approach. Refactoring isn't just about code, it's also about the system design. If you decide not to use a database, but then when implementing a feature discover that it will take twice as long to build without one, it's time to take a hard look at that decision.

A simple rule of thumb: If it costs more to design a feature than the customer is willing to pay for it, you're probably doing too much design.

For more on agile development tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • Great article. It's so easy to paint methodologies with black and white criticisms when in fact the real truth is so much more subtle and so wholly dependent on the people involved.

    By Anonymous Anonymous, at 5:05 PM  

Post a Comment

Links to this post:

Create a Link

<< Home