Simplicity By Default

I’ve observed quite a few instances where engineers, including myself, have created unnecessarily complex solutions. To cultivate a better R&D organization, it is crucial to choose simplicity by default. In this blog, we’ll look at three don’ts and three do’s that help make simplicity the default.

Don’t invent requirements.

Engineers solve problems, which are often made complex due to bloated or unclear requirements. Simplify by reducing requirements to a minimal set that satisfies the product. Exercise caution when phrases like the following show up.

  1. “Maybe it’s useful”. Let’s wait till “usefulness” manifest itself.
  2. “We need all the data”. When you have a clear question, you know the data you need. If you don’t know what data you need, you don’t know the questions.
  3. “We will remove it if it’s not needed”. Removing something later is more expensive than adding it later. Don’t agree? Would you give me $1M today and expect me to pay it back 1 year later? In the engineering example, it’s even worse because adding it today not only incurs the opportunity cost of delaying something more pressing but also carries the complexity until the day it is removed. It’s like borrowing money with interest and lending it without interest.

Don’t follow best practices blindly.

There is never a shortage of best practices; some even contradict each other. ‘Best’ is the superlative of good, and good is subjective. Let’s challenge conventional wisdom and popular practices before adopting them case by case. I once designed a service that generates globally unique, directionally increasing identifiers. The service utilizes etcd to coordinate a set of stateless workers and can support tens of thousands of workers. I came across this service while reading an engineering blog of a tech giant that handles tens of millions of identifier requests per second. However, the best practice behind that service does not apply to my problem.

Don’t make things complex to show you are smart.

Steve Jobs had a great comment on this in a 1996 interview. “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains. Complexity, on the other hand, is easy. Anyone can make things complicated. It takes a genius to make things simple.”

Be brutally honest about productivity.

True 10X engineers are rare, and most engineers operate at a 1X or 1.5X level. While it is possible to temporarily increase productivity by working longer hours, we all know that sustained long hours are not sustainable. Be honest about what you and your team can realistically achieve within a sprint or a month.

Know your priorities.

If there are limited engineering resources, you have to rank projects, and features and cut the ones near the bottom. What if you have abundant resources? You may have a bigger problem if not careful because managers will always invent work. So in both cases, know your priorities and focus only on the priorities.

Be open-minded to simple solutions.

If you have a tendency to over complicate things, it’s important to remain receptive to people who offer simple solutions. Challenge yourself to ask, ‘Why does John’s solution work?’ f you can come up with at least three valid reasons, give John’s solution a try.

Further Reading

  1. Overcome the Complexity Within You
  2. “Worst Practices”, from the book “It doesn’t have to be crazy at work’.
  3. Kill Overkill