I was reading an Ars Technica article today which talks about the company that designed the Microsoft Surface. The first few paragraphs focus on the specifications of the display — its size and resolution — and continually refers to the tradeoffs made between size, resolution, power needs, weight, etc.
Although the term “tradeoff” is pretty ubiquitous and I use it often myself, for some reason today I was struck by the feeling that it is inaccurate, or overly simplistic. It struck me that the word “tradeoff” implies selecting one thing over another, of going one direction versus another.
I don’t think that’s really what is going on much of the time when we are talking about tradeoffs.
The word that occurred to me this morning that was better suited was “balance”. We usually don’t have the luxury of discarding one factor totally in favor of another. Rather, we need to try and address both factors simultaneously.
Which isn’t to say we don’t prioritize, but it isn’t a simple “this is more important than that”. I think all the factors that go into a design are related in a web of relative weights. The designer’s challenge is to try to derive a global optimization of competing, mutually-dependent priorities.
Here’s a simple example: performance can often be enhanced by caching data in storage. Excellent! So if performance is most important, store data on disk. However, storing stuff on disk often runs the risk of exhausting disk-space and crashing the system. So if availability and up-time are most import, don’t store data on disk.
It isn’t that any one of these factors is simply the most important. The designer needs to weigh priorities, risks and their mitigations, development costs, etc. and create a solution that balances them all in proper proportion.
So the next time I want to use the binary word “tradeoff”, I’m going to try to identify the other factors involved and shift my thinking to multivariate “balance”.