Why You Should (Almost) Never Rewrite Your Software

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:


Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Why You Should (Almost) Never Rewrite Your Software


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:

Why Rewriting Is (Almost) Never A Good Idea

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!


Posted by Dharmesh Shah on Mon, Oct 29, 2007


I recently rewrote large portions of an existing application, and although I keep the "no re-write rule" in mind, I found there were two compelling reasons to do so: 1. To write out portions of code dependent upon 3rd components. In my case, I was using several components that caused 95% of my support issues. Getting rid of these was painful, but paramount. 2. The existing design doesn't lend itself to readily extending functionality. This type of refactoring is a judgment call based on (a) how much time it will take to recode and (b) how much time it will save you down the road. For startups, the time savings ROI must be very good because of the vagaries of time estimation and the short time window a startup has to succeed.

posted on Monday, October 29, 2007 at 4:02 AM by Nick Hebb

One possible situation where it might be smart to rewrite your software is when your underlying architecture is so screwed up that it makes the application slow and prone to failure -- e.g. when you have an Oracle expert write a PHP-based application server (a real-life example). A complete rewrite may also be a good moment to get rid of all the features that you have built in thinking that they will be usefuls but turned out not to be used by anyone. That being said, I agree with your points there, and especially I agree with the refactoring as the ideal tool to make a messy code into a relatively good architecture.

posted on Monday, October 29, 2007 at 4:50 AM by Berislav Lopac

You may be forced to rewrite when potential buyers refuse to buy your business(not your product) becausethe product is not written in Java/C#/Python/Ruby/PHP/Whatever(#3 from a different perspective).

posted on Monday, October 29, 2007 at 5:13 AM by hd

"You may be forced to rewrite when potential buyers refuse to buy your business(not your product) becausethe product is not written in Java/C#/Python/Ruby/PHP/Whatever(#3 from a different perspective)" How big a problem is this really? I'm sure that in some cases it does happen by I imagine the reasons behind this decision may be more to do with how they perceive (and to a lesser extent, use) the product. E.g They want PHP instead of Java. Why? They may like the idea of being able to add/modify functionality and they perceive this to be easier in PHP than Java. But is there an opportunity to change how the client interacts with the product to fulfil at least some of their requirements? If that program was written in another language but identical in every other respect, it would be provide business benefit to the client?

posted on Monday, October 29, 2007 at 6:21 AM by Andrew D

It is not how the product is perceived, because the product has a well established and happy client base. The problem is that the language/platform is considered too esoteric and the buyer has no confidence of being able to maintain (if some unknown problem arises) or rewrite the product themselves. Also, the market might not justify the buyer to risk the rewrite themselves.

posted on Monday, October 29, 2007 at 7:30 AM by hd

I am writing my comments for the purposes having of a mini-celebration! The Sox won! (Sorry Colorado. We like you but it was our time (again!) You’ll have your day in the sun.)

Dharmesh, you pose an interesting question. My old boss and mentor, Dale Reynolds says “its that one good idea” that starts you in one direction and you end up somewhere else because ultimately, you have a series of good ideas. To me, you never do a complete rewrite unless you aren’t getting traction whatsoever.

Due to be released Dec. 1, we wrotewww.epaperchase.com in .Net, C# using ActiveDirectory. Was it the right choice? We hope. Why? Growth, support, speed, infrastructure, object modeling, additional tool suites, etc. MS has the appropriate level of support. I considered open source. I love open source and what it stands for; however, I can’t spend time vetting the entire solution for exposures. It was a business decision. I’ll leave the rest of the exposure vetting towww.hackersafe.com .

The first major rewrite of code I did was as a consultant. There were bugs that I should have just solved. Instead, out of sheer arrogance, I took too long and rewrote the code to make it run faster. It didn’t solve the business problem any faster. When my VP asked why I rewrote it since it was for the most part complete, I said something really stupid like “What I wrote is faster and more elegant.” That really didn’t go over well since it was his code in the first place! Let’s just say I have learned lots about myself since then.

On rewrites; I think you rewrite code that does not perform (speed, business logic, user logic, interface). Getting there in the first place? I believe the critical thing is the foundation. Did you get your data model right? Is your security in place? Did you write with any object hierarchy in mind? Is it extensible? Does it scale? Language selection then becomes driven, in many respects, by what is available based on the platform you have chosen and what is acceptable to the constituency. Users on the other hand, almost never care. They want it simple and to work. It’s usually only the geeks and technology wonks (geeks in suits), and hackers who care. One last note – time is the only thing we can’t rewrite. Unfortunately, it drives everything.

posted on Monday, October 29, 2007 at 8:07 AM by John Stack

