Quality Software ManagementVol 3. Congruent Action

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-28-5). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

Management is the number one random process element.

If you cannot manage yourself you have no business managing others.

Congruent behaviours are not stereotyped behaviours - quite the contrary. Congruent behaviours are original, specific behaviours that fit the context, other, and self, as required by the Law of Requisite Variety.

Congruence is contagious.

It takes a long time and a lot of hard practice to raise your congruence batting average.

A basic law of perception is that we tend to minimise small differences (tendency toward assimilation) and to exaggerate appreciable differences (tendency toward contrast). Thus, our perceptions make the world more sharply differentiated than it is, and we're a lot more alike than we are different.

The simplest idea about curing addiction is to stop the use of X, under the belief that X causes addiction. X does not cause the addiction, the addiction dynamic causes the addiction.

To change the addiction you'll have to use something more powerful than logic.

One of the manager's primary jobs is to set the context in which interactions takes place and work is accomplished.

Management sets the context almost exclusively through the use of language.

Culture makes language, then language makes culture.

In all Steering (Pattern 3) organisations, the team is the fundamental unit of production.

I've learned that there's simply no sense trying to solve software engineering problems, or create software engineering organisations, when I'm not able to be congruent. So I work on that first, and that's what I hope you do, too.

Fit for any type of sea voyage

My beautiful wife Natalie met me here in Norway on Saturday. We visited the Viking Ship Museum. One of the displays said:

Et skip som må øses 3 ganger på 2 døgn er sjødyktig til all slags ferd.

which translates as:

A ship that has to be bailed 3 times in 2 days is fit for any type of sea voyage.

I just love that.

Butter sighted at Olve's house

This is a photo of a pack of butter belonging to my good friend Olve Maudal. Olve has exactly 157 packs of butter in his house right now. All safely housed in his new super-sized fridge. Many of his 157 packs have been flown in specially by relatives visiting from abroad. Olve would only allow one pack out of the fridge for the photo. Even then he insisted it be taken out under the watchful eyes of the two security guards he's specially hired to guard the fridge - Lars by day and the other Lars by night. Well, you can't be too careful right now. Butter is selling for crazy money on the black (or should that be yellow) market.

Yes, it's just one small example of the butter shortage here in Norway at the moment. Apparently the cause is a new fat-rich fad-diet sweeping the population combined with the seasonal tradition of making butter-rich Xmas cookies.

Shortages like this are, as Stephen Fry might put it, quite interesting. At one point there was probably a very mild shortage. Word of the mild shortage started to spread (sorry) and anyone buying butter bought a few extra packets just to be safe. The shortage got a bit worse. Word of the worsening shortage spread further and faster. People bought even more. A self-fulfilling dynamic was thus set in place. Soon the shelves were stripped of all butter.

The shortage the customers are experiencing is, no doubt, fractally mirrored by the shops selling (or rather not selling) butter. Butter wholesalers just don't have enough butter to meet the orders from shops. Shops that get any butter get less than they ordered. Any butter the shops do get is bought in a flash (but only by relatively few people because of the bulk butter buying behaviour) and they're out of stock again. You can imagine the shop keepers pulling their hair out in exasperation. If only they could get more butter they could make a small fortune. But right when there's the most demand they have none on their shelves! They increase the size of their wholesale reorder hoping to cash in.

What will happen in a few weeks time? One possible (perhaps even likely) outcome, is that the wholesalers will finally get enough butter to meet their over-inflated orders. The shop keepers pile the butter onto their shelves and wait for the Krona to roll in... Some of the butter is sold. But not very much. After all, Xmas is now over. The fat-rich fad-diet has gone the way of all fads and the glossy magazines are now preaching a low-fat diet. And lets not forget that a fair percentage of the population has, like Olve, over 100 packets of butter in their new fridges. They're certainly not going to be buying butter any time soon.

The shop keepers then face the daunting prospect of vast butter-walls sitting unsold on their shelves, fast approaching its sell-by date. Lowering the price doesn't help. It all has to be thrown away. Again the same thing will be fractally mirrored at the smaller scale. Lots of people, such as Olve, will have more butter than they can possibly use in time. They too will have to throw out loads of butter as it goes past its use-by date.

The same lurching from one extreme to another can happen when the number of people trying to make phone calls starts to approach network capacity. People can't get through. So they try again. And when they do get through the line gets dropped. So when they do get through they stay on a bit longer. It happens on roads too.

It's dangerous to run systems at full capacity. They reach a tipping point and topple into a death spiral. Busy work and inventory pile up. That causes even more busy work and even more inventory. But almost no butter is being bought or sold. There is no flow.

Everyday heroes of the quality movement

is an excellent book by Perry Gluckman and Diana Reynolds Roome, subtitled From Taylor to Deming : The Journey to Higher Productivity (isbn 0945320078). As usual I'm going to quote from a few pages:

Look for the flaws in the system not in each other.

When we reduce complexity, we start to see the organism behaving as a whole rather than a series of parts.

The effects of preventative medicine are hard to measure.

Theories are only the beginning. Why do we find it so hard to exercise, or give up smoking, even when we know all the arguments.

Quality and productivity are results, not goals.

Automating complexity is never as effective as removing it.

I'm not trying to be destructive. I just want to open the doors to some breezes that feel a little chilling to start with.

If there are problems in the company, we don't borrow money. We solve the problems.

If you automate without first getting rid of complexity, you cast the complexity in concrete.

We do almost nothing to control our workers productivity. They are already doing their best without being goaded. What we all try to control is the process itself.

