14 Code Refactoring smells you can easily sense and What you can do about it?

This post is specifically intended to Project Managers although developers and testers can also get reasonable inputs from this post.  Generally projects tend to accumulate a lot of technical debt over time if refactoring is not applied and if good coding practices are not followed.  It is imperative that as a Project Manager you should understand this and deal with it effectively.  This is especially true in an Agile Project, where there is constant delivery of features and you would be surprised how quickly code quality can take a beating in if proper measures are not taken.  So what are the signs you can observe that your project’s code needs refactoring and what you can do about it?

·         Team is taking more time than expected to deliver features

o    This is probably the number one smell that a Project Manager can look out for in a project.  As a Project Manager you sense that a certain feature should not take so much time, yet it takes that time.  You talk to the team and they often give you a detailed explanation of how much change the feature needs to undergo and how it affects other features.  That is one of the sure smell that indicates that the code needs refactoring

·         Plenty of bug fixes after delivery

o    On one end, the code delivery is being delayed and at another end, there will be a lot of bugs too after delivery.  If you have observed this, then it is a sure sign that your project’s code needs refactoring.

·         Build Quality is on a decreasing trend

o    This is one of the excellent smells that surely indicate the need for refactoring.  If we try to build on bad code, the code quality will get reduced and this trend continues till we attempt to put a stop to it.  If you observe this as a Project Manager, then you need to put a stop to it.

·         Team is increasingly frustrated to make changes in code

o    Team get frustrated with making changes to the existing code as they worry that it might break some other parts of it.  If you observe this, you can be rest assured that the code needs refactoring.

·         Team is reluctant to touch certain areas of code

o    Some areas of code is better left untouched, that is a classic case of legacy code.  You can surely tell that we need refactoring if the team is reluctant to touch certain areas of code.  If you observe this, you can be pretty sure that code area is brittle and team lacks confidence in it.  However if refactored, things can be improved.

·         Team members are very comfortable with working in their respective modules

o    This may not be true in all cases, but it is true in some.  Team members are very knowledgeable in their area of code, and even though their modules contain bad code they know the tweaks of the code and can effectively hack it away to make the changes.  Although this may not be The sign, it does tell you the fact that things are probably not that right and it needs some action.

·         Team members are reluctant to give estimates (Even tentative ones) to make changes

o    When you are reasonably sure of the architecture and code design, you can give more or less good estimates or at the very least dare to provide estimates.  But in case of code that needs refactoring, the team members will be reluctant to give estimates because they are not sure of the impact that it might have on the other areas.

·         Team members often have the opinion that starting fresh is better than working with the existing code

o    If any of your team members feel this, then surely you need to take a big decision or at least start refactoring.

·         Team members often ask for extra time to refactor code

o    As a project manager, you need to often look for this cue as team members know that they are trying to deliver on time, but could not due to the quality of the code.  So they ask for that extra time for refactoring the code.  If that extra time is not allocated, then it ends up messing up the things further and will cause further damage to the code quality.

·         Team members take long time to debug a problem

o    This is also another sign that the code needs refactoring.  Usually when the quality of code is not good, it takes a lot of time to find where exactly the bug occurred and takes a lot of time to fix it as well.  If you observe this, you need to definitely take a closer look and have the team analyze the root cause for this.  Invariably it will be lack of refactoring.

·         Fixing bugs invariably introduces other new bugs

o    When the code quality is not good, fixing bugs in one place tends to open up new bugs in other places/areas of code.  This is a good sign that the code needs refactoring.  If you observe this, you can be sure that the code is very brittle and needs refactoring.

·         If you try to read the code and find out that it is not readable

o    You might not be technically adept at all programming languages.  But if you read through the code and find that you find lots of

Unreadable code

Long methods

Long parameter lists

Inappropriate variable names & method names

These are some simple checks and sure signs that the code needs lot of refactoring.

·         If team members are making same changes in multiple places

o    One of the common characteristics of code that is not refactored is that there tend to be lot of duplicate code across the areas.  If that is the case, even a small change will need to be applied to all those areas resulting in duplicate effort.  So if the team members complain of making same changes in multiple places, then there is a good chance that the code needs refactoring.

·         If all or most of your tests are covered by functional testing

o    When code is not very well designed, it can’t be driven by unit tests or unit integration tests.  So you end up making all your test coverage at the functional level.  This is a sure sign that your code design needs refactoring.

So now you have sensed that something is wrong and your code needs refactoring.  So what you can do about it?

• ·         Discuss with the team and find out where they are stuck and why they are stuck
• ·         Ask them to do a root cause analysis
• ·         If the team is not able to figure it out in the worst case, hire an external consultant who can give valuable insights/feedback
• ·         Identify critical areas that needs to be refactored the most
• ·         Put up a plan for Refactoring
• ·         Start with refactoring them

From a Project Manager’s perspective, Refactoring old code is an overhead but you need to treat it like an investment for the future and a means of improving Agility of the team.  So what you can do to refactor existing code.  Here are some ideas.

·         Refactor Sprint

o    Have a sprint dedicated to Refactoring.  This might be difficult to pull off due to business reasons, but if you can pull this off this is a worthwhile investment.  You will be surprised how much code you can end up improving in a sprint duration.

·         Refactor Week

o    If not an entire sprint, try for at least a weeks time for refactoring.  It will save you some amount of effort later on.

·         Refactor Day

o    This can be introduced once in a while when you feel equally bogged down by pressures of deadline and yet you want to accomplish decent quality. 

·         Refactor Hour

o    If you can’t dedicate long periods of time for refactoring, dedicate an hour every day for Refactoring.  Also ensure that this hour is used only for refactoring and not for any other activity.  Once you do this for a couple of sprints, you will quickly start to realize some benefits, depending on the size of the project.

·         Make it a habit

o    Educate the team to make refactoring a regular habit along with coding.  Team needs to understand that the extra time investment is really worth it as it will make all future changes much easier.

·         Agile Engineering Best Practices

o  Try to follow Agile Engineering best practices like Automated Unit Tests, TDD which naturally emphasizes Refactoring.

The idea is to give a start to the Refactoring activities and make small regular improvements to the code.  By making it a habit, you can easily keep check of the code quality and can utilize the time and effort gained (later on) for something more meaningful.


Do you think there any other refactoring smells that you sense?  If so, please shoot out your comments.  If you found this post useful, please share it with your circles.  You can stay updated with the latest blog post by simply submitting your email id to the right in the "Get Updates by Email" section.