The Design Dilemma

[Chinese][Korean]

Software design must resolve a set of mutually contradictory requirements. That’s why so many people can have such different ideas about design and they can all be right in some circumstances. Nothing will make these contradictions disappear. The quality of a design style depends on how the contradictions are resolved, which constraints are satisfied early and which are left for later. Acknowledging the impossibility of a perfect design style is an important first step towards designing thoughtfully.

Constraints

Here are the constraints that are impossible to resolve.

• Cost. Design should minimize the cost of development, short-term and long-term.
• Precede implementation. In particular, design should be done before implementation because features implemented with a good design can be much cheaper than features implemented with a poor design.
• Change costs. Changing design decisions can be expensive, so making design decisions once and then not changing them can reduce costs.
• Revenue. Design should maximize revenue. A design that is more expensive in the long run can be much more valuable if it delivers just the right feature for just the right demonstration to close a big sale, especially early in the life of a product.
• Time value. Cost and revenue should not simply be added up over the life of a product. A dollar today is worth more than a dollar tomorrow. Design should push costs into the future and bring revenue into the present.
• Options value. Because of the uncertainty of the business of software, a design style that maintains options for future development is more valuable than one that is more rigid.
• Requirements uncertainty. You do not know a priori what features the design needs to support. Because of this you should defer making design decisions until they are proven necessary.
• Design improves. You will learn to design better as you work. Be prepared to incorporate your learning as you go.
• Succession is the price of success. The needs of the design evolve.
• No right answer. There are generally several acceptable families of designs for a given problem along with an infinite variety of worse designs. Even the worse designs may not be fatal, at least not immediately.

Taken together, these constraints form an over-constrained system. No resolution is possible, for instance, for the observations that you want to minimize costs (you do), change costs (it is) and that you will learn as you go (you will).

In different situations these constraints will have different strengths. In some cases, the scope of features for a product is roughly known. In a well-understood domain, the team may only make minor discoveries about design. In an early stage product, the time value of money can be extreme while in a mature product its effect is more moderate. In a mature product, long-term cost drives profitability. No single set of rules for design will cover all cases. Some values and principles are common, but the practices will vary.

In general, I advocate and practice a responsive style of design. I emphasize the importance of requirements uncertainty, time- and options-value, designer learning, and succession. I defer the “change is expensive” constraint in favor of the others. I work hard in my development style to reduce the cost of change through a combination of technique, social organization, tools, and just plain practice with changing design. The result is a style that delivers results quickly at some long-term cost, but quickly switches to cost reduction when some of the uncertainty of the project is resolved.

No design style can simultaneously minimize cost, maximize revenue, and maximize options in both the short-term and the long-term. Choosing which constraints to resolve early and which to defer results in a style of design whose values and process are clear and easier to communicate. Being clear is the beginning of the conversation about design.

I will be presenting the first ever full-day tutorial on Responsive Design in Seoul on September 4 and Beijing on September 10, 2009.