mind and nature

is an excellent book by Gregory Bateson (isbn 1-57273-434-5). As usual I'm going to quote from a few pages:

If you want to understand mental processes, look at biological evolution and conversely if you want to understand biological evolution, go look at mental processes.

How is the world of logic, which eschews "circular argument," related to a world in which circular trains of causation are the rule rather than the exception?

Perception operates only on difference. All receipt of information is necessarily the receipt of news of difference, and all perception is necessarily limited by threshold. Differences that are too slight or too slowly presented are not perceivable.

The universe is characterized by an uneven distribution of causal and other types of linkage between its parts; that is, there are regions of dense linkage separated from each other by regions of less dense linkage.

We should define "stability" always by reference to the ongoing truth of some descriptive proposition.

Notoriously it is very difficult to detect gradual change because along with our high sensitivity to rapid change goes also the phenomenon of accommodation. Organisms become habituated. To distinguish between slow change and the (imperceptible) unchanging, we require information of a different sort; we need a clock.

Stability may be acheived either by rigidity or by continual repetition of some cycle of smaller changes, which cycle will return to a status quo ante after every disturbance.

Every given system embodies relations to time, that is, was characterized by time constants determined by the given whole. These constants were not determined by the equations of relationship between successive parts but were emergent properties of the system.

The shape of what it deposits is determined by the shape of the previous growth.

What characterizes those adaptations that turn out to be disasterous, and how do these differ from those that seem to be benign and, like the crab's claw, remain benign through geological ages?

Above all, in sexual reproduction, the matching up of chromosomes in fertilization enforces a process of comparison. What is new in either ovum or spermatozoon must meet with what is old in the other, and the test will favour conformity and conservation. The more grossly new will be eliminated on grounds of incompatibility.

It is very easy to fall into the notion that if the new is viable, then there must have been something wrong with the old. This view, to which organisms already suffering the pathologies of over rapid, frantic social change are inevitably prone, is, of course, mostly nonsense. What is always important is to be sure that the new is not worse than the old.

fun with feedback frequency

I'm currently reading Brain of the Firm, by Stafford Beer. On page 36 he writes:

The outcome is startling ... ... the total system is dominated, not by the forward network, but by the feedback network ... The output signals will be of greater 'purity' than we had any right to expect.

The word feedback caught my eye.
Feedback is a key principle of complex adaptive systems.
Feedback is also one of the 4 values of eXtreme Programming.
Feedback also gets several mentions in the official Scrum Guide.
So I've been playing around with Feller's walk (named after William Feller) some more...

Feller's Walk

Each Feller's walk is 1000 steps long, and at each step I flip a fair coin.
As I walk I keep a running total (starting at zero):

• adding one each time I flip a head
• subtracting one each time I flip a tail

What will the total look like as the walk progresses?
Here's the plot of the step (x-axis) against the total (y-axis) during one simulated walk.

It starts at a total of zero on the far left and wanders along, edging upwards when a head is thrown, edging downwards when a tail is thrown, and ending at about -26 indicating that overall there were 487 heads and 513 tails (487-513=-26, 487+513==1000).

Apparently, most people's intuition is that the total will hover around zero.
But it doesn't.
You cannot rely on randomness to correct the problems that randomness creates.
Without constraints variance will accumulate.
If the total happens to be +24 the coin isn't going to throw more tails for a while to try to balance things up.
Without feedback the coin has no memory.

To help see this I simulated 5000 walks and plotted the frequency of the total (y-axis) against the total (x-axis) at various points along the walks:

• after 10 steps in gold
• after 100 steps in blue
• after 1000 steps in red
• I chop the x-axis to +- 2 standard deviations

step	freq[0]	max abs(total)	std.dev
10	1204	-10	3.19
100	405	36	10.15
1000	121	140	31.71

Over all the walks, at the 10th step:

• the total was zero 1204 times (5 heads, 5 tails, 5-5=0, 5+5=10)
• the total farthest from zero was -10 (0 heads, 10 tails, 0-10=-10, 0+10=10)
• the standard deviation of the total was 3.19

Over all the walks, at the 100th step:

• the total was zero 405 times (50 heads, 50 tails, 50-50=0, 50+50=100)
• the total farthest from zero was 36 (68 heads, 32 tails, 68-32=36, 68+32=100)
• the standard deviation of the total was 10.15

Over all the walks, at the 1000th step:

• the total was zero 121 times (500 heads, 500 tails, 500-500=0, 500+500=1000)
• the total farthest from zero was 140 (570 heads, 430 tails, 570-430=140, 570+430=1000)
• the standard deviation of the total was 31.71

