I've got some software that I wrote around 2 years ago and needs some features added to it. I've realised that it's in an awful mess, and I have the urge to move everything around, tidy up, etc. I've read the Joel on Software article about not starting again, so whats the best way forward?

  • Which decisions from back then do you disagree with today?
    – user1249
    Aug 17 '11 at 5:58

You have three basic options:

  1. If the app is very small and a real mess, starting again might actuall be your best bet.

  2. Refactor.

  3. Live with the mess and hack in the additional features.

Typically, option (2) is your best bet.

How much refactoring you actually do will depend on the resource you put in vs the value you get out. Questions to ask will include:

  1. What time / budget is available?
  2. How much modification do you anticipate in the future?
  3. Who else will see the code? (ie. will messy code damage your reputation?)
  4. Is anyone else expected to maintain the code?
  5. What refactoring tools are available to help you?
  6. What is your experience of refactoring?
  7. What experience will you gain from refactoring?
  8. What kinds of refactoring will give you the most benefits?
  9. What automated tests already exist? Need to be written?
  10. How much manual testing will be required?
  11. How will you feel if you leave the code as it is?

In my experience, it is very easy to get into proper muddle during a refactoring session. The most important lessons that I've learned are to:

  1. Do one thing at a time.
  2. Take small steps.
  3. Make good use of your source control (check in frequently + include comments).
  4. Make use of automated refactoring tools.
  5. Know the IDE.
  • 6
    I also would like to add to avoid having a broken state for too long. I've seen many open source projects quickly dying during an ambitious rewrite/redesign. A non-functional project kills motivation quickly. Dec 9 '10 at 11:30
  • 2
    Absolutely. Regarding ambitious rewrite / designs, I've fallen foul of this more than once. Now, I try to take things in smaller steps. I've added this suggestion to my answer.
    – Kramii
    Dec 9 '10 at 11:54
  • I'd also add that you shouldn't refactor anything that doesn't have a test written for it. Resist the urge to fix everything and just focus on the areas that need to be changed to add the new features. Once you have that done, then decide how much additional effort you want to put in to refactor the rest.
    – TMN
    Dec 9 '10 at 14:13
  • 1
    @TMN: Ideally, yes. However, you don't always need an automated test. (1) If code has been developed without automated tests then it may not be easy / possible to retro-fit unit tests until you've already done some refactoring (2) It can be expensive to write tests before making trivial, localised changes. (3) Automated refactoring tools + IDE features can help prevent code breaking as a result of refactoring.
    – Kramii
    Dec 9 '10 at 15:22
  • 2
    I'd add - in your source control, put all the refactoring on a separate BRANCH. This helps doing a sensible stepwise as well as big-block compares. This can be invaluable if things turn to custard (WHICH THEY WILL). Dec 10 '10 at 8:06

Well, at least refactor enough so the new feature can be added safely. I.e. don't make it even worse. The rest depends on motivation, budget and time constraints - but be aware to fully cleaning up a mess can take longer than originaly creating it.

  • 1
    This is of course the famous Boyscout Rule: always leave the code in a better state than you found it. Dec 9 '10 at 12:54

This time while fixing the things make sure to document it. Next time you will see the code it will be much easier to recall the things.


It depends, is it going to cost more time maintaining it because it's a mess, or to rewrite it so it's not a mess and easily maintained. I'm personally going through this right now, I'm converting an intranet site to ASP.Net MVC3 because the old code was a pile of crap (that I wrote) because it was supposed to be disposable (yes, I should know better). The old pile of crap is still here, and it's a headache adding features and fixing bugs. MVC is beautiful and makes working on it actually pleasurable, so it's getting a rewrite.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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