trustee from the toolroom

is an excellent book by Nevil Shute (isbn 978-0-099-52998-9). A marvelous tale of courage and friendship. As usual I'm going to quote from a few pages:

At last she asked, 'Do you think my Mummy and Daddy were very frightened when the ship got wrecked?' The adult quality of the question amazed him; children were so much older than you thought they were. 'No,' he said. 'No, I don't think that they'd ever have been frightened. They weren't that sort of people. And you won't be frightened of things either, I don't think.'

He was impressed and somehow amazed by the things he did not know. These men were working as a team, doing things together quickly and accurately, things that he could only guess at. He knew that on their teamwork the safety of the aircraft depended. All his own skill and ingenuity could not assist them by one iota; the most that he could do to help them in their work was to keep right out of their way.

Technical fields, he reflected, of necessity were small; if you were an expert in one subject you could not be expert also in all the others, for no man's mind was big enough. The man who designed the radar presentation that the controller had used to talk them down that morning would not himself have been able to bring them into a safe landing, for he would not have known sufficient about aeroplanes.

Where everything was strange this seemed no stranger than the rest.

He was scared stiff. He sat there in his cricket shirt and braces with Panama hat upon his head under the brilliant sun of the Hawaiian Islands, the bread and the corned beef untasted on the desk beside him, concentrating on doing the one that he had been taught, keeping the tiddly little triangle upon the lubber line.

Towards the morning it occurred to him that anyway he should not keep his grim forebodings to himself. Two heads, or several heads, were better than one. If he shared his apprehensions with other people someone might pull some rabbit out of an unthought-of hat, might make some suggestion that would somehow make Keith's journey to Tahiti safer.

Jack shook his head. 'Ma died last year. She was always wanting to get back to the islands, but she liked the television too, so she was pulled both ways.'

'I tell you one thing,' he said presently. 'I'll leave the little generator set here, in the Mary Belle.' Jack stared at him. 'Leave that here, with me?' 'That's right. This ship hasn't got a motor. She ought to have one.'

'I think when people get older,' he said, 'they kind of get more mellow. They kind of like to give help in return for help they get.'

She had decided in her own mind that he was honest.

She paused. 'Don't refuse him when he wants to do this little thing,' she said gently. 'You've given him a lot of pleasure with your letters and the clock. Let him do this for you.'

XP and culture change

Last week, at a clients site, I noticed an old, coffee-stained copy of the Cutter IT Journal. It was titled "XP and culture change", dated September 2002. Here are some quotes from it.

From Kent Beck:

Because culture embodies perception and action together, changing culture is difficult and prone to backsliding.

Is it easier to change your perception or go back to designing the old way?

From Laurent Bossavit:

A process change will always involve a cultural change.

We were also a culture of Conviviality, which you could easily mistake (as I did at first) for a culture of Communication... In Conviviality what is valued is the act of sharing information in a group setting - rather than the nature, quantity, or quality of the information thus shared.

Culture is what remains when you have forgotten everything else.

From Mary Poppendieck and Ron Moriscato:

If there were one thing that Ron's team would do differently next time, it would be to do more refactoring.

XP is a process that doesn't feel like a process.

The theory of punctuated equilibrium holds that biological species are not likely to change over a long period of time because mutations are usually swamped by the genes of the existing population. If a mutation occurs in an isolated spot away from the main population, it has a greater chance of surviving.

From Ken Schwaber:

Agile process management represents a profound shift in the development of products and software. Agile is based on an intuitive feel of what is right, springs from a completely different theoretical basis than traditional development processes, and is in sum a wholly different approach to building products in complex situations.

From Matt Simons and Chaitanya Nadkarny

A fixed-bid contract changes the very nature of the relationship between customer and vendor from collaborative to "contentious". "Embrace change" undergoes a fatal transformation into "outlaw change."

There is no way to pretend everything is fine when you have to deliver software to your customer every few weeks.

From Nancy Van Schooenderwoert and Ron Moriscato:

The advantages of pair programming hit you hard and fast. As you explain an area of code to your partner, you get a deeper understanding of how it fits into the current architecture. You're your own peer reviewer!

After pair programming for a while, we found ourselves in a situation where the entire team had worked somewhere in the module in the recent past. Code reviews became exciting idea-exchanging periods where refactoring tasks were discussed and planned.

With schedule pressure, there is a huge temptation to put off refactoring, and we did too much of that.

It's not enough for the code to work; it also has to serve as a solid base for the next wave of features that will be added.

