vendredi, octobre 26, 2007

Almost-paired programming, the shrink principle and beer

This strange thought occured to me yesterday:
It is quite disturbing to see how coding can be close to a psychiatric sickness.

I was gently coding through a piece of code while being often disturbed by phone calls, meetings and other daily stuff.

The obvious outcome was a messy code with an almost as much messy runtime result.

At that precise moment, I was having a hard time focusing on this "algorithm" and the fact that the states in my java code could possibly be accessed from multiple threads was going to make things less easy.

Therefore, with all that mess in my mind and my phone ringing now and then, I started commenting my code to make it readable (a bad habit indeed, as code should be self-readable by separating concerns in methods with readable names and sharing states in richly defined objects... but anyway...).

When I was over commenting, the code did not behave any better, but was interweaved with rich textual descriptions.
Though it seemed that the added comments did not go further than the limitations I was already feeling (remember? difficulty to focus and phone ringing).
The comments themselves where sitting on top of the pile of messy code I had produced, with no added value as they were a direct transcription of how I was reasoning at that moment.

So I decided to remove all these comments and to create a few rich immutable objects for states, and using ConcurrentHashMap and Atomic* all around.
My code was indeed completely thread-safe.

But still... its behaviour was the same: not what I expected.

So I decided to call in for help.

I turned to one of my dear colleagues, and asked him to lend me a bit of his time in order to have a second look on my piece of code.
In fact, I couldn't even think of a new way to look at it.

Indeed, he gently accepted and sat next to me in order to look at my uncommented (if he reads this, he'll eventually remember telling me how messy and uncommented it looked ;) ) piece of over-immutable code.

And then began an uncontrolled shrink scene.

Here's how this dialog (approximatively and "embellished" a bit) turned out:

me: "So here's my code, here is what it does, and things are all immutable and stuff..."
colleague-shrink: "Mmmmh mmh... So here's your code, here is what it does, and things are all immutable and stuff?"
me: "eh yes, look I've toggled breakpoints all around and I can't seem to see anything wrong"
colleague-shrink: "Mmmmh mmh... So You've toggled breakpoints all around and You can't seem to see anything wrong?"
me: "Oh no! this little thingy was there all the time...my algorithm was missing one point and I was looking for a synchronization issue. Well thank you for solving this issue with me!"


And then it occured to me that (even if my colleague would probably have solved this problem quite fast) the only presence of a real person to whom you explain your code acts like a catharsis for solving bugs.

Though this is not very new and one of the basis of paired programming, the parallelism with the shrink made me a bit uneasy.

Do I have to pay my colleague now, in order for the treatment to be efficient? ;)

So I now decided that this would now be rewarded by beers. So if you happen (or happened) to be my code-shrink, don't hesitate to reclaim your beverage!