Complexity Matters

Managing complexity is not just how you connect things together but to what extent the connection mechanisms scale. In Nature the scalability of the mechanisms seems to have hard physical limits. D'Arcy Thompson [1] wrote:

In nature, the effect of scale depends not on a thing in itself but in relation to its whole environment.

Everywhere Nature works true to scale, and everything has its proper size accordingly.

In short, it often happens that of the forces in action in a system some vary as one power and some as another, of the masses, distances or other magnitudes involved; the "dimensions" remain the same in our equations of equilibrium, but the relative values alter with the scale. This is known as the "Principle of Similitude", or dynamic similarity, and it and its consequences are of great importance.

Size matters too. Even the smallest mistake can kill an animal/program. In [2] Richard Gabriel writes:

build small abstractions only

build hierarchies slowly, keeping them shallow as long as possible

buildings with the quality are not made of large modular units

we must make sure the structure is correct down to 1/8th of an inch (quoting Christopher Alexander)

Fan-in/fan-out is important complexity metric. The difference in complexity between different levels of the system should be roughly the same. This is reminiscent of fractals and what Christopher Alexander calls "centers". Again from Patterns of Software:

without large structure, the design cannot hold together - it becomes merely a jumble of isolated design elements.

The nature of a system is such that at almost any granularity it looks the same - it is a system. ... When we put together an object-oriented thing, it is a system, not a program. The difference between a program and a system is precisely the characteristic of a system having many centers or ways of approaching it - from the vantage point of any sub-system, the rest of the system is a server - whereas in a program, you generally have a single way of viewing it, usually from the top down.'

Objects are important because they make it easier to create systems rather than programs and systems can handle complexity and change better than programs.

[1] On Growth and Form. D'Arcy Thompson. Cambridge University Press. ISBN 0-521-43776-8

[2] Patterns of Software. Richard Gabriel. Oxford University Press. ISBN 0-19-5100269-X

Benjamin Franklin's Prose Practice

I've finished reading Benjamin Franklin's Autobiography. The thoroughness of his deliberate prose practice is impressive:

About this time I met with an odd volume of the Spectator. It was the third. I had never before seen any of them. I bought it, read it over and over, and was much delighted with it. I thought the writing excellent, and wished, if possible, to imitate it. With this view I took some of the papers, and, making short hints of the sentiment in each sentence, laid them by for a few days, and then, without looking at the book, tried to complete the papers again, by expressing each hinted sentiment at length, and as fully as it had been expressed before, in any suitable words that should come to hand. Then I compared my Spectator with the original, discovered some of my faults, and corrected them. But I found I wanted a stock of words, or a readiness in recollecting and using them, which I thought I should have acquired before that time if I had gome on making verses; since the continual occasion for words of the same import, but of different length, to suit the measure, or of different sound for the rhyme, would have laid me under a constant necessity of searching for variety, and also have tended to fix that variety in my mind and make me master of it. Therefore I took some of the tales and turned them into verse; and, after a time, when I had pretty well forgotten the prose, turned them back again. I also sometimes jumbled my collection of hints into confusion, and after some weeks endeavored to reduce them into the best order, before I began to form the full sentences and complete the paper. This was to teach me method in the arrangement of my thoughts. By comparing my work afterwards with the original, I discovered many faults and amended them;

The Secrets of Consulting

is the title of an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:

There's always a problem. It's always a people problem.

People want training that makes them better adapted to their present task, rather than training that makes them more adaptable to future tasks.

Consulting is not a test for the consultant, it's a service to the client.

Things are the way they are because they got that way.

Study for understanding, not for criticism.

Don't be afraid to cultivate your unconscious.

Cucumbers get more pickled than brine gets cucumbered.

The trick to earning trust is to avoid all tricks.

Never promise anything. Always keep your promise.

When technology pisses me off (3)

This time it's a digital camera. Scroll through the photos on the camera and you can see them all. Connect to a Windows XP laptop and only some of them appear. If you're involved in making technology I plead with you to at least make it do the basics correctly. If it does the basics correctly I can forgive you when rarely used extra frills don't work. What's unforgivable is when the basics don't work.

Quite by chance, I see David Hansson of Ruby on Rails fame is twittering he's having numerous problems making calls from his iPhone. Same thing. RUBBISH.

C/C++ 2 phase unit-testing again

In my previous blog entry on the 2-phase unit-testing idea the code sketch looked like this:

/* test.h */
#define TEST(name) if (run_phase(suite, name))
...

/* wibble_tests.c */
#include "test.h"
#include "wibble.h"
...
static void wibble_tests(test_suite * suite)
{
 ...
 TEST("fprintf failure inside wibble")
 {
   int expected = 42;
   int actual = wibble(4, 2);
   /* assert expected == actual */
 }
 ...
}