All through the project, a frequent cause was that unit testing wasn't thorough enough.

management of the absurd

is an excellent book by Richard Farson, subtitled Paradoxes in Leadership (isbn 0-684-83044-2). As usual I'm going to quote from a few pages:

The more important a relationship, the less skill matters.

Any technique loses its power when it becomes evident that it is a technique.

People need to know they are dealing with a genuine person, not someone who is "managing" them.

It is only when the balance of power is relatively equal that truly candid communication can and should take place.

When we really listen, so that we understand the other person's perspective, we risk being changed ourselves.

Every management act in some way redistributes or reinforces power.

Ex-convicts are better able to rehabilitate prison inmates than is the prison staff. Ex-drug addicts are more successful in getting other addicts off drugs than are psychiatrists. Students learn more from each other than they do from their professors.

The introduction of highly participative systems tends to bring attacks on the stronger members, often the leaders, while more hierarchical systems bring attacks on the weaker members.

The way to judge your effectiveness is to assess the quality of the discontent you engender.

Scale is the enemy of creativity... Only prisons housing fewer than twenty inmates are likely to be rehabilitative.

The big change... held; the little ones have been much easier to resist.

We learn not from our failures but from our successes - and the failures of others.

By and large, organizations are simply not good at changing themselves. They change more often as a result of invasion from the outside or rebellion from the inside, less so as a result of planning.

Planning may not be effective at assessing the future, but it can be a good way to assess the present.

Strengths and weaknesses come dressed in the same clothing.

Children look at things we turn away from. Sometimes just pointing at what is going on is a valuable way to break through a barrier.

When people feel responsible for handling some situation in which they are, in fact, largely helpless, a dangerous combination of feelings is created: responsibility plus helplessness leads to abuse.

Training makes people more alike... Education... tends to make people different from each other.

testing legacy C/C++ when it resists

In my travels I'm sometimes asked to help a client write some unit-tests for C/C++ code which wasn't built with unit-testing in mind and so, naturally, is resisting being unit-tested. This is a classic chicken and egg situation; you want to refactor the code to get the unit-tests in place, but of course that's dangerous and painful and slow until you've got at least some unit tests in place. There are two big problems:

• Repaying the legacy debt is likely to be a long and arduous road. There's not a lot I can do to help here except offer encouragement and to maybe remind them of the Winston Churchill quote

  if you're going through hell, keep going!

• It often seems there's no way to get started. Clients might say something like "this can't be unit tested" when of course what they really mean is "I don't know how to unit test this". Sometimes I can suggest tricks and techniques.

One way to get started is to make the problem smaller. Suppose I have a large legacy C++ class resolutely resisting being unit-tested. I pick a method and start with that. For example, given this file, fubar.cpp

   1|#include "fubar.hpp"
   2|#include ...
   3|#include ...
    |...
1438|int fubar::f1() const
1439|{
    |   ...
1452|}
1453|
1457|void fubar::example(widget & w, int x)
1458|{
    |   ...
1598|}
1599|
1600|int fubar::f2()
1601|{
    |   ...
4561|}
4562|

I decide to start with fubar::example() which starts at line 1457 of fubar.cpp and ends 100+ lines later: I carefully cut all of lines 1457-1598 into its own new file called fubar-example

   1|
   2|void fubar::example(widget & w, int x)
   3|{
    |   ...
 141|}
 142|

and replace the cut lines from fubar.cpp with a single #include to the new file:

   1|#include "fubar.hpp"
   2|#include ...
   3|#include ...
    |...
1438|int fubar::f1() const
1439|{
    |   ...
1452|}
1453|
1457|#include "fubar-example" // <----
1458|
1459|int fubar::f2()
1460|{
    |   ...
4420|}
4421|

I'm aiming to create a unit-test for fubar::example() like this:

// here I'll dummy out everything used in fubar::example

#include "fubar-example"

// here I'll write my first unit test

However, as safe as it seems, this could cause a change in behaviour! I can easily check this. If fubar.cpp is one of the source files that compiles into something.lib then I can compare the 'before' and 'after' versions of this lib file to see if they are identical. They should be. One reason they might not be is because of things like the assert macro which uses __FILE__ and __LINE__ to report the filename and line-number. I've changed the line numbers on everything below the new #include and the lines numbers and filename inside the included file. I can fix that using the #line directive.

