Refactoring vs Rewriting Codebases
The cluster discusses the debate between incrementally refactoring and maintaining existing codebases versus rewriting them from scratch, highlighting experiences with legacy code, technical debt, and the pitfalls of premature rewrites.
Activity Over Time
Top Contributors
Keywords
Sample Comments
"When all you have is a hammer, everything looks like a nail"Don't go into the trap of rewriting the code the first week, all new coders think that is the only solution on the first job. It takes time to realize why the code ended up in that state in the first place and badmouthing previous developers doesn't make you look very good. Management might very well know why the codebase looks like it does, priority is often time, not quality.Something that looks like a bug m
Rewriting a codebase does not always give great improvements relative to hacked together code.
- Real products get cruft. Developers always complain about the state of things.- Everybody writes bad code, and you learn and get better as you go along. If something is bad and you can see that and take responsibility, that sounds good, and it sounds like you have learnt and become better. You don't need excuses like "personal issues".- You aren't always going to be as smart or good as your colleagues, sometimes you just have to come to terms with that.- Major refa
I've literally experienced this exact gut reaction two times in the last couple of months at two different companies. Code that is working fine, might need a bug fix here and there, is deemed worthless and should be rewritten. These we're tiny dev team: 3, 4 people max, so it happens everywhere I guess.
I find that it's always worth the time. Even more so when I'm working on a quick fix code someone else wrote. I kind of have a few reasons for it:1. Making the code cleaner is reducing technical debt. This will help in the long run, and I just sort of do it as I go. It's like tidying the house - it is more efficient to do little things regularly than to have a giant mess to deal with later. The little things make it easier to do something later, because you don't find your
Code is (almost) always better when it's re-written. So, maybe it was a blessing in disguise...
Some people just don't understand that it's harder to maintain the code than to write new ones. They are probably not appreciating your refactorizations because they have not got to a point that it is almost impossible or super hard to write new code because the codebases are a large mess (they probably haven't got to this point because of your great refactorizations). But one day when they reach that point, I think they are probably going to miss and appreciate your past work.
Where could you have been had you focused on cleaning up your existing codebase?
Sounds like an excuse for writing bad code. I work with people who deeply care about the code quality yet somehow open to refactoring and design suggestions. If it is worth it, it is not going anywhere: care, refactor, maintain.
Bad code is something like a constant factor, you cannot avoid them even in somewhere like Google or Facebook. The variable here is if people are willing to accept improvements. Unfortunately, people usually tend to stop you from bringing major updates to the existing code base because this "could" hinder their immediate works. In this perspective, you're very lucky. At least, you don't need to fight your way to make a simple improvement because someone else just want to keep