What if we used salt instead of sugar?
Strip out the abstractions that make the system feel runnable. If the parts underneath can't stand on their own, the sweetness was hiding rot.
There is a moment in the life of every codebase when it starts to feel real. The framework is humming. The data is flowing. The deploys are deploys. You look at it and think: this works. We have built a thing.
I am here to ruin that moment for you.
What you are looking at is probably not a working system. What you are looking at is a system that has been made runnable by a thick layer of sugar. The sugar is doing more work than you think. Some of it is load-bearing. Some of it is holding up walls that should have been foundations. And the only way to find out which is which is to swap the sugar for salt.
The diagnostic
Here is the proposal. Take your system. Identify the things that make it feel easy: the framework, the conventions, the shared mental models, the assumptions about what is “standard,” the happy path, the tooling that quietly handles the mess you never look at. Call all of it sugar.
Now imagine you remove one piece of that sugar. Not because you want to ship without it. Not because you are some kind of puritan. But as a stress test. As a way to see whether the rest of the system stands on its own, or whether it collapses into a pile of assumptions that were only ever true because the sugar made them true.
If it collapses, you have found rot. If it stands, you have found something real.
Engineering is not the architecture
This is the distinction I keep coming back to. Engineering is not the same thing as the architecture of the work being done. The architecture is the shape. The engineering is whether the ingredients can carry the weight.
You can have a beautiful architecture — layers, patterns, abstractions, all the boxes and arrows you want — and still have a system where no individual part can justify its own existence. You can have a system that looks engineered and is actually just a house of cards with excellent interior design.
The building blocks have to matter. The ingredients have to carry weight. A framework cannot be the reason your domain logic exists. A convention cannot be the reason your boundary holds. A shared assumption cannot be the reason your system does not fall over. Those things can help. They can make the work easier. But they cannot be the load-bearing structure.
When they are, you do not have engineering. You have insulation. Insulation feels like engineering because it produces a running system. You can demo it. You can ship it. You can write tests against it. But insulation does not make the underlying structure sound. It just makes the temperature comfortable enough that you stop asking whether the walls are load-bearing.
The regrowth test
Think about an amphibian. Cut off its tail or a limb and the body keeps functioning. It is not ideal. It is not the aim. But the organism does not die on the spot. It adjusts. It reallocates. And when the conditions are suitable, it regrows what was lost.
This is not a practical requirement for software. I am not saying your microservice should literally regenerate a failed dependency like some kind of digital salamander. But the underlying principle matters. The design should be self-standing enough that losing one component does not cause the whole system to drop dead on contact.
Too many systems are built like Jenga towers. Pull one block and the thing tips. Not because the block was load-bearing, but because the blocks were never really independent. They were leaning on each other in ways nobody mapped. The architecture looked clean on the diagram because the diagram did not show the hidden dependencies.
The towers stood long enough
Here is a darker, more useful image. When the twin towers were hit by the airplanes, they stood long enough for quite a few people to get evacuated. The question was never whether the towers would fall or not. The question was how long they could stand and how many could be rescued.
That is the system design that should be the aim for the developer too.
It might seem impossible. Software feels fragile by nature. One bad deploy, one corrupted dependency, one cascading failure, and the whole thing goes dark. But there are ways to make sure that when the impact comes, the system does not immediately die.
Error handling with proper error notifications instead of just a 404 and a prayer. Soft close of ongoing, on-the-fly operations in a storage system when power is disrupted, so nothing is left half-written and inconsistent. Redundancy in servers and storage systems so one failure does not become total failure. Deterministic systems taking over for undeterministic ones when the latter go down, so the machine keeps serving the parts of the work that do not require guesswork.
The argument is not about being strong enough to avoid a nuclear disaster in terms of systems design. That is fantasy. The argument is about being prepared for it. About pressure testing the system down to each component individually, even when that takes valuable dev time. Especially when it takes valuable dev time.
The defensibility test
After you pressure test a component, ask one question: can this part justify its own existence?
Not “does it make the system easier.” Not “does the team like it.” Not “is it idiomatic.” The primary question is whether the part would still deserve to exist if the sugar were gone.
If a layer only exists to make another layer bearable, neither layer is defensible. Both are part of a mutual-aid society of abstraction. They are holding each other up like drunks leaning against a wall.
If a feature only works because five other features are propping it up, you do not have five features and a sixth. You have a single fragile organism with six heads.
If a design decision cannot survive the question “what does this actually do on its own?” then it is not design. It is decoration. And decoration is fine in a room, but it is dangerous in a system.
Failure is the point
Some systems will fail the salt test. This is not a failure of the method. This is the method working.
The point is to find the cracks on a test bench instead of in production. The point is to know, honestly, which parts of your system are structural and which parts are decorative. The point is to stop conflating it runs with it works.
I know engineers who get angry at this exercise. They say it is artificial. They say nobody deploys without the framework. They say the salt version is not realistic. They are missing the point. The salt version is not a proposal. The salt version is a mirror. It shows you what you look like without your costume.
If you are afraid to look, that is information too.
Where this stops being useful
There is a version of this practice that becomes puritanical. Refuse all sugar on principle. Strip every abstraction. Hand-roll everything. Reject anything that makes development pleasant. That version is not engineering. It is aesthetic asceticism. It is performance art.
The point is not to live without sugar. The point is to know which sugar is taste and which sugar is structural concealment.
Taste sugar is the sugar you chose because it makes the system better: cleaner, faster, safer, more maintainable, more humane to work in. Structural-concealment sugar is the sugar you depend on because without it, the system would fall apart. The first is a choice. The second is a confession.
You want to maximize taste sugar and minimize structural-concealment sugar. The salt substitution is how you tell them apart.
The hard part
The hard part is not the technical work. The hard part is the honesty.
It is embarrassing to discover that a layer you defended in meetings, a pattern you championed, a tool you identified with, is actually sugar hiding rot. It feels like a personal failure. It is not. It is normal. Every system has rot. The question is whether you are willing to smell it.
The engineers I trust most are the ones who will do the salt substitution in public. They will say, I thought this layer was load-bearing, but when I removed it, nothing changed. I was wrong. Let us delete it. That is not weakness. That is the strongest thing an engineer can do.
So what
You do not have to stop using sugar. I am not asking you to live in a cave and write assembly by candlelight. Sugar is good. Sugar is civilization.
But know your sugar. Name it. Test it. Every once in a while, imagine removing it and see what survives. Because the system that runs only because it is sweet is not a system that works. It is a system that has not failed yet.
And failure without warning is the most expensive kind. Better to find the rot in the test kitchen than to serve it at the table. Better to know, before the airplanes hit, how long your towers can stand.