I have to disagree. I would say doing one or two rewrites is more the norm and I would even say it is recommended.

I am more maintenance and evolution oriented, but these days technology changes faster than ever. Best practices and available tools and techniques evolve rapidly.

Most importantly, you rarely understand the application fully the first time around. The first version of any system is inevitably off the mark in many ways.

Time to market is crucial and delaying development to 'get it right' is more costly than getting it close and getting it out in the real world where situations and users always reveal unexpected aspects and possible directions.

More often the impulse is to patch and evolve when you really should bite the bullet and rewrite. Or you should at least develop a plan for a methodical major overhaul done incrementally.

If you have good architects who have written major systems before, they know how to approach key aspects of the design such that they can evolve more readily when the time comes, and it *always* comes.

If you have mostly younger, less experienced developers, they will usually box themselves in and the overhaul process is more difficult and painful. This isn't good or bad, it's just part of the learning process. This is why it's usually valuable to have some more experienced system designers on the team.

The key is to be discerning and not to just take one person's word for it, or worse, to let the deveoplers operate unsupervised. The best approach is to have someone in management who understands all of these issues. Who can ask the right questions. And who can tell the difference and who can accurately and objectively assess the trade-offs.

This is why every senior management team needs a person who understands technology and has experience in these areas. Otherwise they are going by gut and often make the wrong decision or no decision at all.

There are no blanket rules that always apply. Each situation is different. You need people who can tell the difference.

posted on Monday, October 29, 2007 at 10:25 AM by Daniel Endy

If you have to do a full re-write, you're in trouble though. I agree with the evolutionary aspects of software design. I believe great object modeling helps in that regard.

posted on Monday, October 29, 2007 at 10:36 AM by John Stack

I'm not an experienced developer, but I think that once you can list the business requirements for your product, and identify how technology choices will solve that requirement, you can stay focused at the start. Reducing the temptation later on to say, "well x technology/programming method has certain benefits, let's rewrite the code to implement it. I'm currently in the design/implementation phase of a product I was to create a business out of. I had a lot of trouble deciding on the MVC platform and database(s). Whenever I think about the choice in my head, I start thinking about the various pros and cons and depending on my mood, I get different answer. But when ever I look at my list of business requirement for the product, the answer is always clear. Maybe not one that I'd like, but one that is best for the business. In the future if I see another technology that is considered better, I'll know that this is simply the progress of technology and is unavoidable. I'd be less likely to consider a rewrite, if I believe I made the best decision at the time. Having said that, it will be interesting to see how I feel 12-18 months after my product is released ;-)

posted on Monday, October 29, 2007 at 10:43 AM by Andrew D

One more thing. The key decision criteria should always be whether the system can do what it needs to do functionally, and whether you can enhance and upgrade the system effectively and efficiently.

It's not about technical esoterica. It's about real-world results.

If the developers consistently take too long to add new features, or say something can't be done, or if the system is consistently buggy and unreliable, you usually need to do something more drastic like a redesign.

I agree that if you have good experienced developers this is not a common occurance. Unfortunately those folks are not common. Furthermore, the current state of technology is fraught with pitfalls and unpassable terrain.

Sometimes you just have to admit you took the wrong path and start over. These days with so many choices that is a common occurance.

Microsoft would like you to believe that .NET has everything you need, all ready to go, but the reality is there are a lot of tricky issues like security models, and overall architecture which .NET does not address.

As a consultant I saw 70% of the .NET projects fail completely because of these issues. I was called in to fix it, only to realize there was no way out. That percentage should be lower today because those pitfalls are better known and understood, but most of them still exist.

On one project in particular, I brought in 2 highly respected technical people to plot a course out of the mess without a full restart, and neither one could do it.

posted on Monday, October 29, 2007 at 10:50 AM by Daniel Endy

I'm with you Dharmesh. Total rewrites almost never make sense. Refactor or change a subsystem. Many of the examples above underscore other problems.

More on my blog:




posted on Monday, October 29, 2007 at 11:43 AM by Bob Warfield

I would agree - re-writing the code can take just as long, however, there are certain times where the original code is so dated, it cannot handle newer concerns. A good example: Windows Never written with security in mind, and now they are building it in. I can guarantee they restructured the code, and look at the result. Could a complete re-write improve things? I doubt it would hurt.

posted on Monday, October 29, 2007 at 2:13 PM by TnT

Perhaps using an agile methodology (or another iterative coding process) can help in this decision but lots of 1.0 software written by founders is virtually unusable, especially considering a universe of applications developed over the last 20 years or apps that may not be built in web standards

I agree that it is a BIG decision.
I agree that it is never easy, typically costs more than budgeted and can significantly impact the company morale, sales process and focus.

