Prioritizing Technical Debt as If Time & Money Matters • Adam Tornhill • GOTO 2022

Cool report. from Adam Thornhill, who continues the theme of complexity in software development, which was central to the book. A Philosophy of Software Designwhich I remembered yesterday. First, the author gives the Lehman's "Laws" of Software EvolutionExplain why complexity management is important

• Continuing change The system must constantly adapt or it will progressively become less acceptable.
• Increasing complexity As the system evolves, complexity increases until work is done to maintain or reduce complexity. This accumulation of complexity leads to the emergence of technical debt, which slows down time to market, reduces the predictability of working on systems, leads to organizational problems, and reduces opportunities for innovation. Behavioral Code Analysis consists of three components: code, people, context. All this can be pulled from the VCS. The author suggests measuring 2 parameter
• Code complexity - code complexity metric, about it a little further apart
• Code change frequency Metric of frequency of code change (It's just the number of code changes over time.) In sum, these two parameters allow us to understand which parts of the code are complex and which often have to be edited.

Code Complexity, the author suggests measuring again not by one metric, but using a set of metrics to assess the health of the code:

• At the module level - low cohesion (Too much responsibility in the classroom), brain class (Low cohesion, + at least one Brain method that is large, complex and centralizes the behavior of the module) Brain methods, copy-pasted logic Deep nested logic, primitive obsession

Next, the author shows an example of analyzing the Android codebase in order to demonstrate his concept. The frequency distribution of work with different files looks like a long-tail distribution, so there are not many often changing files and only some of them are complex. Actually, we need to start working with our debt with these files, and the rest can be ignored – this is a pragmatic, economically sound approach. Interestingly, the author claims that this is the standard picture for all the projects he has seen. And then he finds the problematic ActivityManagerService.java file and drills down to show you how to find a place inside the file where the main problems are concentrated, which he calls X-Ray.

Then comes the story of legacy codewhich it defines as follows: Lacks in quality - standard definition

• We didn't write ourselves - not quite the standard part:) This prevents you from refactoring your code on time. Next, the author tells a funny story about the analysis of three different projects, where two were their relatives and one was adopted. They were comparable in quality, but only someone else’s project wanted to rewrite, since it was suspected that it was a legacy:)

And finally, the author says that it is possible to analyze the contribution of different people to the code base and assess the amount of knowledge concentrated in each, as well as something like a bus factor for each Maintainer in order to minimize the risk of losing important information when key people leave.

P.S. The author has a website. https://codescene.com/ Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis.

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management