Stop rewriting software for the sake of rewriting

Knowing when to avoid fighting unnecessary battles is one of the most valuable skills to have

Stop rewriting software for the sake of rewriting
Photo by Fotis Fotopoulos / Unsplash

When I was barely a couple years into my junior developer stage of my career, I remember being so opinionated about what tech stack to use and what shiny tools should be ideal for any given task. I had a hammer and everything looked like a nail, basically.

This was around the early 2010s – around that time I was really passionate about C# and how sophisticated the .NET Framework was in terms of not reinventing the wheel and just reusing the built-in tools it provided. I was familiar with that tech stack based on a couple of personal projects I was tinkering with at the time, but on the other hand, I was faced with the need to develop and support large production systems developed many years prior using a mix of old-school ASP and VBScript.

Actually, I asked about it back in 2011 in Stack Exchange and found it. And of course it was closed for being off-topic. Classic SE.

There's something about the young developer mindset that thinks that knows better and wants to rewrite and rebuild everything from scratch using the shiniest tool available. I look at my old SE question and cringe about how naive and frankly stupid I was. Nothing wrong with trying to improve things, of course, but many years under my belt I definitely I'm more inclined to left things untouched if they are working as expected, no matter how old the tech

New isn't necessarily better

I see this mistake being perpetuated by newer generations of developers. I find younger developers dismissing well tested bodies of code simply because instead of putting in the hours to understand the underlying concepts behind it, they have used a new library that does the same. Old doesn't equal bad but apparently we need to spend a good amount of time making tons of mistakes to realize that.

I've seen (and done) rewrite efforts that fell flat because the motivation was to swap old and boring tech A with new and cool tech B. A well-rounded rewrite should be based on addressing tech debt and understanding why old-tech A is falling short and how new-tech B addresses these shortcomings. A good plan of attack also doesn't hurt when embarking on such endeavor.

Well seasoned developers will usually have a good amount of battles under their belts. We know a thing or two, and knowing when to avoid fighting unnecessary battles is one of the most valuable skills to have.

Rewriting for the sake of rewriting is never a good idea but seems to be a necessary rite of passage for relatively new developers.