Believe the code over what people tell you

This is just a quick post, about a development principal that I think applies across pretty much all development languages.

Always believe the code over what someone else tells you.

A good example in databases is NULLable columns. You will sometimes get the situation where you are selecting from a NULLable column, but someone in the business tells you there can’t ever be NULLs in there because of how the application works. I get very skeptical of this, because users can always find a way to make applications do strange things, because applications change over time and just because it’s impossible now doesn’t mean it always has been, and because it’s always possible to change the data in other ways that bypass the particual application being discussed (manual data fix, for exmple).

The first thing to do in that scenario is check if there are any NULLs in there, because if there are you can just go back with the evidence. However, sometimes there won’t be, and sometimes you’ll even run into people who will double down on their assertion that there can’t be NULLs in that column despite the evidence. In that case you have two options: either you code to account for the possibility of NULLs anyway, which may involve making some assumptions about what the business wants to replace them with; or you code as if the column is not NULLable, but if you do that I strongly advise getting the assurances that the data will never be NULL in writing.

Which route you end up going down is very much down to your situation at the company, the seniority of the person telling you to not code for NULLs, how serious it would be if there are NULLs, and a whole load of other factors that fall under the broad heading of ‘office politics’ (and just typing that makes me feel a bit dirty inside).

It’s also important to note that this won’t just be limited to NULLability, that’s just a convenient example. I had a case once where we had a complaint that related to one of our core processes. I investigated and found a fairly serious flaw that would have major implcations for a lot of the work we had done for this client. I took my findings to the person pushing this investigation, who was also the CEO. He flat our refused to believe what I was saying and insisted the problem had to be elsewhere. In this case, I stuck to my assertion that this was what the code was doing, and ended up being pulled off the investigation and replaced with a developer who was more likely to go along with the CEO (that developer privately admitted to me that the process was known to not work correctly). It wasn’t the ideal result for the company, but it didn’t do my standing in the company any real harm, and meant I was kept away from any fallout that might ensue from the investigation.

In this case the biggest factor in me sticking to my guns was the seriousness of the issue. I definitely didn’t want anyone to be able to say I gave bad advice on this, or misrepresented the code, and a small loss of standing with the CEO was a price I was willing to pay to either get the right result or get me off the project.