In the original fubar.cpp file example() started at line 1457 so fubar-example becomes:

   1|
   2|...
   3|
   4|#line 1457 "fubar.cpp"  // <----
   5|void fubar::example(widget & w, int x)
   6|{
    |   ...
 145|}
 146|

and the next method f2() started at line 1600 so fubar.cpp becomes:

   1|#include "fubar.hpp"
   2|#include ...
   3|#include ...
    |...
1438|int fubar::f1() const
1439|{
    |   ...
1452|}
1453|
1457|#include "fubar-example" 
1458|
1459|#line 1600 // <----
1460|int fubar::f2()
1461|{
    |   ...
4421|}
4422|

Now the before and after versions of the lib file are identical. Now I try to compile the test file:

// here I'll dummy out everything used in fubar::example

#include "fubar-example"

// here I'll write my first unit test

It fails to compile of course, since I can't define fubar::example() unless I've previously declared it. So I dummy it out:

class fubar
{
public:
    void example(widget & w, int x); // <----
};

#include "fubar-example"

// here I'll write my first unit test

Now it fails because the compiler doesn't know what widget is. So I forward declare it:

class widget; // <----

class fubar
{
public:
    void example(widget & w, int x);
};

#include "fubar-example"

// here I'll write my first unit test

Now it fails because fubar::example() calls a method nudge(int,int) on the widget parameter:

   1|
   2|...
   3|#line 1457 "fubar.cpp" 
   4|void fubar::example(widget & w, int x)
   5|{
    |   ...
    |   w.nudge(10,10); 
    |   ...
 145|}
 146|

So I dummy it out:

class widget
{
public:
    void nudge(int,int) // <----  
    {
    }
};

class fubar
{
public:
    void example(widget & w, int x);
};

#include "fubar-example"

// here I'll write my first unit test

Now it fails because fubar::example() invokes a macro LOG:

   1|
   2|...
   3|#line 1457 "fubar.cpp" 
   4|void fubar::example(widget & w, int x)
   5|{
    |   ...
    |   LOG(... , ...);
    |   ...
 145|}
 146|

So I dummy it out:

#define LOG(where,what)  /*nothing*/  // <----

class widget ...

class fubar
{
public:
    void example(widget & w, int x);
};

#include "fubar-example"

// here I'll write my first unit test

Maybe later I can return to the dummy LOG macro and make it less dumb but for now I'm not even compiling. One thing at a time.

Now it fails because fubar::example() declares a local std::string:

   1|
   2|...
   3|#line 1457 "fubar.cpp" 
   4|void fubar::example(widget & w, int x)
   5|{
    |   ...
    |   std::string name = "...";
    |   ...
 145|}
 146|

This one I don't need to dummy out.

#include <string>   // <----

#define LOG(where,what)  /*nothing*/

class widget ...

class fubar
{
public:
    void example(widget & w, int x);
};

#include "fubar-example"

// here I'll write my first unit test

Now it fails because fubar::example() calls a sibling method:

   1|
   2|...
   3|#line 1457 "fubar.cpp" 
   4|void fubar::example(widget & w, int x)
   5|{
    |   ...
    |   if (tweedle_dee(w))
    |   ...
 145|}
 146|

So I dummy it out:

#include <string>

#define LOG(where,what)  /*nothing*/

class widget ...

class fubar
{
public:
    void example(widget & w, int x);

    bool tweedle_dee(widget &) // <----
    {
        return false;
    }
};

#include "fubar-example"

// here I'll write my first unit test

Now it fails because fubar::example() makes a call on one of its data members:

   1|
   2|...
   3|#line 1457 "fubar.cpp" 
   4|void fubar::example(widget & w, int x)
   5|{
    |   ...
    |   address_->resolve(name.begin(), name.end());
    |   ...
 145|}
 146|

So I dummy it out, making no attempt to write the actual types of the parameters (a useful trick):

#include <string>

#define LOG(where,what)  /*nothing*/

class widget ...

class address_type
{
public:
    template<typename iterator>
    void resolve(iterator, iterator) // <----
    {
    }
};

class fubar
{
public:
    void example(widget & w, int x);

    bool tweedle_dee(widget &) 
    {
        return false;
    }

    address_type * address_; // <----
};

#include "fubar-example"

// here I'll write my first unit test

On I go, one step at a time, until finally, it compiles! Hoorah!

I'm reminded of a saying I heard (from Michael Stal). It's when there's a library you pull in but, on pulling it in, you find it has two further dependencies and you have to pull in those aswell. And they have their dependencies too. etc etc. The saying is:

