Avoid the Rewrite: Rescuing messy software

Do you have old software that no developer wants to touch? It worked fine for decades, your company relied on it and still does. But every time you have someone take a peek, they come out sweating, talking about rewriting it all from scratch? What happened?

The messy basement

Imagine you're invited to help a struggling business. You walk into the storefront and everything looks great. You're led into the basement and you nearly trip down the stairs. There are boxes everywhere, every surface is covered with junk and papers. It's dark, dusty, downright scary.

This is essentially what developers might see when they peek at your older software. But it worked so well for so long, so how did it get so bad?

Understanding the history

Back to our basement, it wasn't always such a mess. Doug ran the business smoothly for many years, and he was always down here. He wasn't a tidy fellow, but he knew where everything was. Nobody else needed to come down here, and they'd rather not. Over time, Doug's mess grew, and he never got around to tidying it all up.

When Doug was retiring, Sandra was tasked with temporarily taking over from him. It took Doug a while to show her where everything was, but she figured out what she needed.

Once Doug left, Sandra kept things running, though a little less smoothly. She avoided all the filing cabinets and desks she could, and stuck to the drawers she knew. She kept a little corner clean and organised, which was all she could handle. Now Sandra's left the company, and nobody knows what to do.

A lack of ownership

You may have had a trusty developer like Doug that built your whole system back in the day. Doug meant well, but his priority was on doing good work, not on keeping things tidy. He wanted to stick around for the long run, and wasn't thinking of handing it over. The daily tidying and organizing was a low priority, since he was the only one down there.

Sandra inherited a big but functional mess. She was able to do her job, and she did the best she could. But she never felt like the owner of the basement. In her mind, she was tending to Doug's messy system until a replacement was found. Without a sense of ownership, she tried to keep any changes to a minimum.

What the messy system needs, whether the basement or your old software, is someone new to come in, take ownership, and clean up the place.

The preciousness of knowledge embedded in a complex system

When faced with overwhelming complexity, many people will feel that starting over or "rewriting from scratch" is the easy path out. This is the equivalent of locking up the basement for good and starting fresh with a new office in the attic.

In my experience, these rewrites often go badly. It's true that starting fresh feels easier than learning an old system. Truth is, that messy basement contained decades of business decisions, improvements, and countless details that a new system will need to recreate. It takes a long time to build up that knowledge base, and even if it's a mess, that embedded knowledge is a precious resource.

Cleaning up and organizing

I absolutely love coming into a complex system, making sense of it, and working to bring simplicity to it. Here's how I approach working with a new system.

Taking inventory

First thing I'll do is carefully look through the system. I'll work to understand the history, and the archaeological layers of the system. I want to know who started it, how the system looked when it was young, and how it evolved over time. I'll trace through the parts of the system, see where things flow, and how it all fits together.

I'm not there to judge, I'm there to learn and understand with empathy and kindness. I know whoever built this did the best they could at the time. Usually weird decisions make more sense if you understand the context.

Turning on more lights

Like a dark and dingy basement, it helps to bring in more light to work in a space like this. With a complex system, this means collecting information and statistics. It means testing to see what works and what's broken.

There may only be a few parts of the system that are still in use. Maybe some of the piles in the back are dusty and untouched in years. Some things were put there temporarily, and nobody remembered to remove them.

Through documenting current processes, speaking with users and stakeholders, and observing activity, I can start to understand any complex system.

Archiving and clearing out junk

As the system becomes more clear, and we know the parts that are still needed and those that aren't, I can start clearing out some of the unused parts. These dusty piles make it harder to find what you need. They may have served their purpose once upon a time. Since they're no longer used, it's okay to archive them, removing them from the current system, but keeping them around for future reference.

Once some space is made, and only useful sections remain, it becomes easier to understand the system as a whole.

Organizing

Working with a cleaned up, simpler system, I can start tidying and organizing. This means putting like things together, grouping by function and use.

As things become organized, there can be opportunities to split a system into two or three separate systems. This splitting allows for even more understanding and simplification, as you can better observe any interactions between parts of the system.

Time for something new

Now that we have a more organized, tidier and well documented system, we're ready to start making real changes to the system. We can trust we have a better understanding of how everything works.

That "rewrite" instinct can finally come back into play here. We may well decide that one of the parts of the system can be replaced.

We don't have to replace everything at once. We can keep the 90% that is working well, and replace the 10% that is causing all the problems. The whole time, the system can remain functional, the company can continue to depend on it as always.

Handing it over

I'm always thinking of the person who's going to come after me. Even though I've taken full ownership of the system, I know eventually I'll need to hand it over to someone else. I want the next person to be able to come into this system and understand it quickly. I want them to be empowered and enabled to make changes to the system with confidence and ease.

I achieve this by maintaining the simplicity in the system. I want the system to be easy to learn, with small and understandable parts. Documentation is important, but so is having a system simple enough that it makes sense from the start.

Avoiding the rewrite

I work with companies and organizations struggling with old, dusty, messy legacy software. I help them to transform their software and systems into something fresh and functional. With 25 years of experience, I love taking on those older projects that nobody else wants to touch. I understand that rewriting is an expensive and risky approach. I focus on learning and making sense of complexity in order to minimize the costs and effort involved in making changes.

If you have a complex legacy system, please contact me and let's figure this thing out! You can also read more about what it's like to work with me.