There's a wonderful line in Fred Brooks' book "The Mythical Man-Month", where he says that when writing a program, plan to throw one way – you will anyway. But that's a bit of a problem for conventional software development, because it's not clear when the best time is to throw that one away.
Doing it during development means delaying the public release, and that will cost you market share and possibly the entire market. First-mover advantage means that the really important thing is to get out there with something – however ropey – and hope to patch it up as you go along (think repairing aeroplanes as they fly....)
That implies you will need to throw one away after you've launched it. However, by then you will (with luck) have an established user base, which means that you can't stray too far from the first version – lack of compatibility when upgrading is one of the worst sins against your users. So your developers' hands will be tied, and at most all you can do is tweak (this is precisely why every Windows upgrade has been flawed: Microsoft is trapped in its past and forced to bring so much historical baggage with it.)
So what about in the open source world? Here's a fascinating example of what can be done, in this case by the founder of the popular CouchDB program, who has just announced that he is forking his own code to create Couchbase:
With Apache CouchDB, much of the focus has been around creating a consensus based, developer community that helps govern and move the project forward. Apache has done, and is doing a good job of that. But for us, it's no longer enough. CouchDB was something I created because I thought an easy to use, peer based, replicating document store was something the world would find useful. And it proved a lot of the ideas were possible and useful and it's been successful beyond my wildest ambitions. But if I had it all to do again, I'd do many things different.
So how does he propose moving forward from CouchDB?
Building on the previous Apache CouchDB and Membase projects, throwing out what didn't work, and strengthening what does, and advancing great technologies to make something that is developer friendly, high performance, designed for mission critical deployment and mobile integration, and can move faster and more responsively to users and customers needs than a community based project.
With open source projects, the great advantage is that you can effectively throw away other people's projects by forking them and keeping just the bits you want. In the case of CouchDB it's even more interesting, because the person doing the throwing away is the founder of the project, but is now forking code that includes contributions from those that built on his work.
It's this flexibility to use whatever you want from other projects, whenever you want, that lies at the heart of open source's power. The "throw one away" moment doesn't have to be singular and fraught: different groups can keep on throwing away the code, forking it to start their own rewrites as and when they please. If they are meeting a real need, the fork will flourish; if they don't, it will fade. Meanwhile, the original code carries on – or is superseded; the community and market decide which they value more: continuity or innovation.
In other words, where "throwing one away" is deeply problematic for proprietary software companies, for free software it's a source of constant renewal.