TL suggests that testing, refactor, and tool usage could avoid the need for verbose logging

Question

Additional Context

I make infrastructure for automated device testing. Debugging can be very time consuming because the devices have many states and are constantly being updated with new builds which might break assumptions that we've made.

Background

A TL who doesn't work on the project that I'm working on is reviewing a commit which I'm also reviewing. The author wrote something along the lines of

print("Entering into method_a")

I commented that we have a decorator which will do this for him and provide the args that are called. The logline produced would be something like:

Infra calling method_a("string_arg", ["list", "elements"], arg3=True)

He said he doesn't like the pattern of logging every method we call. Granted, I don't like excessive logging either and I don't suggest to log every method. However, it's been my experience on this project, and many others, that good logging is very helpful for debugging. He suggested that the stack trace in Python should be adequate.

In my opinion there are a number of cases for added logging:

• To know what functions/methods have previously been called. Especially ones that change the state of something.
• To orientate myself in the logs.
• To know what arguments have been passed into the function that crashed. That's not available in the StackTrace.

This TL is someone who doesn't like to be disagreed with and he doesn't want to discuss it much further suggesting that it is something which naturally follows from system design.

Similar questions that do not answer my question

• Verbose or concise logging

• Logging: Why and What?

Question

I would like to understand what the alternatives are to verbose logging. How does this relate to system design? How would testing, refactoring, and tool usage avoid the need for verbose logging?

Edit

I have asked this TL about the alternatives he mentioned and he brushed off the question suggesting that it is something that extends naturally from system design. I suspect that pressing the matter with him will not yield positive results - as mentioned above, he is someone who doesn't like to be disagreed with.

Answer 1

The reason you're depending on this verbose logging is that you need to be able to make sense of the flow of the code. Therefore, the flow must logically be very complex and/or cluttered without this logging, otherwise you wouldn't be advocating for having it.

The TL's advice stems from not cluttering the code flow to begin with, instead opting for code that is self-documenting, readable, clean and loosely coupled in a way thay it consists of esily digestible chunks and does not require some complex big picture in order to understand what is going on.

I cannot reasonably give you a concrete answer on what you need to fix in your codebase as I (a) don't know your code, (b) don't know your requirements, and (c) this could span the entirety of clean coding practices, which is a massive topic in and of itself.

In other words, the TL would be working in a codebase that precludes the problem you're trying to solve with your verbose logging.
You only really need to log what happens at the boundary between the unmanaged (end users, external systems) and your codebase. Within your codebase, you shouldn't be relying on runtime logging to make sense of your code, because that means you've written code that does not make sense and has not been vetted yet.

Your codebase may have gotten to a stage where the TL's advice, while correct, may no longer be applicable if you're no longer able to unclutter your code in a reasonable timeframe.

I can't know for sure, but the TL might be brushing off your requests for further discussion because he's aware that the amount of rework needed is impossible or would not be signed off on by management, rendering any further discussion on the topic moot (for the current project).

But if we are talking about a new project that is still to be written, I would very much listen to the TL's advice on how to approach the design of your codebase.

Answer 2

The alternative to verbose logging is (obviously) limited logging - and this is really only helpful when you can look at what you do log and pinpoint the exact cause of the problem you're trying to debug. In experience, that is rarely the case. In many cases, the failure is due to the specific data being used (do you log that?) or the specific sequence of actions the user took (do you log those?). The stack trace may help, but the root cause of the problem may have been a variable being set much earlier in the call chain that doesn't show up in the stack trace. Sometimes the necessary information is in the regular logs, sometimes it's not.

Verbose logging is helpful when the actual data and usage you see does not match your test environment exactly, for whatever reason. It's hard to predict exactly how users will interact with your application, and what kind of data they'll input. You can try, of course, and you'll be able to anticipate some of it. This is where your testing comes in.

Unless your app is very simple, though, you'll never be able to anticipate all of the various ways users will break your app, and that's where verbose logging comes in. You may want to have verbosity settings, depending on how deep your call stack gets, how many users, etc so that the log files don't get to be unmanageable. This way every method call is not logged under normal circumstances, but it is possible to do so by changing a configuration parameter and without redeploying your application.

A well-architected system may make it easier to implement fixes, may make it easier to perform unit testing and prevent some bugs, may lend itself to avoiding certain kinds of failures in the first place, but it is not an easy button that will immediately pinpoint the source of every failure.