Hi Sai,
Thanks a lot! Indeed, I have a lot of code battle stories. Part of my work involves analysing codebases so I get to visit different companies, see their differences and similarities. In general, the larger the codebase and the more people working on it, the more value you get out of the techniques in Your Code as a Crime Scene.
The most complex problem I've uncovered with these techniques happened a few years ago. I did some work for a company with around 200 developers organised in small teams. The team I worked with had to request frequent changes to an API that was owned by a different team. The changes themselves were trivial. That's why I was surprised to learn that each change took
at least one week. I decided to investigate the problem by using a special version of the temporal coupling analysis that I cover in the book. It turned out that the requested API changes were indeed trivial for the team that owned the API. But in order to do them they had to modify yet
another API that was owned by yet another team. And that team in turn had to go to another team, which had to request a change from the database administrators. So what was supposed to be a trivial change took forever since it rippled through the organization. Worse: no one had a holistic picture of the problem since each change was treated as a change in isolation and by different people.
When it comes to smaller projects with few collaborators I tend to focus more on technical analyses like Hotspots, Complexity Trends and much less on social analyses. You'd be surprised how often I find the worst maintenance problems in
test code (it's almost like we programmers treat test code as a second class citizen). Sure, its quality may no matter much to end-users, but it's just as important as the application code for our ability to maintain and evolve the codebase.
Hope this answered your questions!
