Throw that code away
Why investors should have no fear when their startups want to throw away their entire codebase
I'm writing this article in the hope that it will increase your understanding of why startups need to continually invest in their codebase and occasionally need to throw it all away and start again.
If your team is doing things properly from the start, you will probably need to throw your entire codebase away at some point.
Most startups are now embracing the ‘lean startup’ methodology to one degree or other, at least paying lip service to it. However, many investors and don't fully understand the consequences of it. Even more so, I'm often meeting founders who are struggling to justify new investment in their codebase, because they don't understand the process and can't articulate it to investors who are wary of any ‘unnecessary’ spending.
At the start of the year, my previous startup (www.enthuse.me) ran out of cash. The majority shareholder hired an external developer to review the codebase. Part of his review include a major criticism that the codebase needed rewriting, this guy didn't get it, the investor didn’t get it and it led to a long protracted and unpleasant email chain. The upshot was that the investor didn’t understand where the value in the business is, for most early stage web startups, it’s not the code.
More recently one of my clients has been battling away with their investors, trying to explain that the use of funds for 2014 will include a rewrite of their codebase. The conversation uses precious time that could be spent finding new customers, creating revenue and value in the business.
Writing bad code quickly
At the earliest stages of your business you will probably be writing bad code that you will throw away soon. This is because ‘Lean’ is challenging you to get answers quickly. That means testing your product with customers as quickly as possible.
An MVP (minimum viable product) should be developed quickly, iterating quickly with the customer feedback loop in full swing. This means that you may very well end up with a bloated, poorly architected application.
If you don't know exactly what you’re building (and you can't know until you have customers using it) you're likely to build things badly. In reality how could you have known that the stack you choose no longer would fit your requirements a year later. How could you have known that 50% of the initial features which you fully integrated into the app would need removing?
When to ditch your code
Here’s the good news: You're allowed to write bad web code at the start. You're also allowed to ditch your codebase and rewrite it.
The first time you are likely to consider rewriting your codebase is when you've ticked the following boxes:
- completed your MVP
- tested it with real users
- iterated on design and implementation
- you have a clear view of the ideal feature set
Despite the terms I have used above, it’s not bad code if the process has been useful and you're prepared to ditch it if needed. It’s actually good practice!
In response to publishing this article, I have been accused by some of challenging a software development axiom which has become also orthodox belief. Joel Spolsky wrote ‘Things you should never do Part 1’ back in April 2000. His thesis was that you should never ever throw away your codebase; he has great arguments to defend his position which have stood the test of time.
However, I believe the context was completely different. He’s talking about established products with established codebases. An example he gave was Netscape's decision to completely rewrite its web browser which possibly cost them their market position. What I'm talking about is completely different. I’m talking about a product that has not been fully born yet, a business that hasn't decided if it’s a web browser or a web server yet. I therefore stand by my article above and reiterate that it applies to early stage businesses.