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?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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:
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:
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
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.