Don't make big decisions, make big decisions irrelevant
Monday 10 December 2012 11:42
We're often faced with decisions that we'll have to live with for a long time. What language should we write our application in? What framework should we use? What will our architecture look like? We spend lots of time and effort in trying to find the right answer, but we often forget the alternative: instead of making this big decision, could we make the decision irrelevant?
Suppose you need to pick a language to build your system in. This is tricky since it often takes months or even years to discover all the annoyances and issues of a language, by which point rewriting the entire system in another language is impractical. An alternative is to split your system up into components, and make communication between components language-agnostic, for instance by only allowing communication over HTTP. Then, the choice of language affects only a single component, rather than the entire system. You could change the language each component is written in one-by-one, or leave older components that don't need much development in their original language. Regardless, picking the “wrong” language no longer has such long-lasting effects.
This flexibility in language isn't without cost though – now you potentially have to know multiple languages to work on a system, rather than just one. What if there's a component written in language that nobody on the team understands anymore? There's also the overhead of using HTTP. Not only is an HTTP request slower than an ordinary function call, it makes the call-site more complicated.
Making any big decision irrelevant has a cost associated with it, but confidently making the “right” decision upfront is often impossible. For any big decision, it's worth considering: what's the cost of making the wrong decision versus the cost of making the decision irrelevant?
Topics: Software development