Anotando Demasiado
Spanish has an interesting word to explain the concept of “excessiveness” or “too much” – demasiado. It can be used to talk about things, such as “Tenemos manzanas demasiadas”\”We have too many apples”, but interestingly enough it can also refer to people, as in “Él es demasiado”\”He is [just] too much.”
Today, Jeff Attwood was talking about how you can do too much logging in an application. I know exactly where he is coming from because I was once told to implement the type of logging he describes in his post. I found the usefulness to be about zero (well…not exactly zero, but more on that later) and they cluttered up my code with something worse than comments. IME, this type of logging comes from a development environment where people spend more time in the debugger than they do writing tests. If you have a system described and constrained by tests, you really do not spend time using the debugger. In fact, I use the debugger so rarely, in order to use the debugger, I need to look up on the Internet how to use it or I need someone to show me. Talk about feeling foolish – a developer with over 8 years of experience and I don’t really understand how to use the debugger, but that is life.
Why? Because if I have a problem, I can debug through my tests or just hit Ctrl-Z enough times and get back to a “good place”. The times when I reach for the debugger are the times I am lost in my own code and I find I just need to step away from the keyboard. The desire to use the debugger becomes a warning I need reconsider what is it I am trying to accomplish, return to first principles and take smaller steps. When you are lost in your own code, you need these trace statements sprinkled everywhere to understand what is going on. When you need to debug your application while it is running, because you have not spent the time to unit test the application during development, these statements are essential.
Now for the obligatory ancedote that highlights a glaring exception to my dogma: I was once working on an application where I was the only developer using TDD and we were having the application fail during system testing. Not just any part of the application, but MY part of the application. The part implemented doing TDD, so it couldn’t be MY part of the app that was failing. Unfortunately, it wasn’t clear why the app was failing from the exception logging, so our architect had us turn on the trace logging. The root cause of the failure: a method of mine was being fed an empty string that I did not anticipate. Bad me that I did not guard against an empty string; good me that I can now write a unit test for it & prove the bug is dead. So where did the empty string come from, a part of the application that didn’t have any tests. My fellow developer never considered an integration test where his part of the app talked to mine. Just proves yet again that if you want to find defects in your application, look for the parts that don’t have tests.
