"Rewrite from scratch everything that engineer X touched in four years of working here after he leaves" does not sound like a feasible approach to development. Also, while having good code separation between contractual APIs is a good goal and worth pushing towards, the idea that nobody would ever have shared ownership of any code unit between API contracts is too extreme.
"Rewrite it" is almost always the wrong answer, although it can be an overpowering instinct.
Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths:
1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me.
2) If I embark on rewriting it "correctly", the odds are very good that I will learn why the code was as it was in the first place, and my rewrite will undoubtedly have my own style, but will not likely avoid whatever issue it was that made me think it should be rewritten.
I've "rewrote" a lot of code in my career. I'm putting "rewrote" in quotes, because it was sometimes porting from unmaintained programs in obsolete platforms to something more modern (sometimes without even being able to run them), and other times by doing large-scale refactoring that left the codebase almost unrecognizable.
While I agree with #1, that "offensive" code is offensive for a reason (no time, no experience, no tooling, no hindsight), I don't really agree with point #2. With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.
IMO: bad code is often due to accidental complexity, often brought in by the programmers themselves. And very rarely due to essential complexity.
Your examples are excellent reasons to do a rewrite. Rewriting code is not always the wrong decision. But in the main, when it seems that a rewrite is warranted, it's a good idea to think long, hard, and objectively about why it seems like a good idea.
> With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing.
You're right. I should have been more expansive. The rewrite may not reproduce the same issue (although the odds are good you'll see what the issue was!), but it will have its own issues, and is also likely to eventually also become "offensive" code that a future dev will have the urge to rewrite.
I use the word "offensive" here in a technical sense, not in a judgmental sense. Great code can become offensive with time as requirements, environments, and development methodologies change.
The main thing is that rewriting code is very expensive in both the monetary and risk sense. In the end, it's a question of cost/benefit. If the benefit of a rewrite is less than the cost, then rewriting is the wrong decision.
> bad code is often due to accidental complexity, often brought in by the programmers themselves.
Yes, I agree. And the majority of it turned out bad because of maintenance. Too much duct tape and bubble gum has accumulated over time.
I find value in rewriting/refactoring it as a learning exercise. just take a quick pass. now you are in a really good position to talk about what the strengths and weaknesses are of the existing version.
Have you met, for instance, the "clean architecture" paradigm? No there are definitely patterns that will be used by developers which end up getting in the way of the intent of the code, making it harder to reason about and maintain over time.
The example that I had to deal with most recently used a "clean architecture" approach in an api. The incoming calls went through three layers of redundant code - of which each layer had its own set of unit tests - before hitting the db and then passing up the response back through the stack.
It deeply annoys me to have to deal with people who have some pattern like this that they read about and, I assume mostly due to its relative obscurity, they feel ... smart? ... when applying it and forcing whomever comes after to deal with it.
To say that I want to viciously rip out the redundant layers is an understatement.
I find the argument against rewriting to be like the DRY principle: an oft-misapplied rule of thumb causing much of the unwarranted complexity in software around us.
Truth is, the cost of “just rewrite it” is as large as your unit of software architecture. Prefer loosely coupled, cohesive small parts and rewriting to accommodate changed requirements becomes preferable to the alternatives that tack on complexity as landscape evolves.
The world and our model of it both evolve all the time; the current version is not a work of an idiot but a necessary step towards a better solution and a lesson.
> Truth is, the cost of “just rewrite it” is as large as your unit of software architecture.
Often, you pick "just rewrite it" when the complexity of a module seems to have grown too high and refactoring to reduce complexity or to hit new objectives seems difficult.
The problem is, a lot of that complexity there may be necessary because of subtlety. Or, we may not do all that much better the next time around.
There's a strong bias in software engineering in particular to underestimate inherent difficulties and overestimate our own capabilities. Sometimes a rewrite is a win, but this bias causes us to select rewrites in times when it ends up not being son.
The problem could be one level up though. It's not just the implementation of a part that's incomprehensible but the design/architecture of how some of the parts interact.
You should not rewrite something that works, only when you need to make larger changes, even if the guy who wrote the program is still there you might want to rewrite from scratch if the requirements change, like you now need to handle 100x more traffic and need to have something with better performance, or scaled out.
