Earlier, I asked to find out which tools are commonly used to monitor methods and code bases, to find out whether the methods have been getting too long.

Most of the responses there suggested that, beyond maintenance on the method currently being edited, programmers don't, in general, keep an eye on the rest of the code base.

So I thought I'd ask the question in general:

Is code maintenance, in general, considered part of your daily work? Do you find that you're spending at least some of your time cleaning up, refactoring, rewriting code in the code base, to improve it, as part of your other assigned work? Is it expected of you/do you expect it of your teammates? Or is it more common to find that cleanup, refactoring, and general maintenance on the codebase as a whole, occurs in bursts (for example, mostly as part of code reviews, or as part of refactoring/cleaning up projects)?

6 Answers 6


If you've got legacy code I think it's often pragmatic to clean-up or refactor code when there's a need to dive into that code e.g. to fix a bug or add a new feature. Otherwise you risk wasting time or breaking code that was never going to be maintained again anyway.

I wouldn't usually dedicate time to cleaning up code for the sake of it but rather while working on a bug/feature a good rule is to always aim to leave the codebase in a better way than you found it.That is in terms of factoring and test coverage.

When you're writing new code you should endeavor to have it maintainable from the outset.

  • 6
    +1, it's the boyscout rule. Leave your camp a little better than you left it.
    – CaffGeek
    Feb 3, 2011 at 22:19
  • yep, agreed - managers hate when you tell them you want to spend time "just refactoring". If you do a little as you go you'll be a good boyscout!
    – ozz
    Feb 4, 2011 at 14:40
  • 3
    @Chad, don't you mean: "Than you found it."
    – JD Isaacks
    May 24, 2011 at 18:02
  • @John Isaacks, indeed I did...unless you have a time machine of some kind...then my sentence could work.
    – CaffGeek
    May 24, 2011 at 19:36
  • Do make changes in its own commit, separate from the bug/feature. See programmers.stackexchange.com/questions/183840/… (Maybe except for legacy code for which reviews might be less of a practice.)
    – Lode
    May 8, 2013 at 15:42

It depends. Early in a project's lifecycle, I am literally all over the code, cleaning things up wherever I see them. As we try to stabilize for release, I do less and less of that. The next time that product is in a development cycle, I will another (smaller) round of cleanup, then stabilize for release. As time goes on, I try not to clean up except where I am adding a new feature or fixing a bug, simply because of the risk of making those types of changes. I have a good number of unit tests, but still, there's a risk each time you do "cleanup" on an app that's in production.


In my current project, it is part of my daily work. I have refactoring tasks scheduled fairly regularly as part of the normal development work. I tend to focus on some specific areas and do larger scale refactoring in about a day long chunks, spread over several months. On the average, I spend half to one day refactoring per every two-week iteration.

This is (surprise surprise) a fairly large legacy project. It had been outsorced to several different subcontractors, and 2 years ago it was at the edge of the abyss, full of bugs, very unreliable, with very unhappy users (rightly so). That's when our team took over and started the lifesaving operation (I joined the team about a year later). By now the situation is way better, but there is still a long way to go.

Luckily, our management understands the situation and knows that we need to pay back a huge accumulated technical debt, so they allow us time to do regular refactoring and acknowledge our effort even when it does not result in tangible, visible changes for the users. They know that this is a business critical app and that they need to invest in its long term maintainability, instead of trying to save short term costs (they tried that, saw the results and learned their lesson). In this sense, this is a dream workplace. In all the previous legacy projects I worked on, the state of the code was more or less the same, but management was far from this level of understanding.

  • +1 for a cool management that realised the importance of long-term maintainability. It gives hope to us all :) Even 1-1.5 days dedicated refactoring per two weeks is a lot imho.
    – Alb
    Feb 3, 2011 at 22:37

Follow the boy scout rule, leave any piece of code you touch in better condition than when you got there. This should be part of daily coding activities. You can also run metrics against the codebase using various tools. But the best method is to make it part of the daily activity.


Of course it is. Anyone saying otherwise works in some alternate universe.


It's part of daily work, but a lot of smaller companies won't like to admit it. There it's all about new features, innovation, things that they can charge a client for.

It's kinda hard to charge clients for maintenance of your own code base when they haven't requested it and get no tangible benefit out of it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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