The dream of v2 - @dugganThe dream of v2<br>🤖AIStartupsSoftware Development<br>July 7, 2026<br>Joel Spolsky once called it "the single worst strategic mistake that any software company can make", and not for nothing:<br>"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."<br>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.<br>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.<br>Fred Brooks described one variation of this as the second-system effect in The Mythical Man Month:<br>"...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."<br>Perhaps it's because I've mostly worked in startups, but the first systems I'm familiar with are big balls of mudA 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.<br>– laputan.org https://www.laputan.org/mud/mud.html#BigBallOfMud

that accrue from generalists and novices building products while still trying to understand the domain – and of course find their customers.<br>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.<br>There is also a helpful corollary:<br>"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."<br>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.<br>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.<br>For startups you often must first build a big ball of mud, and you cannot throw it away.<br>Until now, maybe?<br>#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.<br>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.<br>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.<br>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.<br>This also means that at least some of the risk of a rewrite should be going down commensurately.<br>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.<br>#A golden era of rewrites?<br>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.<br>There are techniques being developed, producing results like the quasi-clean-room rewrite of chardet, or the rewrite of Bun from Zig to Rust.<br>Reproducing a piece of software, or transliterating from one language to another is one thing; a rewrite to me though suggests...