(English) Boring Solutions Revisited: Choose Boring Technology by Dan McKinley

Home » Blog » Business » (English) Boring Solutions Revisited: Choose Boring Technology by Dan McKinley

Leider ist der Eintrag nur auf Britisches Englisch verfügbar. Der Inhalt wird unten in einer verfügbaren Sprache angezeigt. Klicken Sie auf den Link, um die aktuelle Sprache zu ändern.

Dan McKinley’s article on choosing boring solutions, although not exactly new anymore, has been a welcome reminder for me to revisit the topic of of using boring solutions and keeping things simple.

Dan makes the point that „adding technology to your company comes with a cost“ or as I stated in my own article on this subject: „The elephant in the room is: There’s an opportunity cost to everything.“

Most choices come with a trade-off.

If you decide to use a technology for the sake of it or just because it’s popular you incur a cost without sufficient benefit to justify that cost.

Hardly anybody ever does that, of course. However, it’s easy to fall for a novel, interesting technology and subsequently seeing it as a superior solution for a problem at hand while tried-and-true technologies might’ve been the better choice.

This is especially true when indulging in what I’ve termed „nerdy non-problems“: Instead of working on the actual product and most importantly that product’s market fit engineers are often prone to spending a lot of time and energy on first implementing a perfect, “scalable” deployment infrastructure or framework for implementing said actual product.

As Dan says, „Boring“ should not be conflated with „bad“, however. There’s a wide range of technologies that are not only perfectly adequate but even superior in their respective segment but typically don’t attract a whole lot of attention or hype around them. They just work and that’s a good thing.

Dan has a few useful guidelines to consider:

  • Consider how you would solve your immediate problem without adding anything new.
  • Write down exactly what it is about the current stack that makes solving the problem prohibitively expensive and difficult.
  • Set clear expectations about migrating old functionality to the new system.

Sometimes, preferring a novel solution over a proven one indeed is the approppriate choice.

Using guidelines like these and asking yourself the question: „Do we really need this or do I just think we need this?“ can help you with making an informed decision about when to opt for a new technology and when to draw upon proven ones.

About the author: Bjoern

Leave a Comment