Our experience may have not been the same, but I beg to differ. If the old solution is so problematic that nothing can be salvaged from it and the best solution is a full rewrite, instead of some refactoring or modifications, then your problem is not so much that the code is solving the wrong problems. The problem is the team that built it. Every time I was ever called to rewrite a code base, there were certainly some elements that pointed to a clearer understanding of the requirements, but mostly, the necessity to do it from scratch pointed at a people problem.
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.
> If the old solution is so problematic that nothing can be salvaged from it and the best solution is a full rewrite, instead of some refactoring or modifications, then your problem is not so much that the code is solving the wrong problems. The problem is the team that built it.
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.
yes, and also developers grow over time - not every company starts with 20 years of experience seasoned developers.
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
It sounds like most of the application complexity was the UI layer? In a typical app, the UI is an interface to some functionality or business logic which is the actual value of the app. But if the application was something like a GUI builder, I guess most complexity would be directly coupled to the GUI framework.
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.
> I think you're too quick to point fingers and too desperate to throw people under the bus to pass yourself as saviour.
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.
> Thanks for the free armchair psych analysis, but that's not why I came today. I'm here to compare patterns about our practice.
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.
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.