3

I got asked a question today that was so basic I was unsure how to answer it.

I had added some logging statements to our integration testing package, to find out what part of it was taking so long (many hours) to finish. These tests are huge, so I've been going through them adding logging to different parts as time permits.

Our QA manager looked at these statements and said "Why do we need these? We never had logging before, why should we have it now?"

As a software engineer for 20 years, asking why logging's important is like asking me why breathing's important - such a basic question that it's difficult to answer coherently.

Has anyone ever had to answer a question like this? How did you answer it?

user1071914
  • 161
  • 4
  • 1
    Is your QA manager a sports fan? Ask him how well he would be able to play his favorite sport if he were blindfolded or otherwise couldn't see. – Robert Harvey Sep 14 '17 at 22:08
  • By the way, this really happened, this is not a hypothetical. – user1071914 Sep 14 '17 at 22:19
  • @RobertHarvey thank you, that's an excellent suggestion! – user1071914 Sep 14 '17 at 22:19
  • Open a map. Pick two cities. Try to figure out the waypoints without tracing the route. For all but the simplest journeys, this will be nigh on impossible. – Robbie Dee Sep 14 '17 at 22:21
  • (For brainstorming an appropriate analogy) Imagine if you visited a supermarket or a restaurant, and you didn't get any receipt after paying. (Nothing - no paper receipt; no electronic receipt.) How would you find out if something is wrong? – rwong Sep 15 '17 at 04:59
  • 1
    Possible duplicate? https://softwareengineering.stackexchange.com/questions/37294/logging-why-and-what – Dan1701 Sep 15 '17 at 05:34
  • 2
    Possible duplicate of [Logging: Why and What?](https://softwareengineering.stackexchange.com/questions/37294/logging-why-and-what) – Doc Brown Sep 15 '17 at 06:24
  • 4
    FWIW, if you cannot give him a clear answer why you added a specific for of logging, this might be a sign you added superfluous log statements? Logging can be extremely valuable, but if you just throw arbitrary log statements into a program so you cannot explain a second person why you do this, the you do it wrong. Don't add logging for the sake of logging, add it because you know what you are doing. – Doc Brown Sep 15 '17 at 06:29
  • see [How do I explain ${something} to ${someone}?](https://softwareengineering.meta.stackexchange.com/a/6630/31260) – gnat Sep 15 '17 at 13:55

4 Answers4

3

I had added some logging statements to our integration testing package, to find out what part of it was taking so long (many hours) to finish.

Our QA manager looked at these statements and said "Why do we need these? We never had logging before, why should we have it now?"

They're needed because "the code is taking so long (many hours) to finish" and you're trying to find out why.

  • If this is generally perceived as a performance issue, the the QA Manager hasn't been doing their job by letting it degrade to this poor level of throughput.

  • If it's not perceived as a performance issue (and that is a possibility) then the QA Manager should be asking why you're working on this at all, not questioning how you're tackling the problem.

OK, it would be a different discussion if they were suggesting that you hook into a "standard" instrumentation framework instead of rolling your own logging, but I don't think that's the case here.

Community
  • 1
Phill W.
  • 11,891
  • 4
  • 21
  • 36
2

You don't say what you're logging. In my experience logging is a suboptimal solution for most things because what ends up happening is that logging is added and never removed. Then more is added and never removed, and soon you have so many logs that if you want to log something you can't find it in the logging output. So I definitely understand a desire to keep logging minimal.

Are you simply logging timings? Or are you logging things like "Entered function foo()", "Entered function bar()", "Exited function bar()"? Logging timings is what you would want to log if you're going to log, though there are better ways.

The problems with logging for performance are:

  1. Writing performance timing code is often trickier than it looks. Simply calculating the time at the start of an operation and at the end and taking the difference ignores the fact that other processes on the system can slow down the process you're profiling giving you misleading readings
  2. Logging can affect the performance of what you're testing, so performance logging may end up giving you invalid results

There are other tools for profiling (known as profilers!) that avoid the above issues. You should use those tools rather than writing your own or adding logging in most cases. They can give you finer grained detail (sometimes even telling you the exact instruction that's taking the longest), and can automatically differentiate between time spent in your process vs. other system processes. They can still have some affect on the performance of your application or system, but it's probably less than your own logging code would have.

user1118321
  • 4,969
  • 1
  • 17
  • 25
0

(I have a conjecture that) In release builds for a lot of commodity embedded firmware, it might make sense to disable logging or question the utility of logging if the cost of debugging the code is higher than replacing the hardware, Or the cost of storing logs can increase the total cost of the product substantially.

Mostly, I haven't heard why do we need logs but I have heard a lot of "oh we do have logs!?" i.e. folks testing the product were unaware of that aspect.

To triage the issue I had asked them to look at the logs and tell me what is going on.

amritanshu
  • 101
  • 1
0

The common usecase for logging is/was gathering state information:

a) Giving information of the state of an application in terms of errors

b) Giving processural information about a system in terms of what the system is doing while not crashing or perhaps timing information

A subcase of (b) is the so called "print debugging". In case your application behaves in unexpected ways, you could "print" out state information and try to make sense of that.

That said: The natural way for getting knowledge about your black box: the running application, is writing logging information (typically to files). There are packages for each language available or even whole applications (logstash,fluentd etc.) dedicated to that job: gathering information from running systems.

So the answer to the valid question:

"Why do we need these? We never had logging before, why should we have it now?"

Would be:

to find out what part of it was taking so long (many hours) to finish

The follow up question should be:

Is there another way to get this timing information?

And the answer is: Yes. Monitoring

Examples: AppDynamics, New Relic

Besides:

I had added some logging statements to our integration testing package

That sounds smelly. Your tests should be fast in the first place. But perhaps you have a problem in production without knowing it.

Thomas Junk
  • 9,405
  • 2
  • 22
  • 45