All software is a work in progress none is ever perfect. It will always have bugs, sometimes it might even seem that the software is nothing but bugs an it's in these dark times when we normally say fuck it, let's start over. Not always, some of the good excuses I hear for a rewrite are:

• New blood Someone new comes along and the first thing they suggest is a complete rewrite - It's alarming the number of times I hear this suggested. Sometimes it's contractors, which is somewhat exusable - it's more billable time for them. Other times it's by people newly in charge or new to the team.

• Team members have left - rightly or wrongly they've been blamed for the code, and coding them out seems like a good idea

• Too many bugs - An effort to hammer out the bugs feels like it would take longer than to rewrite from the ground up

• New tools! - A shiny new framework is out and you want to use it, it will solve all your problems and put all your spare cycles to work sorting out poverty and war.

Common to all the above is the fact that everything seems like it would be easier if only you could get out from under the crushing weight of legacy. And it's a very attractive fallacy; Bugs could be solved by reworking the architecture; Features would be easier if only the code wasn't written that way; That new framework would fix the bugs we're seeing because of the one we're using.

resist the temptation

They sound like good reasons, but that's the problem with attractive things that are bad for us - they're attractive. It's so much easier to believe that the grass would be greener if we re-turfed the lawn than to work out how to fix those brown patches.

it almost always takes longer than you expect

A complete from the ground up rewrite will take longer than you think. It will probably take almost as long as it took you to get where you are now. It's tempting to believe that you don't need planning meetings to work out what has to be done. It's right there a spec in the current implantation, just get started! So you're initial estimate is just a stab in the dark anyway.

Add to this the further false belief that since you implemented the features once already, you'll be able to do it faster this time around. You won't, well you might - but you won't implement them as optimistically quick as you think you will.

Throughout the process you'll also be further from a releasable product than you think you are - much further. In a rewrite you have to rewrite every feature all those "all we have left in component x to do is..." bullet points add up.

All of this leads to one last problem with timescales for rewrites - in order to get anyone else to buy into them they have to be wildly optimistic about the schedule. So just when you need everyone most motivated and excited, as you're gearing up for a release, you've set them up to be demoralised by missing an increasing number of deadlines.

you're reinventing the [buggy] wheel

Programmers are people, people are creatures of habit. You'll inevitably end up implementing part of your radical new system in a very similar way to your existing system. Then you'll be forced to make the same compromises as you've made before and you'll undoubtedly introduce some bug that's already been patched in your existing software.

Some of your old code will also be good code, at best you might cut and paste it into the new code base but for the most part though trying to hammer it into place and wire it up is going to be as long and as buggy a process as rewriting it. So instead you follow the rewrite it all logic and rewrite it all.

you're standing still

When you're rewriting your software you're stainding still in almost every way possible. If you're rewriting everything, you're spending an awful amount of time not moving your application or business forward. Personally and professionally you're not learning much new (unless a new framework is your excuse).

Even if you're squeezing some features into your rewrite, probably because it's been so long since a release you'd be lynched by a mob if you refused, it's so long before the users are actually going to see them that you might as well not be. The perception of your software isn't going to be sometimes shaky, but getting better all the time - it's going to that it's buggy and the bugs are never fixed.

you'll probably end up no better off

The sad and somewhat painful truth is if a team can't fix something - getting them to make a new one is probably not going to fare much better. Your new version is probably going to be no better than the old, will certainly be worse than an itteratively developed and incrementally improved version of what you had could have accomplished in the same time.

Also problems you're having with a framework or tool probably aren't going to be magically solved by using a new one. Most of the these arguments are born out of a naive belief that because the framework isn't doing what the developer is expecting, the framework has bugs, changing frameworks should then solve the bugs. The problem is of course developer expectation versus reality and more often than not due to some underlying misunderstanding of the platform the framework or tool is abstracting - a reality that a new framework cannot change.

how to sensibly go about a whole rewrite of your software

While it's not sensible to start a full rewrite of your software, it's also ludicrous to decide that nothing written should be changed. Software development is a process not an event. If it's not working fix it; if it's complicated and bug prone, refactor it; if it's shit, code it out. Just don't throw the good out with the bad.

Start where it hurts

In the case of bug riddled software start with an area that is causing the most trouble. Patch the big bugs first. It can be a painful process, I won't lie. It's demoralising to everyone to have buggy software and it's not exciting or glamorous to fix it.

Bug fixes are one of the most thankless tasks developers are asked to perform, so make sure you break it up with some of more challenging and interesting tasks, throw a few features into each iteration.

if I could do it all over I'd change...

These are the generally the things that are hurting the developers rather than the user. Some of them are far reaching, architectural or framework choices. They can all be fixed though, and you don't need to rewrite the whole application to get there.

Again, start with the ones that hurt the most, if it's part of the architecture refactor it. If it's a framework you'd like to integrate to solve problems, try it out on part of the code and work to roll it out incrementally.

I promise it will be quicker, a lot quicker to go down the incremental route than it will be to rewrite the whole thing in one go.