Trade-Offs and Compromise

7/31/2011

A fundamental part of being an architect is making decisions. While we hear a lot about failing fast and often, making the right decision is obviously preferable. And choosing the high road as opposed to the low road (or vice versa) comes at a price. What's the motivation for choosing Rails over PHP? Asynchronous RPC as opposed to synchronous IPC calls? Is the time required to implement a context-sensitive menu in a tree view worth it?

Consider the following -

Trade-off triangle

This is a classic trade-off triangle. Given three requirements - resources, schedule and features, you can only ever choose two. Another example of a tradeoff triange is security, usability, and low cost.

It's worth noting that features have a fixed level of quality that is presumed to be non-negotiable. You can view quality as a fourth dimension which would transform the triangle into a tetrahedron (or three-sided pyramid). Although lowering the quality bar results in simultaneously reducing resources, shortening schedule, and increasing features, it is obviously a recipe for failure

Here are some more possible trade-offs to think about when deciding on your approach:

Leading edge   Tried and tested
Strategic   Tactical
Painful   Painless
Revolutionary   Evolutionary
Ideal   Affordable
High risk   Low risk
Big bang   Incremental

Finaly, I threw together a fun recommendation calculator while I was procrastinating over a strategy document I was supposed to be writing.



Home | Blog | Photos | Contact | About

Wittenburg.co.uk and all content copyright 1995-2017 by Michael Wittenburg, unless otherwise stated.
All content on this site is licensed under the Creative Commons license, unless otherwise stated.