If your software is becoming unwieldy, inflexible or inelegant, a good place to start exploring for improvements is in the level of refactoring that is being performed on the code on a day-to-day basis. As a project manager, I learned some key patterns of behavior that served as sure signs that not enough refactoring was occurring. Pay some attention to your project and see if you recognize evidence of any of the following:
- Variance in Code Behavior – When similar features throughout the application begin to respond in dissimilar ways, there is a good chance some refactoring should occur. Some prime examples:
- Reports showing different values than application pages for the same data
- Identical searches returning different result sets in different areas of the application
- Calculations on the same data set resulting different answers
- Developers Avoiding a Module – If you see eyes rolling or hear audible groans when a developer is asked to work in a particular area of the system, it is a sure sign that the code is in need of refactoring. There is nothing worse than being asked to deliver on a deadline within a code base touched by 100 other developers who also had deadlines to meet.
- No Refactoring Chatter – There are several times during a development sprint that the project manager should hear developers talking about refactoring. Story estimation, story tasking and daily standup meetings are the key opportunities. If you aren’t hearing refactoring chatter you can bet it isn’t happening.
- Poor State of the Code – It has historically been next to impossible for a non-technical project manager to gain insight into the true health of the code base. Modern tools, however, make this possible for even the most non-technical project managers. Applying tools such as PMD and FindBugs allow a project manager to quickly and (somewhat) accurately gain insight into the general state of the code.
- Long Ramp-Up Time for New Developers – If a seasoned developer can’t jump in and be productive during his first several days, there is a problem. While there are applications that are inherently complex and difficult to understand, those applications tend to be exceptions and not the norm. Complexity points to poor design and organization which points to refactoring.
Refactoring is normally considered the domain of the technical team members but there is no need for a project manager to turn a blind eye. As a project manager, its critical that you keep your eye on the health of the code base and enforce refactoring as a best practice. To learn more, I suggest reading Martin Fowler’s book “Refactoring”.
