Software startups are fun. In the early days, you have an idea, and a few developers (usually including one of the founders) cranks away and manifests that idea into an application that sort of works -- every other day, except Mondays, or on days when you're giving an important demo.
Hopefully (if you're smart), you get the software into the hands of real people as early in the process as possible. If you're even smarter, you get some of these people to part with money in exchange for suffering the pain and agony that you're going to invariably subject them to. This getting money from your users is called "selling software" and although it seems quaint in this age of advertising-driven business models, it used be all the rage back in the day, trust me.
As time goes on, you continue to get users (and possibly customers), and keep trying to make the software better. You work on two kinds of things: new features and bug fixes. You work a lot. Crazy long hours are spent. If you've been listening really hard to your users and doing something about the problems, then one day, you'll wake up in the middle of the night in a panic and check on the servers because it's no longer acceptable for the software not to work on Mondays. You discover that the software is actually still up, but you decide to stay up and code some anyways, because you're already up and and might as well get that new feature in, because you have lots of users now. This is called "success". Congratulations!
Then, some months later (or the following Monday, whichever is sooner), you're going to start wondering whether what was built was really done "right". Will it scale? Did you pick the right platform? Did that developer you brought on mid-way into the process create a bunch of crap, but you were so busy, you didn't really know? You begin wondering for the first time whether you should consider rewriting the software from scratch. You start looking for good reasons to rewrite it all and start "clean".
To save you some time, I'll identify for you the most common reasons/rationalizations people use for rewriting their software. This will spare you the effort of having to come up with the reasons yourself.
Common Excuses For A Software Rewrite
1. The Code Sucks: Things have become harder to change. Every time you fix something, two new problems pop up New developers joining the company are starting to throw-up over what's there right now.
2. "We're So Much Smarter Now": The development team argues that they understand the problem so much better now and had they known from the start exactly what the market was going to need and the features that would have been required they would have architected things better. Now that they know, it's time to redo it.
3. We Picked The Wrong Platform/Language: New developers joining the team can't believe the idiocy of picking Java/C#/Python/Ruby/PHP/Whatever. How stupid and lacking foresight were the individuals making the initial decisions! Surely, the clear and better choice now is Java/C#/Python/Ruby/PHP/Whatever (i.e. something different than what was picked before).
Now, that we've got most of the common reasons identified, I'm going to tell you that in just about all cases (especially yours), you should resist the temptation to rewrite from scratch. Here's why:
1. It Will Take Longer Than You Think: Despite what you may think, rewriting your software will probably take almost as long the second time as it did the first time. Sure, you have more information now on what you need to build, but this information is already dated.
2. Markets Change: Chances are, your market is not going to hold steady and wait for you to get done with your rewrite. While you're busily rewriting the same software again, things are changing. Competitors are coming in. Demands are different.
2. Existing Customers Become Frustrated: Existing customers are going to want fixes and features to the old stuff (the stuff you're getting ready to throw out). The best you're going to be able to do is hobble along on some old version of your software, make small fixes, make all sorts of promises to customers about why the next version is going to solve all their problems. You're going to sleep even less hours (if that were possible). There just won't be resources to maintain your existing software and work on the rewrite. Even if there were, you're probably then going to have to deal with two different versions of the codebase which creates a whole other set of problems.
3. Refactoring Can Cleanup The Code: If the code is indeed a mess, you don't necessarily have to rewrite everything all at once to make it better. Refactoring is a great way to do this, a step at a time. (Refactoring is changing the internal structure of the code without modifying its external behavior). The upside to this is that all along the way, you still have working software that you can change.
4. You Don't Control The Rewrite, It Controls You: One of the great things about refactoring is that you get to pick how much of your time you allocate to cleaning up existing stuff and how much you allocate to responding to new market demands. (And please spare me the excuses that you don't have the discipline to refactor, you're better than that). Should some massive change happen in your market (like a worthy new competitor), if you are refactoring a piece at a time, you have a fighting chance of responding. If you're in the middle of a rewrite, you're probably toast.
Clearly, I have an opinion on this topic. So, when *would* I advocate actually doing a complete rewrite?
Example #1: You decided to write your software in Lisp because you thought it would cool and you'd been wanting to learn something new for a while anyways, and you figured hey, "even if my startup doesn't succeed, at least I'll have learned something…". Later, you have this uneasy feeling that you didn't really make the right choice which is confirmed by the fact that none of the other developers you're trying to recruit to join you are actually smart enough to program in Lisp and those that are refuse to work for just equity and live on red beans and rice. And besides, though the software is brilliantly architected and designed, it was never quite, well, released. And despite the fact that your technical choices give you the ability to stand heads-and-shoulders above your competitors as you scoffed down at them, for some inexplicable reason, you ended up never actually making any money. [Author's note: I have nothing against Lisp, I could have easily contrived another example].
Example #2: There's some big technology landscape shift (like going from client-server to web-based computing) and your existing stuff just doesn't work well in the new world.
For more on this particular topic, I recommend Joel Spolsky's "Things You Should Never Do, Part 1" It's an oldie, but a goodie. One of Joel's earlier articles (from back in 2000), but still relevant, in my opinion.
So, what do you think? What are the signs you look for that would make a rewrite the right choice? Have you actually tried a rewrite before and lived to tell about it? Would love to read about your experiences and/or insights in the comments.
---
By the way, as I get ready to post this, Boston is celebrating a World Series victory. Woo hoo!