March 22, 2007 - Coding in Public

I can code passably well and I am comfortable with public speaking - but there is something about combining the two that makes my brain just completely shut down.

Yesterday evening, I was giving a presentation on testing to the East Bay Java SIG (it went very well thank you) and I was demonstrating JUnit Factory's ability to detect behavior changes.

I wanted to implement the 'spare' functionality and have JUnit Factory highlight the changes in behavior. I generated tests for Frame and added this method:

  public boolean isSpare() {
    return ballCount > 1 && balls[0] + balls[1] == 10;

Then I modified getSecondBall() to show the spare:

  public String getSecondBall() {
    if(isStrike() && ! lastFrame){
      return "";
    if(isSpare()) {

    return formatBall(balls[1]);

When I reran the JUnit Factory generated tests, I got failures from these two tests:

    public void testGetSecondBall2() throws Throwable {
        Frame frame = new Frame(new Frame(null, true), false);
        String result = frame.getSecondBall();
        assertEquals("result", "1", result);
    public void testGetSecondBall7() throws Throwable {
        Frame frame = new Frame(null, true);
        String result = frame.getSecondBall();
        assertEquals("result", "-", result);

That first one is a straightforward behavior change - before the change the score sheet shows [9][1] and after the change it shows [9][/] - so I fixed the test. But the other failure indicated a bug.

[before you read ahead, see if you can spot the bug. HINT: the boolean param to the constructor of Frame indicates last frame]

Got it yet?

If you get a strike in the last frame, you get two bonus balls. I am reporting a [X][/] for a 10 followed by a 0. The test is (correctly) reporting that it should be [X][-]. The bug is that the condition in isSpare() should exclude strikes.

So far, so perfect. I confidently made the change to isSpare()...

  public boolean isSpare() {
    return ballCount > 1 
        && balls[0] + balls[1] == 10 
        && isStrike();

...and re-ran the tests expecting the tests to pass but there were a whole bunch of failures... ...and that's when my code blindness kicked in.

It was as though the part of my brain that knows about public speaking knows nothing about reading code. The whole Eclipse editor just turned to a bunch of squiggles in my mind's eye - like I was suddenly reading hieroglyphics - and I couldn't make head nor tail of what was going on.

The people in the audience were shouting...

Add a 'bang'!
You typed 'strike()', it should be '!isStrike()'.

...but I have learned from miserable experiences in the past that if, during a demo, I have dug myself a hole, I should stop digging. I mumbled something about "so you can see how characterization tests can help you find regressions...are there any questions?".

In the cold light of this morning, I opened Eclipse and immediately saw that I had - as my audience was telling me and as JUnit Factory was telling me - said "strike" instead of "not strike". I added the missing '!' and all the tests passed. Sigh.

I wonder if other people experience this code blindness or if it is just me? Incidentally, the same thing happens to me when I play the piano with an audience. I can practice a piece over and over without a mistake but, as soon as someone watches me play, my fingers turn to meat hooks and all the black and white keys turn to gray.

Anyway. Thank you, JUnit Factory for behaving so well during the demo and thank you, East Bay Java SIG, for being such a great audience. It's a genuine pleasure giving a presentation to smart people who get engaged in the topic and ask such great questions.

Posted by Kevin Lawrence at March 22, 2007 08:01 AM

Trackback Pings

TrackBack URL for this entry:


Hey, You may also be interested in this article

Posted by: Mallik on March 23, 2007 02:21 AM


You are describing the experience that has happened to me many times. I have learned to prepare scripts and safepoints to be able to deliver presentations that include "live coding", but are actually carefully scripted. I think part of the problem is that something that takes 30 seconds of focused thinking seems like an eternity when you have dozens of eyes pointed at you and you try to compensate by pushing yourself to think "faster" which only makes matters worse.

Posted by: David Vydra on March 23, 2007 12:29 PM

Post a comment

Remember Me?