Hi. I'm Jon Jagger.
I help software teams improve their effectiveness.
I built cyber-dojo, the place teams practice programming.
I'm based in the UK.
I've worked in 22 countries.
If you don't like my work, I won't invoice you.
Hire me

Pages

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.

...is 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.

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:

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:

I use www.ba.com 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.

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).

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 http://www.ayeconference.com/ 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.

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).