Imagine an assembly line building cars. At what step do the doors get painted? Probably before they're attached to the car.
Suppose you follow it down the assembly line and find two, maybe three points where the car is inspected to see if the doors are painted. 1/?
Suppose you follow it down the assembly line and find two, maybe three points where the car is inspected to see if the doors are painted. 1/?
If the car arrives at that step and the doors aren't painted, they get painted then. Maybe that happens when the fuel cap is attached, or when the tires are put on, or both. Maybe once in a while the doors get an extra layer of paint. 2/?
That might sound like a good thing. It means they're taking extra steps to ensure that a car never leaves the assembly line with the doors unpainted. But do you see the problem with that process? 3/?
It means there's probably a step at which the doors are supposed to get painted before moving along, but sometimes the doors just don't get painted, and the problem in that area hasn't been addressed. 4/?
Unless there's something incredible clever going on, it means that doors weren't getting painted, no one found out why, and now they're just guessing, checking at whatever points seem convenient, and doing what should have been done before. 5/?
In other words, they don't know how their own assembly line works anymore. Imagine the chaos if they try to fix a defect. Someone might try to figure out when the door gets painted, identify where it happens, and change something, not knowing it also happens in other places. 6/?
That is a sign of runaway complexity, and it happens in our code too. In particular it happens when we allow the application to enter an invalid state (the doors have been mounted on the car but not painted) and instead of fixing it, we add steps to make up for it later. 7/?
There might be a valid reason for doing that. But often it means that we just didn't figure out the initial problem and fix it. It might be a sign that that code was already too complex, so it was easier to add something in later than figure out what was wrong. 8/?
But now our problem is worse. If we didn't understand it before, now we understand it even less. We've got redundant processes happening, confusing other developers and ourselves, and we don't even know when, why, or if they're needed. 9/?
If we keep our application in a known, valid state, we can understand it. If we don't do that, it enters a state where we likely don't know what's going on, and it only gets worse from there as it grows and more developers work on it. That's a bad place to be. 10/10
