Flashy new things aren't always the answer

Why, oh why?

All too often you often hear people say "I'll rewrite this." The rise of agentic coding makes the rewrite easier (but it's not always perfect, and you'll have to sand down the rough edges yourself - security, bugs, etc).

In a way, I kind of understand when people are builders, and their first instinct is to build things. This is good, because building is what they are good for, and it shouldn't be discouraged. But sometimes building new things make it more painful for everyone involved, eventually.

One common reason is people don't understand how existing solutions work. In a case where an existing solution is a big ball of mud, and is very critical to your business, a rewrite is justificable because as time goes on, it'll be harder for everyone to understand how this solution works - and this is very important, because it means it'll be slower to introduce new features or fix bugs. Similarly, if rewriting in a new language results in a large performance gain and you can justify the time and money invested, it's also a good fit. There are cases when rewriting from Node to Go/Rust which results in higher throughput and less infra cost (but the most might be added elsewhere, just have to do a thorough assessment).

But otherwise, some builders think if it's a solution they create themselves it'll be easier to read and understand. I don't doubt that, but you might as well look into all possible edge cases and failure modes, and assess whether a rewrite to account for all features parity and edge cases handling are a good use of your time.

Another case is when people want to create a service for something without assessing the existing ecosystem. It could be a duplicated service, or a similar service with slight variations. Silos are coming to town, and it's never good.

One example came to mind of when a project uses a static site generator (templating engine, think of Hugo or Zola). New leadership came in and demanded it be rewritten in node because they want to change the website's theme. This project is for publishing articles, which means the whole rendering engine has to be accounted for css injection, not to mention parsing edge cases. The interesting part is that since it's a templating engine, you can dive straight into hacking the project's html template to update the look and feel.

What's so bad about a new service

For builders, assuming there are no bugs report once they shipped a service, you might think you don't have to maintain the service. (But real world isn't like that, sadly). There will be bugs, and users will want new features. Also you'll have to upgrade service dependencies to patch vulnerabilities - not too uncommon when an unpatched service gets hijacked to mine crypto.

You might think "it's fine, we'll do it ourselves" when the ops/infra team shot down your request to deploy this service. I get you, but the ops/infra team have seen too many instances of this - builders eventually couldn't keep up with the maintenance and service operations so they transfer it to the ops/infra team. This is a fast way to build resentment across teams.

Even with LLMs, it's still not a substitute for manual testing and assessing how to fix vulnerabilities. LLMs can do the work, but you will have to approve the decisions.

So what to do

Start by assessing the existing ecosystem, and see where your features can land. Rewrite if you have to, but it should be when it's very painful to add new features due to how messy a project is.

Then there are some leaders who want to left their marks, and one way of being seen is to crank out new stuff or work on new projects - they look good for KPIs. So yes, politics.