Cost of moving Fast

At the end of the year, I found myself staring at old features I shipped back at Tiki. They still work. But look closely and you can see the patches.

At checkout, there were dozens of promotion rules stacked on top of each other. Every new campaign, the team added rules fast to make the deadline. Campaign ends, rules stay. Next campaign adds new rules on top of old ones. Nobody cleans up, because nobody remembers which rules are still alive and which are already dead. Try to fix one and three others break.

Same thing at fintech. Transaction approval rules were written fast to ship fast. Ship it, leave it. A few months later, the logic was so tangled that new engineers wouldn’t touch it. Not because the code was bad. Because nobody knew what it was holding together.

It reminds me of the table I’m writing this on. My girlfriend and I assembled it in a hurry when we first moved in. One look and you know it will collapse someday. It hasn’t yet, so you keep going.

That is how technical debt survives.

Debt isn’t messy code. It’s cost pushed into the future for speed today. The future doesn’t disappear. It just arrives at the worst time.

Bugs appear. The UI gets harder to understand. Fix one thing, break two others. Engineers avoid the “sensitive” areas. The product starts paying debt instead of creating value.

Debt isn’t always bad. Ship with rough edges to catch a window. Write temporary code to make a deadline. That can be leverage. The problem is the sentence “we’ll fix it later.” That sentence rarely comes true.

Most teams fall into one of three modes. Borrow without knowing. Borrow intentionally and repay. Or pretend there is no debt and call it “prioritization.”

That last mode turns debt into culture.

My table still hasn’t collapsed. But every time I sit down, I know it’s waiting.