I'm managing a small team of developers. Every so often we decide we're going to spend a day or two to clean up our code.

Would it be a good idea to schedule regular time, say 1 week every 2 months, to just cleaning up our codebase?

  • 9
    I would prefer first to start registering all the things requiring cleanup in an issue-tracking tool. Analysing the issues logged in the tracker might give one better (much better) idea on what would be the most appropriate approach for a particular project
    – gnat
    Commented Mar 18, 2013 at 11:04
  • 4
    It would be a better idea to schedule a regular time for a code review
    – TtT23
    Commented Mar 18, 2013 at 11:15
  • 1
    What do you mean when you say 'clean up'? Is it prettifying the code or handling all the FIXME and TODO tags or getting more performance out of quickly-written code? Or something else? Any of these could be classified as cleaning up but I would attach different priorities to each of them.
    – paul
    Commented Mar 18, 2013 at 14:28
  • Another "closed as too popular", eh, guys?
    – MGOwen
    Commented Apr 23, 2014 at 4:38

10 Answers 10



Fix it while you're working on it:

  • If you wait to refactor the bit you're working on, you'll forget a lot about it, and have to spend time to get familiar with it again.
  • You won't end up "gold-plating" code that ends up never being used because requirements changed
  • 3
    My money on this answer.. Commented Mar 18, 2013 at 7:42
  • 3
    +1 for excellent answer. You won't end up "gold-plating" code that ends up never being used because requirements changed Commented Mar 18, 2013 at 8:50
  • 8
    On a perfect project with perfect management and a team of uniformly great developers this answer would stand. Unfortunately I have never seen or heard of such a project in my ten years in the industry.
    – 52d6c6af
    Commented Mar 18, 2013 at 13:14
  • 3
    Try to do this but when you can't (and it will happen due to time pressure or because you simply don't know how to do it right, yet) create a ticket in your ticket system. This way you can hopefully come back to it while the problem is still fresh in your mind and not only when it eventually starts causing problems.
    – Sarien
    Commented Mar 18, 2013 at 13:42
  • 1
    I think this is good advise, but does not address the question asked. Haivng managed a team with a horrendous code base (was horrendous before I got there). It was time very well spent to tackle refactoring and cleaning up specific functions. We called them infrastructure projects and worked them into every sprint we could. Often these things were items that were not part of another change, but were things the team had identified as problem areas. We did quarterly retrospectives and would update this list regularly. Commented Mar 18, 2013 at 14:19

My personal opinion: It's absolutely required for 90% of projects.

Particularly for projects that are heavily driven by sales, there's usually a big push for including new features in every release, and you inevitably end up having to compromise your better instincts and introduce a few kludges / hacks here and there.

Eventually you've accrued enough 'technical debt' through these little compromises that you end up spending a fair amount of time working around the flaws in the code base, and are unable to use to it's full potential.

Usually there are two types of issues generated this way:

  • Small ones which can easily fixed but may be systemic, e.g. improperly named parameters, incomplete error handling, etc. They typically will have little impact outside of the block of code where they appear. The best way to deal with these it is code reviews and checking the code as it's being written / modified. As others have stated, there's no need to set aside a special refactor cycle to fix these errors.
  • Big ones which may have arisen from incomplete specifications or poor design decisions early on, or two developers / teams creating two different solutions to the same problem. These are generally much more difficult to fix and require a concerted effort to fix. As a result they are usually deferred, until the become a perpetual nuisance. These kinds of issues require a dedicated period of time to fix.

I generally try to reserve time for a pure refactorring / bug-fixing cycle every 3 to 4 cycles. I always ask my developers to tell me when they feel frustrated with the code base as well. Not every developer has to work on the clean-up effort - you can usually (but not always) stagger the teams a bit, so only one team is working on clean-up at any given time.

  • 1
    I don't understand the increased number of big pushes as being an agile problem.
    – JeffO
    Commented Mar 18, 2013 at 3:53
  • 2
    @JeffO No, it's not an agile problem. It's a management problem. From what I've seen though, companies that are heavily influenced by sales tend to gravitate to aggressive release cycles and large feature sets. Agile strategies tend to appeal to these companies (whether they truly follow the strategies or not). While I like agile development, my experience has shown that when a company calls itself 'agile', it usually means I can expect to see a fair amount of technical debt in the code base.
    – p.s.w.g
    Commented Mar 18, 2013 at 4:01
  • I guess if they have no methodology at all, they can call themselves whatever they want. Since agile, is the current buzzword, it's the most attractive. It's been awhile since I was on a waterfall project; it was such a disaster in so many other ways, that I never use it as an argument against the methodology.
    – JeffO
    Commented Mar 18, 2013 at 4:42
  • In any project, agile or not, refactoring and cleaning up code is something you do as you go, to constantly keep the technical debt to a minimum. If you don't account for that in your estimations, you will have to start doing that. You can't let technical debt accrue to until you need to stop everything to fix it. Instead follow the scout rule: "Always leave the code cleaner than you found it." Commented Mar 18, 2013 at 13:00
  • In my experience, inexperienced teams starting with scrum, without observing good coding principles (like XP), can be sometimes be focused too much on functionality (stories). Instead they should say a story isn't done until the code is 'good' enough, but not everybody has enough backbone to do so under a looming deadline. And with Agile you tend to have more deadlines in a shorter time, so I do associate it with Agile methods as well, whereas I'm perfectly aware they're not the cause.
    – markijbema
    Commented Mar 18, 2013 at 13:37

I have my developers tidy their code prior to checkin (Subversion) or merging with the main development branch (Git).

I have them do the following:

  • Remove irrelevant comments
  • Ensure that their methods, arguments and variables are appropriately named
  • Make sure there is structure to their classes and items are encapsulated as they should be
  • Refactor to improve readability and to reduce any code smells

