This Made Sense at the Time: Why Yesterday's “Bad” Decisions Deserve a Second Look

Every experienced developer has encountered it: a piece of code that looks completely irrational. A mysterious workaround. A feature nobody uses anymore. A subsystem everyone is afraid to touch.

The first instinct is usually simple: "Who thought this was a good idea?"

During my Umbraco Codegarden conference talk "This Made Sense at the Time", I've challenged that instinct. Instead of asking who made the wrong decision, I suggested asking a far more useful question:

What did they know when they made it?

The answer, in my opinion, often changes everything.

Because every legacy system tells a story. Imagine travelling back to the exact moment an architectural decision was made - not to change history, but to understand it.

Because software decisions rarely happen in perfect conditions. They happen under deadlines. During incidents. With incomplete information. Inside frameworks that have limitations. And under business pressure that future developers never get to see. When that context disappears, the decision itself often starts looking irrational.

To begin with, let me introduce you to Anna from the past. That's me, eight years and one baby ago. Young. Full of energy. Convinced that good architecture could save any project. Always up for a technical challenge - the harder, the better.

I'm the one who lives with her decisions now. And I've got two stories about that.

Story #1: The Critical Feature That Was Never Used

This was my first project as a solution architect. A global pet food brand. Fifty-something regional teams. Thirty-five languages.

You can already feel where this is going.

The client insisted on one feature. On their old platform, they'd had a legal incident. The kind that ends with lawyers in the room. The cause was oddly specific: in several countries, you can't show a photo of a dog if its tail or ears aren't fully visible. There are laws against cosmetic surgery on animals. A photo that broke this rule had slipped through to one of those markets.

Now they were building a new platform. The fear came with them. The client insisted on one seemingly simple feature: a switch that could instantly remove an entire dog breed from every part of the website. Not just one page. Every language. Every search result. Every taxonomy. Every related article. Every product filter. And without breaking anything else.

Technically, this wasn't something the platform supported. Building it required significant custom development and introduced long-term maintenance costs.

Past-Anna did try to push back. This is going to be painful to build. Painful to translate. Painful to index. Painful to maintain.

The room heard her out. They agreed with every point. And they decided to build it anyway. Not because they missed the cost. Because the scare was fresh - and the switch was their version of safe.

So we built it. Shipped it to every market. I maintained it for five years.

What do you think happened in those five years? Nothing. The switch was never used. Not once. Not for any breed.

Well, not quite nothing. It had to be maintained. Regression tested. Every audit, every onboarding, someone had to pull up the documentation and explain what the switch was, and why it was there.

The client team had changed. The people from the original incident had moved on. But the switch was still there. And past-Anna was still protecting it because, well. It was critical.

Story #2: The Band-Aid That Held Everything Together

A completely different project. A multilingual B2B and B2C ecommerce platform. We inherited it. A different company had built it on a platform that was new to them, and they'd struggled the whole way. It shipped in a panic. By the time it landed on our desks, that team was gone. Our job was to stabilise it.

While working on it, past-Anna found something that immediately made her stop and think: Why would anyone do this?

A piece of middleware was quietly removing the standard language header. And a custom helper was rebuilding the same information from the URL instead.

It looked like a crazy workaround. So we did the obvious thing. Removed the middleware. Deleted the helper. Used the standard language header, like everyone else does.

The code got cleaner. The bug we were chasing got fixed. We tested it. In every lower environment. And then deployed.

What do you think happened? Half the site's languages stopped working.

And we rolled back.

Same code that had passed every test. Same code that had worked perfectly in staging. In production was broken.

So past-Anna started digging through the git history. And here's what she found.

There was a real bug in the framework. It couldn't handle some of the data this project needed to pass through that standard header. Under deadline pressure, the previous team had put a band-aid in place - strip the header, rebuild the data their own way. It wasn't a crazy hack. It was the only way to keep the site up.

Over time, the rest of the application had evolved around that decision. Removing the workaround wasn't a refactoring exercise anymore. It required redesigning part of the platform. The original developers hadn't written bad code. They had solved the problem they actually had.

So why had our "fully tested" fix worked in staging but not in production? The hosting was set up a little differently in each environment. The test environment had been hiding the bug from us the whole time. Production was the first place we actually saw what the band-aid was for.

And the team who built it was gone. Anna couldn't ask why. She could only read what they'd left behind, follow their steps and try to imagine the week they'd had when they wrote it.

The real problem was that nobody had documented why they had done it.

Two Decisions. One Question.

Two decisions. One is a critical feature nobody ever used. The other is a hack the whole system quietly depends on. Very different shapes but they have one thing in common.

They both made sense at the time.

But both outlived their context and became difficult to get rid of.

So the question isn't who messed up. The question is - what do we do when we find one?

The Time-Travel Exercise

Here's the tool.

Imagine a DeLorean. Jump in. Hit eighty-eight miles per hour and travel back to the day the decision was made and asking:

• What technology existed then?
• What business requirements mattered?
• What constraints shaped the solution?
• What information was unavailable at the time?

Only after reconstructing that context should teams compare it with today's reality.

Sometimes nothing important has changed. Sometimes everything has.

The goal isn't nostalgia. Nor is it defending old architecture. The goal is understanding whether the original assumptions are still true.

Be that person for a minute. Not the version of them you imagine - the real one, with the real deadline, and the information they actually had.

Then compare it to everything you know now. Maybe the requirements have changed. Maybe technology has moved on. Maybe a constraint has quietly gone away.

Or maybe not.

Why This Exercise Helps

It's compassionate. Blame doesn't fix anything. And there's almost always a reason behind a decision past-you made the best call they could with what they had. There's nothing to regret.

It restores the context, so you can compare it to today. Imagine a visual diff tool but for context. Then-and-now, side by side.

But those two columns don't fill themselves. To see the "then", you have to go and get it.

Talk to the team. Read the documentation. Look through the commit history. Get close enough to past-you that you can almost feel what they were feeling.

And then ask the only question that matters:

Does this still make sense?

Back to Story #1: The Critical Feature

So let's actually run the exercise for Story #1.

What was true then? A real legal accident had just happened - content published by mistake on the old platform.

The framework couldn't remove a topic cleanly - a custom switch was the only way to do it. The switch took real effort to build and maintain, and it came with performance tradeoffs.

We built it because the scare was fresh and the switch was the client's version of safe.

Was past-Anna wrong? No. This made sense at the time.

Now let's compare the context.

One thing has not changed. The framework still can't do this natively so the switch is still the only technical way to pull it off. And it still costs what it always costs: effort to maintain, and a drag on the background jobs. So if we were judging by the technology alone, we'd keep it. And keep paying for it.

But look at the risk instead.

In five years on the new platform, there hasn't been a single accident. And not by luck. The new platform gave the client real tools to check what they publish before it goes live. The original accident was a publish that slipped through by mistake. That failure mode is now caught at the source.

So we're paying to maintain a feature, and slowing the system down, to guard against a problem the platform now prevents on its own. And whatever small risk is left? It doesn't need a custom feature on every breed page. It needs a process. A manual or half-automated takedown for the rare case would cover it.

The call: time to revisit. Not because the feature is old. And not because the tech caught up - it didn't. Because the risk changed shape.

We protected it out of habit. Now we can change it out of understanding.

Back to Story #2: The Band-Aid

Now let's run it again for Story #2.

What was true then? A real bug in the framework and no fix coming.

Deadline pressure - release in days, not weeks.

A workaround that looked lightweight, and kept the site alive.

Was that decision wrong? No. This made sense at the time too.

Now let's compare the context.

Much of it is still true. The bug is still there. The system has grown around the hack. Removing it now is a redesign, not a cleanup.

So the call this time: leave it alone for now. But now we understand it. And we can plan the proper redesign on our own terms, instead of being caught off guard by it in production again.

Now the reason Story #2 hurt so much, wasn't the bug. It was that nobody had written down the why. We had to rediscover it the hard way in production.

So if there's one practical thing to take from today, it's this:

When you make a decision under pressure, document the why, not just the what. And if you can, write down what would have to change for this to stop making sense. That's the one note future-you will actually come back and read.

And still even without that note the site stayed up. That mattered.

So knowing the full context, "thank you, past developer" stops being something we say through gritted teeth.