[Sebb767]

> And I’d go further than that. I’d suggest that, contrary to what intuition might tell you, refactoring might be better achieved by throwing the code away and starting again.

I don't think this applies in most situations. If you have been part of the original core team and are rewriting the app in the same way, this might be true - basically a lost code situation, like the author was in.

However, if you are doing so because you lack understanding of the original code or you are switching the stack, you will inevitably find new obstacles and repeat mistakes that were fixed in the original prototype. Also, in a real world situation, you probably also have to handle fun things like data import/migration, upgrading production instances and serving customers (and possibly fixing bugs) while having your rewrite as a side project. I'm not saying that a rewrite is never the answer, but the authors situation was pretty unique.

[OccamsMirror]

Anyone truly considering this should weigh up this post with the timeless wisdom in Joel Spolsky's seminal piece, 'Things You Should Never Do'[1]. Rewriting from scratch can often be a very costly mistake. Granted, it's not as simple as "never do this" but it's not a decision one should make lightly.

1: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[dgfitz]

Fifteen years ago I agreed with his point. Today I do not.

[chronid]

The last rewrite I've seen completed (which was justified to a point as the previous system had some massive issues) took 3 years and burned down practically an entire org (multiple people left, some were managed out including two leads, the director was ejected after 18ish months) which was healthy-ish and productive before the rewrite. It's still causing operational pain and does not fully cover all edge cases.

I'm seeing another now in $current_job and I'm seeing similar symptoms (though the system being rewritten is far less important) and customers of the old system essentially abandoned to themselves and marketing and sales are scrambling to try to retain them.

Anecdotal experience is not so good. Rewriting a tiny component? Ok. Full on rewrite of a big system? I feel it's a bad idea and the wisdom holds true.

[kubanczyk]

Spot on. It seems that OP is considering (1) a rewrite that can entirely fit into the mind of an engineerXYZ, and also (2) will be led by the same engineerXYZ, through executive empowerment.

I guess that in your case probably (1) did not hold. Or maybe (2) did not hold, or both.

OP's experiment doesn't prove at all, that an entire org can rewrite a complex app where 1&2 do not hold. Every indication we have is that org's executive functions perform abysmally for code writing (and rewriting). So exactly the point you are making. It would obviously mean that there is value in code, along the value in the org, once we get above the level of the value that conceptually fits into 1 head.

[RangerScience]

IMHO, anecdotally, if you attempt a full rewrite under the same organizational conditions that resulted in code bad enough to warrant it...

...you're gonna get bad code again, or, as you say, worse. The impact of the organizational culture dwarfs everything else.

[zahlman]

I'm trying to make a small, efficient alternative to Pip. I could never realistically get there by starting with Pip and trimming it down, dropping dependencies, reworking the caching strategy etc. etc. But because I've studied Pip (and the problems it solves), I have a roadmap to taking advantage of a new caching strategy (incidentally similar to uv's), etc. - and I'll (probably) never have to introduce (most of) the heavyweight dependencies in the first place.

Understanding doesn't have to come from "being part of the original core team". Although if you aim to be feature-complete and interface-compatible, I'm sure it helps an awful lot.

[degamad]

You've hit on an important point in the article:

> if you are doing so because you lack understanding of the original code

As I understood it, the key point of the article is that the understanding is the value. If you don't understand the code, then you've lost the value. That's why rebuilds by new folk who don't understand the solution don't work.

[fragmede]

Large sweeping software initiatives that go nowhere and are replaced by a product from a more agile team aspect isn't that unique, though the author being on both teams is.