I’m rather conservative about the tools that I choose to use. I don’t always go for the new shiny toy buy rather the one that’s been battle-tested and is seemingly stable. I didn’t quite have a name for this and so, I was quite happy when I bumped into the idea of “Choosing Boring Technology” by Dan McKinley.
While he’s talking mostly about software development, I think the same idea can be applied to infrastructure work. So I just thought it would be worth distilling his ideas into a few maxims that would be easier for me to remember.
The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
The problem with “best tool for the job” thinking is that it takes a myopic view of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible.
New technology choices might be purely additive (for example: “we don’t have caching yet, so let’s add memcached”). But they might also overlap or replace things you are already using. If that’s the case, you should set clear expectations about migrating old functionality to the new system. The policy should typically be “we’re committed to migrating,” with a proposed timeline. The intention of this step is to keep wreckage at manageable levels, and to avoid proliferating locally-optimal solutions.
Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.