Debugging: The Art of Loosing Your Mind!

If you're a coder, you know what the title means...  If you're not, this post is not for you.

Debugging is essentially trying to fix some code that does not work.  You know what goes in, you know what should go out.  But the results are not those expected.  It should be easy as every instructions are written in front of you.  You just have to find where the numbers do not add up as it should...  Wrong!

Trying to find an error in more than 100 000 lines of code is like trying to find a friend in Montreal.  You know where he's been, you know where he should be heading but you just don't know where he is...

Figuring out what's wrong requires a lot of concentration.  Especially when the issue does not generate an explicit error on the screen. Sometimes, it can be data that is wrong, sometimes it's a matter of logic, sometimes it's the regional settings of Windows that gets in the way.  You never know where to look, you never know what is the "real source" of the issue right from the start.

With time, you discover better ways and workarounds to find the source of the infamous bug, but often, it's a matter of trial and error until to nail it.

When we were young, we were playing this little game that goes like this:
- When I go to the grocery store, I put in my little basket...  a carrot...
- When I go to the grocery store, I put in my little basket...  a carrot... a cake
- When I go to the grocery store, I put in my little basket...  a carrot... a cake... some rice...

And on and on.  Each player has to add a new item to the basket, after reciting to whole grocery list.  Miss one item and you loose.  The last one who stands, wins.

This is a fun game, but it does require a good memory.  How far can you go?  12 items, 30 items, 100 items...  If someone talks to you as you are trying to recite the complete list, you will loose your concentration and probably miss an item or get it in the wrong order.

Debugging is worse than that game.  You have to remember 1000 items, in the order they occurred, with the weight, colour, price and their supplier.  Sometimes, you can't pause the list if it's going to fast and you have to start all over again.  Then someone interrupts you to ask about when it's will be fixed as they are in a hurry...  Again, you have to start all over again.

You take notes, so you won't forget where you were only to find out later that you don't remember what those notes really meant as they are now out of context.  So you need to start all over again...

This is debugging:  Remembering a really long list of interactions happening in real-time and trying to understand what is happening before it happens.

Next time you see a coder holding it's head, fully concentrated on his screen, stop!  Don't break his concentration, don't interrupt his mental process because he may have to start all over again, for the 10th time.

Where is WebcamStudio?

You may wonder how you got on this blog instead of the old WS4GL.org webpage?  

I am slowly phasing out ws4gl.org as I am no longer working on the WebcamStudio project.  The domain won't be renewed this year.  My focus is now on Crombz.com and Youtube as you may have already seen.

So where is WebcamStudio?  It's still alive and well.  It is currenly being maintained by Karl Ellis.  Here's a few links you help you out:

http://code.google.com/p/webcamstudio/ - The official SVN repository
http://launchpad.net/~webcamstudio/+archive/webcamstudio-dailybuilds - The Ubuntu PPA repository
http://plus.google.com/communities/110329269823088092206 - The G+ Community
http://www.facebook.com/groups/webcamstudio/ - The old Facebook Group WebcamStudio
http://www.soylent-tv.co.nf/ - Karl's website where he uses WebcamStudio

Thanks!  It was a great ride!

Now, why not subscribe to my Youtube account?  http://www.youtube.com/user/patrickballeux

How to make more money!

I started a new project a few days ago: MineLotto



The basic idea is to use the power of SQL to find patterns in a list of lottery results drawn since 1982. Technically, it's a great challenge. And who knows, I could find the ultimate way of getting rich ;)



Visit my new YouTube channel "MineLotto" and leave your suggestions on how to explore more than 3000 lottery results.

Patrick Balleux

Beware of the dates!

One of the hardest thing to handle when developing a solution are dates. You always end-up in some worst case scenario if you are not careful with them.




This week, it happened to me. Lucky we found the issue while executing a series of test plans, just in time before shipping into the production environment...

Brain Facts: The Rule of 3