You need to know your financial direction as far as it can be known, and make sure that you don't hit any big rocks. But something else is more important: to design the ship so that it can withstand the blows when they come.

C sequence points

Olve Maudal and I created a Deep C/C++ slide-deck recently. It's been downloaded over 500,000 times indicating no small appetite for learning some of the deep secrets of C and C++. So...




In this C fragment z is initialized to the value of n after n += 42 takes place.

if (n += 42)
{
    int z = n;
    ...
}

But how do you know this? For sure? The answer is perhaps not as obvious as you might think. The C standard says:

5.1.2.3 Program execution
(paragraph 2)
Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

In C parlance, n is an object, and n += 42 modifies n. So n += 42 is a side effect. The only thing governing the sequencing of side-effects are sequence points. And there are a lot less sequence points in C and C++ code that you might imagine. There is a sequence point between n += 42 and the initialization of z. But where? And why? The standard says:

6.8 Statements and blocks
(paragraph 4)
A full expression is an expression that is not part of another expression or of a declarator. ... The end of a full expression is a sequence point.

and:

6.8.4 Selection statements
Syntax
  selection-statement:
     if ( expression ) statement

If we lexically enlarge the expression n += 42 to its left or right we hit the parentheses that form part of the if statement. In other words, the expression stops being an expression and starts to become a statement. That means n += 42 in the fragment is a full expression. That's why there's a sequence point at the end of n += 42. In pseudo code it looks like this:

n += 42;
sequence-point
if n != 0 goto __false__;
int z = n;
...
__false__: 

Photo: http://www.noaanews.noaa.gov/stories2005/images/rov-hercules-titanic.jpg

The Toyota Way

is an excellent book by Jeffrey Liker (isbn 978-0-07-139231-0). As usual I'm going to quote from a few pages:

One day a Ford Taurus mysteriously disappeared. It had been in the factory so they could try fitting it with some prototype mirrors. When it vanished, they even filed a police report. Then it turned up months later. Guess where it was. In the back of the plant, surrounded by inventory.

Extra inventory hides problems... Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes… big buffers (inventory between processes) lead to other suboptimal behaviour, like reducing your motivation to continuously improve your operation.

…was that data was one step removed from the process, merely "indicators" of what was going on.

Building a culture takes years of applying a consistent approach with consistent principles.

It seems the typical U.S. company regularly alternates between the extremes of stunningly successful and borderline bankrupt.

Flow where you can, pull where you must.

When I interviewed [Fujio] Cho for this book, I asked him about differences in cultures between what he experienced starting up the Georgetown, Kentucky plant and managing Toyota plants in Japan. He did not hesitate to note that his number-one problem was getting group leaders and team members to stop the assembly line.

Every repair situation is unique.

The more inventory a company has,… the less likely they will have what they need [Taiichi Ohno]

I posit here that Toyota has evolved the most effective form of industrial organisation ever devised. At the heart of that organisation is a focus on its own survival. [John Shook]

You cannot measure an engineer's value-added productivity by looking at what he or she is doing. You have to follow the progress of an actual product the engineer is working on as it is being transformed into a final product (or service).

Everyone should tackle some great project at least once in their life. [Sakichi Toyoda]

Sense and respond

is an excellent book by Susan Barlow, Stephen Parry, and Mike Faulkner (isbn 1-4039-4573-X). As usual I'm going to quote from a few pages:

Continuous improvement… is not enough… what is needed also is continuous value creation.

…they continue to create products 'just in case' rather than 'just in time'.

The intelligent business therefore embraces voluntary evolution, designing its own fitness to survive and thrive.

...measure the value creation to value restoration ratio.

Most fast-food burger chains follow, to a large extent, the batch-and-queue principle… Contrast this kind of flow with the one-piece flow achieved by another fast-food company that makes sandwiches and 'subs'… What has been standardised therefore, is not the product but the production method...

Very often the traditional organisation passes work from one department to another in a batch-and-queue system, and with this approach it is not atypical to discover that a task that could be done in ten minutes may actually take ten days to complete. The reason for this is simple: the process is designed that way.

Working together in a cross-functional way actually joins up the company, as well as reinforcing and strengthening the value chain.

Two options exist for businesses: to make offers to customers or to respond to customers' needs.

Is the customer purchasing an electric drill or holes in the wall?

Adaptiveness… cannot just be added on to an organisation's existing capabilities: the organisation itself must become adaptive.

Working together in a cross-functional way actually joins up the company, as well as reinforcing and strengthening the value chain. The result is a critical mass of value creation around flow instead of around functions.

Agilis Deliberate Practice

Here's the slide-deck I presented at the Agilis conference in Iceland. It contains numerous examples of the kind of improvements a group of developers typically work through in just a few facilitated CyberDojo iterations.

Intention revealing #include ?

In a previous post I described how C and C++ have a third #include mechanism. It occurs to me that this idea has possibilities beyond simply using LOCAL(header) as a synonym for "header" and SYSTEM(header) as a synonym for <header> and then using the resulting seam to gain some leverage for testing. You could also add intention revealing names. For example, something like this:

#include "dice_thrower.hpp"
#include <vector>

class stub_dice_thrower : public dice_thrower
{
...
private:
    std::vector<int> stubbed;
};

could be written like this:

#include REALIZES(dice_thrower.hpp)
#include COMPOSES(vector)

class stub_dice_thrower : public dice_thrower
{
...
private:
    std::vector<int> stubbed;
};

Caveat emptor: I don't have any actual examples of this in real code. It's just an idea. It feels a bit like a solution looking for a problem. But I thought I would mention the idea here to see if anyone thinks it has any legs...

Responsibility

