User Interview with a Senior Software Engineer
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.
“I was able to demonstrate the cost of technical debt to management.”
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 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:
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.
CodeScene's dashboards present the core metrics that drive engineering intelligence.
CodeScene’s hotspot recommendations were spot on and are calculated pretty smartly based on defect count, complexity, code health, change frequency and other code biomarkers as the tool puts it. These hotspot recommendations would match what a software designer would analyze and conclude manually. We used that along with improved code health score to communicate refactoring progress.
CodeScene provides positive reinforcements on refactorings and design improvements via its code health metric.
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.