Max’s Adventure in SAP Cloud Platform: Debugging

The weirder the introduction the better the blog? Let’s give it a shot. How well do you remember Hannah Montana? One verse of her songs couldn’t be a more appropriate introduction for my new blog post.

“Nobody’s perfect!
I gotta work it!
Again and again till I get it right
Nobody’s perfect!
You live and you learn it!
And if I’m messing up sometimes
Nobody’s perfect”

I want to philosophize a little bit on what debugging means to me, where it is sufficient and where it is not. And moreover, I’m curious about your preferences, experiences, rules of thumbs for debugging/logging, opinions and comments in any sense.

I’m surprisingly not perfect..

Even though I am close to the point being perfect (personal disclaimer: sarcasm may well be included, as promised in my very own introduction), I sometimes fail when writing software code. Sometimes. So I’m apparently not perfect, but close. And perhaps you are the same? Everybody makes mistakes one day when creating a piece of code – no backtalks. To this day, I still get angry with people who take it for granted that software should do what they expect without fail. Whether these are the same people who assume that their code is “self-explanatory” and comments only make their code difficult to read – hard to say.. 😉

So, sooner or later when you fail writing perfect code you can’t avoid debugging.  I was and still am a very close friend of debugging.  And don’t fix it for the actual purpose of finding an error, as the name “debugging” suggests.

What does “debugging” mean and why would one debug a piece of software?

Well, looking for the origin of the term I sometimes prefer to use Wikipedia. Yes, I also heard the legends (way back in time, long before I was born…) of the actual creatures in machines that occasionally caused problems in software by their mere presence. So, Wikipedia, give me an explanation!

“Debugging is the process of finding and resolving defects or problems within a computer program that prevent correct operation of computer software or a system.”

I do agree, 95%. In my opinion, it’s way more than just reactive behavior when something doesn’t work out as you or somebody expected. Launching your debugger only once you are facing unexpected behavior with your application? In most cases, this may seem to be the case, but I find myself debugging more and more frequently to better understand someone else’s code. Or I debug my own code to better understand a new programming language, for instance. What happens to objects and their values, when or how asynchronous tasks respond and much more that today’s programming world has to offer. (Just think back, COBOL was comparatively simple considering the functional scope.) 

By the way, I always associate debugging with a UI debugger. The Java debugger integrated in Eclipse, the ABAP debugger integrated in SE80 and related tools, the developer tools in Chrome or any other UI based debugger or at least an additional debugging tool beside “console.log()” or “logger.info()”.

is it debugging or logging?

For the sake of humor: I’m fairly confident almost everyone has used something similar to this before…

var greeting;
var time = new Date().getHours();
if (time < 10) {
  greeting = "Good morning";
  console.log("good morning reached");
} else if (time < 20) {
  greeting = "Good day";
} else {
  console.log("my coding also works in the evening") //check if my coding is reached
  greeting = "Good evening";
}

And I think almost every developer will agree that this is NOT the best way to debug a program. There has to be a better way (guess what?)! Because the coding above is obviously logging.

Logging? Another topic to deal on top of an already huge topic? Admittedly, not quite out of the air. But in history, there wasn’t always a way to debug code. There was only logging and for some reason, a few people are not aware of debugging capabilities nowadays and still use logging in the wrong situation. On the other hand, many tutorials introduce logging for the sake of simplicity, but not debugging. Therefore, many misuse the logging functions in places where debugging could make sense.

Briefly to the term clarification: Logging for me is writing away information on a certain medium (filesystem/etc.), without having to use the information straight away. Classically, log files simply lie around and are only pulled out of the box when they are required. No breakpoints, no interruption of program execution, because that’s debugging from my point of view. And additionally, from my point of view, this is not either-or, both methods have their right to exist.

Debugging: Pros and Cons

Well, I’ve gone out on a limb that I am a “very close friend of debugging”. Experienced developers will probably sink skeptically into their office chair. Because of that: Yes, I’m a friend of debugging, but only in cases where I’m not yet too familiar with the programming language (a classic in Proof of Concepts) or where there’s no way of avoiding it. Especially for learning a new language or improving in an already known language, I think debugging is great.

