Ask HN: How to tell someone you need to rewrite an entire project?

It's usually better to do things incrementally, even if the whole thing eventually needs to be rewritten and doing it incrementally takes twice as just rewriting from scratch.

Code that is working and in use is worth roughly 10x your imaginary code that doesnt exist. So unless you could prove to me that the savings or value is 10X the cost to rewrite I wouldnt do it.

Can you be more specific about why the code is bad? There are a limited set of architectural reasons for which I would support a complete rewrite. They typically correspond to non-functional requirements: 1) scale - the system architecture simply cannot support scaling 2) reliability - the system architecture is built in such a way that the system often fails 3) multi language - the system needs to be modified to support multiple languages 4) security - the system needs to be modified to support a more robust security access model etc (there are many items like this)

These things all touch every single bit of code and so could warrant a rewrite. Im skeptical of most other reasons. In most cases you can just modularize the most dangerous aspects and you will be fine.

I wonder, and this is not an insult, how much experience you have as a developer. I know that for a good five years, maybe more, as a developer in corporate IT I frequently thought that I was dealing with a "very bad" codebase and rewriting seemed like an easier task than trying to understand the current system well enough to make the changes I needed to make.

I was wrong. Every time. Unless the system is quite small and single-purpose, you very likely don't understand the full scope of what it does, why it is written the way it is, which constituencies it serves, all of its interfaces, etc.

The few times I have been involved in rewrites they always took longer than expected, cost more than planned, and ended up with kludgy patches at the last minute as features of the old system that nobody talked about or knew existed suddenly became showstopper must-have requirements. In other words, they turned out like almost any other corporate IT project.

I'm just going to attempt to answer your question rather than question your motives.

This is the difference between software and most other forms of "construction." There are no material costs. There is no scrap to reclaim. Bits can't be reused like steel. Tearing down code is negative work. This is also goes toward the odd feeling we often have that software shares so many attributes the fine arts even though it shares so many attributes with engineering disciplines.

First: realize that the word rewrite, not the act, strikes fear into the hearts of people. Just don't say it.

Second: realize that the difference between a "fix" and "rewrite" is nil. Are you going to fix it without changing it? Not if the problem is really in the code. You don't edit out the plot hole in your novel or unpaint your landscape into a lounging nude.

Now, the answer: say you'll fix it. You're really talking about the same thing. You asserted that it would be cost-effective and efficient. To me, that implies that it will address the urgency.

It's almost always quick and easy to fix what you know is wrong. The part that makes it hard, slow, and expensive is rolling it out. For instance, it may have taken a week to design a better data model for your SaaS app vs. a month to try to find and mitigate a slow query, but now you have to figure out how to migrate all of your clients, and that's a bitch.

Unless the project is really very small, this is always the case with very few exceptions.

Mind you, refactoring can happen at a fairly high level -- if you identify the worst, most broken part of the code and first lock down/simplify its interfaces, you can write a drop-in replacement for that whole chunk. Just remember that if writing your drop-in replacement is going to take weeks (rather than days)... or if your estimate keeps sliding..., you've probably chosen too large a chunk and should slice & dice a bit more.

I've had this discussion so many times that now I just have it with myself, and generally only say aloud the correct answer (though it's disappointing).

Psychologically, it's a beautiful thing to wipe the slate clean and just do everything fresh from the start. If only this worked as planned more often (and budgets were hefty enough to support "doing it right", and there were not already a user base who actually wanted to keep some of the broken bits because they knew how to use them already, and you didn't have to deal with a few team members who seemed to always be writing more code just like the old stuff, etc etc)...