Both Architecture-First and Delivery-First Suck

Complex Is More Dangerous Than Simple: YAGNI And Gall's Law

I recently stumbled on the following picture by Thomas Nys* on LinkedIn:

This picture is perfect for illustrating one of the most important points of developing a great architecture.

You can’t know if your architecture is good unless you deliver it. An architecture that works and we can easily change means it must be working.

Otherwise, it’s a paper victory architecture, and we all know how that story ends.

You need delivery AND architecture. Architecture-first and delivery-first are a false dichotomy. You need both.

Over-engineering and under-engineering are equally dangerous.

In my opinion, the biggest danger in architecture is delivering over-complicated solutions. It’s much easier to make something simple more complex, than to make something complex more simple. Complex solutions are far more dangerous than solutions that are too simple.

When you deliver a complex solution, it usually means making choices that have a negative impact on reversibility and optionality. As the system grows more complex, your future choices will be inhibited and constrained by the complexity of the existing system.

We should always push for simple solutions where we have some doubts it will work, for two reasons.

1. YAGNI - You Ain’t Gonna Need It

As a Product Manager, I always push teams to deliver the simplest solution where they have some doubts it will work, assuming the decisions we make are reversible and we increase optionality. Then, if we do discover problems and fix those, we KNOW we have the simplest solution possible.

If you deliver a solution and it immediately works, with nothing to optimize, there is a good chance your solution contains unnecessary complexity which can bite you in the ass later.

I’ve seen complete projects derailed because unnecessary complexity was introduced early on in the project.

2. Respecting Gall’s Law

Gall’s Law states:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

If you do architecture-first, without quick delivery, then you’re disrespecting Gall’s law. You must start with a simple system that works. If you aim for a complex system that works, the likelihood of failure is high.

That’s why you need architecture and delivery. You only know if your system works, when it works, not because you designed it to work on paper.

You must take into account reversibility and optionality when making decisions. Once you do that, it becomes much easier to build simple systems. Because you know it’s easy to make them more complex if necessary.

Making something less complex, if necessary, is much harder, especially when you have unnecessary complexity.

*I want to stress, Thomas Nys used this picture to prove a different point and I don’t think we’re in disagreement, so don’t see this as a criticism of his perspective.