Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know Joel says that rewrites are always bad, m'kay, but that is assuming the person who wrote the code in the first place had some idea what they were doing.

I've got a medium sized (for a single developer anyway, ~18k LoC) C++ project, which I started when I did not truly know C++. Therefore, there are several things that are just... wrong. Wrong is the only way to describe it. It needs to be rewritten, plain and simple.

However -- I've spent a long freaking time doing the rewrite -- bugs in the original aren't getting fixed. However, some of the bugs themselves are problems with the architecture of the original tool -- and some of that is what I need to fix would require touching almost every line of code anyway.

On one hand, I feel fixing the bugs in the old program is going to be a massive wasted effort, because those bugs aren't even possible with the new design I've been working on. On the other hand, I've felt that I've neglected users of my original program because it's not been updated in so long.

What should I do?

share|improve this question
Keep your users happy, or you won't have anybody to develop for...? – Marjan Venema May 29 '11 at 6:55
Learn a "phased approach". With actual, paying, deployed customers this is very important. – Job Jul 9 '11 at 3:47
@Job: Generally I do try to do that. However, there are times when the original system was complete garbage, and attempting to go further with it is unreasonable. In my case, it was the first serious program I had ever written in C++ and it was full of nastiness. – Billy ONeal Jul 9 '11 at 3:54
up vote 4 down vote accepted

It sounds like you are suffering from Second System Effect.

I would suggest going back to the old system. Then choose between refactoring (which I'm not as big a fan of as many around here) or trying to write a minimal usable replacement for as little of the functionality of the original system as possible. But stay well away from, "Here is my grand design for how to do everything right!" Because that way there are dragons that have burned many unwary developers.

share|improve this answer
Back to the old system it is. – Billy ONeal Jun 2 '11 at 21:48

The cases where you have to rewrite every line of code are rare, especially for large projects. How can the code be wrong at every line of code, after all? What's wrong with the following line for example?

int a = b + c;

What is important, on the other hand, is to do refactoring regularly.

  • Some refactoring changes may be small (change the name of the local variable pi to productId, because, well, pi is too misleading).

  • Other changes would instead force you to modify the whole structure of your application and affect thousands of lines of code.

The most important think in this case is to have a solid reason to do the refactoring. Spending thousands of dollars of a customer refactoring a code which will not even be used in a few months is not a good idea; on the opposite, spending thousands of dollars refactoring a code which is nearly impossible to modify and for which, each change has an extremely high cost, is not so bad if the code is intended to be used for years.

In all cases, you can avoid whole rewriting by doing small refactorings. For a week you refactor one part of a code, letting other parts for further refactorings. Months later, you begin refactoring another part of your code, etc.

share|improve this answer
+1 for refactoring. – user2567 May 29 '11 at 9:21
It should be multiplication. – alternative May 29 '11 at 11:56

Two things:

  1. It is said that only 20% of all features in a system is actually used, so if you want to shorten the rewrite time, consider working only on those 20% and release when they are done. Work incrementally.
  2. You should use your knowledge of the old system and make the new system better, more focused and user friendly. Simply mimicking the old system piece by piece doesn't really give your users anything valuable.
share|improve this answer

This is a bit of a cop out answer, but if you find yourself getting too conflicted, that can in itself be your worst enemy. I think there's merit in both points of view. Search your feelings on it and commit to it, and follow through. In the end, it'll be about whether you completed or not. I doubt anyone will persecute you if you deliver.

share|improve this answer

In my experience, when you have a project that is quite simply wrong from the bottom up, the best thing to do is set fire to it all and run around in your underwear for a bit, before sitting down and not just doing a rewrite, but a complete, bottom-up, clean-room rewrite of the entire project.

Some projects can be refactored into submission, sure, but some, …

Not so much.

Especially in old projects; starting out with a clean slate using modern tools is usually faster and less error-prone than trying to do a line-by-line rewrite; at least in my experience.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.