The conversation

SzpadelHNSource author
Business & incomeExperience excerpt · English

Agree, but there is also one more point, always allow people that created legacy system to work on …

Agree, but there is also one more point, always allow people that created legacy system to work on new one. In one of projects I worked there was legacy system that had enough issues causes by architecture, that 95% of workforce was assigned into fixing new and new bugs/regressions. So business decided to rewrite that system, but mistake they made was to create complete new team for that task. The new team didn't know why previous solution failed, as this was on first sight very simple system, and not knowing all of the hidden complexity made similar mistakes that caused previous system to fail. And in that way we ended up brand new legacy system that also failed in similar ways. Fortunately I convinced them to create third version with the same team as this second failed system and it all looked well until.. some well known consulting company was hired and they decided to rewrite everything on react, and 90% of people just resigned from work.

Original discussionLet It Fail84 source comments · at import
2

What was this responding to?

Parent context · original excerpt

BR
bruce511HN

Replacing one system (typically referred to as legacy - almost in a pejorative way) with another new system can be a big improvement. Or it can be a complete waste of time and money. It all depends on the actual quality of the old system, and the actual quality of the new system. The most common way this manifests is with technology changes. We must rewrite in a modern language like c#. We must switch our JavaScript framework to React. From my experience 90% of these transitions fail precisely because the legacy system is working fine, and _doesn't_ fail. The new system is always 2 years behind, so is never adopted. Good architecture trumps new language. And there are a lot of legacy systems with good architecture. There are also plenty of systems with bad architecture. Ones with too much tech debt. Ones that will fail. And these need to be rebuilt, hopefully with better architecture. So…

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 2

Direct replies available in this import. Original-language excerpts.

PR
PragmaticPulpHN

> So business decided to rewrite that system, but mistake they made was to create complete new team for that task. The new team didn't know why previous solution failed, as this was on first sight very simple system, and not knowing all of the hidden complexity made similar mistakes that caused previous system to fail. The most nightmarish company I ever worked for did this, but took it even further: The two teams (old and new) were set up as competing with each other to see who could create the better solution. The team that lost (for some unclear definition of losing) would often see several people laid off and the remaining members assigned to lower seniority positions on the winning team. It created chaos every time the CEO set up competitions like this. Few things create infighting and information hoarding quite like setting two teams against each other with the threat of losing the…

Full original
RZ
rzzztHN

"But they are needed on the old system to fix bugs! The new team wouldn't know how to solve these" -- reasons the fictional manager.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.