Skip to main content

Why Dbux?

Video Introduction

Video Introduction

A more Personal Explanation

I (Dominik) started this project on 11/16/2019 because I felt that after programming/designing software, and debugging for 20 years, I have not fully mastered my craft. This became particularly apparent during problem solving sessions with clients, when I'm rather, or at least quite, unfamiliar with the code. Being stuck for 30 minutes or longer to locate a single bug was not a rare occasion. I felt like I was lacking something, lacking an approach, lacking strategy, and sometimes also lacking a sufficiently deep understanding of what this entirely unknown piece of code is trying to do. It was this frustration that lead me on the journey to build Dbux.

It all started with some hopes and dreams...

  1. I wanted to be able to answer (seemingly always the same type of) questions, like: How did THAT happen? Where did THAT data come from? Where did the execution take THAT turn?
  2. I wanted to actually see (not just guess/assume/theorize/conjecture/suppose/opine/test/prod/verify) what is going on.
  3. I wanted to interact more with the runtime structure, not just indirectly through print statements, or one single small step at a time. I wanted to be able to explore some of the non-obvious connections from where I am to where the bug is.
  4. I wanted to see the whole thing, zoom out all the way to gain a big-picture overview.
  5. I wanted to be able to zoom in real close and see all details regarding that one piece of code.

Given this wish list, it was clear: I needed to collect all relevant run-time data, record it and make it easily accessible. And thus, Dbux was born.

We (Dominik and Michael) believe that Dbux does NOT make someone good at debugging. However, it can help better see (and appreciate?) what is going on in our applications by revealing the hidden structures beneath it. What you do with that information, is up to you!

Lastly, we feel that it is (speaking from a rather biased position) also a lot more fun to use Dbux to interact with the actual behavior of the code, navigating along the connections, and uncovering interesting little insights into what is actually going on under the hood. It is at least more fun (or so we feel) than just staring at the code guessing, more fun than adding/removing print/console statements, and more fun than waiting for the debugging session to re-start for the 5th time, after overshooting a crucial line of code yet again.