Every production issue offers two fixes. The quick one makes the symptom go away today. The real one makes sure it can’t come back. The first always looks cheaper, until you count how many times you apply it.
How band-aids happen
Nobody sets out to build a fragile system. Band-aids happen under pressure: a client is waiting, the fix is obvious, and investigating feels like a luxury. So the wrong price gets corrected by hand, the failing job gets re-run, the odd error gets hidden in CSS. Each one is reasonable on its own. Together they become a system nobody fully understands, where every fix risks breaking something else.
Questions I ask before fixing anything
- What exactly is wrong, and since when? A precise description and a start date narrow the search more than any amount of guessing.
- What should be true instead? Write the rule down. “The price should be the preferred supplier’s, if it has stock” is testable. “The price looks wrong” isn’t.
- Can I reproduce it, or measure it? If I can’t make it happen on demand, I want a query or a log that shows every case, not just the one that was reported.
- What changed? Deployments, imports, integrations, configuration and traffic. Most problems start with a change.
- Why did that cause this? Keep asking until the answer is something you can fix in code or process, not “it just happens sometimes”.
When a quick fix is the right call
Doing it properly doesn’t mean leaving customers with a broken checkout while you investigate. Sometimes you need to stop the bleeding first. The difference is honesty about what you’ve done:
- label the quick fix as temporary, on the ticket and in the code;
- keep the ticket open until the cause is found and fixed;
- remove the workaround once the real fix is in.
A temporary fix with a follow-up is engineering. A temporary fix that quietly becomes permanent is debt.
Make the fix stick
- Fix it where it starts. If an import writes bad data, fix the import, not the data afterwards.
- Add a check that would have caught it. A test, a monitoring query or an alert turns “it happened again” into “we were told before the client noticed”.
- Write down what you learned on the ticket, so the next person doesn’t start from zero.
Why it’s worth it
Root-cause work takes longer the first time. But a platform where problems are fixed at the source gets calmer over time: fewer repeat tickets, fewer surprises after releases, and a team that trusts the code it’s changing. That is what clients are really paying for.