I had the pleasure of attending the Agilis conference in Iceland recently.

Christopher Avery gave an excellent keynote and spoke about the difference between accountability and responsibility; you are accountable to someone else but responsibility is personal.

He presented his six step ladder of responsibility:

• Responsibility
• Obligation
• Shame
• Justify
• Lay Blame
• Denial

For example, I'm typing this in TextEdit on my Macbook whilst on a train to XP Day. The font is small and my eyesight is fading. For a moment I struggled to discern the tif in the word Justify. I could almost hear a tiny voice inside my head starting to blame. But then I jumped to Responsibility because I realised the fault was not with TextEdit but with me. I simply enlarged the font size.

Christopher handed out a sheet expanding a little on the six step ladder above.

• Responsibility is owning your ability and power to create, choose, and attract. It's about your ability to make a response - to respond.
• Obligation is doing what you have to do instead of what you want to. As always, if you listen carefully, you can hear this distinction in patterns of speech "… but I have to …".
• Justify where we attempt to rationalise the blame, to use excuses for things being the way they are; we make things just in our mind.
• Shame is laying blame on oneself (often felt as guilt).
• Lay Blame (which is not a French verb ;-) is holding others at fault for causing something.

My son Patrick has Asperger's Syndrome and he has a strong tendency to blame. For example, if he bumps his elbow on the door he gets angry and blames the door. He finds it very difficult to move past this blame, to get inside a positive feedback loop which helps him become less clumsy. So I think laying blame is more than holding other people at fault, it can take the form of blaming anything - anything except oneself.

There is no best practice

I had the pleasure of speaking at the Agilis conference in Iceland recently. While preparing my slides on Deliberate Practice I was naturally thinking about the word practice. As far as I can tell, "Best practice" is the most common phrase with the word practice in it. I searched for "Best practice" on goggle and got over 270 million hits. I searched for "Better practices" on google and got a paltry 20 million hits.

Best practice…

• focuses on achieving someone else's perfect future state
• assumes there is only one best practice
• implies improvement beyond the best practice is impossible
• emphasises the noun practice
• fits with the waterfall-defined-fixed mindset
• doesn't start from where you are now

Better practises…

• focuses on improving your own imperfect present state
• assumes there are many possible better practices
• implies improvement beyond the best practice is always possible
• emphasises the verb - to practice
• fits with the agile-empirical-growth mindset
• starts from where you are now

Float fishing rivers

is an excellent (out of print) book by Ken Giles and Dave Harrell (isbn 0-947674-23-3). As usual I'm going to quote from a few pages:

I always tend to feed the line off the [closed face] spool by hand.

It is also important, regardless of which brand of line you use, to use them in conjunction with a silicon spray. … it does make a big difference. I always spray it on my spool at the start and even if the wind gets up later on, I find I can still sink the line when I have to and then leave it on the surface again if the wind drops.

If you are fishing a very slow moving river such as the Nene or the Welland, where there is a strong wind, then you need the float to be loaded, because when you cast, it goes into the water like an arrow, completely burying itself and helps you to sink your line without it being pulled away from the far shelf.

Holding back is generally only used after the first frost of winter.

The most important point that must be covered on stick float fishing is the need to keep the line behind the float at all times. This is a must. It just does not work if the line is allowed to go in front of the float.

As a line gets older, it has a greater tendency to sink, so by always having fresh line on your reels this problem is easily overcome.

When I hold back, I do not hold back really hard.

Regardless of the method, be it stick float or wagglier, you must keep changing your depth around between being a couple of feet over depth to a couple of feet below the surface. Also, it is important to keep altering your shooting to find and keep in touch with the fish.

You do not select the float you want, you select the amount of weight you want to reach where you intend to fish and then pick a float to suit that.

I also feel that it pays to feed two lines like this anyway, to allow you to rest one against the other.

When waggler fishing I am ringing the changes far more often than I need to with the stick float.

The worst thing you can do… is to feed out of habit, as opposed to in response to the fish.

I think that work rate is the key to it all.

10,000 warnings

Suppose you are working on a codebase that has 10,000 warnings. Perhaps you have discussed how you can get rid of the warnings. Perhaps you have discussed it more than once. But you still have 10,000 warnings. What can you do? There is no magic bullet. You are not going to be able to buy a magic tool, or wave a magic wand, and with almost no effort, get rid of them all. If there was you would already have waved the wand.

Even if there was such a silver bullet it would create a shallow improvement, rather than a deep one. It would create no dynamic whatsoever to encourage the developers to learn how not to introduce warnings in the first place. It would do the opposite.

Naturally new warnings keep appearing. Tomorrow there will be 10,001 warnings. But the 1 new warning gets lost in the sea of 10,000 others. It's not even noticed. The number of warnings is trending relentlessly upwards.

The only way you can get rid of 10,000 warnings is the same way you got them in the first place. A little bit at a time. With effort. Effort that shows you care.

The first thing to do is put a finger in the hole. Cap the number of warnings. Make new warnings count as errors from now on. Don't just say "new warnings count as errors from now on". You said that last time and it didn't work. Alter the way you build your software so that new warnings cause a build failure. If module X has 3,663 warnings then 3,663 is the stake in the ground. If it gets more than 3,663 make that a build failure.

This creates pressure to remove warnings on the code actually being worked on. In a culture where warnings are ignored to the extent that they've grown to be 10,000 strong, developers are not likely to see the merits of removing warnings from old code that seems to work and no one has touched for a long time.

