Guide Refactoring by Data
User Interview with a Senior Software Engineer
How to Visualize Technical Debt and Refactoring Progress to Management
Refactoring is the art of improving existing code without changing its behavior. Most refactorings are small and a natural part of successful software. Continuous refactoring ensures that we can continue to grow our products with new features.
Occasionally, a codebase might call for larger and more drastic measures. The trigger is often a specific situation. Perhaps you start to lose customer satisfaction due to a multitude of bugs where each change to the software is risky? Or a you notice a negative impact on your product roadmap where promised features cannot be delivered on time due to a growing mountain of technical debt? Ironically, this is often driven by product success; only software that is being used is also being maintained.
When that happens, an organization needs to strike a balance between improving existing code versus adding new features. This means that each series of large-scale refactorings or re-designs have to be prioritized to ensure we get the largest bang for the buck.
In this article, we meet a senior software engineer at a health care technology brand who successfully tackled this challenge.
I relied on CodeScene heavily to guide my refactoring efforts on a medium sized codebase (~34K Loc). We had seen a few problems with this codebase - from regular culprits like low cohesion, duplication etc. to more serious ones. The project did not start out this way, but complexity kept increasing over time resulting in low team velocity and whack-a-mole defects.
CodeScene proved useful in three ways:
First, its nifty metrics. I was able to demonstrate the cost of technical debt to management and present a strong case to allocate time and resources for refactoring.
Secondly, during refactoring, CodeScene’s hotspots feature helped in triaging the work. The x-ray and virtual code review features provide an active feedback loop. Code Health score helps objectively demonstrate if refactoring led to a significant improvement and also track code health.
Lastly, with CodeScene’s ability to dig through git history and display contribution statistics, the Senior Developers could identify struggling team members and mentor/coach them as needed.
There are many more features that I haven’t tried yet (Code age etc.) but overall, I found it a very useful tool. 10 out of 10 – I would definitely recommend it.
Sure. Communicating technical debt to management was indeed the first challenge. I presented a detailed report and backed it with CodeScene’s code health score and hotspot figures comparing it with other teams' repositories.
The next question was of time and resources estimates considering this is a project with tight deadlines and dependencies. The trade-off was between how much to invest in new features vs. refactoring and gaining velocity.
We hope you enjoyed this user interview and are eager to learn more about CodeScene’s Hotspot analysis and how to visualize technical debt. So checkout this blog post by Adam Tornhill: Communicate the Effects of Technical Improvements to Non-Technical Stakeholders.