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

    dd($value);

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Invest in user stories

Meet Timmy. Timmy is a freelance developer with several years of experience. He has previously worked on small to medium size projects and has a good feeling about his ability to execute.

Meet Sarah. Sarah is head of sales at BigCo Consulting. Since she started at the organization as an intern, they have grown leaps and bounds. She now runs a team of ten people but managing communications within them is becoming unwieldy. She has at best, a vague idea of how tasks she is assigning are getting completed and in what time.

Sarah has heard of the good work that Timmy did for her friend. She believes that her organization would benefit a lot from his services. Seems everyone is making it big in tech this days and she wants in on it.

A kickoff meeting is set off between Sarah and Timmy. Sarah explains that she needs a system to manage her workers more effectively. They discuss about potential features on the product and come up with a list that Timmy is to develop.

  1. Secure authentication
  2. Task management
  3. Accessible from anywhere

This feature list seems good and Timmy comes up with a time estimate and tells Sarah what she needs to pay him. A contract is signed and they both leave the table happy.

One month later Timmy is back with the first MVP done. In the MVP the app enables Sarah to assign tasks to her staff but is still unsatisfied with the product. She can’t really pinpoint it but she doesn’t feel that the app will be particularly useful especially because she could have just as well sent out an email to the team member with the same task.

Sarah decommissions the app having only paid the deposit and leaves the table thoroughly dissatisfied. Timmy feels the deposit paid was barely enough to cover the work done and loses a potential referee for his work. What went wrong?

The curse of knowledge

KRS One has a lot to teach us in the software world. Everyone perceives the world from the prism of their personal experiences. Sarah and Timmy come from vastly different worlds. In Sarah’s mind she saw that she had properly communicated her intent, she assumed meaning to her words were built from the same pool as Timmy’s. Timmy assumed the same.

Unfortunately whilst Sarah was thinking of automating her existing process, Timmy was imagining all the bells and whistles he could build on top of her task list program.

Is there a way out of this conundrum?

The bad news is that there isn’t. The good news though is that we can mitigate it.

User stories

A user story is tool used to capture a description of a software feature from the users perspective.

A good user story outlines specific software feature while keeping all the requirement in a consistent format.

They are easy to write, read, evaluate and dare I say fun.

A user story comes in the format:

    As a ______
    I want to ______
    So that ______

User stories come with goodies that would have saved Timmy and his client from the situation they found themselves.

The goodies I speak of are the characteristics that all good user stories share. They have a convenient Acronym

    INVEST

Independent

Good user stories are independent. That is they can be developed separately from each other. By putting the requirements in form of user stories. Sarah would have been able to prioritize the user stories that had the most value to her. This action would have informed Timmy on what Sarah’s actual needs were.

Valuable

Each user story comes with a non-codable part, the So that _____ bit. That part of the story gives meaning to the requirement. Sarah would have a good platform on which to elucidate not just what she wanted built but why she wanted it built.

Estimable

Software estimation is hard to get right. You can tell when the leading material on the subject is called Software Estimation: Demystifying the Black Art.

Yet we humans can better estimate smaller components than we can larger ones. User stories enable Timmy to get a more realistic view of how the project is and Sarah to understand the effort required to build her application.

Small

User stories should be small enough to fit on an index card. A side effect of this property is that each story can be developed rather rapidly. The quicker the story is developed the faster the feedback loop between Sarah and Timmy can be closed.

Testable

Written in this format, it is fairly easy for Sarah to run the user story through the application to see if it actually meets her expectation (Technically called Acceptance test)

There we go. I am convinced next time, Timmy and Sarah will use user stories to capture their requirements. What about you?

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to give critical feedback

You get a frantic call at 2am at night from your most valuable client, their payment processing page is returning a 404. You jump quickly out of bed and login to github to see what changed in the code. You note one of your junior developers merged his local test branch to the main branch. What do you do?

The story above may seem convoluted but many product owners have nightmares of it and even more have seen a version of it play out in real life.

But today we are not going to go technical and talk about version management, no, today we talk about the developer. Yes that is the human being who just messed up.

Faced with this situation your initial reaction maybe to simply jump at this persons neck and strangle them, 18th century style. Yet doing this would be the most ineffective way to handle the situation.

In this entry we talk about techniques of giving critical feedback.

Bad news does not age well

Don’t keep the feedback to yourself no matter how bad it is. Tell the concerned individual as soon as is reasonable.

Telling them the news early allows them to see the effect of their mistake on you, the client and the organization.

The devil vs the person

Back in primary school, our disciplinarians used to cane us while saying “It’s not you am caning, its the evil inside you”.

In our anger it becomes hard to separate the person from the behaviour. No, your developer is not the devil reincarnate she just made a mistake, thats as human as it gets.

Point out the specific behaviour and have her correct that.

Get to the point

Illusion of transparency is a phenomena in which an individual overestimates the degree to which their personal mental state is not known to others.

With this information in mind, you may realize that the developer probably has no idea why you are fuming. If you fail to give specific feedback he will overtime come to the conclusion you are neurotic, a person to hide from, not listen to.

As a power tool, you may want to have the offender rephrase the problem he caused and the steps he plans on taking to prevent such an occurrence in the future.

The folly of sandwiching

The sages of old said it “If you wish to give bad news, first start with good, then the bad and finally more good”. This is really tempting to do since we want to protect the feelings of the recipient of the bad news. Yet in practise it never works as expected!

You see we humans are particularly adept at selective hearing. The developer will hear all the words but only remember the good parts. Not ideal to inspire any changes wouldn’t you agree?

Positive reinforcement

Sandwiching maybe a bad idea but that doesn’t mean you should throw appreciation out of the window! What you need to do is actively look out for changes that you want to see and reward them as they occur.

Negative actions and behaviours have a powerful emotional impact compared to positive ones. You must always be looking to compensate for this bias. Better to err on the side of compliments.

How have you dealt with mistakes in your workplace? Tell us in the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail