Desert Island Books

Appeared in the ACCU magazine CVu, Vol 21 Issue 4, Sept 2009

Introduction (by Paul Grenyer)

I've been doing this series for ten months now and every person has been brilliant. Jon's Desert Island Books is the longest yet and, I have to admit, the one I've enjoyed the most so far. As I know I've said to many people, and maybe even in a previous Desert Island Books, it's about people and Jon has demonstrated that admirably. I've known Jon for a few years and I had no idea he liked fishing! For me, Jon has always been up there with Kevlin as the best of the best of us. He not only understands how to write software, but he understands the people that write it and processes.

Albums

I'll start with my two albums. I considered choosing an album of my own. Not stuff I personally composed or sang. Heaven forbid. I couldn't sing in tune if my life depended on it. I mean a compilation of singles from different artists. I bought loads and loads of proper vinyl singles as a boy. The singles I could list. In fact I think I will. Pad it out a bit... What comes to mind.... Early OMD stuff such as Electricity. This is the day by The The. What a cracking single that is. Echo Beach by Martha and the Muffins. I liked a lot of the mod stuff too. Poison Ivy by the Lambrettas was a favourite. Pretty much anything from early Dexies Midnight Runners. Everything by David Bowie. Recently, at my daughter's school concert a very talented fifth form girl played the piano and sang True Colours by Cyndi Lauper which reminded what a great song that is. Another favourite from later on was Jeans Not Happening by The Pale Fountains. I bought plenty of singles from previous decades too. Del Shannon, The Isley Brothers, Roy Orbison. The House of the Rising Sun by the Animals. That would definitely be on the compilation album. How many singles could you fit on a compilation CD? A hundred easily. We may be here some time... Lots by the Beach Boys. Louis Armstrong's We Have All the Time in the World (recorded for the James Bond film - On Her Majesty's Secret Service in one take. He died shortly afterwards). In short I like most things with a good tune where I have a reasonable chance of discerning the lyrics by listening (the exception being Kevin Rowland from Dexies). But I decided that would be cheating. So I've mentioned it so I can discount it but at least it gets mentioned. That seems to be a standard tactic employed by previous Desert Island visitors. Instead I've opted for two regular albums instead.

Ziggy Stardust and the Spiders from Mars

By David Bowie. I just love this album. All of this album. Every single track. Every second of every track. It's hard to explain why you love an album. Perhaps its not something you should even try to explain. How can you explain how you feel about an album you love and know intimately? Other than to say you love it. And know it intimately. So I'll leave it at that.

OK COMPUTER

By Radiohead. A very apt title. You'll no doubt be familiar with the haunting No Surprises which is from this album. Or maybe Karma Police - "Arrest this girl, her Hitler hairdo is making me feel ill, and we have crashed her party". What a great lyric. But neither of these is my favourite. My favourite is all 6 minutes and 23 seconds of Paranoid Android. I tweeted that I was listening to this about a week ago! In fact I've been fishing for the last two days on the River Wye so I haven't heard it for a while (I never take anything electrical with me when fishing - that would just not be right) so excuse me while I listen to it again for a moment... Rain down on me...from a great height...God loves his children...yeah...

Books

So on to some books. Five books. I'm going to try and make choices that haven't been made by previous visitors.

World Class Match Fishing [1]

I confidently predict no one will have heard of this let alone read it. Fishing is similar to developing software in that both can involve large amounts of invisibility. But even so, unless you are keen on freshwater fishing (as I am) I don't recommend it. To explain a little (there is a point honest), match fishing is where a group of fisherman compete against each other to see who can catch the most fish (by weight) in a fixed interval of time (usually 10am - 3pm when they're the hardest to catch). Small stretches of a river (or pond/lake) are numbered and marked and the anglers draw a number to determine where to fish. Fish, like people, do not spread themselves out evenly. Quite the opposite. Consequently the vast majority of numbers (they're called swims or pegs) have no chance of winning. It's crazy really. (What has an IQ of 100? Answer 100 match fisherman! ha ha) Swims are split into sections; in a match of 60 anglers there might be 5 sections of 12 and there are smaller cash prizes for winning your section (it helps to maintain interest since, as I said, most swims have zero chance of winning). The best anglers will regularly win their sections. Kevin Ashurst was an exceptional fisherman once winning the individual World Championships. In this book he explains, often in great detail, the thinking behind his tactics and strategies when trying to win. I love it for the unselfish explanation of his secrets but even more for the insight into his clarity of thought. Good thinking is pretty rare but he had it in abundance. There are some lovely examples of the Lean principle of removing waste. To give you one example - on a river you can sometimes beat everyone in your section even if they are "better" fishermen than you simply by making sure your float is in the water longer than theirs! How can you do that? One way is simply to slow the float down!

Northern Lights [2]

For a novel I'll pick the last one I read that I could not put down once I'd started. A wonderful book, the first in His Dark Materials trilogy, it's a hypnotic mix of fantasy and reality where the fantasy is a grown-up fantasy weaving a rich picture of a parallel but definitely alternate universe with wonderful flights of imagination. The author says he prefers not to explain the meaning of what he writes instead letting the reader draw their own more personal meaning. I guess that means I shouldn't really explain the meaning I draw from it either since it might spoil your enjoyment if you decide to read it. Let's just say that the trilogy has a fairly strong and obvious athiest aspects to it. Hitch Hikers Guide to the Galaxy [3] was a close second for the novel but I've read that so many times my copy is falling apart.

The Secrets of Consulting [4]

Something closer to home for my third book. I have a lot of books by Jerry Weinberg. His most famous is probably The Psychology of Computer Programming [5] but some parts of that haven't aged particularly well. He writes that he regrets using the word psychology in its title since he is not, nor has he ever been a psychologist. Jerry may not have a certificate or official qualification but it's clear he has a great understanding of people, of the systems they are involved in, and in consulting - the art of influencing people at their request. This is my favourite Weinberg book by quite some margin and, reading between the lines, I think it is his too. I recall Kent Beck once saying he was greatly influenced by it. It's stuffed full of advice under the banner of consulting but in truth much of the book has much broader application. A lot of the book is about change which is pretty universal. It's also one of those rare books that has quality in depth. The more you read it the more you see it's hidden layers and the deeper your understanding becomes. It's well written and the advice is summarised into numerous pithy laws/aphorisms such as The Fast Food Fallacy (no difference plus no difference plus no difference plus ... eventually equals a clear difference, p.173). For a software example of that consider compiler warnings. A rare gem.

The Life of Brian [6]

It seems a shame that Desert Island visitors can't choose a couple of their favourite films. Perhaps Paul could add it as a new category? Meanwhile I'm going to have to cheat by including a film screenplay as my fourth book. Most pythonistas agree this is their finest film. The others are a bit patchy in places but every scene of Brian is a sure fire rib tickler. It's easy forget the controversy it caused when it was released. The back of the screenplay contains some reviews and, possibly uniquely, two are distinctly unfavourable! Entirely deliberate of course. I like the New Statesman's review "Hurray for blasphemy". And let's not forget the classic song "Always Look on the Bright Side of Life". That would be sage advice if you were stranded on a desert island.

The Systems Bible [11]

My last choice is is proving difficult. Lots of worthy books will miss out. Classics such as Programming Pearls [7] and The Mythical Man Month [8]. I've been reading a lot about Systems Thinking recently. Systems Thinking essentially means non-linear thinking. Human beings have evolved a very strong association that cause and effect are simple and linear; that cause and effect are local in space and time. Unfortunately the world of software is not as simple as that. Developing software takes time. Another phrase sometimes used in this context is "dynamic complexity" a term from The Fifth Discipline [9] where Peter Senge draws a useful distinction between detail complexity and dynamic complexity. The excellent An Introduction to General Systems Thinking [10] is recommended and almost got the fifth spot, but in the end I've plumped for The Systems Bible. This is a light hearted, slightly tongue in cheek book with more pithy summaries in the forms of Laws and Principles. For example Le Chatelier's Principle "Systems tend to oppose their own proper function". Another one is called The Basic Axiom of Systems-function "Big systems either work on their own on they don't. If they don't you can't make them." Very apt. It's occasionally laugh out loud funny too. Ro/Rs on page 47 for example. Well worth considering if you want to edge away from technical aspects of work for a while.

Footnotes

• [1] Kevin Ashurst. (1977 Long out of print). World Class Match Fishing, Cassell, ISBN 0304-297291.
• [2] Phillip Pullman. (1995). The Northern Lights (The Golden Compass in USA, Knopf), Scholastic, ISBN 043995178X
• [3] Douglas Adams. (1979). The Hitch Hikers Guide to the Galaxy, Pan, ISBN 0330258648
• [4] Jerry Weinberg. (1985). The Secrets of Consulting, Dorset House, ISBN 0932633013
• [5] Jerry Weinberg. (1998). The Psychology of Computer Programming: Silver Anniversary Edition, Dorset House, ISBN 0932633420
• [6] Monty Python. (2001). The Life of Brian (screenplay), Metheun, ISBN 0413741303
• [7] Jon Bentley, (1989). Programming Pearls, Addison Wesley, ISBN 0201103311
• [8] Fred Brooks (1985 2nd edition). The Mythical Man Month, Addison Wesley, ISBN 0201835959
• [9] Peter Senge (2006 2nd edition). The Fifth Discipline, Random House, ISBN 1905211201
• [10] Jerry Weinberg (2001). Introduction to General Systems Thinking Silver anniversary edition, Dorset House, ISBN 0932633498
• [11] John Gall (2002 3rd edition). The Systems Bible: The Beginner's Guide to Systems Large and Small , General Systemantics Press, ISBN 0961825170

Another C/C++ Testing Idea - 2 phase execution

Languages that support reflection allow you to mark a function as a test which the test framework then automatically runs. Not having to explicitly run the test is nice. C and C++ don't support runtime reflection so at some level you have to also explicitly run the function. That's not so nice. But... I've an idea. One that I mentioned it to my friend Kevlin Henney and it turns out he was thinking the same kind of thoughts. As usual he was a few steps ahead of me. The idea is don't use functions! Make the basic unit of testing a block instead of a function! For example, instead of having three separate functions naming three separate tests why not have three separate named blocks inside a single function. Something like this:

void test_holder()
{
   TEST("first")
   {  ... /* assertion */
   }
   TEST("second")
   {  ... /* assertion */
   }
   TEST("third")
   {  ... /* assertion */
   }
}

The test framework then calls the function three times, ensuring each block gets run once. How does it know to call the function three times? The idea is to have two phases, a gather phase and a run phase. First set the phase to gather and call the function. In this phase the TEST macro does not execute, instead it inserts itself into a collection of test blocks. When all the test blocks have been gathered switch to run phase and run the test blocks one at a time. Here's a bare bones implementation of the idea (in C99)

#include <assert.h>
#include <stdbool.h>

#define TEST(name)   if (run_after_gather(blocks, #name))
#define IGNORE(name) if (ignore())

struct test_blocks
{
    int size;
    const char * names[1024];
    bool in_gather_phase;
    const char * run_name;
};

bool run_after_gather(struct test_blocks * blocks, const char * name)
{
    if (blocks->in_gather_phase) 
    {
        blocks->names[blocks->size] = name;
        blocks->size++;
        return false;
    }
    else
        return blocks->run_name == name;
}

bool ignore(void) { return false; }

void run(void (*test)(struct test_blocks *))
{
    struct test_blocks blocks = { .size = 0 };
    blocks.in_gather_phase = true;
    test(&blocks);
    blocks.in_gather_phase = false;
    for (int at = 0; at != blocks.size; at++)
    { 
        blocks.run_name = blocks.names[at];
        test(&blocks);
    }
}

/* - - - - - - - - - - - - - */

void tests(struct test_blocks * blocks)
{
    TEST(first)
    {
        assert(1==1);
    }
    IGNORE(second)
    {
        assert(2==21);
    }
    TEST(third and last)
    {
        assert(3==31);
    }
}

int main()
{
    run(tests);
    return 0;
}

Behaviour Driven Testing in C++

The basis of testing is very basic. You check that an expected value matches an actual value. For example, in JUnit we might write something like this...

Wibble expected = someExpression;
Wibble actual = someOtherExpression;
assertEquals(expected, actual);

You might not have noticed it before but it's quite likely your test code contains a lot of repeated occurrences of that last line (in whatever form it takes). When something keeps re-occuring you should start to wonder what the missing abstraction is. The names expected and actual are extremely strong stylized hints that an assertEquals is about to happen. And then it does happen! So how about writing something like this instead?

expected = 42;
actual = expression();

and somehow the test framework takes it as read that it has to do an assertEquals. In C++ we can put behaviour in a destructor and create an object in a scope, thus automating the behaviour when the object goes out of scope. Based on this idea I've come up with...

ARE_EQUAL(int)
{
  ...
  expected = 42;
  actual = expression();
}

The idea is that ARE_EQUAL is a macro

#define ARE_EQUAL(type) \
 if (const wrapper<type> & expected = wrapper<type>()); \
 else \
 if (const wrapper<type> & actual = wrapper<type>()); \
 else \
 if (const auto_asserter<type> & rrid = \
   auto_asserter<int>(expected,actual)); \
 else

which relies on

template<typename type>
struct wrapper
{
  operator bool() const { return false; }
  const wrapper & operator=(const type & rhs) const
  {
    value = rhs;
    return *this;
  }
  mutable type value;
};

and

template<typename type>
class auto_asserter
{
public:
  auto_asserter(
    const wrapper<type> & expected,
    const wrapper<type> & actual)
  : expected(expected)
  , actual(actual)
  {
  }
  ~auto_asserter()
  {
    assert(expected.value == actual.value);
  }
  operator bool() const { return false; }
private:
  const wrapper<type> & expected;
  const wrapper<type> & actual;
};

Kata Practice

One of my contributions to the 97 Things Every Programmer Should Know is all about deliberate practice. Pretty much the only form of software practice I've ever seen are the various Katas developers sometimes work on in coding dojos. The Bowling Game Kata for example. However, while Katas are definitely a form of practice the ones I've seen people perform have not been very deliberate; I never get the sense much deliberation is going on.

Quoting Peter Norvig again:

The key [to developing expertise] is deliberative practice: not just doing it again and again but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes.

I'm not convinced that the Katas I've seen developers participate in have been beyond their current abilities. I get the strong feeling the participants are there mostly to have fun. Be that as it may I'm absolutely certain that I've never seen any evidence of conscious analyzing of performance during the kata, and certainly no repetition of whole kata again. I mention this because I think these coding exercises have been mislabeled. I think they are much closer to being Randori than Kata.

Wikipedia says Randori is "a term used in Japanese martial arts to describe free-style practice or sparring, sometimes with multiple attackers". That's what I see in coding dojos.

In contrast Wikipedia says that Kata is "a Japanese word describing detailed pre-arranged choreographed patterns of movements practiced either solo or in pairs". That certainly matches my experience of performing Karate Kata - of repeating the exact same Kata over and over again - of moving slowly and, excuse me if I'm labouring the point, deliberately. You might argue that in the Bowling Game Kata the choice of Kata is pre-arranged. That's true but it's not the point. That's focusing on the static rather than the dynamic. The point of a Kata is its pre-arranged movements.

I think if I saw a true Kata syle practice I'd recognise it because of...

• its short duration
• a restriction on freedom of movement
• a marked slowing down of normal development speed
• a definite period assigned to reflection afterwards
• a cycle of repeating the exact same Kata again and again

For example a true Kata style practice might be only 10 minutes long, take place in a environment/ide that refused to give you edit rights to the code files until you'd written a failing test, that delayed the results of each run-the-tests event for 10 seconds or so. I'm planning to incorporate some of these ideas in the next run of the Average Time To Green Game.

2 Things Every Programmer Should Know

Are my contributions to the forthcoming book 97 Things Every Programmer Should Know by O'Reilly. I hope they're accepted.

• Do Lots of Deliberate Practice, and
• Make the Invisible More Visible.

I've been thinking about practice a lot recently. The Average/Mean Time To/Since Green Game has a large element of practice designed into it. In his excellent book The Fifth Discipline, Peter Senge writes:

The total absence of meaningful practice or rehearsal is probably the predominant factor that keeps most management teams from being effective learning units.

Average Time Since Green

Last week I spent an afternoon discussing the Average Time To Green Game with my friend Olve Maudal from Tandberg. We discussed making the game browser-based where everything happens on a game server; the source files are held on the game server, they're compiled on the game server, the unit tests are run on the game server. Suddenly the game morphs from the average time to green into the average time since green (atsg). This is a profound change. It means the atsg can be continuously monitored during an iteration rather than merely being calculated once at the end. (It reminds me of the difference between Linear Thinking and Systems Thinking.) It also opens up masses of further interesting deliberate practice possibilities for the game. And perhaps also for actual software development. I'm working on a proof of concept using Ruby on Rails.

File extension repetition considered harmful?

Don't Repeat Yourself is a well known software development mantra. Suppose your working on a C project and all the #include lines name header files whose name ends in dot-h. Aren't all those dot-h's repetition? They are. But you probably don't consider that as repetition because in this context it doesn't matter. However, sometimes file extensions become a bigger part of the context and then the repetition can start to hurt. For example, I have some PHP files whose names end in dot-php. The content of these PHP files contain some hardwired redirections to sibling dot-php files. These files live on my ISP's server and they run under PHP4. My ISP has upgraded to PHP5 - but only for files ending in dot-php5. Is it worth upgrading I ask myself.

Java initializer block trick

Here's a neat trick Kevlin Henney found in some code Michael Feathers posted at http://pastie.org/534364 Instead of doing this:

ArrayList<Integer> values = new ArrayList<Integer>();
values.add(1);
values.add(2);
values.add(3);

You can do this:

ArrayList<Integer> values = new ArrayList<Integer>() {{
    add(1);
    add(2);
    add(3);
}};

Abstraction

I came across this astonishing illusion the other day (via a Jerry Weinberg twitter). The blue spirals and the green spirals are the same colour. Really. Jerry said he'd looked at the pixels in Photoshop to confirm it. It's not that I don't trust Jerry but I looked too (in Gimp) because it's just so counter-intuitive. It is true. It's amazing isn't it.

The way we perceive the world is based partly on what information it's sending us but mainly on how we interpret that information. If we consciously saw everything we just couldn't cope with the information overload so our minds filter it for us. That's abstraction. We don't see what's there and we see what's not there.

You can see the learning

This is the barchart from The Average Time To Green Game I blogged about earlier. It's interesting to study this barchart.

1. The first green bar on the left is the highest. At this point the students hadn't realized what the aim of the game was - to control the average time to green. Everyone was busy beavering away on what they incorrectly thought they were being judged on - the trivial exercise of stripping backslash newline characters from a buffer. A couple of laptops would probably have carried on into the night without some gentle prompting. The height of the bar represents the average time to green remember. There were four very high individual times and the standard deviation was a hefty 174 (seconds).
2. The second green bar is marginally lower, indicating the average time to green had reduced slightly. Remember that before each iteration everyone swapped pairs (and moved to a new laptop). The pair swapping was the primary mechanism by which strategies for controlling the average time to green were passed on. At this point only one swap had taken place so not much strategy passing on had occured. There were three very high individual times and an even heftier standard deviation of 196.
3. The third green bar shows a bigger drop. Since there had now been two pair swaps the effect of passing on strategies was now more marked. Only now was the group really starting to realize what the true aim of the game was. They were starting to experience first hand how effective simply strategies like frequent compilation can be. There were two high individual times and the standard deviation was now down to 142.
4. By the fourth iteration three pair swaps had taken place and all the groups now genuinely understood the aim of the game (which was not to produce the world's greatest unsplice function!) Every single group got to green within 8 seconds. It was noticeable that on this iteration, as soon as the bell was rung each group chose to get to and stay at green at their first possible opportunity. The standard deviation was only 22.
5. The fifth iteration bar is perhaps the most interesting of all. By this time everyone understood the aim of the game and everyone was able to get their laptop to green within a very short time of the bell ringing. However, with some gentle prodding we suggested that they didn't have to stay at green at their first opportunity. Consequently, they were starting to decide whether to stay at green or continue for a little longer. They were starting to think about all the pairs not just their pair. This was the first real point when they were in control of the development process and not vice-versa. The standard deviation was 71.
6. For the sixth iteration we suggested the group aim for an average time to green of 60 seconds (they were at 130 seconds for the fifth iteration). On the seventh iteration the average was 85 seconds with a standard deviation of 74. Pretty impressive.

At the end of the game people were really starting to act with more team awareness. On the first iteration none of the green pairs offered to help a red pair - they just sat watching. In contrast by the end (with a little prompting) some green pairs were offering help to a red pair.

Something else that was noticeable too: at the first iteration everyone looked quite tense but by the end they all realized it really was a game and they all looked at lot more relaxed. Their manager Lars commented on how marked this difference was.

In a review the next day one of the developers commented "suddenly baby steps were being encouraged and large steps were being frowned upon." One developer recounted instinctively firing up the debugger, only to be persuaded by their partner that there were other more effective strategies.

Campaign for small change

When I'm buying something at a shop and I pay with cash I rarely have the right money so I usually get some loose change back. When this happens I look for a charity tin to drop the small coins into. I'd like to claim this is an act of generosity and altrusim but I can't. For one it's not very generous since it's only small change, and for another it's not very altrusitic since I do it mostly to reduce the hassle in my life. I go to great lengths to try to keep my life hassle free and I don't like lots of loose change in my pocket.

Of course, giving away my small loose change means I'm unlikely to ever have the correct change which creates a pleasant reinforcing feedback loop - broken only when there is no charity tin :-(

Doing this on my own doesn't make a lot of difference, but if everyone did it... Are you willing to give away your small change each time you shop? Would you sign up to a "campaign for small change"?

10,000+ warnings is people problem

When you read "there is always a problem and it's always a people problem" it's easy to get the wrong idea. Technical problems and people problems are almost always deeply intertwined.

For example, suppose you're part of a team that has let warnings accumulate one on top the other over many months until they now number 10,000+. Aside from the obvious technical problem of having 10,000+ warnings the team has a much deeper people problem.

Ask yourself the question - why does the team continue to live with the pain of 10,000+ warnings? Their answer is "that's how its always been". Sure the number creeps ever upward, but what does that matter when they're up to 10,000+? The team have had so many warnings for so long that they no longer even think about them! That's abstraction!

And given that the team don't even see 10,000+ warnings as a problem will they be motivated to get rid of them? Unlikely. They've lived with 10,000+ warnings for so long they've become comfortable with the discomfort they cause! Of course they claim they're not in discomfort. Abstraction again!

They are caught in a vicious circle of blindness and numbness. To solve this people problem the first step is to somehow get the team to see and feel the pain 10,000+ warnings are causing. That will be difficult. Then you'll have to get individuals to change their behaviour. That will be difficult too.

Oh, and you also have a smaller problem - 10,000+ warnings.

Ha ha

An old couple go to the doctors. The doctor says they are fine for their age but he's noticed they are starting to become more forgetful and suggests they write things down so they don't forget them. Back at home the husband asks the wife if she'd like anything to eat. "A bit of ice cream would be nice" she replies. Anything with it he adds. "Some chocolate sauce. And you'd better write it down or you'll forget". The husband says he doesn't need to write it down. "And a spinkling of nuts too" adds the wife. "And you'd better write it down". Again the husband is sure he doesn't need to write it down. "Oh and a cup of tea" adds the wife again. "You'd better write it down". Still he doesn't write it down. Of goes the husband to prepare the food. Fifteen minutes later he walks into the lounge with a lovely english breakfast on a plate: fried eggs, bacon, sausage, mushrooms, tomato. The wife looks at the plate and says "where's the toast?"

Complexity, testing, coverage

Several years ago I was bitten by a bug where my C# unit tests weren't being run because I had accidentally left the public specifier off my test class definition (and therefore NUnit could not see the class). It was easy to fix - I simply added the public keyword. Wondering how many other times I had accidentally done the same thing I decided to write another NUnit test whose job was to use reflection on its own assembly looking for test classes that weren't public. I was pondering this episode again recently while doing some C training. In C (and C++) you don't have reflection. It occured to me that you might be able to use code coverage to avoid this potential problem. If the coverage could separate out the test code from the tested code you could use less than 100% coverage of the test code to help indicate one or more accidentally uncalled test functions. This highlights that test code and tested code are not the same. Test code typically has lots of detail complexity but very little dynamic complexity.

Agile Software DevelopERS

De Luca's Law says that Managing software developers is 20% technology and 80% psychology. Dale Carnegie believed it was 15/85. On my bookshelf are half a dozen Agile books. All are about Agile Development, Agile Management, etc. None are focused on Agile Developers - on how to improve your agility as an individual. Conway's Law says "An organisation is constrained to produce designs which are copies of the communication structures of the organisation." Can this law be extended to consider agility?

A design cannot be more agile than the developers who designed it.

Intuitively it seems a reasonable idea. If XP aims to improve technical practices, and Scrum to improve management practices then perhaps it's time for a movement aimed at improving personal practices?

Bill Bailey's Law

Here's a law I invented which I use sometimes when training or consulting.

Never believe any assertion containing the words never or always.

It can be applied to itself of course. And to many other laws. If you believe it then you don't and if you don't then you do. It essentially says you should think for yourself. Bill Bailey is a UK comedian. On UK tv one time he recounted being shown into a big cat enclosure in a zoo in Chile. The keeper, whose English was very broken, said "Never face the cats". Bill said ok and they went in. After they had been inside for a while the keeper turned to Bill and said, "No no, sorry, always face the cats". Bill joked that the keeper added "we lose a lot that way".

The Average Time To Green Game

Something special happened last week. I was in Bangalore doing some training at the request of my good friend Olve Maudal of Tandberg (now part of Cisco). A day on Test Driven Development was scheduled for Monday and I fell asleep Saturday night thinking about how to really get across the idea and nature of TDD to a group of developers. I woke up at 2am Sunday morning with The Average Time To Green Game pre formed and named, ready in my head!

Game setup

1. Each computer is given a label (eg Alligators, Bears, Cheetahs, etc).
2. Minimum of two people per computer.
3. Each computer must have a TDD framework installed (better still, use CyberDojo).

Game play

1. Every 10-15 minutes ring the Average Time To Green Bell (we found a small brass bell in a local shop).
2. When you ring the bell you also start a timer and project it so everyone can see it. This timer starts at zero and increments second by second.
3. The aim at each computer is then to get to green (all tests passing).
4. When a computer has got to green two things have to be recorded for that computer: the iteration number, the time it took to get to green since the bell (simply look at the projected timer).
5. When your computer is green you have to cover your laptop (we provided sheets of green paper) and wait till all the computers have got to green.
6. The data for all computers is recorded in a spreadsheet.
7. When all computers are at green everyone briefly looks at the graph made from the spreadsheet.
8. Then you have to swap partners and computers and a new iteration starts.

Game Goal

The goal of the game, which was clearly and explicitly printed on the instruction sheets was simply to control the average time to green across the whole group. The group naturally didn't understand that at first - they focused instead on the problem. The problem was completely trivial - Olve and I picked stripping backslash newline pairs off a character buffer - as in C/C++ preprocessor logical lines. It was utterly fascinating to watch how things progressed, and we feel it worked really well (and more to the point I think the participants did too), both in the TDD sense and in the team building sense.

Game photos

1. Graph of the average time to green over several iterations.
2. Helping to solve one computer that was holding the team up.
3. Total number of tests passing split by computer.
4. Relaxing at the end.

Game retrospective

1. The group were all well above average ability so we could have perhaps run fewer iterations, or used a less trivial problem.
2. We could have used staged goals. First measure the average time to green, then lower it, then control it.
3. Once the group felt they had control of the average time to green we could have let them choose their own goals.
4. We could have encouraged participants to write down their choice of strategies and their experience of pair programming.

Here's a follow up blog-entry/

C# 2.0 - Visitor return type

In this entry I'm revisting the Visitor Pattern, this time using C# 2.0 generics rather than Java generics. One addition to the previous design is to declare two interaces, one for a void return and one for a non-void return:

public interface IVisitable
{
    void Accept(IVisitor visitor);
    R    Accept(IVisitor1<R> visitor);
}
public interface IVisitor
{
    void Visit(A visited);
    void Visit(B visited);
    void Visit(C visited);
}
public interface IVisitor1<R>
{
    R Visit<R>(A visited);
    R Visit<R>(B visited);
    R Visit<R>(C visited);
}

Each concrete element then simply implements both Accept methods:

public class A : IVisitable
{
    ...
    public void Accept(Visitor visitor)
    {
       visitor.Visit(this);
    }
    public R Accept<R>(Visitor1<R> visitor)
    {
        return visitor.Visit(this);
    }
    ...
}

I could do this in Java too of course. However, the C# version edges out the Java version in two respects. First, C# allows two types to have the same name as long as they have a different number of generic arguments.

public interface IVisitor
{
    void Visit(A visited);
    void Visit(B visited);
    void Visit(C visited);
}
public interface IVisitor<R>
{
    R Visit<R>(A visited);
    R Visit<R>(B visited);
    R Visit<R>(C visited);
}

Secondly, generic IVisitor works with all types (including value types such as bool) without the need for wrapper classes:

public class ExampleVisitor : IVisitor<bool>
{
    public bool Visit(A visited) { ... }
    public bool Visit(B visited) { ... }
    public bool Visit(C visited) { ... }
}

Statement Refactoring

I've just noticed this somewhere:

public string MakeRequest(string hostname, string message)
{
    Socket socket = null;
    IPAddress serverAddress = null;
    IPEndPoint serverEndPoint = null;  
    byte[] sendBytes = null, bytesReceived = null;
    int bytesReceivedSize = -1, readSize = 4096;
    serverAddress = Dns.Resolve(hostname).AddressList[0];
    serverEndPoint = new IPEndPoint(serverAddress, 80);
    socket = new Socket(AddressFamily.InterNetwork,
    SocketType.Stream, ProtocolType.Tcp);
    bytesReceived = new byte[readSize];  
    sendBytes = Encoding.ASCII.GetBytes(message);
    socket.Connect(serverEndPoint); 
    socket.Send(sendBytes);
    bytesReceivedSize = socket.Receive(bytesReceived, readSize, 0);
    socket.Close();
    if(-1 != bytesReceivedSize)
    {
        return Encoding.ASCII.GetString(bytesReceived, 0, bytesReceivedSize);
    }
    return "";
}

Why do programmers still write code like this in C#? Do they like verbosity? Why not write this instead:

public string MakeRequest(string hostname, string message)
{
    IPAddress serverAddress = Dns.Resolve(hostname).AddressList[0];
    IPEndPoint serverEndPoint = new IPEndPoint(serverAddress, 80);
    Socket socket = new Socket(AddressFamily.InterNetwork,
                               SocketType.Stream, ProtocolType.Tcp);
    int readSize = 4096;
    byte[] bytesReceived = new byte[readSize];  
    byte[] sendBytes = Encoding.ASCII.GetBytes(message);
    ...
}

It seems to me there are loads of these statement level refactorings that would prove really useful. Do any tools support "small" refactoring like this? Do any books talk about them?

Here's another: Instead of writing:

if (expression)
    return true;
else
    return false;

why not just write:

return expression;

How Buildings Learn

I've been rereading How Buildings Learn by Stewart Brand. It's a really great read. It's author took the time and effort to do what few authors do. He didn't do the simple thing and just write about buildings at a certain point in time. He did the difficult thing and wrote about the underlying processes that govern the evolution of buildings over time.

At the heart of this book is the idea of change - of time. That buildings change. That people change them. That the elements change them. This, fundamentally, is the reason the parallels with software leap off every page. Understanding and managing change is arguably the fundamental aspect of understanding and managing the process of developing software. Software isn't written perfectly in a sudden flash. It takes time. It takes lots of small changes. The author writes "My approach is to examine buildings as a whole - not just whole in space, but whole in time". He laments the aphorism "Form ever follows function" written in 1896 by Louis Sullivan (A Chicago highrise designer) because "it misled a century of architects into believing that they could really anticipate function". The idea is to aim for software that gets better over time. Or, more accurately, that is capable of getting better over time.

Here are some quotes:

Our basic argument is that there isn't such a thing as a building. A building properly conceived is several layers of longevity of built components.

Many buildings are demolished early if their outdated systems are too deeply embedded to replace easily.

Hummingbirds and flowers are quick, redwood trees slow, and whole redwood forests even slower. Most interaction is within the same pace level.

The dynamics of the system will be dominated by the slow components. with the rapid components simply following along. Slow constrains quick; slow controls quick.

Trust, intimacy, intense use, and time are what made these buildings work so well.

Architects offered themselves as providers of instant solutions, and only the look of a building gives instant gratification.