Refactoring agile fragile code is the gift that keeps on giving

It all made sense at the time but not anymore

Image made in Canva.

I’ve been around the dev work block. There have been some good and fun projects. Then there have also been horror shows. But it doesn’t matter what feelings I have towards the code, they all have one thing in common — they all need to be refactored, eventually.

Refactoring is one of those facts of life for all developers. At some point, we all encounter it. There’s no escaping and explaining the concept to upper management can be as equally challenging.

For many non-techies, software is akin to an asset that’s built and paid for. For the software developer, it’s more like homeownership. At some point, the old pipes are going to leak, or you suddenly realize that building with asbestos was a bad idea.

Even new builds come with their own set of issues.

Nothing is perfect. You might love the color scheme and architectural plans, but to a different set of eyes — it might just be an overload of hedonistic maximalist self-indulgent code that only made sense to its creator.

Someone, somewhere, will always have an opinion.

So what can be done to create at least some sort of consensus? What lessons from refactoring have…