the #include test

Suppose we have a class called widget defined in widget.hpp
class widget
{
    ...
};
How many ways 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".

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

Slack

is the title of an excellent book by Tom DeMarco. This second snippet (here's the first) continues my tactic of rereading good books several times. As usual I'm going to quote from a few pages:
Talented managers are ... all sense organ, constantly attuned to the effect their leadership is having on their people ... Managers without such talent find themselves relying on formulas and "principles" of management. They reason, "This thing I'm trying to do should work; the fact that it isn't working probably suggests that I'm doing it half-heartedly." And so they do more of whatever they've been doing.
When the new automation is in place, there is less total work to be done by the human worker, but what work is left is harder. That is the paradox of automation: It makes the work harder, not easier.
In my experience, standard processes for knowledge work are almost always empty at their center.
The power you've granted is the power to err. If that person messes up, you take the consequences. Looked at from the opposite perspective, it is this capacity to injure the person above you that makes empowerment work.
When there is neither time nor staff to cope with work that runs more slowly than expected, then the cost of lateness is paid out of quality. There is no other degree of freedom.
... voluminous documentation of everything that will hold still for it.
Successful change can only come about in the context of a clear understanding of what may never change, what the organization stands for... the organization's culture... If nothing is declared unchangeable, then the organization will resist all change. When there is no defining vision, the only way the organization can define itself is its stasis.

the (de)composition fallacy

You've probably heard the saying "the whole is greater than the sum of the parts". You can think about this law in various ways. For example, if you remove the brain from a man you no longer have a man minus a brain. You have two dead things. A brain is more than just a "part" of a man. A part has relationships to a whole that contribute to the essential wholeness of the whole.

Another way is at a much simpler level - where all the parts are of the same type aggregating together over time. Time patterns them. Human beings are pretty poor at seeing effects over time. We tend to think things are more permanent than they are. We think that the way things are now is how they've always been and how they'll continue to be. I recall showing my children some old Victorian pennies and telling them that's what pennies used to look like. They didn't believe me! Before street lighting it was apparently very common in England to have two sleeps a day. The short one after a midday meal was called the "small sleep". The time we eat our main meal has changed. Eating several courses at a meal is a relatively recent phenomenon. The cutlery we eat with has changed. And what we wear. Before the 17th century your left and right shoe (if you had shoes at all) were the same and were called "straights".

But things do change, and this matters because

Things that don't matter in isolation often matter in composition.

Suppose you compile some code and you get a few warnings. Do these warnings matter? You might think not, since there are only a few, but they do. Tomorrow you'll be writing some more code, and the day after that some more too, and so will your colleagues. After six months those few warnings have turned into 3000 warnings. That's the composition fallacy.

3000 warnings is a big problem for at least two reasons. But the two reasons I'm thinking of are really the same reason. Let me explain.

The first reason is that if you've got 3000 warnings then any new warnings aren't even noticed in the comparative vastness of the existing 3000. You've become completely desensitized to warnings. The number of warnings inexorably grows but no one notices - you've just got "a lot of warnings" that is always "a lot of warnings".

The second reason is the same reason but in reverse.

Suppose you see what you couldn't see before - that a lot of warnings is a composition problem - and you try to do something about it. You've now got to work hard learning how to do something you don't know how to do - namely how to write code without warnings. That takes effort. And what do you get for all your effort? Almost nothing it seems! The number of warnings goes down a tiny bit but there are so many warnings you've hardly made any difference at all. A lot of warnings remains a lot of warnings.

One thing you can do in this situation is to stop reporting the total number of warnings and switch to reporting only the number of warnings either added or removed. This is an example of switching from a static measure (the number of warnings is now 2981) to a more dynamic measure (in the last 24 hours the number of warnings has gone down by 19).