However, at the point in time, when the support costs exceed the rewrite of the code and significantly impact customer satisfaction, a complete rewrite needs to be seriously considered.

posted on Monday, October 29, 2007 at 2:15 PM by Dan Tyre

I've successfully rewritten a few internal apps for a couple of financial IT depts. There are just some things that should either be retired or rewritten. It depends on the project, benefits, people, time, and talent. One of my primary reasons for rewriting an old app recently was to to make it more refactorable: support unit testing from the get-go. Bug fixes and enhancements to the old system were taking too long to test and implement and were never stable.

posted on Monday, October 29, 2007 at 2:28 PM by Dana

Thanks to everyone for your comments so far. Looks like we have a good discussion going. Just one quick note: The article was written primarily from the perspective of a startup (which is usually dealing with more constrained resources and newer code). Will let the conversation continue and respond to specific points later on.

posted on Monday, October 29, 2007 at 5:28 PM by

We've been rewriting our application since January and we hope to finally be able to match our previous functionality by this January. We have migrated all our users from the old system www.thelinguist.com) to the new system www.lingq.com) but our 6 month rewrite will be over a year before we're back to where we're satisfied. Never mind any new functionality. Sure, we've improved almost all facets of the site during the rewrite but the basic functions are still the same. Having admittedly taken at least twice as long as we projected, we are still happy with our decision and it was the right one for us. Our old system was limping along and we were spending more and more time holding it together. We also made a decision to switch from teaching only English, to teaching mulitiple languages. These and other significant changes would have been next to impossible for us to implement given the horribly restrictive framework we had in place. We truly did make a horrible choice the first time in our framework. An untested automated code generation platform. We've learned our lesson there! Having said we would have done this again knowing what we know now, we will never again rewrite our current system from scratch for all the reasons you gave!

posted on Tuesday, October 30, 2007 at 1:38 AM by Mark Kaufmann

I think a rewrite must be considered when the underlying architecture can't cope with new requirements anymore (scalability, usability, etc.). I quit my last job because of such a beast. I was hired as a software architect to turn an over 10 year old 2-tier application into a scalable N-tier application that can be distributed world-wide. A terrible mixture of technologies was already in use and I desperately tried to introduce an object model, component-based development etc. After two years I gave up because the upper management didn't move an inch and always said that the new system must have the same functionality as the old one, even when this functionality was too complex, too slow etc.

posted on Tuesday, October 30, 2007 at 3:10 PM by Michael Link

Regarding Dharmesh's comments about constrained resources, perhaps this is the key point. A startup is going to be constrained by time and skills (unless they have a generous VC funding them). And given these constraints some aspects will "de-prioritised". If I'm trying to build a web app I may not spend much time designing for security or scalability (and it's quite obvious that some companies do work this way - I've worked in them) because that may not matter much to initial customers.
Some may say that if you don't design for such things at the beginning, you're creating your own mess. But the truth is that you don't have time do everything well, because you're limited by time and skills. A few people with extensive experience in business or development have said to me, "Don't worry about getting it (perfectly) right the first time, just get it out there. Get some customers then go back and make it pretty". But it can be hard to tell what decisions will come back to bite you in a major way in the future, forcing you to consider a rewrite.
Are there key principles to adhere to which would reduce the risk of a rewrite, or does the list of do's and don'ts change from project to project?

posted on Tuesday, October 30, 2007 at 4:22 PM by Andrew D

With my one data point I can say its a bad idea. We had 6 months budgeted for it and it took over a year. Did we reduce our bug load? No, we actually introduced a huge heap of them in the conversions. Did we create a better working environment? Several people left the team during the rewrite out of complete frustration. Did we reduce the long term speed of deliveries for new features? I hope so, but we have a debt of over a year and the lose of some key team members. I highly doubt we will make up that debt in 1 year or 2 years or 5 years. To make up that debt in 5 years would mean the rewrite improves productivity by over 20%. From now on, my plan is to identify specific problems and focus on them for a shorter period of time. It is far less risky.

posted on Tuesday, October 30, 2007 at 5:52 PM by mccoyn

you guys forget about the bugs, not every bug is easy to see and easy to fix, sometimes you find bug when program is used by clients and if you do rewrite the whole thing you got a good change of using the clients to find that bug again (i dont believe that you will rememeber every little thing about the project, plus if you rewriting it doesnt that mean you dont like the code so you havent written it). Rewrites are good if project is small or you do it for fun in another language/technologii.

posted on Wednesday, October 31, 2007 at 1:07 AM by raveman

My approach is to refactor extensively as I develop. I will slip the schedule to do it right the first time. Much of my core functionality is hard as h*ll to get right and I have gone over the tough parts 3-5 times. I have a very complex but pretty clean and robust beta release product. I am satisfied with the result.

