BOYD The fighter pilot who changed the art of war

is the title of an excellent book by Robert Coram. As usual I'm going to quote from a few pages:
He was determined to excel athough he did not yet know in what area. He only knew that he had to do something better than anyone had ever done it before.
Boyd is the only known Hun driver to work in the dangerous low-speed end of the airplane's envelope. And that was how he solved the adverse yaw problem.
They might have lost three or four pounds during the strenuous high-G maneuvers. They were thirsty and longed for a cold beer. But first they had to catch a ride on the truck that served as the flight-line taxi. They headed back to ops for the debrief, the most important part of the mission.
...more usable energy always goes into a system than comes out, because there is unavailable energy called entropy.
Tactically, the ability to quickly slow down is as important as the ability to quickly speed up.
Boyd despised optimization.
The Air Force launched a Zero Defects Campaign, and the base commander at Eglin wanted every person on base to sign a pledge saying he would make no mistakes during the coming year. Most organizations at Eglin already flew a flag saying the office was 100% FOR ZERO DEFECTS. But Boyd knew, as did almost everyone who signed the pledge, that he and everyone else would make mistakes. He thought Zero Defects was a stupid idea and refused to sign. A group of lieutenants working for Christie not only followed his lead but raised a flag that proudly proclaimed there were 100% AGAINST ZERO-DEFECTS.
Study after study shows that the higher the rank a military officer ascends, the less likely he is to make change.
You gotta challenge all assumptions. If you don't, what is doctrine on day one becomes dogma forever after.
Anything new and different is feared by a bureaucracy.
He did not become fixated on technology or "one-point" numerical solutions.
Boyd worked daily to remove things.
A twenty-pound maintenance ladder does not simply add twenty pounds to the aircraft.
Again and again they practiced.
In life there is often a roll call. That's when you will have to make a decision. To be [someone] or to do [something]? Which way will you go?
The lightweight fighter had such an extraordinary thrust-to-weight ratio and could recover energy so quickly that energy dumping became a tactic of choice rather than of desperation.
Boyd liked ambiguity.
One cannot determine the character or nature of a system within itself.
He must operate inside his adversary's time-scale.
People, ideas, hardware - in that order.
"You synchronize watches," Boyd shouted, "not people."

Another Great Week At Tandberg... coming to an end. Tuesday and Wednesday I taught an Advanced C course. Thursday Olve Maudal and I did some work preparing for our Code Archeology talk at this years accu conference. I think it's going to be really great. I also had two really great pair programming sessions. I was flipping through Mary Poppendeick's Lean Software Development book and I noticed there was a page about Tandberg. She's been to Tandberg and rates it as the gold standard. I couldn't agree more. I've been fortunate enough to be asked back many times and each time I am awed by how good it is on so many levels. And then on the very next page of her book John Boyd is mentioned, which is a coincidence as I'm reading Robert Coram's book on John Boyd at the moment. I'm looking forward to the next time already.

Another C++ Unit Testing Idea

In a previous blog entry about unit-testing in C++ I wrote that instead of writing something like this...
expected = 42;
actual = expression();
assert_equals(expected, actual);
you could write something like this...
    expected = 42;
    actual = 40+1
Admittedly this was not much of an improvement, if at all. However, on a flight to Oslo a few days ago I suddenly realized a way to improve it. The idea is to fold an expected == actual assertion down to this:
expected(42) == actual(40+1);
Where expected and actual can be two function templates that return objects wrapping their arguments. These objects can have an overloaded == operator that does the assertion for me. Instead of emphasizing the assertion I emphasize the roles instead. Here's some proof of concept code:
#include <cassert>
#include <iostream>

template<typename T>
struct asserted_role
   asserted_role(const char * name, const T * ptr)
       : name(name)
       , ptr(ptr)
   const char * name;
   const T * ptr;

