One of the biggest challenges I think that many developers have is when you are looking at code and looking to improve it we are faced with the question "Who is going to pay for those changes". Adam, I would be interested in hearing from your past experiences any approaches that you may of taken.
Yes, I'm quite familiar with that problem myself (I used to be a consultant before I started Empear).
One thing that I've learned is that managers, most of the time, are pretty much like the rest of the population That means, they want an ROI on the things they invest in and they want to minimize risk. I've found that it makes a huge difference when you can support suggested improvements with data. In addition, we also need to show the consequences of ignoring those suggested improvements.
So what I suggest is to present a hotspot map (Chapter 4) together with complexity trends (Chapter 6) of the top hotspots. The nice thing here is that you now have supportive evidence to the suggested improvements, which minimizes risk and has a high probability of leading to real savings since the data is based on how we developers actually work with the code. The complexity trends are important too since it's easy to understand the cost and risk of maintaining code that grows along the infamous hockey stick curve.
I think that's one of the big wins with these kind of technologies; they make deep technical issues accessible to a non-technical audience. It's something I see in my workshops where I occasionally have participants that don't even code.
Hope this helps.
Author of Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis (2018).
posted 4 years ago
It does. Thank you for responding! I'm hoping to win one. I find your book very interesting and I think I'm going to buy it and if I win one I'll keep it at work.