Iâve worked on a lot of systems over the past 11 years. I heard the same discussions. I heard the same arguments. Iâve heard the same excuses.
One the issues that always seems to be in contention is how much a web application should log about user activity. My stand has always been âLog everything you can about what is going on. The only reason you should cut back is due to storage limitation.â For some reason, this always causes arguments with my fellow developers. (It ranks up there with the statement âOur app should be cross-browser compatible.â)
One of my big problems with applications written by junior (and some senior) developers is that they donât log enough. On a development machine or server, logging is not really neededâyou can set a break point or log onto a server to see whatâs going on. In a production environment with tight change controls, this is not possible.
Iâve looked after third-party software applications in large companies which would routinely fail. The company would spend a fortune for a software package from a small start-up no one has heard of. We get this software, install it on our servers and before long, we have our first exception. Angry users call me. I call the vendor:
âWe are getting an error number x00012012928 when click on the save button.â
âHmm. What happens when you click on the popup?â, he asks.
âThe application crashes. Now no one can log in.â
âCan you check to see if the server is still up?â, they ask. This is when I glean that he doesnât really know whatâs going on. Heâll ask for a reboot next.
âThe server is up. I can still get to the web pages. But no one can save anything. Can I talk to the developer.â
âI am the developerâ the snooty developer replies.
âOkay. So why is it doing this?â
âOh. Umm. . . . It shouldnât happen.â Yeah. No sh*t.
âWhat is x00012012928?" I ask trying to move things along. âIt looks like an internally generated error number. A description of the error would have been nice. Iâve checked event viewer but see nothing. It looks like the exception is being caught, but not handled. What would generate this number?â
âIt could be a number of things . . . â This is the wrong answer. If you are going to raise your own errors, be as specific as possible. You canât anticipate every error, but you can differentiate between db or web error for example. This conversation goes on and on where eventually I need to get someone with server admin rights to send him an IIS log so he can review it for a few days. Meanwhile, I have to try to calm down an angry user base and continue to chase the vendor.
Iâve been in the above situation at least a half-dozen times in different companies. It most definitely is not an exaggeration.
I like to contrast this with a friend of mine who wrote an application where he logged everything. He kept log files as text files in a web root where he could access them securely with .htaccess rights. Every day, a new file was generated and files over 30 days old were deleted.
One day, he got a call from an irate user.
âIâm trying to use this rubbish application and it isnât working.â angry user yells.
âI see. What is your username?â the developer calmly asks.
âI see you logged into the application 3 times today. Did you get an error every time or just the last time.â Already the developer with logged activity at his disposal knows more about the userâs problem than the user knows. If there was an exception, he would have been able to see it in his logs. If there is no exception listed, he can view user activity. âI see the last page you accessed was the transaction details page. Is this where you get the error? Can you describe it?â
âThe button does not show up to save the data I entered,â the calmer user explains.
âI see. This is a common problem. You left a mandatory field out. You should see it highlighted in red.â
âOh yes. I see it now. How did I miss that? Thanks.â
So the developer had 3 things working for him:
1. He had more information at his disposal than the user had. He could identify an exception or user error.
2. He did not try to make the user feel at fault when he clearly was. (âThis is a common problemâ may necessarily be true, but there is no better way to put someone on the defensive than to accuse them of being wrong)
3. He spoke in a calm, unassuming, and sympathetic voice. A user can quickly tell whether you are doing everything you can to help him or if he has to try to prove to you that his problem is real.
So, Iâm always in favour of extreme logging. I hear the same excuses every time why this canât be done. âIt will take up too much space.â âIt will be too difficult to clear down.â âNothing should go wrong with the application, because we tested it.â âWe will log the exceptions. Thatâs all we need.â