you reach for the banana; you get the whole gorilla!

Except that sometimes it's worse than that. Sometimes...

you reach for the banana; you get the whole jungle!

Ok. So now it compiles. But I haven't written my first unit-test yet! So I start that:

#include <string>

#define LOG(where,what)  /*nothing*/

class widget ...

class address_type ...

class fubar
{
public:
    void example(widget & w, int x);

    bool tweedle_dee(widget &) 
    {
        return false;
    }

    address_type * address_; 
};

#include "fubar-example"

int main()
{
    fubar f;
    widget w;
    f.example(w, 42); // <----
}

Now I have a test I can actually run! Hoorah! There's no actual assertions yet, but one thing at a time. I run it. It crashes of course. The problem could be the address_ data member. The compiler generated default constructor doesn't set it so it's a random pointer. I might be able to fix that by repeating the same extraction of the constructor(s) into separate #included files. Ultimately that's what I want of course. But one thing at a time. I can definitely fix it by writing my own constructor:

#include <string>

#define LOG(where,what)  /*nothing*/

class widget ...

class address_type ...

class fubar
{
public:
    explicit fubar(address_type * address) // <----
        : address_(address)
    {
    }

    void example(widget & w, int x);

    bool tweedle_dee(widget &) 
    {
        return false;
    }

    address_type * address_; 
};

#include "fubar-example"

int main()
{
    address_type where; // <----
    fubar f(&where); // <----
    widget w;
    f.example(w, 42);
}

Now it compiles and runs without crashing! Hoorah! It is a horrible hack. Painful. But the gorilla is no longer so invisible! And if nothing else, I've got code reflecting the current understanding of my attempt to hack a way into the jungle! I've made a start. I've got something I can build on. And remember, when you say "X is impossible" what you really mean is "I don't know how to X".

P.S.
Here's another horrible testing hack for C/C++.

the starfish and the spider

is an excellent book by Ori Brafman and Rod Beckstrom (isbn 1-59184-143-7). As usual I'm going to quote from a few pages:

This is a book about what happens when there is no one in charge. It's about what happens when there's no hierarchy.

Instead of a chief, the Apaches had a Nant'an - a spiritual and cultural leader. The Nant'an led by example and held no coercive power. Tribe members followed the Nant'an because they wanted to, not because they had to... The phrase "you should" doesn't even exist in the Apache language.

Instead of having a head, like a spider, the starfish functions as a decentralized network. Get this: for the starfish to move, one of the arms must convince the other arms that it's a good idea to do so. The arm starts moving, and then - in a process that no one fully understands - the other arms cooperate and move as well. The brain doesn't "yea" or "nay" the decision. In truth, there isn't even a brain to declare a "yea" or "nay". The starfish doesn't have a brain. There is no central command.

Open systems can't rely on a police force. On the one hand there's freedom to do what you want, but on the other hand, you have added responsibility: because there are no police walking around maintaining law and order, everyone becomes a guardian of sorts.

To collect money, you generally need to have an accountant somewhere, which leads to centralization.

When you give people freedom, you get chaos, but you also get incredible creativity.

It is the right as well as the duty of every managerial employee to criticize a central management decision which he considers mistaken or ill-advised... such criticism is not only not penalized; it is encouraged as a sign of initiative and of an active interest in the business. It is always taken seriously and given real consideration. [Peter Drucker]

I taught them that communication is to be upward if it is to work at all... I taught them that top management is a function and a responsibility rather than a rank and a privilege. [Peter Drucker]

A typical GM factory in the 1980s... if an employee make a mistake or detected a problem, he could stop the line, whereupon a loud alarm would sound... The Toyota assembly line... if an employee stopped the line a pleasant "ding-dong" would sound and teams would carefully study what was going on.

It's better, as the saying goes, to be vaguely right than precisely wrong.

When we are used to seeing something in a certain way, it's hard to imagine it being any other way. If we're used to seeing the world through a centralized lens, decentralized organizations don't make much sense.

the teachings of don juan

is an excellent book by Carlos Castaneda (isbn 978-0140192384). As usual I'm going to quote from a few pages

By experiencing other worlds, then, we see our own for what it is and are thereby enabled also to see fleetingly what the real world, the one between our own cultural construct and those other worlds, must in fact be like.

There is nothing wrong with being afraid. When you fear, you see things in a different way.

Fear is the first natural enemy a man must overcome on his path to knowledge.

You dwell upon yourself too much. That's the trouble. And that produces a terrible fatigue.