Once the number of warnings has stabilized, or even started to trend slightly downwards, you can work on reducing the number of warnings. If the maximum number of warnings in the build is currently 10,000 then set a target. Agree that in a weeks time the number will have dropped to 9,900. Or agree to look at the classes of warnings and target the worst one.

You don't have to get to zero. Getting to zero would mean removing warnings from old code that hasn't been touched for ages. That's not as important as changing the dynamics of the how people act so that the number of warnings is going down rather than going up.

Once you get to a level your happy with, don't turn the build-checks off. Don't take your finger out of the hole. If you do that warnings can easily start to rise again. Leave them in place.

Once you get to a level your happy with, look at ways you can improve further. Buy new tools that detect new warnings. And start again. Focus on improvement not perfection.

#include - there is a third way

Isolating legacy code from external dependencies can be awkward. Code naturally resists being isolated if it isn't designed to be isolatable. In C and C++ the transitive nature of #includes is the most obvious and direct reflection of the high-coupling such code exhibits. There is a technique that you can use to isolate a source file by cutting all it's #includes. It relies on a little known third way of writing a #include. From the C standard:

6.10.2 Source file inclusion
...
A preprocessing directive of the form:

  #include pp-tokens 

(that does not match one of the two previous forms) is permitted. The preprocessing tokens after include in the directive are processed just as in normal text. ... The directive resulting after all replacements shall match one of the two previous forms.

An example. Suppose you have a legacy source file that you want to write some unit tests for. For example:

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

int legacy(void)
{
    ...
    info = external_dependency(stdout);
    ...
}

First create a file called nothing.h as follows:

/* nothing! */

nothing.h is a file containing nothing and is an example of the Null Object Pattern). Then refactor legacy.c to this:

/* legacy.c */
#if defined(UNIT_TEST)
#  define LOCAL(header) "nothing.h"
#  define SYSTEM(header) "nothing.h"
#else
#  define LOCAL(header) #header
#  define SYSTEM(header) <header>
#endif

#include LOCAL(wibble.h)  /* <--- */
#include SYSTEM(stdio.h)  /* <--- */

int legacy(void)
{
    ...
    info = external_dependency(stdout);
    ...
}

Now structure your unit-tests for legacy.c as follows:
First you write the fake implementations of the external dependencies. Note that the type of stdout is not FILE*.

/* legacy.test.c: Part 1 */

int stdout;

int external_dependency(int stream)
{   
    ...
    return 42;
}

Then #include the source file. Note carefully that we're #including legacy.c here and not legacy.h

/* legacy.test.c: Part 2 */
#include "legacy.c" 

Then write your tests:

/* legacy.test.c: Part 3 */

#include <assert.h>

void first_unit_test_for_legacy(void)
{
    ...
    assert(legacy() == expected);
    ...
}

int main(void)
{
    first_unit_test_for_legacy();
    return 0;
}

Then compile legacy.test.c with the -D UNIT_TEST option.

This is pretty brutal, but it might just allow you to create an initial seam which you can then gradually prise open. If nothing else it provides a way to create characterisation tests to familiarize yourself with legacy code.

The -include compiler option might also prove useful.

-include file
    Process file as if #include "file" appeared as the first line of the primary source file.

Using this you can create the following file:

/* include_seam.h */
#ifndef INCLUDE_SEAM
#define INCLUDE_SEAM

#if defined(UNIT_TEST)
#  define LOCAL(header) "nothing.h"
#  define SYSTEM(header) "nothing.h"
#else
#  define LOCAL(header) #header
#  define SYSTEM(header) <header>
#endif

#endif

and then compile with the -include include_seam.h option.

Fred Foster's Swing Tipping

is an excellent (out of print) book by Fred Foster (isbn 0-304-29467-5). As usual I'm going to quote from a few pages:

Imagine you are just lifting the hook gently but firmly into the fish and you've got the idea.

As soon as the bomb has settled, I tighten up to it in the normal way and set the swing tip. That's the starting position. I leave the bait there for one minute and then twitch it forward for the first time. ... I give my bait a twitch once every 30 seconds after leaving it for the opening minute.

On hard fished waters, my aim is always to fish as far out from the bank as the prevailing conditions will permit.

As I see it, the hook is always far more visible to the fish when the bait is suspended (as it mostly is with the float) than it is when the bait is on the bottom as it always is when swing tipping.

I prefer a 3 foot hooklength.

In my experience, accurate casting is more vital when swing tipping than in any other form of fishing I have known.

There isn't such a thing as a magic bait and if those who suspected it spent their time practising their tipping instead of wasting it on wild goose chases like this they'd start to give the likes of me a closer run for our money.

Accurate synchronization in the placing of the hookbait in relationship to the feed is one of the most important requirements if you are to achieve any real success.

It's a case of practice makes perfect until you can drop that bomb on the same spot every time.

Quality Software ManagementVol 2. First-Order Measurement

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-24-2). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

The update cycle on the project control panel should be scaled to something less than the longest period of time the project can afford to be late.

Large projects always fail when their communication systems fail.

The slowdown of fault removal is a major reason why project times are underestimated.

In the end, it's not the observation that counts, it's the response to the observation. That's why Zen masters teach patience in response.

Culture makes its presence known through patterns that persist over time.

What power corrupts most thoroughly is the ability to make meaning of observations.

Incongruent behaviour is the number one enemy of quality, because it disguises what people truly value.

If you can see it you can review it.

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

In my consulting, I frequently talk to managers who seem obsessed with cutting the cost of software or reducing development time, but I seldom find a manager obsessed with improving value.

No other observational skill may be more important to software engineering than precision listening.

Ian Heaps on Fishing

