the power of example

Last week I attended another excellent Jerry Weinberg course in Albuquerque. Here's one of the nuggets I learned. It's related to the famous Solomon Asch social psychology conformity experiment.

In the experiment a group of people are shown two cards. The first card has a single line on it. The second card has three lines on it labelled A,B,C one of which clearly matches the length of the line on the other card (and the other two clearly don't). Only one person in the group is the actual subject and is unaware that the other members of the group are part of the experiment. The experiment measures how likely the subject is to conform to the answer given by everyone else when that answer is clearly the wrong one. The answer is "quite a lot". But that's not what I learned. What I learned about is a variation on that experiment. One where Solomon Asch measured how the effect varied depending on how many other people's answers matched, or didn't match, the subject's answer. You can read about this variation (and some others) here. This is the punchline:

The presence of a [single] supporting partner depleted the majority of much of its power. Its pressure on the dissenting individual was reduced to one fourth: that is, subjects answered incorrectly only one fourth as often as under the pressure of a unanimous majority.

Isn't that a great example of the power of setting an example. Of how change happens one person at a time. Of courage. Of how important it is that people feel safe. People are always more impressed by the power of our example than by the example of our power.

the tao is silent

is an excellent book by Raymond Smullyan (isbn 0-06-067-469-5). As usual I'm going to quote from a few pages:

The Taoist strikes me as one who is not so much in search of something he hasn't, but who is enjoying what he has.

Just what is the Tao; how should one define the Tao? Perhaps one of my favourite definitons is: "the reason things are as they are."

"Don't look for the meaning; look for the use" [Ludwig Wittgenstein]

Is it completely out of the question that there may be objects in the universe which are so sensitive that the very act of naming them throws them out of existence?

It is unnameable because it changes in the very process of naming it.

The situation is perfectly analogous to a man who does not trust his dog and keeps him perpetually chained. The chaining process obviously makes the dog vicious, and the man then says, "You see why such a vicious dog has to be chained!"

You are trying to force that which can thrive only if it is not forced.

Kindness cannot be taught by harshness - not by any amount of harshness.

Freedom is doing what one likes: Zen is liking what one does.

The problem of hiring astrology professors is relatively easy. To hire an astrologer professor, all one has to do is to cast his horoscope and see if he would make a good astrology professor.

My immediate reaction to the remark "one should not be too tolerant" was to be intolerant of it.

Taiichi Ohno's workplace management

is an excellent book by Taiichi Ohno (isbn 978-0-07-180801-9). As usual I'm going to quote from a few pages:

When I was a middle school student in the old system, we studied the Chinese classics, and during this class we learned from the Analects of Confucius. In these writings Confucious says, "The wise will mend their ways" and "The wise man should not hesitate to correct themselves."... Confucius was saying that we should change gracefully... I think his words mean that in the end it is not good if you hold onto your ideas too strongly and try stubbornly to justify them.

When we said we would set up a centralized grinding operation, one experienced worker said, "No, we tried that during the war, but it failed. That's why we do it the way we do now." [I said] "I did not see it fail during the war. Show me again how it fails. If I am persuaded by this, I will let you continue doing it the way you do it now."

If you asked me, "What is the most important part of production control?" I would say it is to limit overproduction.

The kanban was a slip that indicated how many pieces they were coming to get, so that if they were going to take ten parts this became a production instruction slip directing the production line to make ten pieces.

When lot sizes are small, you need to do changeovers more frequently.

Stopping the line causes a great loss, so this forces us to think, "How do we keep them from stopping the line?" and this results in more and more quality kaizen.

You can only really tell what is better based on results.

Accounting cannot do any cost reduction... The shop floor reduces inventory. This money goes to the bank... Instead, accounting thinks it just needs to allocate cost savings targets.

There is something called standard work, but standards should be changing constantly. Instead, if you think of the standard as the best you can do, it's all over. The standard is only a baseline for doing further kaizen. It is kaiaku if things get worse than now, and it is kaizen if things get better than now. Standards are set arbitrarily by humans so how can they not change?

You must create a standard for comparison.

Drop a nut once and pick it up. Working at the average time is like trying to catch the nut halfway because letting it drop all the way down takes too long... There is no such thing as average value in this world.

Do not seek to follow in the footsteps of the old masters, seek instead what these masters sought. [Matsu Basho 1644-1694]

Once he asked me how the terms kaizen and kairyo (reform) were differentiated in the West. I said that while kaizen means to make improvements by using brains, kairyo means to make improvements by using money, and that in the West, most managers only think of improvement in terms of money. [Massaki Imai]

Let the flow manage the processes, and not let management manage the flow.

The aim of kanban is to make troubles come to the surface and link them to kaizen activity. I tell people, "Let idle people play rather than do unnecessary work."

The production line that never stops is either excellent or terrible.

Costs exist to be reduced, not to be calculated.

lessons from geese

Here are some facts about Geese, borrowed from Dr Robert McNeish. They appeared in an issue of Southwest Airlines corporate newsletter.

When you see geese heading back north for the summer flying along in a "V" formation you might be interested in knowing what scientists have discovered about why they fly that way. It has been learned that as each bird flaps its wings, it creates an uplift for the bird immediately following. By flying in "V" formation, the whole flock adds a least 71 percent greater flying range than if each bird flew on its own.

Whenever a goose falls out of formation it suddenly feels the drag and resistance of trying to go it alone and quickly gets back into formation to take advantage of the lifting power of the bird immediately in front.

When the leads goose gets tired, he rotates back in the wing and another goose flies point.

The geese honk from behind to encourage those up front to keep up their speed.

When a goose gets sick or is wounded by gunshot and falls out, two geese fall out of formation and follow him down to help and protect him. They stay with him until he is able to fly or until he is dead, and then they launch out on their own or fly with another formation to catch up with their group.

the pleasure of finding things out

is an excellent book by Richard Feynman (isbn 978-0-141-03143-9). As usual I'm going to quote from a few pages:

Looking at the bird he says, "Do you know what that bird is? It's a brown throated thrush; but in Portuguese it's a … in Italian a …, " he says "in Chinese it's a …, in Japanese a …," etcetera. "Now," he says, "you know in all the languages you want to know what the name of the bird is and when you've finished with all that," he says, "you'll know absolutely nothing whatever about the bird. You only know about humans in different places and what they call the bird. Now," he says, "let's look at the bird."

I said, "Say, Pop, I noticed something: When I pull the wagon the ball rolls to the back of the wagon, and when I'm pulling it along and I suddenly stop, the ball rolls to the front of the wagon," and I says, "why is that?" And he said, "That nobody knows," he said. "The general principe is that things that are moving try to keep on moving and things that are standing still tend to stand still unless you push on them hard." And he says, "This tendency is called inertia but nobody knows why it's true." Now that's a deep understanding - he doesn't give me a name, he knew the difference between knowing the name of something and knowing something, which I learnt very early.

To do high, real good physics work you do need absolutely solid lengths of time.

You cannot expected old designs to work in new circumstances.

If you are in a hurry, you must dissipate heat.

We had lots of fun.

The people underneath didn't know at all what they were doing. And the Army wanted to keep it that way; there was no information going back and forth... I felt that you couldn't make the plant safe unless you knew how it worked… I said that the first thing there has to be is that the technical guys know what we're doing. Oppenheimer went and talked to the security people and got special permission. So I had a nice lecture in which I told them what we were doing, and they were all excited. We're fighting a war. We see what it is. They knew what the numbers meant. If the pressure came out higher, that meant there was more energy released and so on and so on. They knew what they were doing. Complete transformation! They began to invent ways of doing it better. They supervised the scheme. They worked all night. They didn't need supervising at night. They didn't need anything. They understood everything. They invented several of the programs that we used and so forth. So my boys really came through and all that had to be done was to tell them what it was, that's all. It's just, don't tell them they're punching holes. As a result, although it took them nine months to do three problems before, we did nine problems in three months.

Most of the trouble was the big shots coming all the time and saying you're going to break something, going to break something.

We used to go for walks often to get rest.

Advertising, for example, is an example of a scientifically immoral description of the products.

The magnetic properties on a very small scale are not the same as on a large scale.

But what we ought to be able to do seems gigantic compared with our confused accomplishments. Why is this? Why can't we conquer ourselves?

Erosion and blow-by are not what the design expected. They are warnings that something is wrong. The equipment is not operating as expected, and therefore there is a danger that it can operate with even wider deviations in this unexpected and not thoroughly understood way… The O-rings of the Solid Booster Rockets were not designed to erode. Erosion was a clue that something was wrong. Erosion was not something from which safety can be inferred.

We have also found that certification criteria used in Flight Readiness Reviews often develop a gradually decreasing strictness.

The computer software checking system and attitude is of highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems. To be sure, there have been recent suggestions by management to curtail such elaborate and expensive tests as being unnecessary at this late date in Shuttle history. This must be resisted for it does not appreciate the mutual subtle influences, and sources of error generated by even small changes of one part of a program on another. There are perpetual requests for changes as new payloads and new demands and modifications are suggested by the users. Changes are expensive because they require extensive testing. The proper way to save money is to curtail the number of requested changes, not the quality of testing for each.

Official management, on the other hand, claims to believe the probability of failure is a thousand times less. One reason for this may be an attempt to assure the government of NASA perfection and success in order to ensure the supply of funds. The other may be that they sincerely believe it to be true, indicating an almost incredible lack of communication between themselves and their working engineers.

It is presumptuous if one says, "We're going to find the ultimate particle, or the unified field laws," or "the" anything.

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!

we seven

is an excellent book by the seven mercury astronauts (isbn 978--4391-8103-4). As usual I'm going to quote from a few pages:

By working with the designers and engineers on a brand-new, complicated airplane you learn to ferret out the bugs and problems before they can be built into the system to worry other pilots who will use later production aircraft. [John Glenn]

Looking back on it now, it sounds a bit silly. But it takes little moments like that to build up a person's tolerance of fear and his ability to face the unknown. [Malcomn Scott Carpenter]

When I got back to the States, I served a hitch teaching some younger pilots how to fly. This kind of duty is probably even more dangerous than combat. At least you know what a MIG is going to do. [Virgil Grissom]

A test-pilot is fiercely proud of his profession. [Walter Schirra]

I could not take care of the polyp right away because part of the procedure before they could operate on it was to keep me absolutely quiet for four days and not let me speak… Later on the medics did put me on a week's silent treatment. I had to break it only once when a NASA official called me up from Langley to ask me how my polyp was coming along. I told him he had just interrupted the cure. [Walter Schirra]

In combat, for example, you are thinking about what goes on outside of your airplane… But in test flying you have an entirely different problem. You are concerned about what is going on inside the airplane, and what the aircraft itself is doing. [Deke Slayton]

If you are an amateur in this business, and you just think you are in trouble, you can really get yourself into trouble very fast by doing the wrong thing first. You might be a whole lot better off if you did nothing at all. [Deke Slayton]

In flying, navigation is generally defined as "continuously detecting and correcting infinitesimal errors in the flight path." [Deke Slayton]

The schedule was flexible. We knew that variable factors such as weather, over which we would have no control, could cause delays. [John Glenn]

This panel groups all of the warning lights in one convenient place so we can see at a glance if any problems have cropped up. [John Glenn]

Each part that goes into the capsule has had a prototype tested to destruction to make sure it can stand the rough ride and the temperature changes. The test procedures are extremely painstaking. First, one part is tested; then two parts are linked together and both of them are tested as a unit. The small units are joined into bigger units for further testing, and this process continues until finally the entire machine is ready for a master test. [Malcomn Scott Carpenter]

We adopted three basic principles. First, we would use any training device or method that had even a remote chance of being useful. Second, we would make the training as difficult as possible so that we would be overtrained, if anything, rather then undertrained. And third, except for some wise scheduling of time, we decided to conduct our training on an informal basis. Everyone assumed from the start that we were mature, well-motivated individuals. Everyone knew we were all eager to make good. [Deke Slayton]

The manual went out of date as fast as the capsule grew… In the meantime… we had to work with some early drawings of the spacecraft that had been included in the original specifications. This was a bit like learning how to cook from looking into some chef's garbage pail. [Deke Slayton]

We did not blame any of our problems on such things as gremlins. For one thing, these creatures belonged to another era. [John Glenn]

We also had daily scheduling meetings to keep everyone informed of our progress and up to date on any problems which cropped up. Here is where we reviewed the work being done on the various systems. [Virgil Grissom]

Even though the electronic machines were clever, we did not let them run the show. [Alan Shepard]

an ecology of mind

is an excellent dvd, by Nora Bateson, about her father, Gregory Bateson, who wrote An Ecology of Mind. As usual here's are some selected quotes:

Without context, words and actions have no meaning at all. This is true of all communication... [Gregory Bateson]

A role is a half-arsed relationship. It's one end of a relationship. You cannot study only one end of a relationship and make any sense. What you will make is disaster. [Gregory Bateson]

I've been bothered a little bit the past few days by people who say, "What do you mean 'ecology of mind'". And approximately what I mean is that the various sorts of 'stuff' that goes on in ones heads and in ones behaviour, and dealing with other people and walking up and down mountains, and getting sick and getting well and all that. That all that stuff interlocks, and in fact constitutes a network, and you've got the sort of complicated, living, partly struggling, partly co-operating, tangle, that you find on the side of any of these mountains with the trees and various plant and animals that live there. In fact an ecology. [Gregory Bateson]

The division of things into parts tends to be a device of convenience, and that's all. [Gregory Bateson]

Wise men see outlines and therefore they draw them. [William Blake]
Madmen see outlines and therefore they draw them. [William Blake]
If a fool should persist in his folly, he would become wise [William Blake]

The difference that makes a difference is a way in which to define something in terms of its relationships, using contrast and context, instead of isolating it with a name. [Nora Bateson]

Krishnamurti said something like "You might think you're thinking your own thoughts. You're not. You're thinking your culture's thoughts." [Nora Bateson]

I guess I've been reading too much Alice. [Gregory Bateson]

The double-bind is a creative imperative. Its the moment when, because this doesn't work and that doesn't work, something else is going to have to be improvised. A creative impulse is necessary at that moment, to get out of the situation, to take it up a level. [Nora Bateson]

The combination of theme with variation immediately points you to something behind it. A formative principle. [Terrence Deacon]

He was often accused of talking in riddles and never coming to the point. The question he posed "What is the pattern that connects?" was never meant to be answered, because the patterns are changing. It was the act of questioning that he was pushing for. Knowing that the eyes behind that curiosity will be the most apt to give the patterns of connection room to wiggle as they perpetually self correct. And to see the beauty in that process. [Nora Bateson]

When you see process you see constant change. That's why Gregory was constantly quoting Heraclitus "no man can step into the same river twice". Because it's flowing. [Mary Bateson]

Only by the creation of change can I perceive something. [Gregory Bateson]

A man walking is never in balance, but always correcting for imbalance. [Gregory Bateson]

He asked the question "What is there about our way of perceiving that makes us not see the delicate interdependencies in an ecological system, that give it its integrity." We don't see them, and therefore we break them. [Mary Bateson]

Any kind of aesthetic response is a response to relationships. [Mary Bateson]

I hope it may have done something to set you free from thinking in material and logical terms, when you are, in fact, trying to think about living things. [Gregory Bateson]

Larry and Jen do Roman Numerals in C++

You may remember Larry and Jen from the popular (900,000+ hits) Deep C (and C++) slide-deck. Well, they're back - this time practising their C++ by doing the Roman Numerals problem.

Larry and Jen do Roman Numerals in C++ from Jon Jagger

Here it is in pdf too.

agile development in the large

is an excellent book by Jutta Eckstein (isbn 978-0932633576). As usual I'm going to quote from a few pages:

Quick feedback should be the first thing you introduce.

It is important that instead of the process being adopted it is adapted.

Starting with really short cycles seems to help implement the change to an agile process. If the cycles are short it is very difficult for the whole team to fall back into its old habits.

Learning and change processes are part of each other. Change is a learning process and learning is a change process.

Every agile process contains the following subtle steps
(1) reflection (awareness)
(2) learning
(3) change.

A plan is nothing; planning is everything. [Eisenhower]

If a project is on time and in budget it doesn't mean it was a successful project, but a successful estimate.

Methodologies do not produce skilled developers.

Stability is more negative than it is thought to be. [To stabilize something is to kill it]

A book is always a prevented dialogue.

more secrets of consulting

is an excellent book by Jerry Weinberg (isbn 978-0932633521). As usual I'm going to quote from a few pages:

Consultants are hired for knowing what others don't know, so a consultant who stops learning soon decays in value.

It's always better to be a do-something rather than a know-everything.

The Wishing Wand reminds me of the ability to ask for what I want, and if necessary, to live with not getting it.

Modern psychology often scorns introspection and has become the study of other people's behaviour.

I personally think that big changes result from an accumulation of small changes.

Incongruence is stereotyped behaviour.

It takes big balance to learn small balance.

Nothing is immutably programmined into my mind - except its programmability. The ability of my mind to program itself is a far greater ability than any particular program.

Fear is one of the brakes on creativity.

In social engineering, as in all engineering, failures teach more than successes.

the right stuff

is an excellent book by Tom Wolfe (isbn 978-0-099-47937-6). A marvelous tale of courage. As usual I'm going to quote from a few pages:

In the military they always said "flight test" and not "test flying".

Once the theorem and the corollary was understood, the Navy's statistics about one in every four Navy aviators dying meant nothing. The figures were averages, and averages applied to those with the average stuff.

What people were seeing on television were, in fact, ordinary test events. Blown engines were par for the course in testing aircraft prototypes and were inevitable in testing an entirely new propulsion system, such as jet or rocket engines.

Conrad stares at the piece of [blank] paper and then looks up at the man and says in a wary tone, as if he fears a trick: "But it's upside down."

This obsession with active control, it was argued, would only tend to cause problems on Mercury flights. What was required was a man whose main talent was for doing nothing under stress.

The boys' response, however, had not been resignation or anything close to it. No, the engineers now looked on, eyebrows arched, as the guinea pigs set about altering the experiment.

The esprit throughout NASA was tremendous... Bureaucratic lines no longer meant anything. Anyone in Project Mercury could immediately get to see anybody else about any problem that came up.

They had barely moved the first stick of furniture in when the tour buses started arriving, plus the freelance tourists in cars. ... Sometimes people would get out and grab a handful of grass from your lawn. They'd get back on the bus with their miserable little green sprouts sticking out of their fingers. They believed in magic.

Herein the world was divided into those who had it and those who did not.

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.