Let's Rewrite Everything

However, I have had success in rewriting my own code base a number of times. This is a unique situation of a one-man-band that understands the business case, handles support, and every bit that went into every decision of the code base.

With this kind of clarity, when you've spent years with the problem domain, you can uniquely rewrite a project to get at the real business case that, now with years of experience, you see what your customers actually wanted you to solve in the first place, or maybe what they evolved to want in the end.

Jim Keller advocates rewrites in a similar way as the only way to progress in chip design.

I think we could rewrite very basic things in exciting ways with this sort of attitude. For instance, we know a lot more about what we need in a desktop OS, an email client, a search engine, etc. Basic things that have gotten a lot of cruft over the years as they evolved. Taking a fresh look could be rewarding.

I guess one could reframe this as 'first principals thinking" but with the caveat that the problem needs to be truly understood.

Here's Jim Keller talking about it: https://www.youtube.com/watch?v=Nb2tebYAaOA&t=1361s

However, "X2" was definitely an example of an appropriate rewrite. It had the following conditions:

* The existing code "X" was the product of an early-phase startup which hadn't yet figured out what it was going to do. "X" already existed at the point we were still asking questions like, "Who is the customer?" with possible answers like "The NSA and similar entities" even though it eventually became a consumer product - and so obviously it was very flexible but had also been greatly distorted from its original conception to produce a product we were actively selling.

* The existing code was developed and maintained by a third party team. So the knowledge of how that system worked was something we'd need to absorb anyway to bring it in-house. Existing code reflected house style of that team, and X2 would be in our style.

* It was modestly sized. I think our plan said our small team (less than half-a-dozen people, not all of them available for this full-time) would rewrite it in one calendar year, with an MVP in maybe six months and from there simultaneously copying less important features from "X" and also new want-to-have features to get the finished "X2", that's roughly the timeline we followed.

* I was pretty confident we could execute from the initial description of the work to be attempted. I went into a meeting assuming (as I always do in all-hands meetings) that I'd get fired, and came out thinking I should brush up my Java (the chosen language for "X2") but it seemed very possible.

* The non-technical leadership actually wanted a new system. "We need a new pig" is how it was explained back to me by the CEO. (From "Lipstick on a pig" the idea that superficial changes to a product can't really disguise its flaws) so there was buy-in of this idea and nobody yelling at us about why the "X2" MVP doesn't deliver most of the things "X" didn't have yet.

[This software, and its predecessor, had code names but somebody let me name the successor software and I have no imagination so although it wasn't literally "X" and "X2" that's about how similar the code names were].

Perform a root cause analysis for why the current code is in a bad state and why it doesn’t improve over time.

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

Very good post, that holds a lot of experience. Unfortunately these things have to blow up in your own face, often more than once, for a lesson learned.

> It’s a bit smarmy of me to criticize them for waiting so long between releases. They didn’t do it on purpose, now, did they?

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.