Take the 2-minute tour ×

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?

share|improve this question

closed as not constructive by gnat, MichaelT, Martijn Pieters, thorsten müller, Kilian Foth Mar 19 '13 at 10:25


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 Mar 18 '13 at 11:04
It would be a better idea to schedule a regular time for a code review –  l46kok Mar 18 '13 at 11:15
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 Mar 18 '13 at 14:28
Another "closed as too popular", eh, guys? –  MGOwen Apr 23 at 4:38

10 Answers 10

up vote 100 down vote accepted


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
share|improve this answer
My money on this answer.. –  Soner Gönül Mar 18 '13 at 7:42
+1 for excellent answer. You won't end up "gold-plating" code that ends up never being used because requirements changed –  Md. Mahbubur R. Aaman Mar 18 '13 at 8:50
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. –  Ben Mar 18 '13 at 13:14
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 Mar 18 '13 at 13:42
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. –  Bill Leeper Mar 18 '13 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.

share|improve this answer
I don't understand the increased number of big pushes as being an agile problem. –  JeffO Mar 18 '13 at 3:53
@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 Mar 18 '13 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 Mar 18 '13 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." –  Christoffer Hammarström Mar 18 '13 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 Mar 18 '13 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.

share|improve this answer
Just out of curiousity: Why are you using two different VCS? –  Eekhoorn Mar 18 '13 at 10:12
There was/is a migratory phase. We've migrated most SVN repositories now, I mentioned both for some context. –  Sam Mar 18 '13 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 Mar 18 '13 at 14:16
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. –  Bill Leeper Mar 18 '13 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).

share|improve this answer
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. –  Bill Leeper Mar 18 '13 at 14:21
@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 Mar 18 '13 at 14:37
Good point, I do agree that the regular time doesn't work well. Too often priorities cause it to be cancelled etc. –  Bill Leeper Mar 18 '13 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.

share|improve this answer
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 Mar 18 '13 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.

share|improve this answer

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.)

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
This is called refactoring whether you are using TDD or not. This question has nothing to do with TDD... –  Ben Lee Mar 18 '13 at 20:02
