Simplicity is invisible

When a design is genuinely simple, it tends to feel obvious. It reads as the natural solution, the kind of thing anyone would have reached for. You move through it without thinking, which is exactly the point, and also exactly why simplicity is so easy to miss. Even if took a hundred steps of refactoring to get there.

Complexity does not have this problem. You feel it immediately. An elaborate class hierarchy that needs a diagram signals effort. Whether that effort was necessary or self-inflicted is another question, but the struggle is visible and it is felt.

Unfortunately, where simplicity hides the struggle or skill it took to achieve, complexity might look impressive and even be recognized and celebrated as a job well done. This is a known phenomenon in software and well beyond it. Hindsight makes good decisions look inevitable. It collapses the space of alternatives that were genuinely open at the time and replaces them with a sense that the right answer was always obvious. The engineer who found that answer gets less credit than the one who built an elaborate Rube Goldberg machine, because the complicated solution suggests “This was a difficult problem, but I pulled it off!”.

There is also a subtler incentive at work. A system that is difficult to understand creates ongoing demand for whoever understands it. The engineer who introduced the complexity becomes essential to navigating it, which is a form of job security that simpler systems do not provide. The engineer who prevented unnecessary complexity from accumulating in the first place is easy to overlook, because there is nothing difficult to point at. This is not an argument for complexity, but it is worth being honest about: the way teams measure contribution tends to reward visible effort, and simplicity is very good at hiding the effort behind it.

So what do you do about recognition?

One approach is to make the invisible work visible. Capture discarded designs in brief notes or design docs. Show the trade-offs that led to the simpler solution. Not a full history, just enough to demonstrate that the final form was discovered and chosen, not stumbled upon. Another is to anchor recognition in outcomes. Simpler designs tend to have fewer bugs, clearer ownership, and lower maintenance cost. Pointing to those properties shifts the conversation from how hard something was to how well it works.

The other side of this is learning to recognize simplicity in the work of others. When something feels frictionless, it is worth asking what constraints and decisions made it that way. The absence of friction is not a lack of effort. It is often the result of it.