Often, the requirements changed along the way as the problem domain incrementally became better understood. At that point, the original design is not helping, but sabotaging everything.
This is why that first version should always be considered a prototype. And the next version will probably also be.
Not rewriting will have a much larger cost down the line.
Many successful projects started as reverse engineered clones of old and established ones, that then became improved versions of their predecessors. Those are rewrites, just not done by the original project's team.
My opinionated rules of full rewrites, informed by experience and observation:
1- Bring in one, just one, project lead who is a specialist of the technical domain. E.g. if you're building a web app, hire a seasoned web developer, instead of relying on your in-house electrical engineer, whom you allowed to architect the previous solution, because they managed to convince you that code is code.
2- Let the new lead vet every member of the old team, including (especially) the old team leaders.
3- Allow the new lead to drop any dead wood.
I think you're too quick to point fingers and too desperate to throw people under the bus to pass yourself as saviour.
There are plenty of everyday scenarios where software piles up technical debt in spite of the developers. All it takes is a single requirement to change for an entire tech stack to become a problem instead of problem-solver, and all it takes is a business goal to be met at record time to pile up quick-and-dirty solutions instead of well-architected implementations. These happen far more often than replacing whole teams, and new project leads solve nothing.
I've worked on a legacy project which started as a multi-platform desktop app that in the meantime became Windows-only. You can imagine the cruft that resulted from this requirements change alone. During the same period, business requirements changed to support new major features, and Microsoft started pushing for Windows 11. Of course we discussed a major rewrite, as the legacy tech stack didn't supported native Windows features well and the legacy application was riddled with multi-platform code that made no sense anymore. Switching to vanilla WPF alone would eliminate 90% of the project's pain points.
Tell me exactly how the team created this problem, and how you would be the key to fix it.
Lots of start-ups start with developers that have 2-3 years of experience. Once they reach the state of a rewrite those developers (if they stayed for the whole period) are probably 3-5 years more experienced than when they started and might look at things differently than at the beginning. And those years can make a huge difference especially during a start-up's growth phase
Still, in my experience, ripping out code which isn’t used anymore is a lot simpler than rewriting the things you do need from scratch.
Thanks for the free armchair psych analysis, but that's not why I came today. I'm here to compare patterns about our practice. My answer is not about me as some kind of savior. It's also not some definitive rule of thumb about the cause of rewrite worthy mess. It's about my own observations as part of one specific domain that I'm good at. If another expert of their domain noticed something different, it provides perspective. If they confirm my view, it reinforces the possibility of a pattern.
> There are plenty of everyday scenarios where software [...]
You're describing your garden variety software development. The SOP for technical debt is refactoring, not rewrite. Despite what's thrown at the dev team, it's part of their practice to keep the code maintainable. If you find that the code base grew beyond salvage, then, yes it's possible that it grew too fast beyond their control. But in my experience, the need for a complete rewrite, instead of carving a bit more time for refactoring, tends to point to people as the root cause. Someone is either preventing or has prevented refactoring, or/and has caused too many problems. Sometimes people do it actively (e.g. team leader doesn't want to spend the time), or passively (e.g. team leader can't communicate to management that the team needs the time). Sometimes, those people are not even in the team, sometimes they're long gone. And yes, sometimes the culprits were newbies who have since grown into much better developers. But unless you identify what made the code so bad that you just need to rewrite from scratch, you're likely just setting yourself up to repeat exactly the same mistakes. If you reread my answer, you'll notice that I advocate to bring in a technical domain expert, but I also advocate to vet the team anew, and get rid of the excess. What about that isn't common sense?
In many occasions, I've found that I was actually not needed at all. Some team members had actually tried to previously push for exactly the same solutions that I would end up suggest much later. But due to cultural or political reasons, they were hampered by tenured team leaders. This scenario is so common that it's almost a cliche.
> I've worked on a legacy project which started as [...]
Even after reiterating that I'm neither a savior nor a know-it-all, any attempt at an answer would be futile, since I know nothing of this project.
Rewrite a legacy .NET MVC app with lots of cruft. Build a new Node.JS app with lots of cruft.
The Rorschach test you inadvertently did in your post resulted in you throwing whole hypothetical teams under the bus to then try to pass off yourself as the holder of the one true fix. You fabricated the hypothetical problem, you were quick to point fingers to throw blame around, and you were quick to present yourself as the fixer. There is no way around it.
> You're describing your garden variety software development. The SOP for technical debt is refactoring, not rewrite.
I didn't, and you don't refactor out a whole tech stack written in an entirely different programming language targetting entirely different platforms.
Again, you didn't even pay attention to the problem and you're quick to point fingers and present yourself as the fixer. There is a pattern in your behavior.
Humility is a virtue, and I'm not your psychologist. Have a nice day, and try at least to be kind to others instead of succumbing to your need to throw everyone under the bus.
Even when it follows trends and best practices, you might end up with non-malleable code. Perhaps especially when you over-do trends (eg: metaprogramming, 15 years ago) or best practices (design patterns, 100% unit test coverage, etc).
You will only have the same problem if you fail to solve the malleability problem.
Or perhaps the problematic people who made the code too rigid already left.
Using different languages and frameworks will also affect the outcome.
Maybe the Product/Business side is more mature and will account for malleability in the requirements.
Also, perhaps they already know how to do it, but "malleability" wasn't a goal for the previous version.
I dont know how code could be too rigid to change by a competent developer. If it has bad abstractions just rip them out. If it is unclear and badly documented, you will have the same problem when rewriting.
This is an unfair characterization of what I said. I never said it was impossible to improve, just that it is too difficult and costly.
Whether a rewrite is warranted or not, is up for each individual team to decide, we shouldn't leave this decision to dogma. I have run into some cases where a rewrite was the correct thing to do, and it did pay off.
> If it is unclear and badly documented, you will have the same problem when rewriting.
A program being unclear and undocumented on the development side doesn't automatically means it is unclear and undocumented on the business/product side. There is also the possibility of changing workflows or simplifying functionality.
A lot of people in this topic are mentioning full reuse of tests, but not all software rewrites should be done in a vacuum by the development team without continuous input from the rest of the business.
EDIT: And there's another case: sometimes the app itself is actually quite simple, but understanding things from the code-side is very difficult. I'm currently finishing a rewriting of one of those: the code is too large and unmanageable due to accumulated cruft (it is difficult to know what can be removed), but some product managers, business owners and business intelligence people have an amazing understanding of the database (better than some past developers, actually), and the database is simple, so they can verify if the new version is correct and even draft requirements based on it.