Quick and dirty design – thoughts

by daniel on March 10, 2009

Last week I got a call from a past coworker, asking for design guidelines and comparison between storage vendors. The question itself does not surprise me, but he wanted the information distilled into a few sentences, so it can be presented to management for decision taking.

The situation raised a question; can design be done quick and dirty?

The Agile process promises shortening development time by leaving the waterfall method of design up front, and instead do it on the move while coding. YAGNI promises limiting the design only to parts really used and KISS provides a sound reason for doing it simple. To put it in a few words, the processes above try to replace the waterfall model with something interactive, where design changes with the experience learned while coding and allowing for maneuver room as requirements change.

What do I perceive as a problem in the agile processes?

  • Design in parts can corrupt the conceptual integrity and provide very limited concepts at the start
  • Technical debt due to development done according to limited design
  • Limited infrastructure design can lead to architectural changes along the way

Should one or more of these problems occur, the presumed gain in time will be lost due to architectural modification and probably code rewrite.

Are there other options? Or just Agile vs. Waterfall?

I believe that the extremes are too extremes, that some compromise should be taken. And this is where I concur with Joel, on having requirements and initial design up front. Agile processes can be then used for low level design and coding when the gross conceptual framework is already defined.

Would I be in my coworker place I would take time to design the main components of the system, while analyzing the requirements deeply. These are the major components that need attention and not use snippets of information for decision taking.

Comments on this entry are closed.

Previous post:

Next post: