« Archives in December, 2009

The Safety Net That Wasn’t

The other day, I wasted time debugging some Java code. When I say “wasted” I do not complain about debugging per se — debugging is part of my life as a developer. Time was wasted because debugging should not have been necessary in this case. Let me explain…

It just so happened that I called a method but violated a constraint on a parameter. Within the called method, the constraint was properly enforced via the use of an assertion, just like in this example:

Normally, my violation of the method’s contract would have been immediately reported and I wouldn’t have had to debug this bug. Normally, yes, but not in this case, as I forgot to run my program with assertions enabled. So instead of

I wrote what I had written thousands of times before:

Silly me, silly me, silly me! That’s what I thought initially. But then I was reminded of the words of Donald A. Norman. In his best-selling book “The Design of Everyday Things” he observes that users frequently — and falsely — blame themselves when they make a mistake, when in fact it is the failure of the designer to prevent such mistakes in the first place. Is it possible that Java’s assertion facility is ill-designed? After having thought about it for some time, I’m convinced it is.

Assertions first appeared in the C programming language and they came with two promises: first, assertions are enabled by default (that is, until you explicitly define NDEBUG) and second, they don’t incur any inefficiencies once turned off. These two properties are essential and Java’s implementation misses both of them.

The violation of the first principle means that you cannot trust your assertion safety net: It is just too easy for you, your teammates or your users to forget the ‘-ea’ command-line switch. If you don’t trust a feature, you don’t want to use it. What use is an anti-lock break system that you have to enable manually every time you start your car?

Efficiency has always been a major concern to developers. If you execute your Java code with assertions disabled (which is, as we know, unfortunately the default) you will most likely not notice any speed penalty. What you will notice, however, is the additional footprint for your assertions that will always travel with your Java program. There is no way to compile assertions out. Take a look at this C example:

A prerequisite of any binary search implementation is that the input values are sorted, so why not assert it? Since we need to iterate over all elements, a simple assert expression is not sufficient. Contrary to Java, this is not a problem in C and C++: the code for the assert as well as the for-loop will be removed from the release build, thanks to the pre-processor.

While assertions — especially non-trivial assertions that require supporting debug code — already waste memory, you can do worse if you use the kind of assertion that allows you to specify a string to be displayed when an assertion fails:

This string is of little use. If a programmer ever sees it, (s)he will have to look at the surrounding code anyway (as provided by the filename, line number pairs in the stack trace), since it is unlikely that such an assertion message can provide enough context. But, hey, I wouldn’t really mind the string if it came at no cost, but in my view, wasting dozens of bytes in addition for the string is not justified. I prefer the traditional approach, that is, an explanation in the form of a comment:

Assertions are like built-in self-tests and one of the cheapest and most effective bug-prevention tools available; this fact has been confirmed once again in a recently published study by Microsoft Research. If developers cannot rely on them (because someone did forget to pass ‘-ea’ or inadvertently swallowed the assertion by catching ‘Throwable’ or ‘Error’ in surrounding code) or always have to worry about assertion code-bloat, they won’t use them. This is the true waste of Java assertions.

Personal Scrum

pomodorosEven though I’ve never participated in a Scrum project, I’m a big Scrum fan. I’m convinced that a feedback-enabled, quantitative project management approach, one which puts the customer in the driver’s seat, is key to avoiding delays and frustration.

Especially the concept of time-boxing is very powerful: the Scrum team sets their own goals that they want to achieve within a given period of time. In Scrum, this period of time — or iteration — is called “sprint” and usually lasts two to four weeks. Because the sprint deadline is in the not-so-distant future, developers stay on track and the likelihood of procrastination and gold-plating is fairly low.

But there is even more time-boxing in Scrum: Every day at the “Daily Scrum Meeting” the team comes together and everyone tells what they have achieved and what they want to achieve until the next daily scrum. In practice, that’s another 24 hours (or 8 work-hours) time-box.

Still, getting things done is not easy. If you are like me you are distracted dozens of times every day. While hacking away, you are suddenly reminded of something else. Maybe it’s a phone call that you have to make. Or you want to check-out the latest news on “Slashdot“. Maybe a colleague pops by to tell you about the weird compiler bug he just discovered in the GNU C++ compiler…

If you give in to these interruptions, you won’t get much done in a day. You won’t get into what psychologists call “flow“: a highly productive state were you are totally immersed in your work.

Is there a way to combat such distractions? There is, but let me first tell you what doesn’t work: quiet hours. Quiet hours are team-agreed fixed periods of time were you are not interruptible, say, from 9.00 to 11.00 in the morning and from 14.00 to 16.00 in the afternoon. Every team member is expected to respect these hours. Sounds like a nice idea, but it fails miserably in practice. Especially in large projects, people depend on each other and productivity drops if developers are blocked because they cannot ask for help for two hours. All teams I belonged to and which tried quiet hours abandoned them shortly after they had introduced them.

The solution is to make the period of highly focused work much shorter, say 25 minutes. If interruptions occur, you make a note of them in your backlog and carry on with your task. When the time expires, you take a quick break (usually 5 minutes), check your backlog and decide what to do next: either continue with your original task or handle one of your queued interrupts. In any case, you start another period of highly efficient 25 minutes and after 4 such iterations, you take a bigger break (15 – 30 minutes). That’s the Pomodoro technique in a nutshell.

Pomodoro (Italian for tomato) was invented by Francesco Cirillo, a student who had problems focusing on his studies. He wanted to find a method that allowed him to study effectively — even if only for 10 minutes — without distractions. He used a mechanical kitchen timer in the shape of a tomato to keep track of time, and hence named his technique after his kitchen timer. He experimented with different durations, but finally came to the conclusion that iterations of 25 minutes (so-called “Pomodoros”) work best.

I like to think of the Pomodoro technique as “Personal Scrum”. To me, a 25 minute time-box is just perfect. It’s enough time to get something done, yet short enough to ensure that important issues that crop up are not delayed for too long. In his freely available book, Francesco writes that while there are software Pomodoro timers available, a mechanical kitchen timer usually works best — and I definitely agree. The act of manually winding up the timer is a gesture of committing to a task and the ticking sound helps staying focused, since you are constantly reminded of time. However, mechanical timers are a clear no-no if you share your office with others: the ticking and especially the ringing sound would be too annoying.

When I’m all by myself, I prefer a mechanical kitchen timer, but if I share a room with someone else, I prefer something softer. I’ve asked the folks at AudioSparx to implement a Pomodoro kitchen timer MP3 for me: 25 minutes of ticking, followed by a 10 seconds gentle ring (yes, you can download it — it’s USD 7.95 and no, I don’t get commission). I listen to it on my PC’s MP3 player wearing headphones, which has two additional benefits: first, headphones shut off office noise and second, they signal to others that I wish to be left alone, so they only interrupt me if it is really, really urgent.

“I have a deadline. I’m glad. I think that will help me get it done.”
–Michael Chabon