Dealing with elusive bugs

We all have been there before, you make an update to the code, hit refresh and get the dreaded Error Exception. No error message. No way to track what you did wrong.

The sensations that follow can only be described as horrid as you scramble to sort the issue yet you still end up in the same place. Stuck. At this point you start doubting why you even joined this horrid field, with its horrid deadlines. Maybe, just maybe you really are not cut out to be a Software Engineer.

Well the good news is that you are not alone, in fact I am going to discuss how I deal with this very issue myself. The bad news is there is no magic bullet. With that said lets start exploring, but first a story.

In southern Mynammar, locals still hunt monkeys for food. Now if you have ever dealt with monkeys you understand this animals are rather intelligent beings. Yet the burmese invented a very simple trap to catch them.

The design of the trap consists of a hollowed out coconut tied down. The coconut has a small hole through which a monkey can squeeze its hands in. Rice, a delicacy to the monkeys, is put inside the coconut.

The monkey slides in its hand through the small hole and takes in its fill, however it now can not remove the hand.

The hunter then is at leisure to come in and take his game.

Back to our stuckness. We tend to be a bit like the monkey. In solving our problem, we hang on to an idea of the solution. Enticed by it, we don’t let it go even when we feel intuitively know nothing is coming of it. We tug and tug. But what if you we’re to advice the monkey, would you tell it to continue to tug?

Getting unstuck

  • Retrace where you have been. How did you come up with this solution? What informed the decision
  • Write the reasons down. And I mean physically, not in your head!
  • Stare at your list
  • Take a break. Minimum 30 mins. Ideally a nap would be even better.
  • Come back and start writing other possible solutions
  • Start with the first idea, i.e the one that got you stuck
  • Write all the other ideas as they flow. This is not the time to judge write whatever comes to mind no matter how stupid

While not a guarantee, its likely that another potential solution will come to you, this one more suited to your problem.

Have you been in such a situation before? How did you handle it? Talk to us in the comment section below.


Ignore them at your own peril

A big problem exists in the tech industry. Specifically that it seems that software development is considered analogous to coding. This misconception is very dangerous and may very well be the reason your next project fails!

Lets start by looking at what the definition of coding is:

    Coding is the mechanical translation of preexisting design into a computer language.

By that definition we can already tell there is more to software development that just coding, so what is this more. Steve McConnell to the rescue! In his epic book Code Complete aptly nicknamed The Bible by software designers, Steve lists other processes that relate to the building of software, below is the listing;

  • Problem definition
  • Requirements development
  • Construction planning
  • Software architecture
  • Detailed design
  • Coding and debugging
  • Unit testing
  • Integration testing
  • Corrective maintenance

As you may have noted, coding is way down the list!

Going through all this steps might seem like a lot of bureaucracy and that doesn’t play quite well with us techies who most got into technology to avoid it. Still you should consider the steps for all non trivial projects.

The reasons are many but below are samples:


Scheduling is a pain to even the most experienced practitioners in the field. In a previous blog post Simple Software Estimation we talk about how to estimate the time it will take to write software. However the client/market cares about how long the entire process of software development takes. By having a more holistic view of the processes. You will be able to give better estimates.


Users of your application care only if the product meets their needs, by giving proper credence to earlier stages of the development process, you are more likely to build a product that the market actually wants not what you think they want.

Resource management

Administrators in the project can get a better view of the entire project and see what resources they will need when they will need them and level which they will need them. This helps avoid last minute rushes hunting for talent.

Code quality

The single most effective way to boost the quality of your code is to work on the design. The benefits of front up design are many, I will likely cover it in another post but suffice it to say planning architecture of your code helps you avoid writing Spaghetti code

Emphasize all tasks

If you don’t make a conscious effort to consider the other phases, you are likely to simply ignore it and jump straight to coding! Properly considering all aspects ensure that they all get their spot on the table.

What is the software development process in your own organization? Talk to us in the comment section below


Wicked Problems

There are many types of problems in software and we developers love to solve them all. However there exists a class of nefarious problems that all teams must go through and they are no fun at all, welcome to the world of Wicked Problem

A Wicked Problem is defined as a problem that could be clearly defined only by solving it or part of it.

For most problems we first understand the problem then find ways to tract it, Wicked Problems offer no such luxury.

Essentially the only way to solve such a problem is iteratively by first coming up with a tentative solution which helps you define the problem then solve it again to come up with a solution that works.

To know wether you are smack right in the middle of a problem Conklin in his book Dialogue Mapping: Building Shared Understanding of Wicked Problems shares what characterizes a wicked problem:

  1. The problem is not understood until after the formulation of a solution.
  2. Wicked problems have no stopping rule.
  3. Solutions to wicked problems are not right or wrong.
  4. Every wicked problem is essentially novel and unique.
  5. Every solution to a wicked problem is a ‘one shot operation.’
  6. Wicked problems have no given alternative solutions.

In the world of software design, non trivial projects are inherently wicked. This follows from the following facts:

  • Requirements are almost certainly guaranteed to change
  • Different designers can come up with different designs all of which are correct
  • The design process is full of false starts
  • There is no way on the onset to know if your chosen design is good enough
  • A good design is usually subtly different from a bad one.

While I would wish to conclude this article with nice algorithmic solution to this class of problems, the best advice I can give is when you come across such a problem, iterate and iterate first. It’s far cheaper to correct design mistakes at design stage than when you have a full blown coded project.

Have you dealt with a wicked problem before? How did you handle it?