The further along the walk I progress, the less likely my total is to be zero.
Without constraints variance will accumulate.

Once again, with feedback

Every Nth step, instead of flipping the coin, I look at the total and:

• if the total is negative (more tails than heads) I pretend I've flipped a head, and add one to the total.
• if the total is positive (more heads than tails) I pretend I've flipped a tail, and subtract one from the total.

This feedback increases the likelihood of the total staying nearer to zero.
The smaller the value of N, the greater the effect.

Estimating feedback effectiveness

Using the simulation I can measure how good (or bad) people's estimates are of how effective feedback is. For example, I can:

• run the simulation with some feedback (N==10 say) and display the results
• gather estimates with no feedback (N==never) of, eg
  • freq[0], or
  • max abs(total), or
  • std.dev, etc
• run the simulation with no feedback and see how the actual results compare.

Or

• run the simulation with no feedback and display the results
• gather estimates of the least feedback needed to, eg
  • triple freq[0], or
  • quadruple max abs(total), or
  • half std.dev, etc
• run the simulation with various amounts of feedback and see how the actual results compare.

I've put the simulation source up on https://github.com/JonJagger/Fellers-1000-coin-tosses.
The simulation runs directly from this URL https://rawgithub.com/JonJagger/Fellers-1000-coin-tosses/master/fellers.html so you can try out various values of N if you want to before reading on...

A little feedback goes a long way

Here's 5000 simulations of a 1000 step walk with N==25.
That means, that every 25th step instead of flipping the coin, the simulation nudges the total towards zero as described above.

step	freq[0]	max abs(total)	std.dev
10	1379	-10	2.97
100	553	32	8.04
1000	387	84	15.18

The effectiveness of one feedback nudge every 25 steps amazes me.

• freq[0] tripled from 121 to 387
• max abs(total) shrank from 140 to 84
• std.dev halved from 31.71 to 15.18

Startling! Just as Stafford Beer said.
Let's hear it for feedback!

driving in India

