Very interesting, how to view code as a crime scene

Measuring software complexity is a popular and common activity in the software development community, judging by the number of tools and related literature that have emerged in recent years. Adam Tornhill, speaking from his background in engineering and psychology, suggested at QCon London that everyone treat the code like a crime scene with the help of version control tools.

Tornhill believes that the current measurement of software complexity is incomplete. So he turned to psychology for answers. Geographical offender profiling is based on the principle that the criminal's home base is often within the boundaries of the place where he/she committed the crime.

Tornhill applies this principle to code with the help of tools like CodeCity. The idea behind it is to create a geographical representation of code. Regions and buildings map the structure of the code, such as packages or classes. Code attributes, such as the number of lines of code or methods, determine the dimensions of the regions and buildings. Tornhill then combines this code structure information with what he calls spatial movement in the code with the help of version control tools.

Version control tools provide a lot of forensic details, such as who made changes, when, and where in the repository. Combining this spatial information with the code structure highlights hot spots. Tornhill claims that in one case analysis (400,000 lines of code, 89 developers, 18,000+ commits) there were 8 areas of defect concentration, 72% of the defects were concentrated in 4% of the code, and hot spots were used to pinpoint 7 of them.

A code city with hot spots highlighted.

Using version control information, you can do time-space coupling analysis. If two code files are changed at the same time, it means that the files are physically coupled, for example: one class calls another. However, they may only be coupled in a logical form, which is the result of common copy-paste. Without time-space coupling analysis, it is easy to ignore these problems.

Spatiotemporal coupling analysis is also useful in other ways. It can point out patterns of change when people from different teams change different components at the same time. This pattern can indicate inconsistencies between the system's architecture and team structure, which can lead to longer cycle times between change requests and deployment.

Version control information can also be used to mine knowledge owners and component ownership. If a developer is the primary committer of a given code file or component, then we can safely assume that he is the knowledge owner of that component, even if he is not on the team responsible for that component. This also means that "collisions" will be traceable and mitigated. In more extreme cases, where the knowledge owner is no longer in the company, there will be knowledge gaps. These techniques help discover these gaps and close them.

Version control forensics shows effective ownership of components.

Tornhill is writing a book on this topic, which is currently in Beta. The Pragmatic Bookshelf will publish it soon, with an expected publication date of March 10, 2015.