June 3, 2021

Why Are Code Hotspots so Hard to Pinpoint?

Table of Contents

When I think of a code hotspot, I often think of traffic on highway 101 in the Bay Area. It really could be any highway in any major city actually. You know how there are always those annoying patches where for no apparent reason traffic suddenly slows down. Maybe even come to a standstill? Or the most traffic incidents happen in that patch? That is a hotspot. Traffic is still flowing. People are still getting where they need to go. But everyone spends a bit longer on the road and in those particular areas. The reason for this slowdown may not be obvious - it's not an obvious bottleneck like say a construction zone. But there is something in the foundation - maybe there is a slight curve in the road. Maybe there is a pothole. Maybe there is an exit that many people are getting off at, and this was not taken into account when the freeway was designed. Untill that issue is fixed, people will continue to pay the price for it.

Similarly, code hotspots are areas of the code where there are issues. The issue may not be obvious, since it is still a working piece of code. But many defects and bugs arise from there, and overall, developers spend a lot more time working on or around that piece of code. It hinders overall productivity, and also often compromises the quality of the software. Poorly architected or designed code can also lead to bad user experience.

What do you do when you have a code hotspot?

Code hotspots can happen due to a variety of reasons, the most common being poorly architected or designed code. Once you know you have a hotspot in a certain area of code, you can try to fix it by redesigning or rewriting that code. But what if there are other dependencies that make it impossible or very difficult to rewrite that code? It might be legacy code that you no longer have skills for, or something that has many interactions with other components or applications and is just too complicated to change? In that case, your next best option is to make sure that you have a lot of test automation built around that, so that every time you build, you are able to test that piece and make sure no new defects or regressions are introduced. 

Either way, before you can figure out a plan of what to do with the hotspot, you need to be able to identify it and determine the risk factor around it.

Identifying code hotspots and their risks

How do you identify such hotspots? And how do you prioritize this amongst all your other requirements? How do you figure out other dependencies so you can plan and test properly? You need to have the right development metrics in place to make data driven decisions on the impact and severity of these hotspots. 

You could try to do this with Excel, using data from your customer support system and your defect management system. Let's say you have Zendesk and Jira. 

  • First you would identify all the tickets raised from Zendesk
  • Next, you can export Jira metadata to an Excel sheet and group the data by code module. However, this is assuming that your team tags or labels Jira tickets by code modules. Most of us are not so lucky, and it is highly unlikely that Jira tickets are “well groomed” and have info about the code module.

Another option would be to manually correlate Github PRs with Jira activity to identify which module, branch or areas are the ones that are causing the most defects and that need attention. But this again can be quite challenging in itself.

Either of the options above can be very time consuming. Based on the quality of data you have, how well your tickets are groomed, etc, this effort could take a few days to a few weeks even, and can be extremely frustrating for the team. You need to have a better way of being able to visualize the hotspots and their severity based on impact to the end users and the time it takes from the development team.

Do it the easier way

Getting the right software metrics by correlating data from your different DevOps toolkits is not as easy as you’d think. Luckily, Harness Software Engineering Insights does this for you. It correlates data from all your tools and provides out of the box software metrics and insights into issues such as code hotspots that are impacting your software quality as well as your development velocity. 

Interested in learning more about how Harness Software Engineering Insights can help you find your code hotspots? Request a demo

You might also like
No items found.

Similar Blogs

No items found.
Code Repository
Software Supply Chain Assurance
Infrastructure as Code Management
Continuous Error Tracking
Internal Developer Portal
Software Engineering Insights
Cloud Cost Management
Chaos Engineering
Continuous Delivery & GitOps
Security Testing Orchestration
Service Reliability Management
Feature Flags
Continuous Integration