Hacker News Reader

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.

For what it’s worth, I see this pattern too.

Rewrite a legacy .NET MVC app with lots of cruft. Build a new Node.JS app with lots of cruft.

> 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.