Skip to Content
Technical Articles

Maxi’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!

20 Comments
You must be Logged on to comment or reply to a post.
  • Using the debugger is a habit of people who don’t know or are not trained to automated unit tests. But in some tricky situations during development, especially when you are beginner in the language, the debugger cannot be avoided; when it’s about solving an issue, then the debugger is THE tool needed to understand the reason and to prepare the missing unit tests. I write my code using TDD if I can, or at least define unit tests as far as I can to avoid the debug, but there are many unexpected situations so I still use the debugger a lot.

    @Maximilian Streifeneder I use ABAP. My colleagues don’t write test classes, but let’s them answer.

    • Hey Sandra!

      interesting to hear, guess a huge number of developers do agree. Which language(s) do you code in? Does everybody of your colleagues use Unit Tests? Lot of folks I know still don’t use Unit Tests on a regular basis, that’s why I ask 😉

  • Many interesting thoughts Maxi 🤔

    (Unit) test automatization is not easy when you’re doing UI(5) development, which is why I started to love debugging and the Google Chrome DevTools in my previous position. I think it’s also a great tool when you want to understand someone else’s code (e.g. to understand OS contributions better).

    But there obviously areas in which debugging can be described as an “anti-pattern” (as Linus Torvalds and Robert C Martin mention).

    It actually reminded me of this quote:

    “Most coders think debugging software is about fixing a mistake, but that’s bull****. Debugging’s actually all about finding the bug, about understanding why the bug was there to begin with, about knowing that its existence was no accident. It came to you to deliver a message, like an unconscious bubble floating to the surface, popping with a revelation you’ve secretly known all along.”

    Elliot (from the TV Show Mr. Robot S1.Ep3: eps1.2_d3bug.mkv)

    • haven’t thought about the different facets of backend and frontend debugging, you’re totally right! Was over my Mr. Robot addiction, thanks for reminding me to get back to the series 😀

  • Wow great thoughts. Here are my 2 cents

    • Primarily my reason for debugging has been more or less similar to yours. One to understand how this great application has been developed kind of reverse engineering and learning from some great patterns deployed and  second is to understand how the new programming language behaves for example while learning javascript i used it a lot. I will be honest here being an ABAP programmer we have been using debugger a lot to find the root cause but after reading specifically the “Not everybody likes debugging. Do you?” it has added another dimension in which we should definitely give it a thought. I am actually speechless after reading the 3 quoted statements and thinking in an endless loop now:)
    • Logging is something we have been dealing with a lot off-late while working on a complex highly customized My Inbox application. This application  is connected 10+ different systems. The data being sent via RFC, background tasks to central systems and inconsistencies happening regularly.  In order to understand them we needed logs but not debugger. The quality of logging improved with each iteration as we realized that we need to neither have more information nor less. A balance is must.

    I will say both logging and debugging compliment each other depending on which situation you are in but “Not everybody likes debugging. Do you?”  has left me wondering what all i was doing in all these years. Never too late to learn.

    Thanks for the great blog.

    Nabheet

    • Hey Nabheet!

      I find myself in your comment. thanks! Have you developed any kind of guidelines for logging? Always looking for the right kind of questions in order to distinguish if a log-statement is necessary at all, etc..

      Cheers!

      • The application for which we implemented logging was used on a mobile, so initially while finding reason for the first issue we ended up creating one more issue which is the performance. So after N number of iterations we had a version which was just right, logging important stuff and can be turned on and off as and when needed. This switch was very important for us. Let me see if i can share some tips based on my learning via a blog which will be helpful and we might see better approaches coming up.

        Thanks

        Nabheet

  • Great blog!!

    I would like to point out that there is a growing trend amongst consultants to misuse debugging to find out what customising they have missed out or due to what missing data they are facing issue.

    Unfortunately the developers are always at the end of line not knowing whether it’s a “bug” or something else.

    I do not know yet if we can even curb such misuse.

  • Maxi,

    thank you for the blog and also for the animated image 🙂 I use the same type of images on my blogs.

    Well, in my opinion, debugging is done for more than finding issues to software code… in my opinion, when I inherit a piece of code (or an entire application), I like debugging to see how the execution of code happens. There may not be any issues with the code but I still want to see the execution of certain functions, operations, logic path, or even judge (good or bad) whoever wrote it 🙂 If it is well written, I learn from it and take notes. If it is badly written, then I can either try to improve it or suggest to that dev why I think it could be improved – after all, I am in the team now and we either all succeed or fail together.

    Moreover, I like logging to see certain values or conditions as I debug, even though there may be other ways to see what the current values of execution are at a specific point in time/line of code… depending on what a developer is debugging, then there may be different ways to tackle the problem… as you mentioned, if you are debugging a UI, you could use the browser tools, if you are debugging a web service, you could use 3rd party tools such as postman to send a request, scripting to automate your UI tests, among other options. if you are debugging SQL, well that is a different monster all together, I am sure you and other developers have debugged a sql script/procedure that works (or doesn’t in dev) and as soon as it gets moved to a different environment, the it behaves totally different, well, guess what in QA/Prod, we can’t really debug because we may not have enough permissions to do so, therefore, we may add a few log commands in between to see what is happening… what if you are debugging a mobile app and as you know, it behaves differently on different devices and with different programming languages (your comment about doing PoCs)… what about debugging a piece of code that runs on several severs and one of them has an issue (yikes and yes it happened in one of my projects… and I ended up adding a response header to identify which darn server it came from) Anyways, I am sure there is more to the story…. I really enjoyed reading your blog…. keep it up!

    • Sergio!

      which animated image are you talking about? thanks for nothing 😉 judging code, you are so right, entertaining pastime too beside your very accurate arguments! Other than that, I enjoyed your examples of debugging scenarios too. Heck, i struggled a lot to shrink the content for this blog – happy that I read your load of examples only right now, otherwise I may have changed my mind 🙂 There’s so much to write about!

  • Hey Maxi.

    I’ve been doing development for around 15y and I’ve done way more code I’m not proud of than the opposite.   Coming from the C and Fortran MPI development, struggling to debug distributed race conditions with crazy distributed tracing tools we developed ourselves, I got really bitter towards debugging and would happily throw away code and reimplement stuff instead of trying to fix.

    I like this quote and I think it goes well in dev.: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe” (Abraham Lincoln). So, with a bit of experience and self love you can get rid of a lot of pain and debugging and depending on the type of software, even unit testing is questionable (have you ever read about anyone actually unit testing bash scripts?)

    Throwing another quote here:  Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. (Kernighan)

    On the other side (and punchcard folks will bash me), but I like very much Erlang ‘let it crash’ approach for building reliable services. Of course it cannot be applied everywhere, but even bugs are not that of a nasty thing, depending on the context and technology.

    So, like most things in life, I believe debugging or neither good or bad and it depends on the context, developer experience, technology behind, availability of debugging tools …. and let’s be honest … code quality and deadlines.

    And thanks for the post!  I think it’s really nice to discuss this sort of things  😉

  • Hi Maxi,

    Nice blog there..

    But I believe the last 3 quotes gives a very wrong impression about debugging, atleast for me :D.

    If you write the code, logging is pretty much required and of course the unit tests. But remember no one is perfect and everyone makes mistakes.

    “Unit Testing is good for making sure things we already expect continue to behave as expected” and the same thing applies for logging.

    If we are writing a small – medium piece of code, then the issues might not come, but if we are creating some big applications or frameworks or our application dealing with other frameworks then we need to debug at times to understand it better( Not everyone will have photogenic memories here 😀 to remember the hundreds of lines of code we write everytime ).

    Instead of spending hours to understand what might have went wrong, it could be solved by just going through the debugging in a minute and it can be vice versa as well. I guess logging/unit testing/debugging should complement each other like few people mentioned here, we should know when to use one. Just simply believing the other is not good is a narrow thinking!

    BTW I recently posted a blog on how I solved an issue by debugging. The problem with that  SAP architecture is that it will not give any error or logging (which I believe is right) and a silly mistake I did, the framework didn’t pick my piece of code. So its unavoidable to debug that to find the issue.

     

    BR,

    Mahesh

  • I don’t use unit tests but I don’t spend my days in debugger either. Couldn’t care less what some highfalutin’ CTO or Uncle Bob thinks about it. Pfst. When you need it it’s helpful and I am yet to hear about a single case of “debugger addiction” in ABAP Community. And SAP debugger is fine, maybe debuggers just suck in other environment and now everyone is like “booo, debugger!” Unjustified generalization, as usual.

    Debugger is not a drug. It’s a plunger. No one longs to use it. But when you need it – you need it.

    • Thanks Jelena, couldn’t imagine a more honest comment! 🙂 Really love the ABAP Debugger! Frankly speaking I know some debugger addicted folks following the “first debugging, than reading the code”-paradigm, but that’s fine in most cases.

      Didn’t want to start a war anyway 😉 It’s the time of openness!

      • Not sure what goes on internally at SAP but on the customer side the SAP code complexity helps to keep everyone’s debugging addiction in check. Every time the business users are like “can’t you just debug this transaction to see what it does?” I’m like “are you insane?! heck no!” 🙂