For the larger projects, the code is reviewed formally prior to merging from the development branch to the main branch.

I think that "devoting time" will mean it is something that might be deferred, or put off due to the amount of work involved. By having developers do it on a per-checkin (which equates to a change request / issue in JIRA) it is much more manageable.

  • Just out of curiousity: Why are you using two different VCS?
    – Eekhoorn
    Commented Mar 18, 2013 at 10:12
  • 2
    There was/is a migratory phase. We've migrated most SVN repositories now, I mentioned both for some context.
    – Sam
    Commented Mar 18, 2013 at 10:38
  • This is what I do. Clean the code before a checkin and refactor it if I return to the code to improve the functionality.
    – Barfieldmv
    Commented Mar 18, 2013 at 14:16
  • 1
    This won't address those nagging problems that are lurking around in areas that may not be part of the feature request from the product team. Commented Mar 18, 2013 at 14:21

Not in my opinion. If you let too much time go between when you encounter tech debt and when you fix it, you lose context of what the problem is. It takes longer to fix, and it tends to get fixed worse. Most importantly, people leave the broken windows because it's not "clean up week".

Personally, I negotiate for technical debt cleanup each sprint if I know we created some in the sprint before. It keeps the debt fresh in people's minds. It limits the amount of code using the problem code so that refactoring is easier. It prevents technical debt from piling up. And it helps push developers from just slapping something together, because I'm just going to make them do it right next sprint (so might as well do it right in the first place).

  • Your second sentence contradicts the first. You said no, but then said you work these kinds of things into every sprint. In a way that is scheduling time to do it. Commented Mar 18, 2013 at 14:21
  • 2
    @BillLeeper - enh. When I hear "regular time" that means that there's some regular interval to do cleanup work. IMO, that's incorrect - all the time is the right time to do cleanup work.
    – Telastyn
    Commented Mar 18, 2013 at 14:37
  • 1
    Good point, I do agree that the regular time doesn't work well. Too often priorities cause it to be cancelled etc. Commented Mar 18, 2013 at 15:09

I would say definitely yes, with a proviso: it should be done often, preferably on a weekly basis. I believe that a scheduled regular code review coupled with actually acting on the items coming out of the code review pays off very quickly. See the answer of p.s.w.g.

1 week every 2 months is definitely not often enough. This speaks to most of the other answers who responded with 'No' to your question. The gist of most of these answers is that if you wait too long you will no longer be in touch with the code and it usually takes much longer to fix/clean up/refactor.

  • We do a "Technical Debt Tuesday" for this. Its half way threw an Israeli work week and lets us take a step back to deal with issues
    – Zachary K
    Commented Mar 18, 2013 at 13:09

It is not that clear if you meant an additional clean-the-code exercise once in a while. In that sense , yes. What ever practices we follow, some degradation always occur.

You should not use that as excuse not to do the right thing [Applying SOLID principles, relevant unit tests, inspections etc ] in the first place.


I think that the currently two popular "No" "Yes" answers are two aspects of the same truth. Remember the OP is talking about a group he is managing, not just himself as an individual. We cannot assume that all developers in the group are well-disciplined enough to write clean, easily readable code; and there's the issue of external pressure and agile-style methodologies. Also, even with people's best efforts, their differences in style will mean they might write code which would be considered clean when apart, but unclean when considered together with other people's (not to mention the creaky interfaces).

On the other hand, the "fix it while working on it" is in my opinion an ideal to aspire for. You can make your code come out even more "fixed-up" by

  • careful peer CRing
  • writing unit tests together with the code itself
  • adopting coding guidelines
  • using automatic formatters and linters (but YMMV)
  • etc.

Now, if the OP's team adopts the above, and if he encourages his subordinates - e.g. during code reviews and during periodic code clean-up sessions - to try to anticipate pitfalls and avoid ugliness in advance, over time he/they will hopefully need less clean-up time. (And then they could devote that time to documentation, deeper refactoring, and knowledge sharing of what they've written and consolidated.)


I think scheduling regular time is very good whether that is a task in a regular waterfall style project, or stories in an agile one. Having a set time may not be as valuable as just working it into your schedule. This allows you to get it done as part of the schedule vs. canceling cleanup day because you are behind on the project.

Having managed a project that had a tremendous amount of code debt, working these in on a regular basis was key to getting things working smooth. Some of our things were big, some were small.

After a few months of this kind of work our operations team lead told me how smooth everything was running.

Each item may not seem like a lot, but just like all debt, it ads up.


The ideal answer is No, because you take the steps necessary to avoid making this a necessity (clean up as you go along for several reasons already stated).

This may be the goal in the end, but you may have a team that is far from putting this into practice.

Managers have to take some responsibility It's not always the developer's fault. Managers can say one thing, but they start pushing for projects to get finished and make suggestions that promote bad practices. They may literally say, "we'll clean it up later" or if it works, that's good enough.

You may have to start with dedicating a particular time to show this is important. Once you know your team is capable of cleaning up their code (not a given), then you can try to incorporate it more frequently.

Eventually, you shouldn't have to set a time.

Personnally, I struggle with solving a new problem and getting it to work while trying to keep things tidy. I am getting better at it, but often take a deliberate break and clean things up. It's a different mind-set for me. Eventually, the solid practices become habit.


No, you should do this while you are coding. This is called refactoring if you are using TDD. The problem when you wait a month or two to fix and clean your code is that you may alter the code behavior because you don't remember every piece of your code.

I suggest refactoring which is based on coding first the necessary code to make something work, and as soon as it works redesign it, optimize it, and make it pretty.

  • This is called refactoring whether you are using TDD or not. This question has nothing to do with TDD...
    – Ben Lee
    Commented Mar 18, 2013 at 20:02

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