One can inspect any variable at any point the execution stops, jump deeper into (preshipped/standard and thus more mature) methods to learn from more professional developers. Or how certain, more complex functions work. I always try to dig into the documentation of functions/methods first, but – sadly – not everything is described so well that I can inhale them. So setting a breakpoint and spectate the behavior of a certain coding is often a viable solution.

There are a bunch of pros, to be honest. But to list and explain all of them let me feel like marketing. (I’m sorry if you miss powerpoint slides filled with a bucketload of bullet points) Watchpoints, live editing of code without restarting your program, inspecting complex and deep objects (which is a nuisance with logging), etc – Debugging offers a lot! So use it!

But debugging doesn’t stop there from having disadvantages. Debuggers can’t solve a number of problems. Bugs have the characteristic that they are not deterministic. Reproducing a bug, possibly with a user interaction in a UI or with third-party systems involved – it’s unfortunately not always as easy as you might think at first. So the bottleneck, in my opinion, is the dimension “time” as in you can’t travel back in time to have the exact same situation again! Debugging remote processes or multi-threaded processes is also not necessarily extremely convenient or often not possible at all.

How much fun would it be to debug the above multi-threaded Java logic? I don’t wanna debug it, honestly.

Logging: Pros and Cons

While the dimension time was the bottleneck during debugging, it’s vice versa with logging.
Timewise you can simply scroll back and forth in your log file in order to imagine what the execution was at a certain point in time. And I repeat myself, but recreating the state of a larger application at a particular time is often tricky. A major plus of logging

There’s no real bottleneck in logging. It is rather problematic to select which information should be dumped out. Sure, technically I could just log out the state of the complete runtime environment after every statement. And then we would actually get our well-known bottleneck: performance and storage capacity to store the corresponding information. And that’s probably the most difficult aspect of logging and somehow feels like a “contra”: Be aware of what you want to log, where and for whom. What: Too much, too less? Where: Are you sure you want to use all info logs in the productive environment? For whom: It’s not always you who checks the log files in case of a production error. Or let’s say in the rarest case it is you who first encounters the errors.”Always treat all others as you’d like to be treated yourself.” 😉

As an example, which one would you prefer?

ERROR: failed saving customer

or

ERROR: failed saving customer -- KUNNR=4711, InsertObjects=[id=4711_DE country="DE"] - SQLException....

I guess you got a feeling what I’ve tried to describe you…

Logging is also remarkable for the comparison of the application state. For example, you can print an array or object before and after calling a function. None of this is available for debugging or only hardly achievable.

I would narrow it down to: Logging is powerful, not yet the best solution every time. But keep in mind to log “as much as necessary, as less as possible”. And hopefully as soon as possible. Because your next bug will come soon and you might not be able to reproduce the bug in order to add necessary logs to the dedicated program behavior again.

Not everybody likes debugging. Do you?

To give you an idea, that not everybody is happy that developers have debuggers handy. I’ve met some developers or architects in my life who don’t have a crush on debuggers. And for very specific, sometimes peculiar reasons. Of course, I don’t want to deprive you of that, here are just some quotes I came across:

Linus Torvalds, Linux

“I happen to believe that not having a (kernel) debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don’t get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_.”

Robert C. Martin, Author & Editor of various books:

“I consider debuggers to be a drug — an addiction. Programmers can get into the horrible habbit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort. Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just rewriting the offending code, *then* you may need a debugger.”

John Graham Cumming, CTO Cloudflare

I hate debuggers. And not only do I hate them, I rarely use them. For me, a debugger is (almost) always the wrong tool. And people who habitually use debuggers are making a big mistake, because they don’t truly understand their code. I suspect that the same people who use debuggers all the time, are the same people who don’t unit test their code.

Well, this is just my opinion. What is yours? What do YOU think? How do YOU relate to / use debugging? I’m really curious about your thoughts!