Table of Contents for

Your Code as a Crime Scene

Complexity by the Visual Shape of Programs

A few years ago, I used to commute to work by train. Since I went to the station at about the same time each day, I soon recognized my fellow commuters. One man used to code on his laptop during the ride. I don’t know whether he wrote Java, C++, or C#, but even with just a hurried glance, I knew his software was complex.

You’ve probably done the same. Isn’t it fascinating that we can form an impression of something as intricate as software by a quick look?

Humans are visual creatures. Our brain processes a tremendous amount of visual information in a single glance. As programmers, when we glimpse code, we automatically compare the code’s shape—how the code looks visually—against other code we’ve seen. Even if we aren’t consciously aware of it, after years of coding, we know what good code looks like. We can use this skill more deliberately.

Judge Complexity by Program Shape

Look at these modules, A and B. Which one would you rather maintain and extend?

Independent of the programming language used, the differences in complexity are striking. Module B looks pretty straightforward, while module A winds down a complex, conditional slope. You see how the shape of the code reveals its complexity?

Learn from the Shape of Code

I started to investigate the idea of using the shape of code while teaching test-driven development—TDD, a high-discipline methodology littered with pitfalls. (See http://www.adamtornhill.com/articles/codepatterns/codepatterns.htm for the original writeup.) The design context resulting from TDD is far from trivial. By creating compact overviews of the code’s shape, similar to the image that follows, the programming team was able to: Compare differences in complexity between unit tests. Use shapes during code reviews as an effective way to encourage discussions about the high-level design. Identify parts of the design that diverge from the rest of the structure. Let the visual contrast serve as a tool to highlight basic design principles. For example, a solution using polymorphism looks quite different from one based on conditional logic. The reason this technique works is that visual shapes give you a compact high-level perspective without distracting with details.

Visual inspections are fine for analyzing individual units. But what happens when we want to scale up and look at complex systems? We automate the task.

This kind of image comparison is hard for a computer to do. For what your brain does by the flick of some neurons, a machine must use complex algorithms and have serious computing power. So we’ll analyze the textual representation of the code. We’ll also simplify the process by shifting our perspective: let’s focus on the negative space.