Are you angry at me don Juan? I asked when he returned.
He seemed surprised at my question.
No! I'm never angry at anybody! No human being can do anything important enough for that. You get angry at people when you feel their acts are important. I don't feel that way any longer.

What will happen to the man if he runs away in fear?
Nothing happens to him except that he will never learn.
He will never become a man of knowledge. He will perhaps be a bully or a harmless, scared man, at any rate, he will be a defeated man. His first enemy will have put an end to his cravings.
And what must he do to overcome fear?
The answer is very simple. He must not run away. He must defy his fear, and in spite of it he must take the next step in learning, and the next, and the next. He must be fully afraid, and yet he must not stop. That is the rule! And a moment will come when his first enemy retreats. The man begins to feel sure of himself. His intent becomes stronger. Learning is no longer a terrifying task. When this joyous moment comes, the man can say without hesitation that he had defeated his first natural enemy.
Does it happen at once, don Juan, or little by little?
It happens little by little, and yet the fear is vanquished suddenly and fast. But won't the man be afraid again if something new happens to him? No. Once a man has vanquished fear, he is free from it for the rest of his life because, instead of fear, he has acquired clarity - a clarity of mind which erases fear. By then a man knows his desires; he knows how to satisfy those desires. He can anticipate the new steps of learning, and a sharp clarity surrounds everything. The man feels that nothing is concealed.

The freedom to choose a path imparted a sense of direction through the expression of personal inclinations.

Exertion entailed not only drama, but also the need of efficacy. Exertion had to be effective; it had to possess the quality of being properly channelled, of being suitable.

To become a man of knowledge was a task that could not be fully achieved; rather, it was an unceasing process comprising (1) the idea that one had to renew the quest of becoming a man of knowledge; (2) the idea of one's impermanency; and (3) the idea that one had to follow the path with heart.

zen in the art of archery

is an excellent book by Eugen Herrigel (isbn 978-0-14-019074-8). As usual I'm going to quote from a few pages:

He who has a hundred miles to walk should reckon ninety as half the journey.

I have also tried to keep my language as simple as possible. Not only because Zen teaches and advocates the greatest economy of expression, but because I have found that what I cannot say quite simply and without recourse to mystic jargon has not become sufficiently clear and concrete even to myself.

No reasonable person would expect a Zen adept to do more than hint at the experiences which have liberated and changed him, or to attempt to describe the unimaginable and ineffable 'Truth' by which he know lives.

I hit upon the thought that there must be a trick somewhere which the Master for some reason would not divulge, and I staked my ambition on its discovery.

In spite of its being divided into parts the entire process seemed like a living thing wholly contained in itself and not even remotely comparable to a gymnastic exercise, to which bits can be added to taken away without its meaning and character being thereby destroyed.

I once remarked that I was conscientiously making an effort to keep relaxed, he replied: 'That's just the trouble, you make an effort to think about it. Concentrate entirely on your breathing, as if you had nothing else to do.

A great Master, he replied, must also be a great teacher.

You had to suffer shipwreck though your own efforts before you were ready to seize the lifebelt he threw you.

Do you know why you cannot wait for the shot and why you get out of breath before it has come? The right shot at the right moment does not come because you do not let go of yourself. You do not wait for fulfilment, but brace yourself for failure.

Right presence of mind. This means that the mind or spirit is present everywhere, because it is nowhere attached to any particular place.

It is all so simple. You can learn from an ordinary bamboo leaf what ought to happen. It bends lower and lower under the weight of snow. Suddenly the snow slips to the ground without the leaf having stirred. Stay like that at the point of highest tension until the shot falls from you. So, indeed, it is: when the tension is fulfilled, the shot must fall, it must fall from the archer like snow from a bamboo leaf, before he even thinks it.

If I tried to give you a clue at the cost of your own experience, I should be the worst of teachers and deserve to be sacked! So let's stop talking about it and go on practising.

Don't ask, practice!

c++ development slide deck

Here's the slide deck for a presentation I recently did for a large gathering of C++ developers.

systems thinking slide deck

Here are the slides for the talk on Systems Thinking that Niklas Bjornerstedt and I did in the Scotsman pub in Oslo yesterday. The point about "Your wife is very beautiful" is that it is very easy to read that in a static sense. To get a sense of reading it in a more dynamic (relative) sense, imagine if someone replies "compared to who?!"

The books mentioned in the talk are:

• The Systems Bible by John Gall
• The Secrets of Consulting by Jerry Weinberg
• Aesthetics of Change by Bradford Keeney
• Steps to an Ecology of Mind by Gregory Bateson
• The Principles of Production Development Flow by Donald Reinersten
• Slack by Tom DeMarco
• Quality Software Management: Volume 1 - Systems Thinking by Jerry Weinberg
• Freedom from Command and Control by John Seddon

The Law of Unintended Consequences slide has three images for these three stories:

• Andy and the Crusty Cobs
• The Cobra Effect
• Dolphins are Deep Thinkers

dojo = way place

Tore Martin Hagen and some of his colleagues did their first team Cyber-Dojo recently. One team member, Manabu Mochida, is from Japan and he wrote a nice explanation of the term Dojo on the white board. Love it. Thanks Manubu.

the principles and practice of fly and bait casting

Is an excellent book by Reginald D. Hughes (published 1924). As usual I'm going to quote from a few pages:

The great majority of fishermen are ignorant of the actual principles which underlie their every act, whether right or wrong.

One certain index of efficiency is the absence of effort. Style is synonymous with efficiency, and style and effort do not go together.

Double-handed fly casting may especially be recommended as almost, if not quite, the most beneficial form of exercise one can take. It calls for the use of every muscle in the body. It exercises without exhausting.

Excessive effort is not only uncalled for, but if practised defeats itself.

Brute force alone will never put one in the front rank.

A tight grip means tense muscles and joints throughout the body. It kills all attempts to cast smoothly and easily. It imparts, through a vibrating rod tip, waves and irregularities to the line, and is very tiring even to an onlooker.

Remember that the rod should be practically noiseless. Any distinct "whoosh" is a sign of a faulty casting, and shows that the cast is made with the entire rod instead of with the top.

Hold or grip of the rod - there should be none. The rod merely rests in the right hand, while the left hand lightly encircles the butt end. Any tendency to a tight grip must be resolutely suppressed.

Both hands must do an equal share of the work.

Our desire is to cast the fly across and downstream at an angle of about 45 degrees. So we stand, as regards our feet, facing this direction, and, without moving them, rotate the body until we face downstream, rod low and pointing in the direction of the fly.

In learning these casts try to avoid too much concentration, as the great secret is to let the whole body be free and swing easily and comfortably, letting the rod do it, and it will do it if the timing is right.

If the line is allowed to slacken in the least, even momentarily, the pull on it is lost.

the importance of living

Is an excellent book by Lin Yutang, isbn 978-0688163525. As usual I'm going to quote from a few pages:

In the West, the insane are so many that they are put in an asylum, in China the insane are so unusual that we worship them.

I consider the education of our senses and our emotions rather more important than the education of our ideas.

Only he who handles his ideas lightly is master of his ideas, and only he is master of his ideas is not enslaved by them.

A great man is he who has not lost the heart of a child.

Passion holds up the bottom of the world, while genius paints its roof.

The courage to be one's own natural self is quite a rare thing.

An Old Man was living with his Son at an abandoned fort on the top of a hill, and one day he lost a horse. The neighbours came to express their sympathy for his misfortune, and the Old Man asked, "How do you know this is bad luck?" A few days afterwards, his horse returned with a number of wild horses, and his neighbours came again to congratulate him on this stroke of fortune, and the Old Man replied, "How do you know this is good luck?" With so many horses around, his son began to take to riding, and one day he broke his leg. Again the neighbours came round to express their sympathy, and the Old Man replied, "How do you know this is bad luck?" The next year, there was a war, and because the Old Man's son was crippled, he did not have to go to the front.

The trouble with Americans is that when a thing is nearly right, they want to make it still better, while for a Chinese, nearly right is good enough.

When the chains of a bicycle are kept too tight, they are not conducive to the easiest running, and so with the human mind.

Tea in invented for quiet company as wine is invented for a noisy party.

Luxury and expensiveness are the things most to be avoided in architecture.

Taste then is closely associated with courage.

We must give up the idea that a man's knowledge can be tested or measured in any form whatsoever.

Only fresh fish may be cooked in its own juice; stale fish must be flavoured with anchovy sauce and pepper and mustard - the more the better.

The thing called beauty in literature and beauty in things depends so much on change and movement and is based on life. What lives always has change and movement, and what has change and movement naturally has beauty.

zen bow, zen arrow

Is an excellent book by John Stevens, isbn 978-1-59030-442-6. As usual I'm going to quote from a few pages:

He never missed a day of teaching, regardless of the weather, and would often sit for hours in the dojo watching and instructing, even if it was freezing outside.

Gratitude will make you brave.

Learn from a teacher everything he or she has, all the way - that is the real secret of training that will give you great results.

Self-reflection encourages great bravery. Rationalization is your greatest enemy.

Fostering the spirit is painful, hard work; shoot each shot as if your life depended on it.

The essence of Buddhism is not meditation or liberation from samsara. It is kenso, "seeing into your nature."

Do your best at each and every thing. That is the key to success. Learn one thing well and you will learn how to understand ten thousand things.

The two greatest virtues: self-control and returning kindness.

Human beings always cling to things. Practice begins when you stop clinging.

One day of effort is one day of bliss; One day of sloth is a hundred years of regret.

the #include test

Suppose we have a class called widget defined in widget.hpp

class widget
{
    ...
};

How many ways (exclusing templates) can the definition of the class fubar depend on widget?
I can think of thirteen ways:

class fubar : public widget // 1 inheritance
{
    void value_parameter(widget  ); // 2
    void   ref_parameter(widget &); // 3
    void   ptr_parameter(widget *); // 4

    widget value_return(); // 5
    widget & ref_return(); // 6
    widget * ptr_return(); // 7

    widget instance_value_member; //  8
    widget & instance_ref_member; //  9
    widget * instance_ptr_member; // 10

    static widget static_value_member; // 11
    static widget & static_ref_member; // 12
    static widget * static_ptr_member; // 13
};

Now for the test.
Which of the thirteen ways require a hash include

#include "widget.hpp"

as opposed to a forward declaration

class widget;

I've given this test to many many programmers and the vast majority get it wrong. The variety of answers I get is amazing. I recently gave it to a room of about 100 C++ developers and 5 got it right with about 20 different wrong answers (at which point I stopped counting).

What's your answer?
Once you've decided you can scroll down to find the answer.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.keep scrolling...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
The answer is 1 and 8.
How did you do?


If you don't believe me why not try it now in cyber-dojo (click the link and then click the start button).

cyber-dojo Raspberry Pies in action

Liam Friel, who helps to run a CoderDojoBray (in Ireland) asked me for some Raspberry Pies which I was more than happy to give him, paid for from the donations lots of you generous people have made from cyber-dojo.

Liam sent me this wonderful photo of a CoderDojoBray session and writes:

Your Pies have been getting a lot of use... We've got 8 Pies in total. Got a reasonably steady turnout at the dojo, 75-85 kids turning up each week.

Awesome. If, like Liam, you would like some Raspberry Pies to help kids learn about coding, please email. Thanks

ACCU conference charity bookstall

A huge thank you to all the excellent folks at the ACCU conference who helped to raise £481.28 which, like all donations to cyber-dojo, will be used to buy Raspberry Pies for kids.

Pair Programming Illuminated

is an excellent book by Laurie Williams and Robert Kessler. As usual I'm going to quote from a few pages

Programmers admit to working harder and smarter on programs because they do not want to let their partner down.

The pair results were also more consistent, while the individuals varied more about the mean. Individuals intermittently didn't hand in a program or handed it in late; pairs handed in their assignments on time.

Widespread use of pair programming involves a cultural shift in values of the organization - away from individual and toward team recognition and goals.

We have observed that effective pair programmers communicate with each other at least once a minute.

Interestingly enough, the more experience a developer has, the more likely he or she is to ask for help; novices are less likely to ask for help.

We used to consider a new person unproductive for their first three months. Now, we find that new people can help out almost immediately.

We still feel that a novice pair is a better alternative to a solo novice.

We believe pair programming is an integral part of XP, and it is dangerous to do XP without doing pair programming.

changing

Back to quotes table-of-contents

From The Aesthetics of Change

Cybernetics therefore suggests that "all change can be understood as the effort to maintain some constancy and all constancy as maintained through change".
Change cannot be found without a roof of stability over its head. Similarly stability will always be rooted to underlying processes of change.

From How Buildings Learn: Chapter 2 - Shearing Layers

The rates of change over time define the layers as clearly as the individual physical changes.

Hummingbirds and flowers are quick, redwood trees slow, and whole redwood forests even slower. Most interaction is within the same pace level.

From Understanding the Professional Programmer

You must begin to see change as something wonderfully rare, and worth observing. You must stop taking change for granted if you wish to master the art of productive change.

From How Buildings Learn