is an excellent (out of print) book by Ian Heaps (isbn 0-907675-02-6). As usual I'm going to quote from a few pages:

The best way to improve is to practice.

You must feed according to how many fish there are and how they are feeding.

There was a method though, and that was slowing the bait down… the caster needing fishing in a very different way to the maggot.

You must keep it as simple as possible: fish as efficiently as you can.

You must learn to feed on a regular basis so that the fish are charged up, and they get to know exactly when the next amount of food, is going to arrive.

Especially on a river which is flowing, the most important thing is to get a feeding pattern going. Then, there are a thousand and one shooting patterns which will catch them.

If you see the float lifting up a bit when it should be bullying its way through the swim, it is not big enough to do the job.

For me, far too many people are obsessed nowadays with fishing light. All too often they do not experiment and put on enough lead.

Generally speaking, I have found that the more lead you can get on the line and still present the bait properly the more, and the bigger, fish you will catch.

Practice makes perfect, and there is no substitute for experimenting yourself.

If you put on a number of smaller shot and bunch them together, you can soon space them out if the feeding pattern changes.

John [Dean] did the same thing as everyone else - only he did everything just a little bit better.

The lady tasting tea

is an excellent book by David Salsburg (isbn 0-8050-7143-2). As usual I'm going to quote from a few pages:

It was a summer afternoon in Cambridge, England, in the late 1920s. A group of university dons, their wives, and some guests were sitting around an outdoor table for afternoon tea. One of the women was insisting that tea tasted different depending upon whether the tea was poured into the milk or whether the milk was poured into the tea.

What I discovered working at Pfizer was that very little scientific research can be done alone. It usually requires a combination of minds. This is because it is so easy to make mistakes.

Galton discovered a phenomenon he called "regression to the mean."

The numbers that identify the distribution are not the same type of "numbers" as the measurements. These numbers can never be observed but can be inferred from the way in which the measurements scatter. These numbers were later to be called parameters - from the Greek for "almost measurements."

Bliss invented a procedure he called "probate analysis." … The most important parameter his model generated is called the "50 percent lethal dose," usually referred to as the "LD-50." … The further you get from the 50 percent point, the more massive the experiment that is needed to get a good estimate.

If you are willing to settle for knowing the two parameters of a normal distribution within two significant figures, you need collect only about 50 measurements.

It is better to do mathematics on a chalkboard than on a piece of paper because chalk is easier to erase, and mathematical research is always filled with mistakes. Very few mathematicians work alone. If you are a mathematician, you need to talk about what you are doing. You need to expose your new ideas to the criticism of others.

In the deterministic approach, there is a fixed number, the gravitational constant, that describes how things fall to the Earth. In the statistical approach, our measurements of the gravitational constant will always differ from one another, and the scatter of their distribution is what we wish to establish in order to "understand" falling bodies.

No test can be powerful against all possible alternatives.

In the near disaster of American nuclear power plant at Three Mile Island power plant in Pennsylvania in the 1980s, the operators of the reactor had a large board of dials and indicators to follow the progress of the reactor. Among these were warning lights, some of which had been faulty and presented false alarms in the past. The prior beliefs of the operators were such that any new pattern of warning lights would be viewed as a false alarm. Even as the pattern of warning lights and associated dials produced a consistent picture of low water in the reactor, they continued to dismiss the evidence.

Kolmogorov called a sequence of numbers collected over time with successive values related to previous ones a "stochastic process."

Attitude, passion

Attitude is a shop somewhere in an airport terminal in USA. I forget where exactly. Possibly Chicago. Passion is a restaurant in Ghent in Belgium.

The Princess Bride

is an excellent book by William Goldman (isbn 0-7475-4518-9). As usual I'm going to quote from a few pages:

It's still my favourite book in all the world. And more than ever, I wish I had written it.

This is my favourite book in all the world, though I have never read it.

Miracles. Giants. True love.

Eyes like the sea before a storm.

We are but poor circus performers.

Absolutely, totally, and, in all other ways, inconceivable

Then one morning, Inigo was gone. In his place were three words: "I must learn" on a note pinned to his pillow.

I am not left-handed.

What you do not smell is called iocane powder.

Don't you rush me, sonny, you rush a miracle man, you get rotten miracles.

I AM THE DREAD PIRATE ROBERTS AND THERE WILL BE NO SURVIVORS.

Authentic happiness

is an excellent book by Martin Seligman (isbn 1-85788-329-2). As usual I'm going to quote from a few pages:

Daddy, do you remember before my fifth birthday? From when I was three until when I was five, I was a whiner. I whined every day. On my fifth birthday, I decided I wasn't going to whine any more. That was the hardest thing I've ever done. And if I can stop whining, you can stop being such a grouch.

All emotions about the past are completely driven by thinking and interpretation.

There are, however, no known ways to enhance forgetting and suppressing of memory directly. Indeed explicit attempts to suppress thoughts will backfire and increase the likelihood of imagining the forbidden object.

If you think about bad things in terms of "always" and "never" and abiding traits, you have a permanent, pessimistic style.

Learned optimism… is about accuracy.

Almost nothing that happens to you has just one cause.

Mindful attention to the present occurs much more readily in a slow state of mind.

Total immersion, in fact, blocks consciousness, and emotions are completely absent.

The mood state Americans are in, on average, when watching television is mildly depressed.

The overarching principle of good listening is validation.

By encouraging cheap success, it produced a generation of very expensive failures.

Every drug that breaks up depression also blocks dreaming.

Agile A-Z Keynote

I attended the excellent Agile .NET 2011 conference in Ghent, Belgium this week. Jason Gorman pulled out at the last minute and Erik asked me if I'd step in and do the keynote. I said yes of course and prepared this on the train+plane there.

An Agile A to Z

View more presentations from JonJagger.

Waiting work wall

One of the things I do a lot when visiting software groups is simply sit with individuals as they work. Sometimes the person I'm sitting next to is a really superb developer. They finish their work fast and to a high standard and hand the work on to the next person downstream. This next person may also be really skilled but their work might just inherently take longer. If the amount of work passed on exceeds the capacity of the next person then a growing batch of work-waiting-to-be-started-by-the-next-person will naturally form and grow.

This batch of work-waiting-to-be-started-by-the-next-person is waste. That's well known and well written about. What's not so obvious and not so well written about is how it encourages silos to form. It literally forms a barrier between the increasingly separated silos that form on either side of it.

Think of each waiting-work-item as a brick in a wall. But not a long, low, queue-shaped wall that's easy to see over. Rather, a short, high wall. One that you can't see over. One that hinders communication.

The amount of waiting-work between two silos is inversely proportional to the lack of communication between the two silos. The more waiting-work, the less the communication. The less communication the more waiting-work. Round and round it goes.

So, if you have some really superb developers then beware. They might be creating a downstream wall of waiting-work around which silos are forming.

Zen in the martial arts

is an excellent book by Joe Hyams (isbn 0-87477-101-3). As usual I'm going to quote from a few pages:

At least empty your cup and try.

Those who are patient in the trivial things in life and control themselves will one day have the same mastery in great and important things.

The martial artist develops through practice until it becomes mechanical and then spontaneous.

When you lose your temper, you lose yourself - on the mat as well as in life.

The proper system is to think twice more. Patience is part of it. To avoid being intimidated - think more and react less.

Try softer. When one eye is fixed upon your destination, there is only one eye left with which to find the way.

To know and to act are one and the same.

Relaxation and concentration go hand in hand. But too much concentration defeats itself.

Most of the time we generate our own fears, and this is especially true when we confront an unfamiliar situation that shatters confidence.

Years ago I thought too much about what I had to do, laboured over it, put off difficult chores, waited for the mood to be right or the creative juices to flow. Now I just do it without conscious effort. It flows because the work and I are one, and not in conflict with each other.

The only reason men fight is because they are insecure; one man needs to prove that he is better or stronger than another. The man who is secure within himself has no need to prove anything with force, so he can walk away from a fight with dignity and pride.

C will live forever

My good friend Olve Maudal said something the other day that caught my ear. He said C will never be replaced. I think he's right. Languages like Java and Ruby are great languages when you don't need to get near to the metal. But if you do need to get near to the metal, then C has already filled that niche so well that it's hard to see it ever being replaced. You might say that a language like C, but without C's penchant for undefined behaviour, could somehow replace C. I don't think so. The point is that the sweet spot for a language designed to be used close to the metal is a language that deliberately does not get rid of its undefined behaviour. Because that is part of it being in the sweet spot. And besides, C has been around long enough that if a language was going to replace C wouldn't it already have happened?

Situated learning - Legitimate peripheral participation

is an excellent book by Jean Lave and Etienne Wenger (isbn 0-521-42374-0). As usual I'm going to quote from a few pages:

The world carries its own structure so that specificity always implies generality (and in this sense generality is not to be assimilated to abstractness).

Reversing production steps has the effect of focusing the apprentice's attention first on the broad outlines…

The fact that the work was done in an interaction between members opened it up to other members of the team.

There is anecdotal evidence that where the circulation of knowledge among peers and near-peers is possible, it spreads exceedingly rapidly and effectively.

A learning curriculum is thus characteristic of a community.

Understanding and experience are in constant interaction.

Mirroring the intricate relationship between using and understanding artefacts there is an interesting duality inherent in the concept of transparency. It combines the two characteristics of invisibility and visibility… It might be useful to give a sense of this interplay by analogy to a window. A window's invisibility is what makes it a window, that is, an object through which the outside world becomes visible. The very fact, however, that so many things can be seen through it makes the window itself highly visible, that is, very salient in a room, when compared to, say, a solid wall. Invisibility of mediating technologies is necessary for allowing focus on, and thus supporting visibility of, the subject matter.

World class match fishing

is an excellent book by Kevin Ashurst (isbn 0-304-29729-1). As usual I'm going to quote from a few pages:

I always try to visualise what is happening under the water, and the only concrete clues I can count on are the bites, or the lack of them.

When loose-feeding for roach and dace, it always pays to shuffle the tackle when bites cease. Moving a shot an inch or two, or altering the depth slightly, works so frequently that one has to assume that the fish, as well as becoming wary because of their diminishing numbers, also get shy of baits coming to them in precisely the same way all the time.

Good loose-feeing is one of the key factors affecting success in match angling, and the difficulty of getting it right is one of the reasons why I set so much store by practising for big matches.

The starting point is the knowledge that you cannot scare fish away if they are not there to begin with.

I always think fish behave a bit like birds. If you scatter breadcrumbs on a lawn the birds begin eating it from the edges, rarely alighting in the middle, and I reckon fish behave the same way.

The trick to drop fishing is to read the signs, and the most important one is getting a caster shelled or a maggot sucked without seeing a bite.

A stick float is quite heavy in relation to its size, and at any sort of range we can cop for a splashy sort of strike.

The fish in shallow water tend to be shy. They usually come into the baited area, pick up a bait and bolt.

The original choice of float is obviously dictated by the distance to be cast and the conditions on the day, and the aim should be to achieve whatever distance is required easily. It is better to overcast and pull back than to fall short and have to cast again.

It goes without saying that the kinds of bites we can expect depends entirely on the way the fish are behaving on the day, and how we are shotted in response to that behaviour.

To be perfectly honest the appearance of my floats has never interested me. I never even thought about them in the artistic sense until Colin brought it up, but I suppose the answer lies under the general heading of ignoring everything which is not essential. I devote a lot of time, thought and energy to my fishing, but only to those departments which require time, thought and energy.

More CyberDojos

I ran a CyberDojo at the excellent Tampere goes Agile conference recently (left photo). It got a 100% green card vote.

A few days later I ran another CyberDojo for the devs at Solita Oy, also in Tampere. A nicer bunch of people you couldn't ask to meet.

And a few days after that I ran yet another CyberDojo at the Ericsson Agile conference in Helsinki (right photo). @jussikm @htaubert and @karmolis tweeted that it was the most fun they'd had at work in 2011.

ALE CyberDojo Ice Breaker

I ran a mass-participation CyberDojo "keynote" at the excellent ALE conference in Berlin recently. 10 laptops were setup with a Yahtzee refactoring exercise in Java. Over 200 people participated. The aim was not to write code - it was to mix people up and get lots of energy into the conference right at the start. I think it worked very well.

We are what we say

Steven Fry wrote a piece for Radio Times about his new BBC2 series Fry's Planet Word. The following snippets caught my attention.

Most social groupings of young people have their own private language, catchphrases and nicknames for people and processes.

All that bright individual verbal clothing is put away for the workplace and dull, pretentious verbal suits are worn in their place. Never was the word "suit" less... well... suitable. The memos, meetings and conferences of the workplace are couched in agglomorations of phrases as soulless, bloodless, styleless and depressing as they grey carpets, strip lighting and hessian partitions that constitute their physical environment. Sick-building syndrome is now well understood, sick language syndrome perhaps less so.

We may be what we eat, but we most certainly are what we say.

They reminded me again of the importance of precision listening.

Brain rules

is an excellent book by John Medina (isbn 978-0-9797777-4-5). As usual I'm going to quote from a few pages:

Students learn better from words and pictures than from words alone.
Students learn better when corresponding words and pictures are presented simultaneously rather than successively.
Students learn better when corresponding words and pictures are presented near to each other rather than far apart on the page or screen.
Students learn better when extraneous material is excluded rather than included.
Students learn better from animation and narration than from animation and on-screen text.

When the brain is fully working, it uses more energy per unit of tissue than a fully exercising quadricep.

Charles Darwin noted… the brains in wild animals were 15 to 30 percent larger than those of their tame, domestic counterparts.

Studies show that a person who is interrupted takes 50 percent longer to accomplish a task. Not only that, he or she makes up to 50 percent more errors.

Spaced learning is greatly superior to massed learning.

A great deal of research shows that thinking or talking about an event immediately after it has occurred enhances memory for that event.

Students are expected to known certain things by certain grades. Curiously absent from this model is how durable that learning remains after the student completes the grade.

When people become sleep-deprived, their ability to utilise the food they are consuming falls by about one-third.

Sleep loss cripples thinking in just about every way you can measure thinking.

Vision is by far our most dominant sense, taking up half of our brain's resources.

All I need to know about manufacturing I learned in Joe's garage

is an excellent book by William B. Miller and Vicki L. Schenk (isbn 0-9630439-3-5). As usual I'm going to quote from a few pages:

I mumbled back something equally unintelligible, the traditional response to somebody whom you aren't sure you've met and whose name you aren't certain of.

"Why is there such a conflict?" he asked. "Both departments are striving for the same thing, the good of the company. Why should they not work together?"

With all that volume flowing through his "factory," even the slightest unplanned act will ripple through everything else with a domino effect.

Fanatic: A person who redoubles his effort after having lost his direction.

If you double the amount of equipment and tools in use, you must halve the failure rate simply to stay even.

Planning can be perfect - it's all theoretical. Execution can never be perfect - it involves real people using real tools on real material.

People are expected to inspect their own work, both for function and to specification… Statistical and analytical charts are maintained on the production floor by workers, not by Quality Assurance people in a remote office.

Like most computer people would have, he had stayed close to his electronic toy rather than come to the garage to watch the production operation.

The finest carver does the least cutting.

Nobody ever tried harder under pressure.

"know'why" in addition to "know-how"

Long test method names

Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch

Writing good code is hard. For lots of reasons. One reason is the tension you try to balance when choosing identifiers. On the one hand you want your identifiers to be longer to give you enough space to make them expressive. But on the other hand you want your identifiers to be shorter so they don't balloon into monsters when combined into expressions. For example:

// too short
bool is_leap_year(int y)
{
    return y % 4 == 0 && y % 100 != 0 || y % 400 == 0;
}

// too long
bool is_leap_year(int intYearValue)
{
    return intYearValue % 4 == 0 && intYearValue % 100 != 0 || intYearValue % 400 == 0;
}

// just right, said Goldilocks
bool is_leap_year(int year)
{
    return year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
}

However, the names of your test methods are not subject to this design tension. The names of your test methods should never be part of a larger expression. So loosen up! Feel free to use long test method names. Names that reflect the specification not the implementation.

// not like this
static void test_leap_year()
{
    assert(!is_leap_year(1999));
}

// like this
static void years_not_divisible_by_4_are_not_leap_years()
{
    assert(!is_leap_year(1999));
    assert(!is_leap_year(2001));
}

THE Secret of Scrum

This is another fragment of the ALE conference lightning talk I did. It again follows on from Jerry Weinberg's quote:

No other observation skill may be more important to software engineering than precision listening.

I've tried to become a much better listener in recent years. An active listener. One of the things I've noticed is that software developers are somewhat prone to treat things as being black and white. True or false. Right or wrong. This is perhaps not so surprising for several reasons. Anyway, the point of the clip is not really to poke fun at Scrum, but to highlight the use of the word THE.

Precision Listening

At the ALE conference I did a lightning talk. On my first slide I quoted this from Jerry Weinberg's Quality Software Management Volume 1: Systems Thinking:

As consultants, we've found that the quickest and surest way to classify organizations into similar patterns is by the way people think and communicate.

On the second slide I quoted Jerry again (from the same book):

No other observation skill may be more important to software engineering than precision listening.

I was reminded of this a moment ago when someone cold-called me. I honestly don't remember what the person's name was or what they were selling. What I do remember is how the conversation started:

Hello, Jon Jagger speaking.

Hello, can I speak to Jon Jagger please.

Do you recognise this pattern? This response is pure waste. It does nothing but waste my time. After this response the one thing I know for sure is that they're not listening to me. And if they're not listening to me why should I listen to them?

flow = speed x density

I attended the ALE conference in Berlin last week. It was excellent in many many ways. Lots of participants have written blog entries and I thought I would write a short one about just one of the many things I thought was really great. It was the above graph which Karl Scotland drew in his talk, The Science of Kanban.

Karl used this graph in the context of traffic.

• The green line is traffic Speed and it rises (to the right) from zero at the bottom left.
• The red line is traffic Density and it rises (to the left) from zero at the bottom right.
• The black line is traffic Flow and equals Speed x Density.

Speaking to Karl afterwards we discussed the analogy:

• Speed = cycle time. The time it takes from the moment a piece of work enters the system to the time it gets to Done.
• Density = work in progress. The amount of work that has entered the system but hasn't yet got to Done.

Karl also pointed out two feedback loops.

• Start on the density line (red) at zero (bottom right) and increase the density (move up and to the left). For a while increasing the density increases the flow. Increasing the flow causes the density to reduce. Thus you have a stabilizing feedback loop helping to increase the flow.
• As you continue to increase the density you drop over the top of the flow-curve.
• Now as the density increases the flow decreases. And decreasing the flow causes the density to further increase. Thus you have a different destabilizing feedback loop helping to decrease the flow.

Simple and effective. Thank you Karl.

The unknown craftsman

is an excellent book by Sōetsu Yanagi (isbn 0-87011-948-6). As usual I'm going to quote from a few pages:

The good artist or craftsman has no personal pride.

Seeing relates to the concrete, knowing to the abstract.

To divine the significance of pattern is the same as to understand beauty itself.

A pattern is both true to nature and artificial.

If the material is poor the pattern will suffer.

By and large, good pattern is of communal parentage.

Beauty must have some room, must be associated with freedom.

The Theologica Germanica, written in the fourteenth century, tells is: "He would know before he believeth cometh never to true knowledge". Applied to the perception of beauty, this means that if a man employs the function of knowing before seeing, his power is impaired.

Intuition is the power of seeing at this very moment.

The thing shines, not the maker.

They are made without obsessive consciousness of beauty; thus we catch a glimpse of what is meant by "no-mindedness", whereby all things become simplified, natural, and without contrivance.

Wye Barbel

Just back from two fantastic days fishing on the River Wye with my mate Brian on the Wye and Usk Foundation Wyebank and Courtfield beats. He caught this 11 lb'er - a new personal best. We can't wait to go back.

the alchemist

is an excellent book by Paulo Coelho (isbn 978-0-7225-3293-5). As usual I'm going to quote from a few pages:

"This is the first phase of the job," he said. "I have to separate out the sulphur. To do that successfully, I must have no fear of failure. It was my fear of failure that first kept me from attempting the Master Work.

"But arms cannot be drawn unless they also go into battle. Arms are as capricious as the desert, and, if they are not used, the next time they might not function."

"I had to test your courage," the stranger said. "Courage is the quality most essential to understanding the Language of the World."

"It is not what enters men's mouths that's evil," said the alchemist. "It is what comes out of their mouths that is."

"Tomorrow, sell your camel and buy a horse. Camels are traitorous: they walk thousands of paces and they never seem to tire. Then suddenly, they kneel and die. But horses tire bit by bit. You always know how much you can ask of them, and when it is that they are about to die."

"There is only one way to learn," the alchemist answered. "It is through action."

Quality Software ManagementVol 1. Systems Thinking

is an excellent book by Jerry Weinberg (isbn 0-932633-22-6). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

A locked-on system tends to hold itself to an existing pattern, even against logical reasons to change. … Lock-ons occur in clusters.

We particularly look for the degree of congruence between what is said and what is done.

The quickest and surest way to classify organisations into similar patterns is by the way people think and communicate.

The feedback model says you can't successfully control anything for very long without information.

errors - deviations from requirements that give you information to control the system.

The treatment of error as a source of valuable information is precisely what distinguishes the feedback (error-controlled) system from its less capable predecessors and thus distinguishes Steering software cultures from Patterns 1 [Variable] and 2 [Routine].

If the technical reviews are not detecting a lot of mistakes it could mean that … the system is working very well.

Late modules tend to be fault prone modules.

The more modular you make the system, the fewer side effects you need to consider. You trade for this effect by creating modularity faults, or faults in the interaction between modules. You never get something for nothing.

Feedback must operate in small increments, at all levels - personal, product, process, and cultural.

In such a system it is meaningless to ask who is controlling whom?