How to design well by trading well and guessing well

There is a rumor going around that IT application design is some sort of scientific endeavor that proceeds logically from requirements gathering through to the production of "the design".

At least half of what I have read in this area suggests that there is something inevitable about the shape the design will take. Some perfect model of the world that needs to be found. Thereafter, or so it goes, it is a mere matter of picking a technology stack, perhaps making a few "buy or build" decisions...

The truth as I have experienced it, is significantly different. There is no such thing as the "correct" design for any given set of requirements. Rather, there are an infinite number of possible designs that meet the stated requirements. Somehow, the designer must wade through these making decisions in order to arrive at one design.

How is that decision making process structured? What does it consist of? How does one go about it? Unfortunately, this seems to be something of a methodological dessert in the industry. That dreaded concept of "experience" comes in to play in a big way. Do it for 20 years or so and you will develop good design skills for sure. Unfortunately, a twenty year apprenticeship is not sustainable given the world's dependency on IT.

Sadly, we are where we are. For what it is worth, here is how I go about it. Trade-offs and educated guesswork.

Trade-offs: For any given set of requirements, there are N possible designs that meet the requirements. In order to whittle N down to 1 (or perhaps 2 - it's always good to have a backup), you must engage in trading one thing off against another. Examples:

- Buying X will be cheaper/faster than building X but you trade off time/money against control/IP/flexibility/independence.

- Indexing X will take up more disk space and effect loading performance but will result in faster reporting/access times for X. Do you trade disk/load performance for reporting/access performance?

- Making X secure will involve adding multiple, overlapping security aspects to the design. The trade off here is ease of use/complexity versus security.

Start by making a list of the trade-offs that you see and get the customer involved in the decision making process. I like to get customers to help me craft a set of "design principles" to act as guides in the decision process without getting bogged down in details.

Some possible examples of design principles include:

- In a trade-off between security and complexity/cost, security wins.

- In a trade-off between disk space and ease of interactive use, interactive use wins.

- In a trade-off between (reasonable) capital expenditure and roll-your-own, capital expenditure wins.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine