“We need to improve our error routing to target individual engineers based on the line of code that raised an exception and who is on the git blame,” an engineer explained to me. I could see that he already had a few diet pills in hand.

I’ve needed a term nice term for the things that seem like an easy fix or an improvement, but instead just make a complicated system more complicated. I’m using the phrase Diet Pills. All engineers are susceptible to ingesting a few, even the most vigilant.

Diet Pills are the ideas or solutions that paper over existing problems rather than fixing a core issue. While at the outset they seem like a solution, they inevitably make things worse over time. It’s as if I can hear my father’s voice in the back of my head saying, “…and now you’ve got two problems!”

When it comes to software engineering, these come in a few forms. Here are a few I’ve seen throughout the years:

  • Adding concurrency mechanisms to eventually consistent systems. It’s hard to reason about distributed system and data that eventually gets there, so let’s just add a lock! Failing to embrace the nature of distributed systems can work at small scales and then really blow up down the line.
  • Investing a lot of time into error routing and reporting. Some novelty in error routing at different scales of engineering organizations is required, but at a certain point we must ask “Why are there so many errors?”
  • Coming up with a test flake retry heuristic to retry non-deterministic tests when they flake (i.e. fail). If our tests generate random output, what value to they bring to us?
  • A new technology being introduced to patch an existing, faulty technology. What would it take to fix the old technology to not be faulty?

Whether it’s software or the human body, the diet pill solutions exist and are enticing because they appear to solve the problem. But these are very complicated systems we’re dealing with. Every action has tradeoffs. Here’s how I identify diet pills in my day to day:

  • We have acknowledged there is some experience or metric we’d like to improve.
  • There are multiple solutions available, with varying costs (usually in the form of time).
  • The naive thought seems to be high cost (“doing it right”), the low cost solution seems easy but has unknown side effects (“diet pills”).
  • If you were just looking at costs and the metric for improvement, you would always choose the low cost solution.

Hopefully this helps your teams navigate technical change. Oh, and watch out for those amphetamines.