Table of Contents for

Your Code as a Crime Scene

Let’s Look into the Future

Remember the old saying that what happens in a commit stays in a commit? Well, probably not, since I just made it up. But it’s nonetheless true, and that’s a problem.

Today’s tooling limits us to a commit as the smallest cohesive unit. If we knew what happened within a commit, we could take our analyses and predictions to a new level. Consider a temporal coupling analysis as an example. The analysis lets us identify modules that change together. But we cannot tell anything about the direction. Perhaps a change to module A is always followed by predictable modifications to B and C, never the other way around. That would be valuable information to have.

The next generation of tools has to go beyond version-control systems. We need tools that integrate with the rest of our development environment, and tools that record our every interaction with the code. Once we get there, we’ll be able to support the most important activities in programming: understanding and reading code. Let’s look at how we do that.

Support Code Reading

Most analyses focus on the design aspect of software. But reading code is a harder problem to solve. Let’s take inspiration from other areas.

Think about how online sites tend to work. You check out a product and immediately get presented with similar products. What if we could do the same for code? You open a file and get presented with a “programmers who read this code also looked at the UserStatistics class and eventually ended up modifying the ApplicationManager module. Twice.” Such reading recommendations are a natural next step to take.

Integrate Dynamic Information

Another promising area of research is to integrate dynamic analysis results into our development environments. We could use that information to present warnings for particular pieces of our codebase. Let’s look at an example.

You have learned that a high degree of parallel development leads to lower quality. What if we hooked the results of such an analysis into our code editors? When we start to modify a piece of code, we would be presented with a warning like “watch out—this code has been modified by three different programmers over the past day.”

To really work, you’d also need a time aspect. If you had a problem with parallel development in the past, you reacted, and then you fixed the problem, the warning should disappear automatically over time.

We already have all the building blocks we need. The next step is to integrate them with the rest of our workflow. Perhaps some of these new tools will be written by you?