template<typename T>
void failed_assertion(const asserted_role<T> & lhs,
               const char * op,
               const asserted_role<T> & rhs)
   std::cout << "FAILED ASSERTION" ...   
       << " " << << "(" << *lhs.ptr << ") " 
       << op 
       << " " << << "(" << *rhs.ptr << ")" 
       << endl;      

template<typename T>
void operator==(const asserted_role<T> & lhs,
         const asserted_role<T> & rhs)
   if (*lhs.ptr == *rhs.ptr)
      failed_assertion(lhs, "==", rhs);

template<typename T>
asserted_role<T> expected(const T & t)
   return asserted_role<T>("expected", &t);

template<typename T>
asserted_role<T> actual(const T & t)
   return asserted_role<T>("actual", &t);

int main()
   expected(42) == actual(40+1);
There are a couple of things I like about this idea. The first is I no longer have to remember to get the expected and actual in the right order; if I want to I can write:
   actual(40+1) == expected(42);
The second is that the idea can be extended. For example, I can create similar function templates called lesser and greater and add a < operator:
   lesser(42) < greater(40+1);
I can create a new template function of any name I like to express the role I'm thinking of. For example, suppose I want to test that the value of one expression is equal to the value of another expression, but neither value is "expected" or "actual" they are just two values and I don't care what the values actually are, other than the two values are equal. I can create two function templates called lhs and rhs:
   lhs(2 + 2) == rhs(4);

Paloma Faith Based Development

The morning I drove into a snow-meltwater flash-food and wrote off my car - Paloma Faith was singing on the radio. The lyrics caught my ear:

Do you want the truth or something beautiful?
Just close your eyes and make believe
Do you want the truth or something beautiful?
I am happy to deceive you

The words resonate with the way some software companies are run. They close their eyes and make believe. They practice (Paloma) Faith Based Development, rather than Evidence Based Development.

British Airways - today you were RUBBISH

I use to book Heathrow-Oslo flights a lot. I just booked another one and accidentally specified a return day of March 20th instead of February 20th. I'm pretty careful about this kind of thing but this time I got caught out, partly because both days are a Saturday. I spotted it immediately and changed it straight away. For a flight costing £265.50 ba charged me an extra £200 which frankly I find outrageous. Their website says to ring 0844 493 0787 for help. I tried that - it's a waste of time. Endless recorded messages saying they're sorry lots of passengers have been separated from the luggage because of the snow. But no human being.

I'm reminded of something Jeff Bezos said recently - that there were two kinds of companies; those that work to charge you more, and those that work to charge you less. All my previous Heathrow-Oslo flights have been for one week. Suddenly their system was being asked for a much longer stay. It surely wouldn't take a lot of effort to get the system to spot that sudden difference and before accepting the booking simply say "we've noticed your booking is for a longer period than usual - are you sure it's correct". If their system had done that I would have been very impressed. I would have told my friends. But it didn't. Instead it charged me an extra £200.


My vimeo submission to Jason Gorman's Software Craftsmanship 2010 conference has sparked a little interest so I've created a cyber-dojo github project and uploaded a an initial git repository of the rails software that drives it.

Software Craftsmanship 2010

The following is my first attempt at a submission to Jason Gorman's Software Craftsmanship 2010 conference. My submission is to run a code dojo at the conference in the alternative manner demonstrated. It's a bit rough in places, in particular the sound seems to lag the picture slightly, and I didn't set up the Ruby game instructions properly but its a start, and Jason says we're allowed to polish it during February and March anyway (which I plan to do).

Adrenaline Junkies and Template Zombies

is the title of an excellent book by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson and Suzanne Robertson. As usual I'm going to quote from a few pages:
On most development projects, time is a scarcer resource than money.
Film critics believe they can be successful even if the project they are on is a failure.
Perfection is not expected; delivery is.
Whenever people get together and break rank and responsibility, the organization gets a little healthier.
Organizational lines exists for control and decision-making. They don't usually exist to accelerate work throughput.
Reality is king.
An abundance of information creates a paucity of attention.
Suppressing bad news can turn solvable problems into unsolvable problems.
The result of this misdirected civility is deep mediocrity.
Whenever you hear "I don't know," you hear a declaration of trust.