A follow on idea from this to make the string literal test names globally available. Suppose the wibble function looks like this:

/* wibble.c */
#include "wibble.h"
#include <stdio.h>

int wibble(int lhs, int rhs)
{
 ...
 ret = fprintf(stdout, "%d,%d", lhs, rhs);
 if (ret < 0)
   ...
}

And you want to mock fprintf. You can move the definition of wibble() into its own .func file like so:

/* wibble.c */
#include "wibble.h"
#include <stdio.h>

#include "wibble.func"

/* wibble.func */
int wibble(int lhs, int rhs)
{
 ...
 ret = fprintf(stdout, "%d,%d", lhs, rhs);
 if (ret < 0)
   ...
}

This allows you to isolate wibble() by #including the wibble.func file. This is quite brutal but it shouldn't affect the behaviour and brutality can be appropriate when your trying to write characterisation tests because you don't have any tests yet. The last step is to make run_phase() access the suite parameter itself (rather than being passed it) so the TEST macro can be used anywhere:

/* test.h */
#define TEST(name) if (run_phase(name))
...

/* wibble_tests.c */
#include "test.h"

typedef int mock_file;
static mock_file * stdout = 0;

static int fprintf(mock_file * mf, const char * format, ...)
{
 TEST("fprintf failure inside wibble")
 {
   return -2;
 }
 ...
}

#include "wibble.func"

static void wibble_tests(void)
{
 ...
 TEST("fprintf failure inside wibble")
 {
   int expected = 42;
   int actual = wibble(4, 2);
   /* assert expected == actual */
 }
 ...
}

The Machine That Changed The World

...is the title of a book by James Womack, Daniel Jones, and Daniel Roos. It's subtitled How Lean Production Revolutionized the Global Car Wars. As usual I'm going to quote from a few pages:

In striking contrast to the mass-production plant, where stopping the line was the responsibility of the senior line manager, Ohno placed a cord above every work station and instructed workers to stop the whole assembly line immediately if a problem emerged that they couldn't fix. Then the whole team would come over to work on the problem.

Lean distribution will form the front end of a system that is driven by the needs of the customer, not by the needs of the factory.

The ultimate cause is almost always an organizational problem.

Workers at mass-production plants learn no skills.

Japanese companies do not believe they can turn around existing mass-production facilities.

In Japan...practically all hiring in companies is from the bottom only.

Anything that is new is likely to be misunderstood, typically by attempts to explain the new phenomenon in terms of traditional categories and causes.

The central problem is people - how to reward and motivate thousands of individuals from many countries and cultures so that they work in harmony.

When technology pisses me off (2)

A Buzz Lightyear DVD this time. My son Patrick has Asperger's Syndrome. He likes to watch the same film over and over again. He likes to watch the film over and over again. Not the adverts. Going to the cinema is not like watching a DVD at home. DVD's that won't let you skip the adverts when you're watching the DVD for the umpteenth time are RUBBISH

When technology pisses me off (1)

I've just come back from a great days fishing on the river Wye with my mate Brian. To get to the spot we tried to use a sat-nav. A Garmin something or other. It was Brian's. I don't have a sat-nav because on the few occasions I've used one in the past they have been universally rubbish. I'm sure when the work they're great - it's just that they've failed to work for me with sufficient regularity that they no longer get a chance. And this time it was more of the same. Brian spent about 20 minutes trying to enter GL17 9NU, the post-code of our destination. It refused to let him enter the post-code. He typed in GL1 (on a keyboard display that was not qwerty and consequently slowed you down, why?) and it jumped to a screen showing GL16 something or other. Various other options were tried. Nope. It flatly refused to play ball. I've learned that if something's not working there's no point carrying on trying to force it to work. That very rarely works. So we abandoned it and headed off in the general direction relying on good old paper map technology. Much later, quite by chance, we discovered what was going on. The previous sat-nav trip was for our first days fishing in Builth Wells, which is in Wales. Because of this it seemed to have got stuck in Wales. It was only accepting post-codes in Wales. Why doesn't it just let you enter the post-code you want to enter and then see if that post-code is in Wales or England? RUBBISH.

The fifth discipline

...is an excellent book by Peter Senge. It's subtitled The Art and Practice of the Learning Organisation. As usual I'm going to quote from a few pages:

Surprisingly few adults work to rigorously develop their own personal mastery.

More often than we realize systems cause their own crises, not external forces or individuals' mistakes.

Living systems have integrity. Their character depends on the whole.

In systems thinking it is an axiom that every influence is both a cause and an effect. Nothing is ever influenced in just one direction.

