Why don't you look at the codebase?
I was recently called 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.
Full-stack Web Developer PHP/Laravel/Vue.js (freelance - remote)
5moThe contractor was clearly on the defensive (which was understandable given the legal dispute) and you found a way to break down the psychological "locks". This story clearly shows that the code base is just one piece of the puzzle, the tip of the iceberg, and that the context in which the service is provided is everything else. However, I ask myself the following question: were the difficulties encountered by the contractor reported to the client throughout the work? The daily reporting of my work and the difficulties encountered has saved me from this situation for the time being (but maybe I'm lucky). This helps to make the customer aware of the realities of development work, which involves working on complex systems with a degree of uncertainty, and to have a written record in the worst-case scenario.