It was a Thursday afternoon when the Teams message came in.
A bug in production. A date formatting issue causing checkout to fail for users in cer...
For further actions, you may consider blocking this person and/or reporting abuse
I’d push back on the ‘quick fix = bad’ framing. the 12-minute fix was the right call - broken checkout, paying users, you patch it. the real bug was six months later when it got copy-pasted into four other places.
Completely agree, the 12-minute fix itself wasn’t the problem.
In production incidents, especially on critical paths like checkout, restoring service fast is often the correct engineering decision.
The real cost appears when the temporary workaround silently becomes “the architecture” because nobody revisits it afterward, exactly like your copy-paste example.
That’s actually the distinction I was trying to make in the article:
A quick patch with a follow-up ticket, visibility, and a planned cleanup is healthy engineering. A quick patch that survives for years and spreads through the codebase is where long-term velocity starts to erode.
Your example captures that perfectly.
right on both — though I'd push back slightly on the framing that intent is what matters. teams that intend to revisit still don't, because the checkout patch works fine for 7 months until you try to add a new payment method. the workaround becomes architecture before anyone calls it that.
That’s a really important distinction.
A lot of teams do intend to revisit temporary fixes. The problem is that software systems reward whatever keeps working in the short term. Once the incident is over and the metric recovers, the patch stops feeling temporary, even if everyone originally treated it that way.
So you’re right: intent alone isn’t enough protection.
What actually seems to matter is whether the organization has mechanisms that force temporary decisions back into visibility:
Without those, “temporary” naturally hardens into dependency.
And the dangerous part is that it usually doesn’t fail immediately. It fails later, exactly when the business needs flexibility, like adding a new payment method, supporting regional logic, or scaling throughput. That’s when accumulated shortcuts suddenly reveal themselves as architectural constraints.
So maybe the better framing is:
quick fixes are operationally necessary,
but systems need deliberate pressure to prevent them from fossilizing into architecture.
the naming moment is the tell - when someone writes it into the runbook as 'our approach to X' you know the window closed. it's not a patch anymore, it's architecture.
Exactly!
This hits a problem almost every engineering team eventually faces: optimizing for immediate delivery at the expense of future velocity.
What makes “it works” dangerous is that the cost is delayed and invisible at first. The feature ships, everyone moves on, and only months later do teams realize they’ve created a system that’s harder to change, harder to debug, and harder to trust.
I especially agree with the idea that long-term speed comes from maintainability, not shortcuts. Sustainable engineering isn’t about perfection — it’s about leaving the codebase slightly easier for the next person (or future you) to work with.
The best teams I’ve seen treat quick fixes like loans: sometimes necessary, but always tracked and intentionally repaid.
Really appreciate this perspective, @lucaferri.
You explained perfectly why this mindset becomes so dangerous over time: the consequences are rarely immediate, so teams often don’t notice the impact until the codebase starts resisting every change.
I also like your comparison between quick fixes and loans. Sometimes they’re necessary, especially under pressure, but the important part is acknowledging the debt and planning to pay it back intentionally instead of normalizing it.
Completely agree as well on sustainable engineering not being about perfection. In many cases, even small improvements in readability, structure, or maintainability can compound into huge gains for the whole team months later.
Thanks for sharing such a thoughtful comment.
Thanks Gavin, really appreciate the thoughtful reply.
I think one of the hardest parts is that technical debt often looks like productivity in the short term, so it gets rewarded unintentionally. Teams feel fast right until the moment every change starts taking twice as long.
What you said about small improvements compounding over time is key. Clean architecture rarely delivers a dramatic “wow” moment, but over months it creates stability, confidence, and much better decision-making speed across the team.
Really enjoyed the article — it captures a reality many developers experience but struggle to articulate clearly.
That’s such a good point.
Technical debt often disguises itself as efficiency because the negative effects arrive much later, usually when the context has changed or the pressure has increased. By then, teams are no longer optimizing for delivery, they’re spending energy fighting the system itself.
I also completely agree on clean architecture rarely being “visible” work. People notice flashy features immediately, but maintainability shows its value quietly through faster onboarding, safer changes, fewer regressions, and better confidence across the team.
Really appreciate your insights here, Luca. This is exactly the kind of discussion I was hoping the article would spark.
Thank you @gito3 :)
That Thursday-afternoon scene is the most common origin story for the kind of fix that becomes the architecture. The quick patch never gets revisited because nothing breaks again, and the next person inherits the dead code as load-bearing. I started writing a one-line 'why this is here' comment on every hot patch — not the fix description, the reason the proper fix did not happen. Six months later that comment is the only thing that lets the next engineer judge whether the original constraint is still real.
That’s an excellent practice.
I especially like the distinction between documenting what the patch does versus documenting why the proper fix didn’t happen. That context is usually what disappears first.
Most “mysterious legacy code” started as a reasonable constraint under pressure:
But six months later, nobody remembers whether that constraint still exists, so the workaround gets treated as intentional design.
Your “load-bearing dead code” phrasing is painfully accurate 😄
A small comment explaining the original trade-off can save hours of archaeology later and, more importantly, it gives future engineers permission to reevaluate the decision instead of preserving it indefinitely.
The "permission to reevaluate" framing is the part I keep underestimating in my own commits. The temporary trade-off comment isn't really for the next engineer's understanding it's an explicit unlock that future-you didn't lock the door behind you. Most workarounds calcify because the original constraint loses its expiration date, not because anyone trusts the workaround on its merits.
That’s such a sharp way to frame it.
I love the idea that documentation around a workaround isn’t just historical context, it’s a form of permission architecture. You're signaling to future-you (or the next engineer) that this was a conscious compromise, not sacred design.
“Temporary” fixes become permanent mostly because the original constraint disappears, but the workaround keeps looking intentional. Without an expiration date or explicit reevaluation trigger, people assume touching it is dangerous.
That’s also why I think the psychological side of technical debt matters as much as the technical one: undocumented compromises quietly become team norms.
Your “didn’t lock the door behind you” line captures that perfectly.
The "expiration date or reevaluation trigger" is the part I've been trying to nail down for a while. A workaround comment without one is basically asking the next engineer to inherit a decision they don't have permission to revisit.
What's worked for me: every workaround block I write now ends with // re-evaluate when X where X is a concrete signal. Usually that's a library version bump, a feature flag flip, or some metric crossing a threshold. I avoid dates here on purpose. They get bumped in review and quietly turn into noise. The behavior shift was that the team started reading comments with a real trigger as load-bearing and the rest as decoration.
The timezone bug story really hit home. Twelve minutes of hotfix turning into four separate duplicated variations and a refactor that took three days is exactly the kind of silent compound interest that makes me nervous every time I see a TODO older than a sprint. I also liked the distinction between a deliberate shortcut with a plan and an unconscious one born from denial. That line about step one becoming the finish line is a painful but accurate summary of how standards erode.
Really appreciate this comment, because you captured the part of technical debt that’s hardest to quantify: the compounding effect.
That “12 minutes now, 3 days later” pattern is exactly what makes these issues so dangerous. The original shortcut rarely looks catastrophic in isolation, but once duplication, assumptions, and copy-paste variations start spreading, the cleanup cost grows exponentially.
I also love how you framed the difference between deliberate and unconscious shortcuts. That distinction matters a lot to me. A conscious trade-off with visibility and a remediation plan is engineering. An unconscious shortcut that quietly becomes “the way we do things” is where teams start losing velocity without realizing why.
And yes, “step one becoming the finish line” is probably the most common failure mode I’ve seen in real projects. Not because teams are careless, but because pressure changes incentives. Once the immediate fire is gone, the system naturally pulls attention toward the next delivery instead of the cleanup.
Really thoughtful takeaway here, thank you for adding it.
Great read, @gavincettolo! Your point about quick fixes creating "invisible drag" hits home.
I've seen teams celebrate a 2-hour hack that turns into months of refactoring hell. In my experience at a fintech startup, we once patched a legacy auth system with duct tape to hit a deadline. Six months later, it was costing us 30% more dev time weekly. What's your go-to metric for spotting when "fast now" becomes "slow forever"?
Spot on, @paolozero.
Fintech is brutal for this stuff! My top metric is cycle time drift: track how long features take from idea to deploy. If simple tasks balloon from days to weeks, technical debt is the culprit. We use DORA metrics (deploy frequency, lead time) at my shop to quantify it.
Yours sounds like a classic "auth debt trap." How'd you finally untangle it? Refactor sprint or big rewrite?
Cycle time drift—stealing that for our next retro! We did a hybrid: carved out a "debt weekend" (48 hours, pizza-fueled) to modularize the auth mess, then incrementally swapped it with OAuth2 over two sprints. Deploy frequency jumped 40%, and no more 3AM fire drills. But your article nailed the psychology—PMs love quick wins, devs dread the bill. Ever tried "debt budgets" like financial ones? Allocate X% of sprint capacity to payoffs?
"Debt weekend" is genius, might pitch that here!
Debt budgets are gold; we cap it at 20% per sprint, tied to OKRs. Forces trade-offs upfront.
Love the OAuth pivot too, pragmatic wins over purist rewrites.
Quick question: According to you, do cultural factors amplify quick-fix temptations, or is it universal dev pain? 😄
I think that quick fixes are global, blame tight budgets everywhere! Debt budgets convinced our PMs; now they forecast "interest payments" in roadmaps. Your article should be required reading for product folks.
What's one fix you've seen backfire spectacularly?
Fair, budgets unite us all!
Worst backfire: a team "fixed" a DB query perf issue by duplicating data across micros. Felt speedy... until schema drift caused week-long outages. Cost: 2 engineers full-time for a month.
Lesson: measure systemic speed, not local.
Paolo, this chat's threading gold! Thank you!
"15-20% of each sprint for technical debt reduction" - that seems like quite a big number. In a typical Scrum team (say, 6 actively working devs), it's:
6 people x 10 days x 8 hours = 480 human/hours * 20% = 96 human/hours, if I count correctly. A lot of work can be done in 96 h/h. Though most teams really have these numbers, I'd say it's still a problem to solve (in several years, the summary amount of waste becomes terrifying). With Kaizen, we reduced debt to 6-7%, and we are still displeased 😡So, I'd say 5% tech debt time should be considered as the goal (especially, in long-term projects, where wasted time accummulates).But on all the other items I agree 👌🏻
That’s a very fair point and, honestly, I’d love to see more teams operating in the 5–7% range instead of 15–20%.
The number in the article comes mostly from observing teams already carrying significant accumulated debt, where some dedicated recovery capacity is needed just to stop the slowdown from compounding sprint after sprint.
I really like your Kaizen example because it highlights the ideal state: technical debt management becomes continuous instead of periodic “cleanup mode”.
In my experience:
The bigger issue is usually not the exact percentage, but whether teams intentionally budget for sustainability at all, many still operate at effectively 0% until delivery speed collapses.
Thanks for bringing real numbers into the discussion
Sharp, honest take. Calling out “it works” as hidden tech debt is dead‑on, and the 1‑3‑10 rule makes the cost impossible to ignore. The cultural angle is even stronger - teams don’t fall apart overnight; they erode through repeated “just this once” shortcuts. Treating quick fixes as visible debt instead of invisible magic is exactly what keeps long‑term velocity intact.
Really appreciate this, especially the point about erosion happening gradually rather than through a single catastrophic decision.
That’s the part I think many teams underestimate: most engineering slowdowns don’t come from one terrible architectural choice, but from hundreds of small “just this once” compromises accumulating over time.
And yes, visibility is the key difference. Technical debt itself isn’t inherently bad, hidden debt is.
Once teams acknowledge quick fixes as conscious trade-offs instead of pretending they’re permanent solutions, they can manage them intentionally rather than letting them silently shape the system.
Glad the 1-3-10 framing resonated 🙌
I’d genuinely love to hear your thoughts on this.
Do you agree with the idea that “quick fixes” often slow teams down long-term, or do you think speed sometimes matters more than clean architecture?
Curious to hear different perspectives 🙂
Quick fix will have cost! So, for that emergency period, it needs to be applied.
But, the moment it gets fixed, then we should take our time to think about the problem and the fix we did and solve it properly!
But, I think, at the least, for the person who did the quick fix and saved the day, can feel to be the hero for that day! 😃
Absolutely, quick fixes are sometimes the right call when the house is on fire 😄
The danger starts when the emergency solution quietly becomes the permanent architecture. That’s usually how teams accumulate invisible complexity over time.
And yes, the person who ships the quick fix does deserve the “hero of the day” moment 🎉 as long as the team also makes space afterward for the less glamorous work of turning that rescue into a sustainable solution. The real win is not just saving production today, but preventing the same fire tomorrow.
True!
Great read, @gavincettolo! Your point about quick fixes creating "technical debt snowballs" really hit home. I've seen teams celebrate short-term wins, only to spend months untangling the mess later. What's one cultural change you've seen that actually prevents this debt from piling up?
Thank you @elenchen, glad it resonated!
Spot on about the celebration trap. The best cultural shift I've witnessed is "debt spikes": short, dedicated sprints (like 1-2 weeks every quarter) where teams exclusively pay down tech debt, no new features allowed. It builds in accountability without killing momentum. Have you tried something similar, or what's worked in your experience?
Love the "debt spikes" idea—feels like a pressure valve! In my last role, we adopted "refactor Fridays," but it fizzled because leadership tied bonuses to feature velocity. We switched to metrics blending speed and debt reduction (e.g., tracking cycle time + code churn). Velocity actually improved 20% long-term. How do you convince skeptical stakeholders that investing in cleanup isn't "wasted time"?
@elenchen Refactor Fridays" scaling to measured outcomes is gold, those blended metrics are key.
For stakeholders, I use a simple ROI frame: "Every hour on quick fixes costs 3x in future maintenance" (backed by our data). Pair it with a quick demo of a refactored module running 2x faster. Turns skeptics into advocates fast. What's your go-to demo or story for winning them over?
My killer story? A legacy API we "fixed" with hacks—deployments took 4 hours. We refactored it in a debt spike, dropping to 10 minutes. Showed execs the demo live, with before/after logs. They greenlit quarterly spikes on the spot! Quick question: How do you prioritize what debt to tackle first when everything feels urgent?
That's a demo masterclass, live proof crushes doubt every time!
Prioritization: We score debt by "pain multiplier" (frequency of touch slowdown impact team frustration).
High scores first.
Tools like SonarQube or custom spreadsheets make it data-driven, not democratic debates. Cuts through urgency noise. Ever used a scoring system, or what's your triage method?
This is the tech-debt argument applied perfectly to the AI era. "It works" is the most dangerous phrase in software because it's where most people stop - and AI makes reaching "it works" so fast that the temptation to stop there is stronger than ever. The quick fix isn't free; you're borrowing speed from your future self at a brutal interest rate.
The AI twist worth naming: agents are exceptionally good at producing "it works" code and indifferent to whether it's maintainable, because they optimize for passing the immediate check, not for the next engineer who touches it. So the discipline of "works AND is clean" now has to be imposed by you, deliberately, because the tool won't do it for free. The faster the generation, the more intentional you have to be about not stopping at "it works." Sharp, evergreen point.
Mb Foysal
?