Would you eat where you cannot see the kitchen?

Most restaurants will let you look. Some are built around it, with the pass in full view and the chefs working in front of you. Nobody stands there watching for long. It is enough to know that you could.

Now imagine a place where the owner says no. The food seems excellent, the staff are friendly, most reviews are good, but the kitchen door stays shut. Not today, not next week, not ever. You might eat there once. You would think about it the second time.

I bring this up because the same thing happens in software, and more often than people expect. An organisation pays a vendor to build a system. The vendor builds it, runs it, invoices for it, and does a decent job by every visible measure. Then somebody asks whether the code could be looked at, by the client or by an independent party, and the answer is no.

The reasons vary, and most of them sound reasonable in the room. It is our framework. It contains our intellectual property. It would be a security risk. Our developers would find it uncomfortable. Occasionally you get the honest one, which is that nobody has ever asked before.

I am not going to pretend the refusal tells you nothing. It is not proof, and I have seen good code behind a closed door. But people do not generally hide work they are proud of, and the question answers itself often enough to be worth asking. What makes it easy to wave away is the delay. A sloppy kitchen does not make you ill that same evening, and neglected code does not fail on the day it ships. Both present the bill later, and not to the people who kept the door shut.

It arrives with you. When the system becomes expensive to change, that lands on your budget. When it cannot support the thing the board decided last quarter, that lands on your roadmap. When you eventually want to move to another supplier, the cost of that move was largely settled years earlier, by choices in a codebase you were never allowed to read. The vendor knows what state it is in. You do not. That asymmetry is the whole issue, and it is worth considerably more to them than it costs you to leave it alone.

So check the contract before you accept the refusal. In a surprising number of cases the client already owns the code outright and simply never wrote down how they would get to it, which leaves ownership on paper and access with the vendor. Those are not the same thing, and only one of them is any use to you.

The better news is that this is a solvable problem, and the solution is not a fight. No supplier has to expose trade secrets in order to allow a measurement. An independent party can read the code under a non-disclosure agreement and report on architecture, maintainability, testing and QA practice without disclosing a single line of it. The client gets a number and a trend. The vendor keeps exactly the confidentiality it asked for. I have yet to meet a supplier who is confident in their own work and still objects to that arrangement once it is explained.

Which is what makes the objection so informative. Ask to see the kitchen. If the answer is yes, you have learned something useful. If the answer is a long explanation of why the question is inappropriate, you have learned a good deal more.