It Was Supposed to Be a Quick Fix
· 2 min read · Tim Cooley

You pull the faucet apart to swap one washer and by the time you're done you've replaced the washer, the O-ring, and the valve seat, and rerouted a line that wasn't in your way until you moved it. What looked like one job was never one job. It just presented as one.
We had a request last year that came in exactly like that. Change the button color on the checkout flow so it stops getting flagged as broken. I said it out loud in the room, "that's a quick one," because it read like a CSS change. Three weeks later we were still in it. The button pulled a design token that a dozen other screens used, one of which had a hardcoded exception for a client contract, and fixing the flag meant touching an accessibility rule nobody had tested in over a year.
I did the thing I always do, which is say what I think in the room. What I didn't do was ask the one question that would have caught it, which was how many other things touch this. I'd been doing a worse version of asking that question for years — on the flight line if a part is "just a bolt" you still ask what it's holding, because the answer is never nothing else. I only found out later there's a name for the bigger idea, that most of what makes software hard isn't the accidental stuff sitting on top, it's essential to the thing itself, and no process makes that go away, it just tells you sooner. I recognized it. Nobody taught it to me.
What I'm still unsure about is where the line is between diligence and paralysis. If I make every quick request go through a full dependency check before anyone commits to a date, I've built a process that slows down the fast things to protect against the rare one that isn't. I haven't solved that. I still say "that's a quick one" sometimes, and I'm still sometimes wrong, and the cost of being wrong is a team that gave a client or a boss a three-day estimate that became three weeks. That's its own kind of damage, even when the fix itself was right.
If you plan software for a living, how do you tell in the room whether something is actually one thing, before you've opened it up?
perspectiveproductestimationcomplexity