Have you ever tried to remember a phone number? I'm pretty sure you did. We all did. Haven't you noticed that phone numbers have a pattern that helps us remember them? 3 digits, followed by another 3 digits and ending with 4 digits (in North America at least...).

Most of us will actually see 3 digits, then 3 digits and 2 pairs of digits. For example (#1): 819-555-1010 (don't worry, it's a fake number).

You probably have read: eight,one,five --- five,five,five --- ten,ten

iOS versus Android: Comparing Apps

I have both iOS and Android devices at my hand.  Tonight, I started comparing the major apps between both platform.  Nothing fancy, just a quick comparison between them.

Here's few screen captures taken at the same time (almost).  You'll notice that the Android device, an Asus Memo FHD 10 (Android 4.3) is wider than the iPad 4 (iOS 7.0.4).  Some layouts may be different because of this.

How to update Asus Memo FHD 10 to Android 4.3

Here's an easy way to upgrade your tablet Asus Memo FHD 10 (ME303C) to Android 4.3 if your have the US SKU.

How to kill a sheep?

I admit, I had time to waste...  But it was fun!

See my latest YouTube video: Kill a sheep, Minecraft Style!

PocketMine Server and MCPE 0.8.1

I was curious about running PocketMine-MP on my Windows laptop to host a game for my iPad and my iPhone.  I found out that the latest version of PocketMine-MP is not compatible with MCPE 0.8.1.

After some investigations, I finally found a quick fix to make it work.  See my tutorial on YouTube.

WS4GL.org redirected here...

As I will phase out ws4gl.org this year, don't be surprised to land on my blog.

The domain http://ws4gl.org is currently being redirected to http://hotcoding.crombz.com


Patrick Balleux

You can't code what you can't explain

As developers, we've all been asked to add a new feature or to create a software that will do what a user wants. At the start, the request looked simple enough that we started coding right away as proof of concept that ended up as the final product. It took just a few hours, contained many tweaks and it was unstable. But it worked.



Then the debugging cycle starts and we get trap into a fix/deploy/re-fix/re-deploy circle as the user is asking for more and pointing out that what we've developed does not meet his requirements.

At some point, we would need to start from scratch as the code is getting harder and harder to maintain due to the fact that it was a mere proof of concept at the start.




The issue is not your developper skills nor that users are asking the impossible. You were too eager to start coding and did not make sure that you understood everything about the initial request.

The best way to ensure that you know everything that is required for a new feature is to write a functional documentation. I know, it can be boring if you don't like to write, but it will save a lot of time and money in the end.

Upon a new request, the first thing you should do is asked: Why? Take notes, take the time to understand the whole issue from the user's point of view. Try to figure out what the user is trying to achieve by having this new feature. In fact, it may be hiding another issue easier to fix or he may be simply not know how the use the existing softwares properly. It's a matter of figuring if that new request will solve his problem or just add another layer in his work process.




Write everything down in details. Describe each and every steps of the work process. Try to explain with words the main issue, the current work process and finally, the new work process that will be put in place with the new feature.

Make detailed list of data that will need to be handled, each conditions, each constraint. Ensure that you have covered all possibilities and results that should be provided on each one of them.

Once you have completed that documentation, review it with a colleague. Ensure that what you have written does explain the issue and the solution so that anyone will understand the whole process using your documentation.

Finally, review the documentation with the requesting user to ensure that everything has been covered. Often, the user will realize that something is missing or that the described process is not exact and will provide you with valuable informations. Rework your document until the user is satisfied.




At this stage, no code was written, everything has been covered and the user as approved the final result.

Writing a functional document can take a few hours to a few days. Writing code that will need to be fixed over and over again can take months if not years. Better edit a text document than a 100k of lines of code.

If you are having a hard time putting down your solution in spoken words, how can you expect to write down the perfect code?

Listen, explain, validate then code!


Patrick Balleux