There's only one reason to increase system complexity

Making simple solutions is hard. Especially if you are the one implementing it. Yesterday I found a good question to ask oneself. It helps us stop overengineering.

If you work with developer, this can help you keep scope in check. And make simpler, cheaper solutions.

During the development of an MVP (Minimum Viable Product), a member of my team proposed changes to our database design. After careful consideration, we determined that the existing design was sufficient.

Why this is relevant

People, especially engineers, love to build beautiful solutions.

If you are an engineer, you probably have several things that never went into production.

• I mean the abstraction that was never used but once.
• I mean the fancy UI that’s only used by exactly one person.
• Or the database table that doesn’t add benefit.

It’s relevant because we need to focus on the main thing.

Focus. And ship.

The thing about database designs

After an inital discussion my developer and I had a solution that could work. All possible use cases for this MVP would work.

Then he wanted to add a table “Subscriptions”, for another table called “Agents”. I don’t want to go into detail here. He had good arguments for this change.

In order to keep things simple, I found a way to end the discussions fast.

It’s a valid question we can ask when a design change is being discussed.

What is this change enabling us to do, that the initial design cannot do?

If the answer is “nothing”, don’t do it.

There’s a thing about designs, of any kind. You usually design something to solve a certain problem.

Let’s say the problem has size X. Then the solution design (call it S), can never be smaller than X.

S > X

A law of nature

Building the machine around a problem will always result in a machine more complicated than the problem itself.

The inveres is true as well:

If a design suffices a certain problem: there’s no point in making the solution more complex.

I feel strongly about this.

By consistently applying this principle, teams can avoid unnecessary complexity and focus on delivering value. This approach not only saves time and resources but also results in more maintainable and user-friendly products.

If you know cases where this is not true, please leave a comment on my X account.