One of the highest leverage points for improving system performance, is the minimization of system delays.

Learning is eventually always about action.

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

No practice, no learning.

Don't push growth; remove the factors limiting growth.

Most organizations are dominated by linear thinking, not systems thinking. The dominance of the event mentality tells people that the name of the game is reacting to change, not generating change.

It cannot be stressed too much that team learning is a team skill.

You cannot change how someone thinks, but you can give them a tool the use of which leads them to think differently [Buckminster Fuller].

Sensing and acting locally is exactly how complex living systems work.

Hierarchy is antithetical to dialogue, and it is difficult to escape hierarchy in organisations.

Systems Thinking in the Public Sector

...is the title of a book by John Seddon. As usual I'm simply going to quote from a few pages:

Standardization constrains a system's ability to absorb variety.

...the test of a good measure: does it help us understand and improve performance.

focus on costs and costs will rise, focus on flow and costs will fall.

There are two kinds of customer demand: value demand and failure demand.

Waste is man made.

People's behaviour is a product of their system.

Systems 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 local in time. We are not good at seeing the non-linear effects of our actions; the effects over distance and especially over time. Here's something a friend emailed me:

Last week I found that the guys had not checked in a big chunk of library code. It was in the place where common tool-chains were getting invoked, so no one noticed. They changed something and I was seeing sudden breakages even with older versions of the code which was working. They didn't even bother to put it into the version control. I just couldn't believe, people can work this way. I immediately put it into the svn.

Here's what I replied...

Why do you think they hadn't put it in svn? Because at some level they associate the pain of putting it into svn as being greater than the pain of not putting it into svn plus living in a messy kitchen! And who can blame them when helpful people like yourself come along and clean up their mess! They are probably hardly even consciously aware that have the option of putting it into svn themselves. If they haven't put it into svn for N weeks then that is the behaviour that has become their norm. And things that don't change are not seen or thought about. That's abstraction! You are part of the vicious cycle! You are helping to perpetuate their behaviour. You are part of the system!

A more congruent approach would have been to sit next to them and talk them through what they needed to do to tidy up the mess. You absolutely mustn't do any part of it for them. Only if they actually do it themselves will they have a chance of not repeating the situation. They have to type the keystrokes at the keyboard. Remember, it is trivial for you to do it, but for them it will mean working through some level of associated pain. That is not their "fault". They are simply, in this case, less experienced than you. You simply sit next to them and calmly, patiently, ever so patiently, talk them through it in a non threatening, non blaming way.

Generativity

Generativity is a tricky thing. It's when you work to achieve a desired outcome indirectly. The indirection helps to hide the desired outcome from your conscious mind. This can be important, because your mind has a tendency to interfere with the desired outcome. It's an example of Le Chatelier's Principle - Systems tend to oppose their own function.

Timothy Gallwey, a tennis coach, tells of a great example of generativity. He observed that direct verbal instructions such as ‘Keep your eye on the ball’ are ineffective because players find it hard to keep the direct advice sharp in their minds and at the same time to follow the advice. Instead Gallwey told the player to say the word "bounce" when the ball bounced in front of them and then the word "hit" as they hit the ball. Players found this alternative advice much easier to retain while playing. And since you have to watch the ball carefully to know the exact moment when it bounces and when you hit it it has the side effect of helping you keep your eye on the ball!

The Hawk and the Rabbit

When I'm consulting I sometimes ask a group what the word "agile" means to them. Their response invariably centers on the idea of speed. Agility is not primarily about speed...

A few years ago I was standing on the roof of my house (the loft was being converted - it's not something I normally do). I spotted a bird of prey (a hawk I think) circling overhead. Rabbits lived in the field opposite and I wondered if I the hawk would swoop on one - something I'd never seen before. And with that the hawk began to dive! It was clearly targeting a young rabbit sitting by the far hedge... The rabbit sensed the danger, stopped eating, and started running for its life... The hawk changed direction and kept after the speeding youngster... got very close... reached out with its talons... was about to make its kill.... And at that exact moment the rabbit changed direction. I don't mean it veered off slightly to the left or slightly to the right. I mean one moment it was running as fast as it could along the hedge and the next moment, with almost no discernible pause or reduction in speed, it was running in the opposite direction back to where it had came from. It was quite something. The rabbit was certainly fast but the hawk was faster. What saved the rabbit was its nimbleness. It's agility.

Agility isn't how fast you can keep going in the same direction; agility is how easily you can change direction.

Footnote

The hawk appeared to have all the advantages during the chase. For one it had gravity on its side, and for two it only had to overcome air-resistance. The rabbit was expending a lot more energy. But the increased friction with the ground helped the rabbit make a sudden change of direction.

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.