Why don't you look at the codebase?

Recently, I was called in to audit a software project embroiled in a legal dispute. The client was unhappy with the vendor's work and wanted me to assess the code quality. Initially, they did not want to give us access to the codebase. Eventually, I was granted access, but only in the vendor's office, on one of their computers, with their technical lead and another independent expert watching over my shoulder.

I arrived early and spent about twenty minutes quickly reviewing the codebase. When everyone settled in, I started asking questions, some about the codebase and many on their way of working. About ten minutes in, their lead developer, clearly frustrated, said, "Why don't you look at the codebase instead?" That was the plan, but the code looked good. I could have been staring at it for hours without getting any extra value out of it.

Building their trust was crucial. I acknowledged the code's quality and offered practical advice on overcoming their challenges. This shifted our meeting into a more casual, three-hour conversation, revealing far more than you would get from a code review. They showed me older codebase versions, discussed team dynamics and personnel changes, and mentioned the pressures of a fixed fee, fixed scope contract. They also admitted they underestimated the technical complexity of some integrations.

This experience reinforced why our audits go beyond just reviewing code. Through conversations, we uncover critical insights that the codebase alone cannot reveal. Interviews allow us to understand the human and organizational factors that impact a project's success.

While the codebase is essential, the value of an audit lies in understanding the broader context. By interviewing, we uncover the real issues.