May 16, 2008, 2:56 PM — 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.
Educated guesswork: No amount of design principles will be the full answer. When designing an application in the modern world, there is no escaping the volatility that exists all around us. Like it or not, we have to make guesses about the future to inform our design decisions.
Some examples:
- If we code the custom parts in X, will X still be a viable technology in 3-5 years? Will X change dramatically in that period resulting in upgrade nightmares?
- How solid is development platform X? Every platform has bugs. Does X have any that will cause us grief? If so, what is the likelihood that they will be fixed in time for the design to benefit?
- How easy is it to get good development resources for X? Is it a niche technology (not necessarily a bad thing!)? Is X itself so volatile that the smart folks currently working on it are likely to change it dramatically soon? Or (equally serious in some cases), is X so stable and "boring" that the good people are going to move on to fresh challenges?
- Will the operating system you are choosing survive? What are the chances of a viable upgrade or porting strategy?
- Are you dependent on any hardware "gadget" that might fall victim to short life? Maybe a cell phone model or a particular game console?
- If you take steps to avoid hardware dependence, what will the impact be on the complexity of the design and on the quality of the user experience?
And on and on it goes. Trading things off against each other as best you can. Guessing the future in a very volatile space, as best you can.
It ain't easy. It ain't very scientific, but I have not come up with anything better. If you have, let me know!