2009 AYE conference report

The 2009 AYE (Amplify Your Effectiveness) conference was started by Jerry Weinberg about 10 years ago. The conference is designed for people working in the software industry but aims to increase their effectiveness by increasing awareness at the personal and team levels.

This years conference was held at the Embassy Suites hotel in Phoenix Arizona on Nov 9th, 10th, and 11th. The weather was hot and sunny as you'd expect in a desert city. The hotel is clean and spacious and air conditioned, the rooms likewise, and the staff friendly and helpful. It has a large heated outdoor pool with an accompanying jacuzzi, a spacious veranda area and an open-tent area for eating outdoors.

I've read that Jerry started the conference to win a bet he made whilst attending another conference he was not impressed with. It's therefore not too surprising that anything remotely resembling a powerpoint presentation is banned and always has been. Instead the conference emphasizes simulation and experience. The website at contains a wiki full of material spanning many years and is well worth a look if you are interested in attending.

Each participant's name badge revealed their Myers Briggs personality type (you are asked to do an online test before you arrive). This provided an interesting topic of conversation but was only very lightly used during the scheduled sessions. Many of the sessions were role play type games, typically organized into teams.

The conference is limited to 80 participants on a first come first served basis. $300 dollars reserved a space and the total cost depended on how early you paid in full (reserve later and its dearer). Paying at the earliest opportunity meant another $900 to pay. Plenty of drink and snacks are provided together with a buffet style midday meal. On top of this the hotel room costs about $100 a night which includes an excellent breakfast. Add to this an evening meal and the flight.

The conference felt a lot like a non-technical version of the ACCU conference. It had a very relaxed atmosphere and yet at the same time was quite intense at times. I really enjoyed it and found it a very valuable experience. I met lots of great people and plan to attend in 2010.

Agile Coaching

is the title of an excellent book by Rachel Davies and Liz Sedley. As usual I'm going to quote from a few pages:
Coaches work one step at a time rather than creating a whirl-wind of change.
Patience is one of the most important qualities of a coach.
We find the hardest part of listening is resisting the temptation to jump in too early with advice or to switch the conversation to a similar story that happened to you.
People usually speak much slower than you can think, which is why it is so hard to give your full attention when someone else is talking.
You have to do more than suggest a course of action for people to follow it. You need to lead the way by explaining why it's important and then show them how to get started with it.
Your focus is process improvement, not individual performance.
Each change they adopt reduces their resistance to the next change.
Take care not to ask questions when you actually want to give guidance.
When people start caring only about their own tasks, teamwork starts to break down.
Useful information should be visible to all and not hidden away in computers. Plans kept electronically are information fridges; they give up their information only when they are opened.

Quality Software Management
Vol 2. First-Order Measurement

is the title of an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:
Software development is not primarily a manufacturing operation for we (ideally) never develop the same software twice. This uniqueness of product means that Deming's "statistical signal" - though necessary - is not sufficient for feedback control, because there often isn't enough repetition - enough stability - to generate meaningful statistics.
In software we are attempting to obtain value by achieving higher precision than human beings have ever attempted before.
The switch from cost observation to value observation is the strongest indication that an organization has made the transition from Pattern 2 (Routine) to Pattern 3 (Steering).
Under emotional pressure, people literally stop thinking.
A fact becomes a feeling as soon as you observe it.
The triad has special significance for observation, because it is the first grouping in which there is both interaction and observation of interaction.
The way I remember the difference between faults and failures is to think of earthquakes. Faults (in the ground) leads to failures (in bridges, buildings, and so forth).
One of the most sensitive measures of the cultural pattern of any organization is how quickly it finds and removes problems.
Any plan is just a plan - a series of guesses about how the future will work out.
Bureaucracy: people doing things whose purpose they don't understand.