Patterns of Software by Richard Gabriel is one of my favourite books. On page 60 he quotes Christopher Alexander (who is talking about D'Arcy Thompson)

What Thompson insisted on was that every form is basically the end result of a certain growth process. ... Thompson was saying that everything is the way it is today because it is the result of a certain history - which of course includes how it got made. At the time I read this I did not really understand it very well; whereas I now realize that he is completely right.

I'll use an example to try and illustrate this idea of, as Jerry Weinberg puts it, things being the way they are because they got that way. The example is driving in India.

The most obvious thing that strikes me when I visit Bangalore or Chennai is the almost constant horn tooting. Is tooting your horn a formally taught behaviour, or is it learned behaviour I wondered. I asked some friends who live in India. They said it is not something you're taught. It is learned behaviour. I find this fascinating. It could mean that at some point in past tooting was common, but not endemic, and that for some reason or reasons it reached a tipping point and became endemic. What are those reasons? Why did they prevail? Do those reasons apply to all Indian cities or are some quieter than others? Do the reasons shed any light on whether endemic horn tooting will or won't ever go away?

A pattern I started to sense during my most recent trip is when a slow vehicle is stuck behind an even slower vehicle (a bus for example) and toots the horn as if to say "move over". The bus slowly moves over, the first vehicle passes it, and as it goes by toots twice, the first toot to say "thank" and the second toot to say "you". I never got the sense the tooting was overtly aggressive. I think drivers are tooting mostly to tell other drivers where they are. Considering the apparent chaos everyone is remarkably relaxed! The tooting has become part of a system of communication.

Naturally, once certain behaviours get a foothold, other behaviours adapt to them, helping to reinforce the co-evolving system. Drivers of slow vehicles start to rely on other drivers tooting them if they want to pass. They politely ask people to toot them by painting "Blow horn" signs on the backs and sides of their trucks. Artistic individuals spot an opportunity and, for a small fee, offer to paint ever more elaborate "Horn please" signs. Before you know it Volkswagen pre-fits cars it sells in India with slightly louder electromechanical horns. Now some truck drivers don't move over unless they're tooted and you have to toot if you want to pass. Viola. A co-evolving, intertwingled, history. Things are the way they are because they've got that way.

Large potholes in the road are common. Roads in India don't really have left lanes and right lanes so much as worse lanes and better lanes. I certainly don't recall seeing any white-line lane-dividers. What looks like total lane switching "indiscipline" is again simply sensible adaptive driving.

If traffic moved very fast the frequent lane switching would be downright dangerous. But traffic doesn't move fast. One reason is simply that lots of the traffic is old. Driving a new car in a sea of old cars could be quite dangerous (because of the brakes). Perhaps that's partly why the roads are regularly punctuated with pretty severe speed-bumps (actual ones as well as the pot holes). The speed-bumps keep your speed low even if you have a new car. So why buy a more expensive new car? Things are the way they are because they've got that way.

The traffic is also very varied. There are trucks, buses, masses of 3 wheeler took-tooks, huge numbers of motorbikes, push-bikes, push-trikes, pedestrians, carts, cows, you name it. As the traffic constantly switches lanes spaces of varying sizes constantly appear. No matter what the size of the space, there is always some form of road user just the right size to fill it. The variety encourages lane switching and the lane switching encourages variety. It gets that way.

Another reason traffic crawls is sheer numbers. More than a billion people Iive in India. There's a lot of traffic because there's a lot of people. And a lot of those people are young people. According to Wikipedia more than 50% of the Indian population is below the age of 25! The average middle-class home in a city such as Chennai is about 20 times the average middle class salary. Combine that with 10%+ interest rates and it's easy to see that a lot of people cannot afford to live in the city where they work. With so many young people, a hot climate, and a urban army of forced commuters it's no wonder there are so many motorbikes and buses, and increasingly, small cars. Things are the way they are because they got that way.

And a system that has got a certain way will, all things being equal, want to stay that way. A system will resist change. That's virtually a definition of a system. Only by resisting does it sit still long enough to be recognisable as something at all!

smart swarm

is an excellent book by Peter Miller (isbn 978-0-00-738297-2). As usual I'm going to quote from a few pages:

As successful foragers return to the nest with seeds, they're met at the nest entrace by foragers waiting in reserve. This contact stimulates the inactive ants to go out. Foragers normally don't come back until they find something. So the faster the foragers return, the faster other ants go out, enabling the colony to tune its work force to the probability of finding food.

Instead of attempting to outsmart the desert environment, the ants, in a sense, were matching its complexity with their own.

Instead of trying to keep fine-tuning a system so it will work better and better, maybe what we really ought to be looking for is a rigourous way of saying, okay, that's good enough. [Deborah Gordon]

If a scout bee was impressed by another scout's dance, she might fly to the box being advertised and conduct her own inspection, which could last as long as an hour. But she would never blindly follow another scout's opinion by dancing for a site she hadn't visited.

J. Scott Turner considers the mound's function as a respiratory system so essential that the termites couldn't live without it. In a sense, he argues, the mound is almost a living part of the colony.

If individuals in a group are prompted to make small changes to a shared structure that inspires others to improve it even further, the structure becomes an active player in the creative process.

Unlike our systems, which are tuned for efficiency, the termites' systems have been tuned for robustness, which they demonstrate by building mounds that are constantly self-healing.

What really made the lights go on was the realization that termites don't pay attention to the environment itself but to changes in the environment.

Not only does this complicated structure represent an indirect collaboration among millions of individuals, it also embodies a kind of ongoing conversation between the colony and the world outside. The mound might look like a structure, but it's better thought of as a process.

We should think of it [the termite mound] as a dynamic system that balances forces both inside and outside its walls to create the right environment for the termites.

When you feel like you belong to something, it gives you so much more freedom and so much more energy that might otherwise be used up in anxiety, to do other things.

On January 12, 2006, several hundred thousand pilgrims had gathered in a dusty tent city at Mina, three miles east of Mecca...
By noon... about a half-million or more pilgrims filled the Jamarat plaza in front of the bridge... The pressure inside the crowd was crushing... More than an hour later, victims were piled up seven layers deep: 363 men and women were dead.
"Those in charge need to remember the root cause of the problem: too many people trying to get through too small a space. The ingress rate at the bridge was 135,000 per hour. The thoughput rate of the pillars was only 100,000 an hour. You can't put a pint into a half-pint jug." [Keith Still]

surely you're joking Mr Feynman

subtitled 'Adventures of a Curious Character', is an excellent book by Richard Feynman (isbn 978-0-099-17331-1). As usual I'm going to quote from a few pages:

Radio sets were much easier to understand in those days because everything was out in the open. After you took the set apart (it was a big problem to find the right screws), you could see this was a resistor, that's a condenser, here's a this, there's a that; they were all labelled.

I finally fixed it beause I had, and still have, persistence.

They didn't even know what they "knew". I don't know what's the matter with people: they don't learn by understanding; they learn by some other way - by rote, or something. Their knowledge is so fragile.

In this room there were wires strung all over the place! Switches were hanging from the wires, cooling water was dripping from the valves, the room was full of stuff, all out in the open. Tables piled with tools were everywhere; it was the most godawful mess you ever saw. The whole cyclotron was there in one room, and it was complete, absolute chaos!
It reminded me of my lab at home. Nothing at MIT had ever reminded me of my lab at home. I suddenly realized why Princeton was getting results. They were working with the instrument. They built the instrument; they knew where everything was, they knew how everything worked. ... It was wonderful! Because they worked with it. They didn't have to sit in another room and push buttons.

I sat with the physicsts, but after a bit I thought: It would be nice to see what the rest of the world is doing, so I'll sit for a week or two in each of the other groups.

So you must be always jiggling a little bit, testing out which way seems to be the easiest.

One day I was watching a paramecium and I saw something that was not described in the books I got in school - in college, even. These books always simplify things so the world will be more like they want it to be.

I chose to play a thing called a "frigideira" which is a toy frying pan made of metal, about six inches in diameter, with a little metal stick to beat it with. ... I practiced all the time. I'd walk along the beach holding two sticks that I had picked up, getting the twisty motion of the wrists, practicing, practicing, practicing.

One day, shortly before Carnival time, the leader of the samba school said, "OK, we're going to practice marching in the street. ...
It was rush hour in Copacabana, and we were going to march down the middle of Avenida Atlantica.
It said to myself, "Jesus! The boss didn't get a license, he didn't OK it with the police, he didn't do anything. He's decided we're just going to go out."
So we started to go out into the street, and everybody, all around, was excited. Some volunteers from a group of bystanders took a rope and formed a big square around our band, so the pedestrians wouldn't walk through the lines. People started to lean out of the windows. Everybody wanted to hear the new samba music. It was very exciting!
As soon as we started to march, I saw a policeman, way down at the other end of the road. He looked, saw what was happening, and started diverting traffic! Everything was informal. Nobody made any arrangements, but it all worked fine.

One exercise they had invented for loosening us up was to draw without looking at the paper. Don't take your eyes off the model; just look at her and makes the lines on the paper without looking at what you're doing.
One of the guys says, "I can't help it. I have to cheat. I bet everybody's cheating!"
"I'm not cheating!" I say.
"Aw, baloney!" they say.
I finish the exercise and they come over to look at what I had drawn. They found that, indeed, I was NOT cheating; at the very beginning my pencil point had busted, and there was nothing but impressions on the paper.
When I finally got my pencil to work, I tried again. I found that my drawing had a kind of strength - a funny, semi-Picasso-like strength - which appealed to me. The reason I felt good about that drawing was, I knew it was impossible to draw well that way, and therefore it didn't have to be good - and that's really what all the loosening up was all about. I had thought that "loosen up" meant "make sloppy drawings," but it really meant to relax and not worry about how the drawing is going to come out.

When it came time to evaluate the conference at the end, the others told how much they got out of it, how successful it was, and so on. When they asked me, I said, "This conference was worse than a Rorschach test: There's a meaningless inkblot, and the others ask you what you think you see, but when you tell them, they start arguing with you!

amplify & dampen

You know how sometimes the universe seems to be trying to tell you something? I had one of those experiences the other day. I was looking through my notes from the ALE2011 conference keynote Dave Snowden gave. I wrote

You know things differently in ordered-systems compared to complex-adaptive-systems. In complex adaptive systems you need discipline, you need safe-to-fail probes. You won't know the effect the probes will have. If the probes have a good effect you need to amplify them. If the probes have a bad effect you need to dampen them. Your strategies for amplifying and damping need to be planned ahead of time.

A short while later I was reading Surfing the Edge of Chaos and I came across this on page 93

The olfactory cells, which provide mammals with their sense of smell, delicately tune receptors to dampen out familiar smells and rapidly amplify receptors with new smells. This is the way the brain is alerted to new dangers or opportunities.

There it was again, amplify & dampen. I was sure this was a theme Jerry Weinberg had written about somewhere but try as I might I couldn't track it down. About an hour or so later I spotted a small red notebook on my bookshelf. I hadn't looked at it in over a year but for some reason I decided to pick it up. On the second page I looked at I'd written the following quote from Quality Software Management, vol 3, Congruent Action on page 95

A basic law of perception is that we tend to minimize 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.

Consilience

is an excellent book by Edward O. Wilson (isbn 0-349-11112-X). As usual I'm going to quote from a few pages:

The first step to wisdom, as the Chinese say, is getting things by their right names.

The cost of scientific advance is the humbling recognition that reality was not constructed to be easily grasped by the human mind.

Analysis and synthesis, he [Goethe] liked to say, should be alternated as naturally as breathing in and breathing out.

Nothing in science - nothing in life, for that matter - makes sense without theory.

Complexity is what interests scientists in the end, not simplicity.

Consilience among the biological sciences is based on a thorough understanding of scale in time and space.

Complexity theory can be defined as the search for algorithms used in nature that display common features across many levels of organisation.

In a system containing perfect internal order, such as a crystal, there can be no further change.

The brain is a machine assembled not to understand itself, but to survive.

The biologist S. J. Singer has drily expressed the matter thus: I link, therefore I am.

No example of bias-free mental development has yet been discovered.

Adapt - why success always starts with failure

is an excellent book by Tim Harford (isbn 978-0-349-12151-2). As usual I'm going to quote from a few pages:

Cross the river by feeling for stones [Deng Xiaoping]

Accepting trial and error means accepting error.

Darwin, a meticulous observer...

The art of success is to fail productively.

Complexity is a problem only in tightly coupled systems.

Make sure you know when you've failed, or you will never learn.

What Palchinsky realised was that most real-world problems are more complex than we think. They have a human dimension, a local dimension, and are likely to change as circumstances change. His method for dealing with this could be summarised as three 'Palchinsky principles'

• seek out new ideas and try new things
• when trying something new, do it on a scale where failure is survivable
• seek out feedback and learn from your mistakes as you go along

If we are to take the 'variation' part of 'variation and selection' seriously, uniformly high standards are not only impossible but undesirable.

When John Nagl served in Baghdad in 2003, he found that while his young inexperienced soldiers had the authority to kill, he - a major with a doctorate and a decade of experience - didn't have the authority to print his own propaganda pamphlets to counteract the clever PR campaign that the local insurgents were running.

Speciation - the divergence of one species into two separate populations - rarely happens without some form of physical separation.

Tight coupling means the unintended consequences proliferate so quickly that it is impossible to adapt to the failure or to try something different.

The first thing Timpson does when it buys another business is to rip out the electronic point-of-sale machines (there are always EPOS machines) and replace them with old fashioned cash registers. 'EPOS lets people at head office run the business', explains John Timpson. 'I don't want them to run the business.'

John Timpson describes one instance where he couldn't buy half-price happy hour drinks at a hotel bar, because midway through giving his order, the hour ended and the bar's computerised sales system refused to allow the half-price offer to be applied.

Timpson's company training manual describes the twenty easiest ways to defraud the company, making it clear that the company understands the risks it is running and trusts its employees anyway - and many people respond to being trusted by becoming more trustworthy.

A central point of the corporation, as a legal structure, is that it is supposed to be a safe space in which to fail. Limited liability companies were developed to encourage people to experiment, to innovate, to adapt - safe in the knowledge that if their venture collapsed, it would merely be the abstract legal entity that was ruined, not them personally.

Fail better. [Samuel Beckett]

Complexity and postmodernism - understanding complex systems

is an excellent book by Paul Cilliers (isbn 0-415-15287-9). As usual I'm going to quote from a few pages:

Complex systems operate under conditions far from equilibrium. There has to be a constant flow of energy to maintain the organisation of the system and to ensure its survival.

If resources were limitless, i.e., if growth could take place unrestricted, no meaningful structure would evolve. Boundaries, limits and constraints are preconditions for structure.

The theory of self-organised criticality tells us the following. A self-organising system will try to balance itself and a critical point between rigid order and chaos.

The classic definition of stability states that in a stable system small causes produce small effects.

The classical definition of instability, at least as used by Poincaré, is probabilistic. Unstable events are defined as events that have no observable cause.

The system of language transcends the choices of any individual user, and therefore has stability.

In the last analysis, the two facts are interdependent: the sign is exposed to alteration because it perpetuates itself.

When dealing with complex phenomena, no single method will yield the whole truth.

Coupling, overcrowding, refactoring, and death

I read The Curious Incident of the Dog in the Night Time by Mark Haddon last week. I loved it. At one point the main character, Christopher, talks about this equation:

P_g+1 = α P_g (1 - P_g)

This equation was described in the 1970s by Robert May, George Oster, and Jim Yorke. You can read about it here. The gist is it models a population over time, a population at generation_g+1 being affected by the population at generation _g. If there is no overcrowding then each member of the population at generation g, denoted P_g, produces α offspring, all of whom survive. So the population at generation g+1, denoted P_g+1 equals α P_g. The additional term, (1 - P_g ) represents feedback from overcrowding. Some interesting things happen depending on the value of α

• α < 1: The population goes extinct.
• 1 < α < 3 : The population rises to a value and then stays there.
• 3 < α < 3.57 : The population alternates between boom and bust.
• 3.57 < α : The population appears to fluctuate randomly.

In biological systems each generation has a natural lifespan. The cycle of death naturally helps to reduce overcrowding. But even with the inevitable death of each generation, the system's behaviour is delicately poised. Once α gets into the 3 - 3.57 range the growth starts to outpace the death leading to a rising population, but this leads to overcrowding which reduces the growth leading to a falling population. That reduces overcrowding, and growth rises again. The population repeats in a stable up/down cycle. But only because of the inevitable death. And only while the rate of death is sufficiently high to maintain the cycle. Once α gets beyond 3.57 the rate of death can no longer regulate the increased rate of growth and the system destabilises.

You can think about the process of writing software with this equation.

You can think of over-crowding as being analogous to over-coupling. We feel that a codebase is hard to work with, difficult to live in, if it resists our attempts to work with it. When it resists it is the coupling that is resisting.

You can also think of death as being analogous to refactoring. Just as death reduces overcrowding, so refactoring reduces coupling.

Refactoring is a hugely important dynamic in software development. Without refactoring a codebase can grow without check. Growing without check is bad. It leads to overcrowding. Overcrowding hinders growth.

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.

Pride and revulsion

Here's a bug that bit me recently. I wrote a very small quick and dirty TDD header for C in my CyberDojo. It has a macro called CHECK_EQ which you use as follows:

CHECK_EQ(int, 42, 9*6);

Part of the macro looks like this:

#define CHECK_EQ(type, expected, actual) \
    ... \
    type e = expected; \
    type a = actual; \
    ... \

Can you see the problem? Well, suppose it's used like this:

    int e = 42;
    CHECK_EQ(int, e, 9*6);

Can you see it now? The problem is that this line in the macro

    type e = expected; \

gets expanded into this line:

    type e = e; \

Ooops. I thought about choosing a very cryptic name instead of x. Perhaps incorporating __LINE__ as a suffix. But I felt there had to be a solution that would always work. After some thought I came up with this. Brace yourself...

#define CHECK_EQ(type, expected, actual) \
   ...
   if (#expected[0] != 'x') \
   { \
       type x0 = expected; \
       type x1 = actual; \
       ... \
   } \
   else \
   { \
       type y0 = expected; \
       type y1 = actual; \
       ... \
   } \
   ...

Like Tom Duff, I feel a mixture of pride and revulsion at this discovery.

Simple and Usable

is an excellent book by Giles Colborne (isbn 0-321-70354-5). As usual I'm going to quote from a few pages:

If you ask people they'll say everything is important and anything is feasible.

We tend to keep things, even when they're broken.

Your first design may seem like a solution, but it's usually just an early definition of the problem you are trying to solve. [Luke Wroblewski]

Broken gets fixed. Shoddy lasts forever. [Jack Moffett]

Feature lists sell so as long customers don't get a chance to use the product.

Mainstreamers want "good enough quickly;" experts want "perfect in as long as it takes."

People prefer to be pilots, not passengers.

"Seven plus or minus two." Many psychologists now believe short-term memory may be rather smaller - perhaps just four items.

Simple organization is about what feels good as you're using the software, not what looks logical in a plan.

Designing simple user experiences often turns out not to be about "How can I make this simple?" but rather "Where should I move the complexity?"

The secret to creating a simple user experience is to shift complexity into the right place, so that each moment feels simple.

Don't try to fill your user's mind with your design.

Things are the way they are because they got that way

If you're working on a complex codebase and you're trying to understand the complexity by looking at the codebase then you're looking in the wrong place. That's like the man in Peopleware who loses his keys in a dark street and looks for them in the adjacent street because, as he explains, "the light is better there". A codebase is the way it is because it got that way. Slowly. Over time. If you're looking at the code your looking at the effect and not at the cause. It was the developers that did it!

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

complexity

Back to quotes table-of-contents

From The Way of the Leader

Do the essential things well: Be proactive (do through action), Reduce complexity (concentrate effort on the essential things), Seek improvement (get the essential things done better).

From Everyday Heroes of the Quality Movement

Automating complexity is never as effective as removing it.

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

From Simplicity

The human brain is a very simple system that is capable of working in a complex way, rather than a complex system.

From Patterns of Software

In the modern era, we have come to favor simplicity over complexity, perfection over imperfection, symmetry over asymmetry, planning over piecemeal growth, and design awards over habitability.

From The Gift of Time

Complexity isn't an attribute; it's a relationship.

From General Principles of System Design

Complexity is a relationship between system and observer.

From The End of Certainty

A nonequilibrium system may evolve spontaneously to a state of increased complexity.

From The Systems Bible

A complex system that works is invariably found to have evolved from a simple system that worked.

From Surfing the Edge of Chaos

Recent study of evolution, both in the natural world and in computer based complex systems, has demonstrated the surprising result that the presence of parasites in a system accelerates evolution dramatically.

From Consilience

Complexity is what interests scientists in the end, not simplicity.

From Adapt - why success always starts with failure

Complexity is a problem only in tightly coupled systems.

From General Principles of Systems Design

There is a tendency for complexity in models to rise as the time between sensing and acting grows.

Photo by Kevin Wong.

Kanban 1's Game Notes

Some notes from Kanban 1's Game's I've played at a few clients sites...

First, some teams have been exploiting the splitting rule. If they have a 4-work-item with 2 bugs on it, they simply split it into a 3-work-item and a 1-work-item and put both bugs onto the 1-work-item and then abandon it, and carry on with the bug-free 3-work-item. They have to check for bugs on the abandoned buggy 1-work-item but otherwise it doesn't affect velocity. This is obvious in hindsight but I hadn't foreseen it. It is amazing how simple rules can create complexity when used in combination. To counteract this I introduce a rule that when you split a work-item into two smaller work-items both new work-items get the bugs. So, for example, if you split a 4-work-item with 2 bugs into a 3-work-item and a 1-work-item, then the 3-work-item and the 1-work-item both get 2 bugs.

Second, the way backlog work-items are created (without any 1's cost), and then moved onto the first table (also without any 1's cost) creates another unintended (from my point of view), but nonetheless very interesting possibility that a few teams have also recently exploited. What they've done is simply created masses and masses of backlog work-items and immediately pulled them all onto the first table. They effectively move the entire backlog onto the first table. The price they pay for this is having to check for bugs on every work-item. Naturally lots of bugs accumulate on the masses of work-items on the first table. However, this does not directly affect the velocity since they can simply any abandon any buggy work-item on the first table and pull in a newly created bug-free backlog work-item at any time.
So I'm currently wondering if it's better to have to pay a 1 to create a backlog work-item and possibly also pay a 1 to move a backlog work-item onto the first table. I think this will be effective for two reasons

• it simplifies the backlog rules a bit since I can now drop the rule that backlog work-items have to move onto the first table in strict creation order.
• I can allow 1's thrown from any table to create backlog work-items. This will give players on tables other than table 1 something to do during the early days of the sprint.

It seems clear to me that the game should somehow take into account the total number of bugs on all work-items on all tables. I'm pondering that.

Thirdly, rather than recording the bugs on an index-card paper clipped to the work-item, simply use the paper clips! Two paper-clips on a work item (as in the photo) means two bugs. Much simpler. Again this is obvious in hindsight.

The way of the leader

is an excellent book by Donald Krause (isbn 1-85788-137-0). As usual I'm going to quote from a few pages:

Do the essential things well: Be proactive (do through action), Reduce complexity (concentrate effort on the essential things), Seek improvement (get the essential things done better).

We can never know everything there is to know about a complex process… The knowledge that we really need to optimise a complex process is unknowable. Therefore, we can only approach optimisation a little bit at a time as our understanding grows.

Battles are won by great execution, not by great plans! Great execution can save a mediocre plan; poor execution will always ruin a great plan. [George Patton]

A person who practices self-discipline and continuously develops his level of skill seldom fails in the long term.

Listen carefully. Observe closely.

When the chips are down, the main question is not how you go about meeting your objectives, but whether you succeed in doing so.

For an effective leader, determination is more important than intellect.

Perfection is the enemy of effectiveness.

The art of leadership is an art based on simplicity, and all success is rooted in performance.

Learn by observing the behaviour of other people. If you observe good behaviour, copy it. If you observe bad behaviour, look for the same behaviour in yourself and eliminate it.

There is no surer road to disaster than to fit past solutions, however successful, to current situations.

Discipline is not intended to kill character, enthusiasm, and initiative, but to develop them.

Minimize form and maximise substance.

It is better to be alone than in bad company.

It has been just so in all my inventions. The first step is intuition - and comes with a burst, then difficulties arise... Persistence is the key [Thomas Edison]

Character is a habit. It is created through the daily choice of right and wrong. It is a moral quality which grows gradually to maturity. It does not appear suddenly.

The ACM Turing Award Lectures

is an excellent book (isbn 0-201-54885-2). As usual I'm going to quote from a few pages:

The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. [Edsger Dijkstra]

If we go back to Latin roots, we find ars, artis meaning "skill." It is perhaps significant that the corresponding Greek word was Τέχνη, the root of both "technology" and "technique". [Donald Knuth]

The assignment statement is the von Neumann bottleneck of programming languages. [John Backus]

I find a certain technique most helpful in expanding my own capabilities. After solving a challenging problem, I solve it again from scratch, retracing only the insight of the earlier solution. I repeat this until the solution is as clear and direct as I can hope for. Then I look for a general rule for attacking similar problems in the most efficient way the first time. Often, such a rule is of permanent value…
To sum up, my message to the serious programmer is: spend a part of your working day examining and refining your own methods. [Robert Floyd]

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. [C.A.R. Hoare]

UNIX is a simple coherent system that pushes a few good ideas and models to the limit. [Dennis Ritchie] I am a programmer. I write programs. [Ken Thompson]

To parody our current methods of teaching programming, we give beginners a grammar and a dictionary and tell them that they are now great writers. We seldom, if ever, given them any serious training in style… Like writing, programming is a difficult and complex art. [R.W. Hamming]

There are many ways to formulate things and it is risky to become too attached to one particular form or law and come to believe that it is the real basic principle. [Marvin Minsky]

To state a problem is to designate (1) a test for a class of symbol structures (solutions of the problem), and (2) a generator of symbol structures (potential solutions). To solve a problem is to generate a structure, using (2), that satisfies the test of (1). [Allen Newell and Herbert Simon]

The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind. Economy of notation is therefore important. [Kenneth Iverson]

General principles of systems design

is an excellent book edited by Jerry Weinberg (isbn 0-932633-07-2). As usual I'm going to quote from a few pages:

It's not the appearance that's the essence of their structure, it's their endurance. Structure is that which stands, which remains, which is unchanged, regardless of its physical properties.

No answer can be both precise and general at the same time.

Aggregation gives protection against the unknown; specialization against the known; and the use of each sacrifices some opportunity to use the other.

The concept of structure... derives from the concept of stability, and not vice versa.

Any representation of a system tends to make certain insights easier at the expense of making others harder.

Failing to yield is the only clue we have to the existence of structure... we can only understand permanence through attempts to change it.

When a system has to deal simultaneously with two threats, protection against one will increase vulnerability to the other.

This conception of the relationship between structure and behaviour is utterly contrary to the most widely held view - namely that structure determines behaviour.

The system responds more slowly in order to respond more surely.

The regulator must be active so that other parts may be passive.

Regulation is invisible - when it works.

Complexity is a relationship between system and observer.

Not only do birds regulate the insect population, but the insects return the favour for the birds.

There is a tendency for complexity in models to rise as the time between sensing and acting grows.

The gift of time

is an excellent book edited by Fiona Charles (isbn 978-0-932633-75-0). As usual I'm going to quote from a few pages:

Jerry warns us that when a system that continues to change or that is in a changing environment is subjected to a fixed set of tests, it will inevitably over-adapt to those tests, leading to a higher probability of severe or surprising failures in the field. [James Bach]

Complexity isn't an attribute; it's a relationship. [Michael Bolton]

When feedback is offered in the spirit of improving a working relationship, it's all positive. [Esther Derby]

In my experience, if you have a passion for something and want to take responsibility for making it happen you can always find an existing group, or find people around you who are willing to form a new group to get it off the ground. [Willem van den Ende]

People are relentlessly themselves. [Naomi Karten]

In experiential learning, students are fully engaged, and as a result, they determine what they learn, not the instructors or presenters. [Naomi Karten]

...problems that look technical. [James Bullock]

Both PSL and aikido teach practiced awareness of oneself, the situation, and others. [James Bullock]

Shugyo is to step onto the mat exactly when there is every excuse not to. [James Bullock]

I have become enormously skeptical of simple cause-and-effect explanations of any system behavior. [Tim Lister]

And maybe most important of all (and I've been a consultant for about thirty years now), I thank Jerry for helping me think about system dynamics and change. [Tim Lister]

In the technology industry, we spend so much time trying to control machines that we start thinking like machines. [Jonathan Kohl]