Tradeoffs
A theme that keeps coming up in our conversations on Beats, Rye & Types [1] is the idea that tradeoffs are an integral part of computology.
What I’ve begun to realize is that at the core of my frustrations with the obsessions with the latest framework and the constant need to burn down the past is that people tend to overlook the underlying choices they’re making when choosing technology.
All of my opinions on this can probably be summarized as: Awareness of the tradeoff’s you’re making is the most important part of your work.
Tradeoff-awareness goes both ways: It’s as crucial when you’re advocating as when you’re nay-saying. It means knowing that when you pick an untested or young technology, it might have problems at a later date. The key is accepting the risk in exchange for the “new-tech smell” and being aware that you made that choice[2]. Having faults is not a critical bug - there is not a single thing in the universe that doesn’t have some sort of issue[3]. Having perspective and knowledge of these limits allows you to address them and move on.
I love Ruby and I’m also fully aware that choosing Ruby for a project trades my familiarity and the ease of use with it’s performance and resource usage at a certain scale. I also love Go and I’m aware that I’m trading performance and concurrency for some of the speed, familiarity, and [over-]abundance of libraries and tools. Having an in-mind index of as many tools as possible and their strengths and weaknesses helps me pick the right tool for the current job.
-
Especially in this episode about Magic ↩
-
@aphyr has been doing a great job recently of outlining the issues with different distributed databases while not negating their merits entirely and recommending them in terms of tradeoffs. ↩
Subscribe via RSS