No.

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

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.

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.

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

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.

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.