How NOT to debug

They say patience is a virtue, if you are a developer you need saint like patience to handle the notorious case of the bug.

Ever since Grace Hopper coined the term debugging our applications have gotten much better at creating harder bugs to debug. At this age, a moth in your machine would probably not even register as a fuss worthy bug.

While there is no “right” way of finding bugs, there certainly is a “wrong” way. Today we are going to be looking at some of the most common.

Output statements

God bless Taylor Otwell for this little tidbit


The dd function dumps the variable passed on to it and then halts the script. By carefully using this function and some binary search chops, you can quickly identify problem areas in your code.

Most programming languages and frameworks provide this functionality in one form or another. Also it’s very easy to implement yourself.

Just like any other good thing, if it’s overused it becomes a problem. Just like any other good thing, its frequently overused!

It’s quite easy to tell yourself that I will put this code here to test if a bug is here and remove it later, but why test the memory gods?. Perhaps you will leave it nested in a conditional with a branch that is rarely executed. At least, rarely executed when you are testing your code. Guess when the branch will get run? Did you guess in production?

So what can you do about it?

Invest in a proper debugger. A tool like xdebug may take far longer to grok but once you master it, the rewards will be worth it.

Code like hell

This one is for all the Code Ninjas out there.

Fortunately I am not a ninja myself (See Why I am not a code Ninja). I am yet to change my sentiments on the matter.

The Code like hell style of development is where the code ninja pops up his/her favourite code editor and starts spitting out code. Damn the requirements and design.

Codebases that we’re coded in this way have a tendency to hide very hard to find bugs. The bugs are usually due to ninja level stupidity that mere mortals just can not comprehend.

If you find yourself debugging such an application, I am sorry my friend, the app is the bug.

So what can you do about it?

Follow a standard development methodology. Yes, even waterfall is better than code like hell. However if you are the unfortunate soul tasked with maintaining the application, start refactoring the code as soon as you can.

Versioning? For who? For what?

Git as defined by wikipedia.

Git is a widely used source code management system for software development. It is a distributed revision control system with an emphasis on speed,data integrity,and support for distributed, non-linear workflows.

Git as commonly used.

Git is a folder that can be pushed to a remote folder called github.

This mismatch in intend and use is characterized by thousand line codebase with one commit.

Unfortunately this scenario is all too common, even today. The effect of course is if you accidentally introduce a bug. You have no way of tracing it back to its point of origin.

So what can you do about it?

Learn to use version control properly. It really is not hard. In fact by simply using gitflow 90% of your problems would disappear into thin air.

Who cares about the need

Surprise surprise most applications we’re actually created to serve a need. Digging your grimy hands into the code’s innards without the slightest clue on why it works the way it does is simply disrespectful.

What you think is a bug just might be a feature.

    My software never has bugs. It just develops random features.

Ok that was just a joke, but seriously take the time to know the original intent.

So what can you do about it?

Take sometime to first check out the documentation and unit tests before starting the debugging. None of those exist? Refer back to the section on “Code like hell”.

Fix the symptom

With a few notable exceptions, a good number of clients just can’t explain their problem well. Instead they focus on what they can easily observe. As a developer you (hopefully) can see more. You see not just a misaligned form, but a missing tag. So what is a busy developer to do? Hard code the position and fix the immediate problem or rework the entire page to bring in all missing elements?

In the first scenario, the developer has just chased away the bug, be sure it will be coming back with its brothers, sisters and beer buddies. In the second scenario the developer solved the problem that caused the bug, not just the symptom of the bug.

If it took you more than a second to figure out the right choice you may want to check out How you pay for technical debt

So what can you do about it?

Don’t settle for the obvious, dig deeper. Try to find out what is the true cause of the issue you are now experiencing. The client will be happier and you will gain insights that will help you through your entire career in software.

How do you debug in your organization? Tell us in the comment section below.