posted on Wednesday, October 31, 2007 at 3:24 AM by dissent

I believe there is a 'rewrite / refactor' threshold which was nicely illustrated in the first article. You should never rewrite code that you've already sold. The very fact that you sold it and that someone is using it is proof enough that it works and is valuable. Therefore you should refactor so that you remain both agile and responsive to your client base. After all, they are the reason you have the funds / resources to consider rewriting your entire app in the first place! However, as long as your code hasn't hit the market and no one is using it or building up on it then feel free to rewrite as often and as much as you care, because frankly, aside from you, nobody cares !

posted on Wednesday, October 31, 2007 at 8:48 AM by paco

Joel's original story is looking decidedly old - he cites Netscape Navigator as a prime example of what happens when a re-write occurs. But a big part of Firefox's success today is that it was NOT based on netscape and was completely re-written, so there's no hard-and-fast rule. Still, I'd prefer to refactor chunks of the application if possible.

posted on Sunday, November 04, 2007 at 9:39 PM by Mark McLaren


Although you've got some smart ideas here Dharmesh, I don't think you must abhor re-writing. It can work very well sometimes when the reasons are right. I can say that from experience. I re-wrote an app that I made in 1999 again in 2003 and it sales jumped way up! No it didn't take me longer to write the new app than the older app, and no, I wasn't dissatisfied.

In fact the experience was so enriching that I plan to re-write than app in a newer more advanced platform again early next year. I've already started laying the foundation.

Let me tell you a few reasons why it might be a good idea to re-write.

1. New competitors will have access to newer technology -- If you made your app in VB6, or Powerbuilder, or whatever... You can bet your every sweet dollar that market's going to be stolen when a competitor uses a newer technology to make a sweeter looking, better working application.

To stay competitive, it's better to re-write then to be obsoleted.

Yeah, you've given me an idea for an article there...

Cyril Gupta

posted on Tuesday, November 13, 2007 at 10:18 PM by Cyril Gupta

@ Cyril
Does really a new platform or the technology drive a product ? Or Some really good innovation ?
In my opinion It good to rewrite when you have a stable customer base and Your developers are free. I believe even worst written applications can be easily re-factored if planned properly. (Yes...even VB 6 app can be migrated to j2ee with some small bridges). As Joel has said, Earlier app is tested and fixed for a longer time so it more safer for a startup.
I have seen projects (In a startup companies) in which they started with redesign.The design was really promising. If successful it can Push up performance even 30 times faster. (And it was needed). But as joel said, When you start from scratch you have no guaranty that it will be better than existing ones. And even if it is; If it takes little more time; Your product has already lost its luster.
Especially for startups; Products are experiments. If they are successful they make business. If failed then however good they are they are of no use however best its written its useless.

posted on Tuesday, January 01, 2008 at 2:12 AM by Jigar Shah

Great article and comments. A few comments on our situation. Feedback is very welcome.
We have an internal application, over 10 years old, written in PowerBuilder v5 with a Sybase v12 database running on Unix. It is a reasonably well-built, well-designed application and there are few complaints from any perspective. A few circumstances, however, have us considering the possibility of a re-write:
1. Scalability. At some point in the near future this application may need to support twice the number of concurrent users. Our current infrastructure likely will not be able to support this growth and hardware upgrades will be necessary. At this point we could either upgrade the Unix server (high $$$) or migrate the database server to a Microsoft/SQL Server environment (lower $$$).
2. Disaster recovery. There currently is no disaster recovery in place for this application and there needs to be. The issues here are similar to #1 above. Do we implement disaster recovery for the Sybase/Unix platform or move to Windows?
3. Skills availability. Code and database support are provided by a third-party consulting company. The perception (not confirmed) is that local availability of PowerBuilder/Sybase technical resources will not be sufficient, and that we might improve this situation with more "modern" technologies.
I realize that there are many more things to consider and I'm sure my train of though may already be flawed, but I thought I would throw this out there and see if anyone had any thoughts or comments.
Thanks in advance.

posted on Monday, January 21, 2008 at 5:04 PM by Rich

Rich: You bring up some very good points.
In my opinion, you're in a situation where the cost/risk of not doing a major overhaul may be higher than doing a rewrite.
I think you're looking at it in the right way. The one thing I would do (if I were you) is to break it up into manageable pieces so you're not changing too much at once. For example, one could make the case to change the database platform first -- and worry about the app later. Or, the other way around. In my experience, by tackling smaller pieces at a time, you dramatically reduce the risk -- even if the net desired outcome is the same.

posted on Monday, January 21, 2008 at 7:19 PM by

Comments have been closed for this article.