By far the greatest rate of change comes right at the beginning, as it does with everything that lives.

From Managing the Design Factory

Best practices are only "best" in certain contexts and to achieve certain objectives. A change in either the context or the objective can quickly transform a "best practice" into a stupid approach.

From The Gift of Time

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.

From Progressive Fly Fishing for Salmon

In my opinion most anglers change their flies too often, generally because they lose faith in it. Moreover, when they change flies it is normally for one of a different colour, and not size, and I believe that this is a great mistake.

From Slack

The more efficient you get, the harder it is to change.

From The Silent Language

Life, in a changing environment, places such strains on the organism to adapt that, if this does not take place constantly, the organism as a species dies out.

From The Importance of Living

What lives always has change and movement, and what has change and movement naturally has beauty.

From Quality Software Management. Vol 1. Systems Thinking

A culture is a self-sustaining pattern that has remarkable powers of resistance to change.

From Quality Software Management. Vol 4. Anticipating Change

Human systems don't change unless the individuals change, one at a time.

From What Did You Say?

One of us is going to change, why don't you go first?

From Mind and Nature

The unchanging is imperceptible unless we are willing to move relative to it.

The Aesthetics of Change

Is an excellent book by Bradford Keeney. This is its first set of book snippets. Here's the second. As usual I'm going to quote from a few pages...

All simple and complex regulation as well as learning involve feedback. Contexts of learning and change are therefore principally concerned with altering or establishing feedback.

Corrective action is brought about by difference. The system is technically "error activated" in that "the difference between some present state and some 'preferred' state activates the corrective response". Cybernetics therefore suggests that "all change can be understood as the effort to maintain some constancy and all constancy as maintained through change". [Gregory Bateson]

Occidentals ... practice in order to get a skill, which is then a tool - in which I, unchanged, now have a new tool, that's all. The Oriental view is that you practice in order to change yourself.

In the [predator/prey] example, the battle over food and territory between two species is only one half of the story. The larger cybernetic picture is that the battle is a means or process of generating, maintaining, and stabilizing an ecosystem.

For the most part, people take distinctions to be representations of an either/or duality, a polarity, a clash of opposites, or an expression with a logic of negation underlying it.

Both Don Juan and Erickson also made use of introducing confusion to bring about change.

A "dormative principle" is a more abstract repackaging of a description of the item you claim to be explaining. To paraphrase [Gregory] Bateson, this occurs when the cause of a simple action is said to be an abstract word derived from the name for the action... What one does, in this case, is to say that an item of simple action is caused by a class of action. This recycling of a term does not constitute a formal explanation.

When we encounter sufficient complexity, such as recursive organization of human interaction, our inability to discern higher orders of patterns leads us to committing what Whitehead called "the fallacy of misplaced concreteness." We then "abstract from relationship and from the experiences of interaction to create 'objects' and to endow them with 'characteristics'".

The more "fundamental" a premise, the less accessible it will be to consciousness. As Samuel Butler proposed, the more one "knows" something the less aware one becomes of that knowledge.

Mere purposive rationality unaided by such phenomena as art, religion, dream, and the like, is necessarily pathogenic and destructive of life. [Gregory Bateson]

The truth which is important is not a truth of preference, it's a truth of complexity.

The Hidden Dimension

Is an excellent book by Edward T. Hall. As usual I'm going to quote from a few pages:

One of the most important functions of territoriality is proper spacing, which protects against over-exploitation of that part of the environment on which a species depends for its living.

As numbers of animals in a given area increase, stress builds up until it triggers an endocrine reaction that acts to collapse the population.

Man's evolution has been marked by the development of the "distance receptors" - sight and hearing...

There is a general relationship between the evolutionary age of the receptor system and the amount and quality of information it conveys to the central nervous system. The tactile, or touch, systems are as old as life itself.

As Freud and his followers observed, our own culture tends to stress that which can be controlled and to deny that which cannot.

All works of art are created on a certain scale. Altering the size alters everything.

The present internal layout of the house... is quite recent. As Philippe Aries points out in Centuries of Childhood, rooms had no fixed functions in European houses until the eighteenth century.

Many of my European subjects observed that in Europe human relationships are important whereas in the United States the schedule is important.

The study of Japanese spaces illustrates their habit of leading the individual to a spot where he can discover something for himself.

Planning and renewal must not be separated; instead, renewal must be an integral part of planning.

Like the link between cancer and smoking, the cumulative effects of crowding are usually not experienced until the damage has been done.