JEDUF

Agilists tend to down play traditionalists reliance on Big Design Up Front (BDUF) and they are right. More often than not, Big Designs without underlying code that demonstrate it actually works and integrates well prove to be a waste of time.

However, that does not mean not to do any design up front--as indeed several people have articulated this (see, for example, Lidor Wyssocky, Keshav, Robert Watkins, Jonathan Kohl and others).

Now some projects allow for no design up front (for example, see Bowling example by Robert C. Martin and Bob Koss). However, I think many projects will greatly benefit from some design up front. How much design you ask? Ah, that's easy--just enough. Hence, Just Enough Design Up Front (JEDUF).

Of course, at the application level it depends. If you are building a safety critical DO-178B certified project, that can mean quite alot. Nevertheless, normal IT projects don't need that much up front design. You should probably spend some time thinking about the system's quality attributes. Analyse them until you can think about them as scenarios in your application; for instance, a perfomance requirement can be written as "Under normal operation, perform a database transaction in 100 miliseconds" or "Under normal or stress conditions, a critical alert generated by the system will be displayed to the user in less than 1 second." The nice thing about expressing quality attributes as scenarios is that it is relatively easy to code a proof-of-concept (or an XP Spike) to check options for actually fulfilling them. The Up Front design occurs when you try to prioritize, integrate, and balance the (sometimes conflicting) requirments of multiple quality attributes to create an integrated architecture that fits your project.

When it comes to class level design, I agree with Lidor Wyssocky. I think you should be pragmatic and apply common sense (well, if you are just starting out with TDD, you probably want to be a little more dogmatic about it so that you would aquire the habit). Also if you solved a similar probelm in the previous iteration or project you can apply a similar solution. The same can be true at the package or module levels.

The point is that is value in design and there is no need to tackle every problem as if it is the first time you see it. You can save time by relying on your past experience.

By the way, this example also shows why a PDOM (problem domain object model) is problematic when it comes to modeling the solution space--but that's another story.

Posted by Arnon Rotem-Gal-Oz at 06:42 AM  Permalink