Blog Posts Case Management Process Management Process Modeling

The Silent Enemy: Failure to Report Exceptions

Blog: Collaborative Planning & Social Business

Stung again, several times in one day. Systems that fail to report problems can waste everyone’s time. The problem is that such system appear to be running fine, and that is great for lazy programmers and product managers alike. Just . Say . No .

Setting

I have a new Windows 10 laptop to work on, and naturally every time I get a new computer there is plenty of time invested in setting it up to do all the things that the old computer was doing. There is a NAS shared drive I use to backup and share among the team. Try to connect to it. It just silently does not work. Check with others: yes the drive is still there and working. But my new computer just simply won’t connect. The problem was that the old Buffalo drive only supported SMB1 which is turned off on Windows 10. Turn it on and everything works, but with no error message, no clue, finding the solution is like shooting in the dark. Imagine how much easier it would be if there was a simple error message: protocol not supported. Or better: protocol disabled.

I don’t use my Apple ID for much except you have to have one with the iPhone. Currently my iPhone is prompting me to enter the password, but I have forgotten it. So I want to reset the password. I follow all the instructions on the web site, but I get to the point that I am supposed to get a notification on the phone, it simply does not appear. No prompt no error no nothing. And it is frustrating because about 100 million support pages all point to the same procedure for resetting your password, and there is no way to explain to the robo-support mechanisms that the procedure simply is not working. I don’t know what the problem is yet, because right now I am locked out of trying to change my password because i have tried too many times recently, but once again something is wrong and there is no error message at all.

There is also some problem with the USB extender. I can plug my headset directly into the laptop and they work fine. But sometimes, when I plug them into the USB extender, they simply are not noticed. This is Windows plug-and-play capability, and it never reports an error. I can’t find what is wrong. All I know is that the task manager will show some activity: something was woken up and did some work, but whatever it did is a mystery, and since there is no error report, there is no way to drill down and try to find the problem.

Error Reporting is Important

The purpose of an error message is to give a clue to the user on how to solve the problem. This means, don’t just report a number. (On one system I used to work on it was called a ‘guru meditation number’) Error messages are for people. Being silent when an error occurs is a crime.

I know. I hear you howling: “But I don’t want to see any error messages! What can a normal person do with an error message!”

By normal person here I mean a non programmer. While I agree that such messages can be cryptic to people unfamiliar with the program, it is still better than reporting nothing. Consider the case where the user understand nothing of the error message. That is the worst case, and in that case it is still better than getting no message at all. With a cryptic message you at least have something to give to the support people. If the messages is even slightly meaningful, it can be a huge improvement, and might be an tremendous advantage to getting the problem resolved.

Not Reporting is Dangerous

Nobody wants to see an error message. We want the system to run without errors. But errors do happen. A system that is silent about errors often gives a false confidence that things are running well. A system that is silent about error allows a lazy programmer to commit code that is not complete or not completely tested. A system that is silent about errors allows project and product management to believe that everything is OK.

Managers and directors of software and system companies run the risk of deluding themselves about the reality of their software if they allow errors to be covered up. Instead, you want errors to loud, noisy, and in-your-face. Because then, if an error occurs, the underlying problem will be fixed. You are many times more likely to find and fix problems while in test, and before it gets into the production use. Don’t let any error go unnoticed. Surface it, and correct the code, so that the code runs without any errors.

Covering up errors is no anyone’s friend. Covering up errors is one of the most dangerous things that a system developer can do. It allows lazy programmers to get paid while leaving dangerous problems in the code. In my mind, the number one cause of systems being released with bugs is the improper handling and reporting of small problems that occur.

The solution

Be sure to check out “The Purpose of Error Reporting” from my other blog. Or the book on the subject: “Articulate Error Handling.” It really is unforgivable for a system today to be absolutely silent when it hits a problem. Make sure that error are always reported, because that is the only way that silence can give you confidence that things are running correctly.