Software Rewrites: or How I learned to embrace architecture redesign

Command: git bulldoze

We’ve all been in this situation at least once:

Ugh we just need to rewrite this whole thing!

It’s often a challenge to justify the effort to rewriting software, not least because there are genuine reasons we shouldn’t. In fact, it should be hard to justify a rewrite.

I’m in the (lucky?) position that it’s often me that has to tell stakeholders that the software they’re using isn’t fit for purpose. Often they’re understanding, because rarely is the software they’re using doing the job that well. All the same, one thing is true:

Rewrites are rarely without more pain than maintenance

The times I’ve been hit by a painful hidden “feature”, edge-case or unexpected requirement are numerous. Yet I still propose rewrites, and for the most part, they get carried out successfully. Here’s what I consider before I get started.

What tech is involved?

Command: a, b = b, a

A large part of software being fit for purpose is if the technology used is fit for purpose. A rewrite to use the right technology is often a wise strategy. However,

The “right” technology does NOT mean your favourite

Particularly look out for:

1. “We used the shiniest framework, it just didn’t have any updates [for five years]”
2. “We had access to a [MySQL 1.5] database, so we used that because it was there”
3. “We know the tool [Visual Basic 5] really well, so we can make it do wild things”

Leveraging the right technology whilst battling through the pain of a rewrite eases the way. One thing is universally false:

I can rewrite that in a weekend!

I know. I tried. However, using the right technology will go a long, long way to genuinely reducing the time of a rewrite and the effectiveness of the result.

Is the architecture right?

Command: rotate_z(180)

It may be the software is genuinely using the right technology, or at the least, is using technology that is endorsed by the business and unlikely to change. However, beware the right tech used in the wrong way,

Wait, it does what?!

Focus on:

1. “The last dev just really liked storing data in [hundreds of] CSV files”
2. “It’s one process, so we just wrote one long [2000 line] script”
3. “If one step fails [every day], we just run all the steps again”

A very effective way to get value out of a rewrite is to build processes that work in the right way. Almost certainly a successful rewrite achieves the same result in a cleaner, easier to understand, and more maintainable way.

Is the functionality correct?

Command: filter:scale(0.1)

There is one particularly difficult question to ask when telling a stakeholder that their software is on life support:

What should the software actually do?

Like the implementation you’re considering rewriting, it may be the functionality asked for was on shaky foundations. If the software doesn’t offer the functionality currently required, it’s likely its users don’t want to use it. In fact, they probably hate it! Look out for:

1. “I get the data out, then I correct it manually in Excel”
2. “Oh yes, that data is always wrong, we know to ignore that field”
3. “I don’t know why that’s in there, we get it from another system”

Working with users to provide software they actually want is very effective in driving change. Making it clear you are invested in a medium term delivery that meets their needs means they’re a lot more likely to accept short term pain (like you are).

Software rewrites and working closely with users can be positive and successful!

We’re recruiting

Find out about the exciting opportunities at THG here:

Careers at The Hut Group (THG)