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.


How you pay for technical debt

You are a developer working on a bespoke accounting software for your client. You need to deduct PAYE for the employees when the payroll runs.

PAYE in Kenya currently stands at 30% and for all you know, it has always been like that. So now you have a choice, simply multiply payout by 70% to get the net pay or write out a taxation module with appropriate config files that control what actually gets charged. In the first option you will only spent a minute or so writing the code, the second option obliterates your weekend. What option would you go with? Why?

Like any good consultant if you asked me what to chose, I would say it depends, but if it was my personal choice then second option it is. Now just to be clear I love my weekends as much as any other bloke. But the repercussions for the first decision are way too painful for me to bear. Here is my why.

Unplanned work

As a modern developer, you get to do a lot of planning. From sprint planning sessions to daily standups detailing what you are going to do, plans abound. And why not, planning gives us a special power,it allows us to see not just what happened but also what is going to happen.

Lurking in the shadows is unplanned work.

    Like matter and antimatter, in the presence of
    unplanned work, all planned work ignites with incandescent fury, incinerating everything around it

What is unplanned work?

Unplanned work is when you are late to go to work but you wake up to a flat tire

Unplanned work is when facebook decides to shut down parse and your entire backend is written on top of it

Unplanned work is when you get a bout of the flu during release week

Get the idea?

Obviously some unplanned work is out of your control, but a good chunk of it actually is. That good chunk is the one that arises when you don’t take any steps to mitigate project risks.

You see risk does not play nice, if you don’t actively attack it, it will attack you. It’s primary weapon of choice is….. You guessed it, unplanned work.

Flat tire? No problem spare wheel good and ready to go and factored in some buffer time before first engagement of the day

Facebook shuts down parse? No problem you only need satisfy the interfaces you had defined and inject them in lieu of parse.

Got a flu? Your code was always in deployable state with a working Continuous Integration process in production

Is my choice any clearer? You see by choosing the first option I would have let the beast of risk and unplanned work right in.

For one weekend sacrificed doing it right I have mitigated the risk of:

  1. Government changing its tax policy
  2. Client hiring expatriates, they don’t pay PAYE
  3. Client instituting institutional wide deductibles
  4. etc

You can bet that any of the above scenarios is going to cost you way more than a weekend.

By taking the first option you took time on usury. You traded in a small amount of time now for a much bigger amount of time later. On the short term you may be able to get away with it but remember all dues eventually must be paid.