The dream of v2

2026-06-15T09:17:19.000Z

Joel Spolsky once called it "the single worst strategic mistake that any software company can make", and not for nothing:

"When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."

Even twenty years into my career, despite understanding, both logically and from experience that a rewrite is a high-risk move with limited chance of success– I still find myself daydreaming about it.

It's easy enough to dismiss other people's mistakes, or even your own, as not applicable, even easily avoidable. But software is built in a time and a place and under very specific conditions. You don't get to reset to the same preconditions and try again. Every retry is a completely different game.

Fred Brooks described one variation of this as the second-system effect in The Mythical Man Month:

"...the tendency for a successful first system (often small and relatively elegant) to be followed by a second system that becomes over-engineered or bloated."

Perhaps it's because I've mostly worked in startups, but the first systems I'm familiar with are big balls of mud^[1] ^[2]that accrue from generalists and novices building products while still trying to understand the domain – and of course find their customers.

As far as I can gather, this is par for the course in startups. It's rarer than perhaps it was in 1976 for a company to start with a team of seasoned specialists working on a domain they fully understand, for a customer that is well defined. Of course, even that is no guarantee of success.

There is also a helpful corollary:

"Brooks separately argues that teams should often expect to build a pilot (or throwaway) system to learn what is actually needed; the management question is whether to plan for that throwaway in advance or to mistakenly ship it as the final product."

I don't think I've ever seen a pilot that does not become the first version of the product. Again, perhaps this is because I've worked mostly in smaller companies, but generally a working artefact for a real problem is too valuable to discard.

I can imagine companies and products where this is different, though they all live in a cozy 90s corner of my imagination where release cycles are multi-year, cash is plentiful, and in defiance of Euclidean geometry, every office is a corner office.

For startups you often must first build a big ball of mud, and you cannot throw it away.

Until now, maybe?

#Fast, good, cheap

There is a project management model called the iron triangle which will be familiar to many software developers. If you don't know it, the basic idea is that there are trade-offs when building something. If you want it done faster, it's going to cost more, if you want it to do more, it's going to take more time, etc. Fast, good, cheap: pick two.

Coding assistants are rapidly changing how we write software. The adage that you can only pick two of fast, good, and cheap, is going to be tested.

In particular, the bar for quality will be permanently raised. In some sense this is not too different from the way that the quality bar for an app or website has risen in the last 30 years – just at a faster rate.

Software is now cheaper to produce; more niche software can be produced by people who don't need to be seasoned software developers. I think this will be good, on balance. There will be more crap, but also more interesting esoterica.

This also means that at least some of the risk of a rewrite should be going down commensurately.

My own timeline for delivering functionality and fixes has gone down, sometimes by an order of magnitude. Code I would comfortably predict would take several weeks to write, test and iterate on in 2025 can usually be produced in a matter of days now. Bug fixing, which often has a higher cognitive burden since it requires more reading than writing, has often become a background task while I'm doing something else.

#A golden era of rewrites?

There's still no magic pipeline to pour in a big ball of mud and have polished marble come out the other side. However, making the process cheaper and easier is going to bring it into the realm of attainability for some projects.

There are techniques being developed, producing results like the quasi-clean-room rewrite of chardet, or the rewrite of Bun from Zig to Rust.

Reproducing a piece of software, or transliterating from one language to another is one thing; a rewrite to me though suggests something that, at minimum, is fixing deep architectural debt. Ideally, it's unlocking new avenues for development, such as faster delivery or improved functionality.

This is a higher bar to reach than mere reproduction. Partly this is because what defines a piece of software, a product, is in people's heads. It's in the various expectations of customers, developers, and business owners, amongst others. It's also the case that providing the original code to an LLM will inevitably anchor the rewrite to the original in ways that may be undesirable.

That said, I have found an agent-based full rewrite valuable even when not shipping the final result. First, it has given me a chance to test out ideas that would have been difficult to retrofit even into a feature branch – the kind of stuff that means tearing out whole subsystems or redesigning the architecture.

Since it's so fast to do, it allowed me to get to a working state very quickly, become more ambitious, and discover things that I might never have done by incrementally improving the original codebase. Some of those ideas were then ported to the original system.

It was also truly cathartic to fix all the things that I feel are broken or badly designed in the original code.

Also, if I'm honest it helped me touch grass a bit and appreciate the value of a functioning system. Sometimes it's easy to forget how much work has been done when all you can see are the flaws.

Certainly it is now easier to produce something complex and polished. However, it still takes time, effort, and money. It still has to be deployed, improved, and maintained. There will still be bugs. Most importantly it still has to be built with intention, and serve customers. It can't just be whatever the agent decides is good enough.

Everywhere you look people are still buying software. They are still complaining about software.

Nobody has the time or money to rewrite every piece of software they use on demand. It may take the market a while to realize that, though.

Notes:

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated.
– laputan.org https://www.laputan.org/mud/mud.html#BigBallOfMud
–

@duggan — software-development

The dream of v2

#Fast, good, cheap

#A golden era of rewrites?