“I’ll just hardcode this for now.”
If I had a dollar for every time those words preceded a disaster, I’d have enough to fund the refactoring project we’re still trying to finish from 2022.
I’m not here to shame anyone who’s ever written a quick fix. I’ve written hundreds of them. Some were justified. Some were necessary. And some—the ones that haunt me—became permanent features of codebases that outlived the people who wrote them.
This is a story about compound interest.
Not the kind your bank offers. The other kind. The kind that accrues in dark corners of pull requests, accumulates in TODO comments nobody reads, and eventually presents its bill when you can least afford to pay it.
Let me tell you about the fastest solution that cost us six months.
The Quick Fix That Changed Everything
It was 2021. Black Friday was twelve days away. Our e-commerce client’s promotion engine had a bug.
The bug was simple: discount codes weren’t stacking correctly when cart value exceeded $500. Above that threshold, customers were getting the lesser discount instead of the greater one.
The right fix would have taken two weeks. We needed to refactor the discount calculation service, update the cart total observer, write integration tests, and deploy through staging.
We had twelve days.
So we did what seemed reasonable. We added a condition:
// Quick fix for Black Friday - REMOVE AFTER 11/30
if ($cartTotal > 500 && $this->isBlackFridayPeriod()) {
$discount = max($discount1, $discount2);
} else {
$discount = $this->calculateStackedDiscount($discount1, $discount2);
}It worked. Black Friday was a success. The client made record revenue.
Then Cyber Monday came. And Christmas. And the New Year sale. And Valentine’s Day.
Every time, someone extended that “temporary” condition. The isBlackFridayPeriod() method grew to include… all periods. Nobody touched the underlying bug because the quick fix was working.
By March, we had a promotion engine with seven nested conditionals, three different discount calculation paths, and zero test coverage because nobody quite understood what it was supposed to do anymore.
The refactoring took six months.
Not two weeks. Six months.
The Compound Interest of Shortcuts
Here’s something they don’t teach in computer science classes: technical debt accrues interest.
And not the gentle, predictable kind. The compound kind.
Research from the IEEE suggests technical debt compounds at approximately 23% per year. That means:
| Initial Quick Fix | Year 1 Cost | Year 2 Cost | Year 3 Cost |
|---|---|---|---|
| 2 hours | 2.5 hours | 3.0 hours | 3.7 hours |
| 8 hours | 9.8 hours | 12.1 hours | 14.9 hours |
| 40 hours | 49.2 hours | 60.5 hours | 74.4 hours |
That “two-hour quick fix” that you’ll definitely fix later? If you don’t touch it for three years, it costs almost double to fix. And that’s assuming the interest rate is only 23%.
In my experience, it’s often worse. Much worse.
Because quick fixes don’t exist in isolation.
The Cascade Effect
Here’s what actually happens when you commit a quick fix:
Week 1: Quick fix works. Everyone’s happy. You have a beer.
Week 4: A junior developer needs to modify that area. They see your conditional. They don’t understand why it’s there, but it works, so they wrap their change around it instead of through it.
Month 2: Another developer needs to add a feature. They see two workarounds now. They add a third, convinced theirs is more temporary than the others.
Month 6: Someone notices the code is hard to test. They write mocks specifically for the workarounds. Now the tests depend on the debt.
Year 1: A new team member asks why this code is so complicated. Nobody remembers. The original developer has left. The comment says “REMOVE AFTER 11/30” but doesn’t say which November.
Year 2: Management asks for a timeline on fixing the “legacy discount system.” You give an estimate. They say it’s too expensive. The debt becomes permanent.
This isn’t hypothetical. I’ve lived this exact timeline. Twice.
The Psychology of “Later”
Let’s be honest with ourselves for a moment.
When we say “I’ll fix it later,” what we really mean is: “I’m making a calculated bet that future-me will have more time than present-me.”
But future-me has their own deadlines. Their own quick fixes. Their own confident assertions that they’ll fix it later.
The average “temporary” fix in enterprise codebases lives 2.5 years. Not weeks. Not months. Years.
I tracked my own quick fixes once. Of the 47 commits I tagged with “TODO” or “temporary” in 2020:
| Status (as of 2025) | Count | Percentage |
|---|---|---|
| Actually fixed | 12 | 26% |
| Still exists | 23 | 49% |
| Code was deleted (lucky!) | 8 | 17% |
| Caused production incident | 4 | 8% |
A quarter of my “temporary” code got fixed. Half of it is still running. And 8% caused production incidents at various moments of inconvenience.
Those are not inspiring numbers.
When Quick Fixes Are Actually Fine
I’m not here to tell you that every quick fix is wrong. That would be naive.
Some situations genuinely call for speed over elegance:
✅ Acceptable Quick Fixes
1. Production is on fire.
When users can’t checkout, you fix it. You don’t stop to write integration tests while revenue is bleeding. You stop the bleeding, document what you did, and schedule the proper fix for tomorrow.
// HOTFIX 2026-01-12 - Production issue #4521
// Null check added because user.address can be null
// for accounts migrated before 2023-04-15
// Proper fix: Migration script + data validation
// Ticket: JIRA-5678 (scheduled for Sprint 24)
if ($user->address !== null) {
$this->validateAddress($user->address);
}Notice what I did there? Context. Date. Ticket number. Why this exists and when it will be fixed.
2. You’re validating an idea.
Prototype code doesn’t need production quality. If you’re testing whether a feature even works, perfectionism is the enemy of progress.
The catch: prototype code should never become production code. That’s where the trouble starts.
3. The alternative is worse.
Sometimes the “proper” fix would require refactoring three other systems. Sometimes the deadline isn’t negotiable because external partners are involved. Sometimes the business genuinely needs something now.
These are real constraints. Pretending they don’t exist doesn’t make you a better engineer.
❌ Unacceptable Quick Fixes
1. You’re just avoiding hard work.
If the quick fix exists because you don’t want to think through the proper architecture, you’re not saving time. You’re borrowing it. With interest.
2. Nobody knows about it.
A quick fix without documentation is a landmine. Someone will step on it.
3. There’s no plan to fix it.
“Later” isn’t a plan. A ticket with a sprint assignment is a plan. If the fix doesn’t have a path to completion, it’s not temporary. It’s permanent code wearing a costume.
The Framework I Actually Use
After nine years of learning this lesson in various painful ways, I’ve developed a decision framework. It’s not perfect, but it’s saved me from myself more than once.
The Quick Fix Evaluation Matrix
Before committing a workaround, I ask four questions:
| Question | If Yes | If No |
|---|---|---|
| Is there a production incident? | Quick fix acceptable | Continue evaluation |
| Can I document the fix in under 5 minutes? | Proceed with caution | Warning sign |
| Is there a ticket created? | Proceed | Stop. Create ticket first. |
| Will I remember this in 3 months? | Okay | Not okay |
If I can’t answer “yes” to at least three of these, I don’t commit the workaround. Full stop.
The Quick Fix Template
Every quick fix I commit now follows this template:
/**
* TEMPORARY FIX - [DATE]
*
* Problem: [What's broken]
* Context: [Why we can't fix it properly right now]
* Risk: [What could go wrong if this stays too long]
* Ticket: [JIRA/GitHub issue number]
* Owner: [Who's responsible for fixing this]
* Deadline: [When this MUST be fixed by]
*/Is it bureaucratic? A little. Does it save future-me hours of archaeology? Absolutely.
The Conversation Nobody Wants to Have
Here’s the hardest part: quick fixes aren’t just a technical problem.
They’re a communication problem.
When a stakeholder says “we need this by Friday,” most developers hear that as a constraint. We problem-solve around it. We find ways to make Friday happen, even if that means cutting corners.
But here’s what we should actually say:
“I can make Friday, but here’s what that costs. If we ship this quick fix, we’re adding approximately 16 hours of future work. We’ll need to refactor before we can add the next feature in this area. Is that trade-off acceptable, or should we negotiate the deadline?”
That’s terrifying to say. I know.
But it’s also the only honest response.
The alternative is pretending that Friday has no cost—that we can somehow bend time and physics to deliver quality code on an impossible timeline. And when we pretend that, we’re not heroes. We’re just passing the bill to our future selves.
The Numbers That Changed My Mind
A few years ago, Stripe published a study on developer productivity. One statistic stuck with me:
Developers spend 42% of their time dealing with technical debt.
Not writing features. Not innovating. Not solving customer problems. Maintaining the consequences of previous shortcuts.
Another study from McKinsey found that:
| Debt Level | Development Velocity Impact |
|---|---|
| Low (under 10%) | Minimal slowdown |
| Medium (10-25%) | 23% slower feature delivery |
| High (over 25%) | 40%+ slower, team morale affected |
We’re not just paying compound interest. We’re paying it while trying to run a sprint with weights strapped to our legs.
The Path Forward
I’m not going to pretend I have a perfect solution. I still write quick fixes sometimes. You will too.
But here’s what I’ve learned to do differently:
1. Track Your Debt
Create a technical debt register. Every quick fix gets logged with an estimated resolution cost. Review it monthly. Seeing the total in one place is sobering.
## Technical Debt Register
| ID | Description | Date Added | Est. Fix Time | Priority |
|----|-------------|------------|---------------|----------|
| TD-001 | Discount calculation workaround | 2021-11 | 16h | High |
| TD-002 | User migration null check | 2023-04 | 4h | Medium |
| TD-003 | Cache invalidation bypass | 2024-08 | 8h | Low |
**Total Outstanding:** 28 hours
**Added This Quarter:** 12 hours
**Resolved This Quarter:** 4 hours
**Net Trend:** ⬆️ IncreasingIf the net trend is up for three quarters in a row, you have a systemic problem.
2. Budget for Paydown
Every sprint, allocate 10-20% of capacity to debt reduction. Not negotiable. Not “if we have time.” Scheduled. Protected.
Think of it like paying more than the minimum on a credit card. It hurts in the short term. It saves your life in the long term.
3. Practice the Conversation
Rehearse saying: “That timeline requires a trade-off. Here are the options.”
Say it out loud. Get comfortable with it. The first time you say it to a stakeholder, it’ll feel awkward. By the fifth time, it’ll feel like part of your job.
Because it is part of your job.
Closing Thoughts
That Black Friday fix from 2021? The one that cost six months to unwind?
I still think about it. Not with regret—the decision made sense at the time. But with clarity about what it taught me.
Every quick fix is a bet. A bet that the future will be more forgiving than the present. A bet that someone will have time to do what we can’t do now.
Sometimes that bet pays off.
Usually, it doesn’t.
The next time you’re about to type “I’ll just hardcode this for now,” pause for 30 seconds. Ask yourself:
- Who’s paying the interest on this?
- When will they pay it?
- Is that fair?
You might still write the quick fix. But at least you’ll do it with your eyes open.
And maybe—just maybe—you’ll create a ticket first.
Have you ever had a quick fix come back to haunt you? I’d love to hear your horror stories in the comments. Misery loves company, and there’s something healing about knowing we’ve all been there.