Authentic happiness

is an excellent book by Martin Seligman (isbn 1-85788-329-2). As usual I'm going to quote from a few pages:
Daddy, do you remember before my fifth birthday? From when I was three until when I was five, I was a whiner. I whined every day. On my fifth birthday, I decided I wasn't going to whine any more. That was the hardest thing I've ever done. And if I can stop whining, you can stop being such a grouch.
All emotions about the past are completely driven by thinking and interpretation.
There are, however, no known ways to enhance forgetting and suppressing of memory directly. Indeed explicit attempts to suppress thoughts will backfire and increase the likelihood of imagining the forbidden object.
If you think about bad things in terms of "always" and "never" and abiding traits, you have a permanent, pessimistic style.
Learned optimism… is about accuracy.
Almost nothing that happens to you has just one cause.
Mindful attention to the present occurs much more readily in a slow state of mind.
Total immersion, in fact, blocks consciousness, and emotions are completely absent.
The mood state Americans are in, on average, when watching television is mildly depressed.
The overarching principle of good listening is validation.
By encouraging cheap success, it produced a generation of very expensive failures.
Every drug that breaks up depression also blocks dreaming.

Agile A-Z Keynote

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





Waiting work wall

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


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


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


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


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



Zen in the martial arts

is an excellent book by Joe Hyams (isbn 0-87477-101-3). As usual I'm going to quote from a few pages:
At least empty your cup and try.
Those who are patient in the trivial things in life and control themselves will one day have the same mastery in great and important things.
The martial artist develops through practice until it becomes mechanical and then spontaneous.
When you lose your temper, you lose yourself - on the mat as well as in life.
The proper system is to think twice more. Patience is part of it. To avoid being intimidated - think more and react less.
Try softer. When one eye is fixed upon your destination, there is only one eye left with which to find the way.
To know and to act are one and the same.
Relaxation and concentration go hand in hand. But too much concentration defeats itself.
Most of the time we generate our own fears, and this is especially true when we confront an unfamiliar situation that shatters confidence.
Years ago I thought too much about what I had to do, laboured over it, put off difficult chores, waited for the mood to be right or the creative juices to flow. Now I just do it without conscious effort. It flows because the work and I are one, and not in conflict with each other.
The only reason men fight is because they are insecure; one man needs to prove that he is better or stronger than another. The man who is secure within himself has no need to prove anything with force, so he can walk away from a fight with dignity and pride.

C will live forever

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

Situated learning - Legitimate peripheral participation

is an excellent book by Jean Lave and Etienne Wenger (isbn 0-521-42374-0). As usual I'm going to quote from a few pages:
The world carries its own structure so that specificity always implies generality (and in this sense generality is not to be assimilated to abstractness).
Reversing production steps has the effect of focusing the apprentice's attention first on the broad outlines…
The fact that the work was done in an interaction between members opened it up to other members of the team.
There is anecdotal evidence that where the circulation of knowledge among peers and near-peers is possible, it spreads exceedingly rapidly and effectively.
A learning curriculum is thus characteristic of a community.
Understanding and experience are in constant interaction.
Mirroring the intricate relationship between using and understanding artefacts there is an interesting duality inherent in the concept of transparency. It combines the two characteristics of invisibility and visibility… It might be useful to give a sense of this interplay by analogy to a window. A window's invisibility is what makes it a window, that is, an object through which the outside world becomes visible. The very fact, however, that so many things can be seen through it makes the window itself highly visible, that is, very salient in a room, when compared to, say, a solid wall. Invisibility of mediating technologies is necessary for allowing focus on, and thus supporting visibility of, the subject matter.

World class match fishing

is an excellent book by Kevin Ashurst (isbn 0-304-29729-1). As usual I'm going to quote from a few pages:
I always try to visualise what is happening under the water, and the only concrete clues I can count on are the bites, or the lack of them.
When loose-feeding for roach and dace, it always pays to shuffle the tackle when bites cease. Moving a shot an inch or two, or altering the depth slightly, works so frequently that one has to assume that the fish, as well as becoming wary because of their diminishing numbers, also get shy of baits coming to them in precisely the same way all the time.
Good loose-feeing is one of the key factors affecting success in match angling, and the difficulty of getting it right is one of the reasons why I set so much store by practising for big matches.
The starting point is the knowledge that you cannot scare fish away if they are not there to begin with.
I always think fish behave a bit like birds. If you scatter breadcrumbs on a lawn the birds begin eating it from the edges, rarely alighting in the middle, and I reckon fish behave the same way.
The trick to drop fishing is to read the signs, and the most important one is getting a caster shelled or a maggot sucked without seeing a bite.
A stick float is quite heavy in relation to its size, and at any sort of range we can cop for a splashy sort of strike.
The fish in shallow water tend to be shy. They usually come into the baited area, pick up a bait and bolt.
The original choice of float is obviously dictated by the distance to be cast and the conditions on the day, and the aim should be to achieve whatever distance is required easily. It is better to overcast and pull back than to fall short and have to cast again.
It goes without saying that the kinds of bites we can expect depends entirely on the way the fish are behaving on the day, and how we are shotted in response to that behaviour.
To be perfectly honest the appearance of my floats has never interested me. I never even thought about them in the artistic sense until Colin brought it up, but I suppose the answer lies under the general heading of ignoring everything which is not essential. I devote a lot of time, thought and energy to my fishing, but only to those departments which require time, thought and energy.

More CyberDojos












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

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

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

ALE CyberDojo Ice Breaker

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

We are what we say

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

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

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

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


They reminded me again of the importance of precision listening.

Brain rules

is an excellent book by John Medina (isbn 978-0-9797777-4-5). As usual I'm going to quote from a few pages:
Students learn better from words and pictures than from words alone.
Students learn better when corresponding words and pictures are presented simultaneously rather than successively.
Students learn better when corresponding words and pictures are presented near to each other rather than far apart on the page or screen.
Students learn better when extraneous material is excluded rather than included.
Students learn better from animation and narration than from animation and on-screen text.
When the brain is fully working, it uses more energy per unit of tissue than a fully exercising quadricep.
Charles Darwin noted… the brains in wild animals were 15 to 30 percent larger than those of their tame, domestic counterparts.
Studies show that a person who is interrupted takes 50 percent longer to accomplish a task. Not only that, he or she makes up to 50 percent more errors.
Spaced learning is greatly superior to massed learning.
A great deal of research shows that thinking or talking about an event immediately after it has occurred enhances memory for that event.
Students are expected to known certain things by certain grades. Curiously absent from this model is how durable that learning remains after the student completes the grade.
When people become sleep-deprived, their ability to utilise the food they are consuming falls by about one-third.
Sleep loss cripples thinking in just about every way you can measure thinking.
Vision is by far our most dominant sense, taking up half of our brain's resources.

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

is an excellent book by William B. Miller and Vicki L. Schenk (isbn 0-9630439-3-5). As usual I'm going to quote from a few pages:
I mumbled back something equally unintelligible, the traditional response to somebody whom you aren't sure you've met and whose name you aren't certain of.
"Why is there such a conflict?" he asked. "Both departments are striving for the same thing, the good of the company. Why should they not work together?"
With all that volume flowing through his "factory," even the slightest unplanned act will ripple through everything else with a domino effect.
Fanatic: A person who redoubles his effort after having lost his direction.
If you double the amount of equipment and tools in use, you must halve the failure rate simply to stay even.
Planning can be perfect - it's all theoretical. Execution can never be perfect - it involves real people using real tools on real material.
People are expected to inspect their own work, both for function and to specification… Statistical and analytical charts are maintained on the production floor by workers, not by Quality Assurance people in a remote office.
Like most computer people would have, he had stayed close to his electronic toy rather than come to the garage to watch the production operation.
The finest carver does the least cutting.
Nobody ever tried harder under pressure.
"know'why" in addition to "know-how"

Long test method names

Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch

Writing good code is hard. For lots of reasons. One reason is the tension you try to balance when choosing identifiers. On the one hand you want your identifiers to be longer to give you enough space to make them expressive. But on the other hand you want your identifiers to be shorter so they don't balloon into monsters when combined into expressions. For example:
// too short
bool is_leap_year(int y)
{
    return y % 4 == 0 && y % 100 != 0 || y % 400 == 0;
}

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

// just right, said Goldilocks
bool is_leap_year(int year)
{
    return year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
}
However, the names of your test methods are not subject to this design tension. The names of your test methods should never be part of a larger expression. So loosen up! Feel free to use long test method names. Names that reflect the specification not the implementation.
// not like this
static void test_leap_year()
{
    assert(!is_leap_year(1999));
}

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


THE Secret of Scrum

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

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

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



Precision Listening

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

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

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

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

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

Hello, Jon Jagger speaking.

Hello, can I speak to Jon Jagger please.

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

flow = speed x density

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

Karl used this graph in the context of traffic.
  • The green line is traffic Speed and it rises (to the right) from zero at the bottom left.
  • The red line is traffic Density and it rises (to the left) from zero at the bottom right.
  • The black line is traffic Flow and equals Speed x Density.
Speaking to Karl afterwards we discussed the analogy:
  • Speed = cycle time. The time it takes from the moment a piece of work enters the system to the time it gets to Done.
  • Density = work in progress. The amount of work that has entered the system but hasn't yet got to Done.
Karl also pointed out two feedback loops.
  • Start on the density line (red) at zero (bottom right) and increase the density (move up and to the left). For a while increasing the density increases the flow. Increasing the flow causes the density to reduce. Thus you have a stabilizing feedback loop helping to increase the flow.
  • As you continue to increase the density you drop over the top of the flow-curve.
  • Now as the density increases the flow decreases. And decreasing the flow causes the density to further increase. Thus you have a different destabilizing feedback loop helping to decrease the flow.
Simple and effective. Thank you Karl.

The unknown craftsman

is an excellent book by Sōetsu Yanagi (isbn 0-87011-948-6). As usual I'm going to quote from a few pages:
The good artist or craftsman has no personal pride.
Seeing relates to the concrete, knowing to the abstract.
To divine the significance of pattern is the same as to understand beauty itself.
A pattern is both true to nature and artificial.
If the material is poor the pattern will suffer.
By and large, good pattern is of communal parentage.
Beauty must have some room, must be associated with freedom.
The Theologica Germanica, written in the fourteenth century, tells is: "He would know before he believeth cometh never to true knowledge". Applied to the perception of beauty, this means that if a man employs the function of knowing before seeing, his power is impaired.
Intuition is the power of seeing at this very moment.
The thing shines, not the maker.
They are made without obsessive consciousness of beauty; thus we catch a glimpse of what is meant by "no-mindedness", whereby all things become simplified, natural, and without contrivance.

Wye Barbel

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

the alchemist

is an excellent book by Paulo Coelho (isbn 978-0-7225-3293-5). As usual I'm going to quote from a few pages:
"This is the first phase of the job," he said. "I have to separate out the sulphur. To do that successfully, I must have no fear of failure. It was my fear of failure that first kept me from attempting the Master Work.
"But arms cannot be drawn unless they also go into battle. Arms are as capricious as the desert, and, if they are not used, the next time they might not function."
"I had to test your courage," the stranger said. "Courage is the quality most essential to understanding the Language of the World."
"It is not what enters men's mouths that's evil," said the alchemist. "It is what comes out of their mouths that is."
"Tomorrow, sell your camel and buy a horse. Camels are traitorous: they walk thousands of paces and they never seem to tire. Then suddenly, they kneel and die. But horses tire bit by bit. You always know how much you can ask of them, and when it is that they are about to die."
"There is only one way to learn," the alchemist answered. "It is through action."

Quality Software Management
Vol 1. Systems Thinking

is an excellent book by Jerry Weinberg (isbn 0-932633-22-6). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:
A locked-on system tends to hold itself to an existing pattern, even against logical reasons to change. … Lock-ons occur in clusters.
We particularly look for the degree of congruence between what is said and what is done.
The quickest and surest way to classify organisations into similar patterns is by the way people think and communicate.
The feedback model says you can't successfully control anything for very long without information.
errors - deviations from requirements that give you information to control the system.
The treatment of error as a source of valuable information is precisely what distinguishes the feedback (error-controlled) system from its less capable predecessors and thus distinguishes Steering software cultures from Patterns 1 [Variable] and 2 [Routine].
If the technical reviews are not detecting a lot of mistakes it could mean that … the system is working very well.
Late modules tend to be fault prone modules.
The more modular you make the system, the fewer side effects you need to consider. You trade for this effect by creating modularity faults, or faults in the interaction between modules. You never get something for nothing.
Feedback must operate in small increments, at all levels - personal, product, process, and cultural.
In such a system it is meaningless to ask who is controlling whom?

It's not the event that counts...

In Quality Software Management volume 1 Systems Thinking, Jerry Weinberg writes (on page 111)

"It's not the event that counts, it's your reaction to the event".


A bit later, on page 124 Jerry writes something which I've read several times before but for some reason this morning it really spoke to me.

Tools do not determine how they will be used. Therefore it's not the tool that counts, it's your reaction to the tool. Programming tools can be used to program without understanding, or they can be used to free the programmer's mind and hands for tasks that can't be made routine.


Jerry finishes the paragraph with:

Pattern 2 (Routine) managers buy tools to force programmers to work in standard ways. Pattern 3 (Steering) managers manage tools to empower programmers to work in effective ways.


What Did You Say?

is an excellent book (subtitled The Art of Giving and Receiving Feedback) co-authored by Jerry Weinberg (isbn 0-924771-33-X). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet. For the past year or so I've deliberately been re-reading books I've already read rather than reading new ones.
Cybernetics tells us that feedback is a relationship between two systems. ... you're a system too.
A lot of our fear of telling them comes from inexperience, or rather experience at giving feedback poorly and then getting a poor result. But getting a poor result is is such a terrible experience only if we have a perfection rule.
Over time, the process of sorting creates an environment that will not provide feedback that leads to change.
In other words, it's not so much the feedback that counts, but the struggle to get it - not the feedback, but the feeding-back.
If you keep doing the same thing why do you expect them to change what they're doing?
Say what you saw and heard.
If mistakes are not acceptable, learning is not possible.
Learning is what feedback is all about.

QCon Deliberate Practice video

Videos are like buses. None for ages then two come along at once. I did this talk, on Deliberate Practice at the QCon conference in London earlier in the year (it's only just been put online). It's an extension of my 97 Things Every Programmer Should Know entry.

In the brain of me

Here's a video of the SkillsMatter talk I did on Thursday, titled "Stuff I'm starting to know now that I really wish I'd known 20 years ago". Its loosely based on the theme of Making The Invisible More Visible, one of my entries from the book, 97 Things Every Programmer Should Know. I completely botched what I was trying to say about courage. What I was trying to say was that courage is not the absence of fear.

My other SkillsMatter talk was based on Do More Deliberate Practice my other entry in the 97 Things Book.

This was the first run of quite a lot of new material so I was quite nervous, but I felt most of it went very well. Here's some of the feedback.
  • Fun, informative, useful
  • An interesting brain dump
  • Entertaining and enlightening
  • Very good. Thoughtful and interesting
  • Great content - very interesting
  • Great laid back presentation
  • Interesting ideas and great presentation to go with it
  • Well planned presentation, not just your standard powerpoint
  • Very good talk. Inspiring
  • Very interactive and well explained
  • Clear explanations, good analogies, funny
  • Fantastic
  • Very good. Passionate speaker. Good insights


Becoming a Technical Leader

is an excellent book by Jerry Weinberg (isbn 0-932633-02-1). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
From working with systems, I have learned that the process of change is always organic.
Organic models may be characterized by "systems thinking": the belief that event X is the outcome of hundreds of other factors, including the passage of time.
People improve their performance not by amputating their old behaviors, but by adding new ones.
There are many technical workers who enjoy wandering so much that, like Alice in Wonderland, they don't much care where they go, so long as they get somewhere. Computer programmers call this process "hacking"
In front of each plateau is a ravine.
Probably the most widespread and pernicious myth about leadership is that only Leaders can lead, where the capital L indicates that someone has been appointed to the position of leadership. ... It's only in threat/reward models that leadership and management are synonymous.
You can develop your ability to see and hear more effectively.
People aren't used to thinking in terms of relationships.
I first look for personal power, which can be converted into almost anything.
Break down big learnings into a sequence of little ones, pay attention to the efficiency of your educational strategies, and become aware of your emotional reaction to learning.

CyberDojos

I've run a couple more CyberDojo's recently. The first was with Kevlin Henney during an onsite run of our Mastering Agile Practice course for commasoft in Bonn, Germany.

The second was for Mott MacDonald, in Croydon, England. Here's some feedback from the sessions:
  • an awesome afternoon!
  • It has been the single most useful training exercises I have attended at motts.
  • it was an excellent team building exercise and a fun introduction to some development concepts we're not familiar with, in particular pair programming and test driven development, but also the concept of 'deliberate practice'.
  • helped improve the cooperation within the team
  • Great!
  • I want more Dojos


Tests as specifications

The other day I was doing the yahtzee kata in C in CyberDojo and I got caught (not for the first time) by a classic gotcha...

I wrote my tests very very simply as follows:


...
static void two_pairs_scored_as_one_pair_is_spots_on_highest_pair(void)
{
    assert(...);
}

static void full_house_scored_as_one_pair_is_spots_on_the_pair(void)
{
    assert(...);
}
...

typedef void test(void);

static test * tests[] =
{
    two_pairs_scored_as_one_pair_is_spots_on_highest_pair,
    full_house_scored_as_one_pair_is_spots_on_the_pair,
    ...,
    NULL,
};

int main(void)
{
    for (int at = 0; tests[at] != NULL; at++)
        tests[at]();
    return 0;
}


I wrote another test and hit the Run-Tests button. But the new test didn't get run because I'd forgotten to add the name of the function to the tests array. Ooops. The new test compiled ok, and I'd tripped up thinking the test was passing when it wasn't even being run.

I've practised in CyberDojo enough that I don't get "sucked into the code" as much as I used to and when something like that happens there's now a fair chance I'll have enough awareness to notice it as it happens.

I stopped and thought about what had happened for a moment and I realized something. My problem was that I was writing the test function definition first. I should be writing the name of the test in the tests array first. And only once I've done that should I define it. There is a nice echo of the idea of Test First Design to this.

Of course in a language with reflection you only need to write the test function. Be that as it is, I like the the way the contents of the tests array lists the function names as specifications. In a language with reflection you don't get that.

The Secrets of Consulting

is an excellent book by Jerry Weinberg (isbn 0-0-932633-01-3). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
Consultants deal in change.
Consulting is the art of influencing people at their request.
..there is the problem of balancing certainty now versus uncertainty in the future.
Consultants are less adapted to the present situation, and therefore are potentially more adaptable.
The toughest problems don't come in neatly labelled packages. Or they come in packages with the wrong labels.
The bigness is not the horse.
The true expert can see multiple aspects of a situation, but the novice sees only... whatever is most conspicuous.
We all know that things tend to fall between cracks and that cracks occur at boundaries, where one system joins another.
For a trigger to be effective, the timing must be perfect: Too late means you're already committed to the troublesome action, while too early means you may forget again betwixt the cup and the lip.
There are always opportunities to jiggle.

Six memos for the next millenium

is an excellent book by Italo Calvino (isbn 0-099-73051-0). As usual I'm going to quote from a few pages:
Lightness for me goes with precision and determination, not with vagueness and the haphazard... (One should be light like a bird and not like a feather)...
... even correctness of style is a question of quick adjustment, of agility of both thought and expression.
... each value or virtue I chose as the subject for my lecture does not exclude its opposite.
Poetry is the great enemy of chance, in spite of also being a daughter of chance.
On folio 265 of the Codex Atlanticus, Leonardo begins to jot down evidence to prove a theory of the growth of the earth. After giving examples of buried cities swallowed up by the soil, he goes on to the marine fossils found in the mountains and in particular to certain bones that he supposes must have belonged to an antediluvian sea monster. At this moment his imagination must have been caught by a vision of the immense animal as it was swimming among the waves. At any rate, he turns the page upside down and tries to capture the image of the animal, three times attempting a sentence that will convey all the wonder of that evocation.
It is useless at every circle to invent a new form of metarepresentation.
What tends to emerge from the great novels of the twentieth century is the idea of an open encyclopedia, an adjective that certainly contradicts the noun encyclopedia, which etymologically implies an attempt to exhaust knowledge of the world by enclosing it in a circle.
There is a type of work that, in the attempt to contain everything possible, does not manage to take on a form, to create outlines for itself, and so remains incomplete by its very nature.
... the collection of objects of which only one specimen exists.
The classical author who wrote his tragedy observing a certain number of known rules is freer that the poet who writes down whatever comes into his head and is slave to other rules of which he knows nothing.

Synectics

is an excellent book by William J.J. Gordon (isbn 978-0060324308). As usual I'm going to quote from a few pages:
The word Synectics, from the Greek, means the joining together of different and apparently irrelevant elements.
Abstraction breeds more abstraction and more generality instead of leading to tough yes-no tests.
Words like intuition, empathy, and play are merely names put to complex activities in the hope that the naming of the activity will in fact describe it.
Human beings are heir to a legacy of frozen words and ways of perceiving which wrap their world in comfortable familiarity.
Synectics theory agrees with the conviction that a man does not know even his own science if he knows only it.
"All the crappy solutions in the world have been rationalized by deadlines."
He refused to recognize the fact that his search for the perfect problem was a way of avoiding failure in solving a less perfect one.
Invention is akin to painting for in practice, the element being constructed has the capacity to tell the builder what the next step should be. In invention this is much more critical than in engineering because the inventor is always attempting to do something new.
When this forgetfulness is formalized into a methodology, it reinforces the rejection of the commonplace.
Organic functions are unfinished, cylical, and self-reproductive... Synthetic functions are complete and more obviously subject to decay.
Conventions as abstractions from reality constitute a virtually complete and unassailable pattern, whereas the commonplace is infinitely repatternable.
The child who asks: "What's that funny noise?" is told the noise is thunder in such a way that speculation is supposed to stop... But naming the noise does not describe it. It does not answer the question, it kills it.

Why do car drivers brake?

Recently I wrote a small blog entry Why to cars have brakes? It's getting a lot of hits. Well, a lot for me. So naturally in my quest for even more hits here's a follow up...

Imagine you're in a car. Driving along. Why do you brake? I'm not asking what happens when you press the brake pedal? That's too easy (the car stops). I'm asking why…?


.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Here are two reasons:

Reason one: because there's danger ahead

This corresponds to a failing test. More specifically, it's when a test runs and asserts. A red. Perhaps there's a queue of traffic ahead (often a problem on the orbital car park known as the M25). Perhaps the road is closed off because workmen are working on it. Or maybe the local council has been meddling and the road is now a one-way-but-not-the-way-you-want-to-go road. Whatever the reason, something is not as expected.

Reason two: because you've arrived!

This corresponds to a passing test. A green. Wherever it is you're going, you've got there. Nothing unexpected happened. No traffic queues. No closed off roads. No meddling local council. Incredible!

In my entirely unscientific sampling almost everyone answers with the first reason. The second reason is not nearly as common. I find this interesting. I think maybe it's a reflection of the thinking statically vs thinking dynamically thing again. A perception that tests are most useful when they fire red. That tests which run to completion without incident are not so useful. But they are. Maybe more so.

Brakes help me stop. And stopping implies I'm already moving - I'm already going somewhere. But where? If I don't know where I'm going why am I moving at all? If I don't know where I'm going I'm just as lost as if I don't know where I am.

Tests are useful not just because of the I-didn't-arrive effect when they fail, they're also useful because of the I-did-arrive effect when they pass.

Another reason passing tests are really useful is the elves. But the elves will have to wait for another time.

Peopleware

is an excellent book by Tim Lister and Tom DeMarco (isbn 0-932633-43-9). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
Development is inherently different from production.
Most organizations don't set out consciously to kill teams. They just act that way.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted. [Tajima and Matsubara]
The manager's function is not to make people work, but to make it possible for people to work.
The trick isn't in the technology; it's in the changing of habits.
An age-old pattern of interior space is one that has a smooth "intimacy gradient" as you move toward the interior.
Employee turnover costs about twenty percent of all manpower expense. But that's only the visible cost of turnover. There's an ugly invisible cost that can be far worse.
It's only the right to be wrong that makes you free.
The structure of a team is a network, not a hierarchy.
Everyone quickly understands that the presence of the posters is a sure sign of the absence of hard work and talent.
The more you improve the way you go about your work, the harder the work will be.
The manager of a large project in Minneapolis has refused to move his people to the new quarters. ("New in this case just meant smaller and noisier.) Administrators were simply stunned at his refusal; they had never considered the possibility.

Just one more thing

is an excellent book by Peter Falk (isbn 978-0-099-50955-4). As usual I'm going to quote from a few pages
My object is to keep you awake.
I didn't stay in college the full four years. I quit after three months and joined the Merchant Marines. Men with one eye were not drafted and in the Merchant Marines they were not allowed to work on deck or below deck, but they could work in the kitchen. I sailed out as third cook. My specialty was pork chops.
About the third time I was late, even before I hit my seat, LaGallienne froze me with a question: "Why are you always late?" I said I had to drive down from Hartford. She asked coldly, "What do you do there? There are no theatres in Hartford. How do you make a living?" I told the truth. "I'm not an actor." She snapped back "Well you should be, now sit down."
I remember vividly that particular performance when for the first time I was suddenly startled by a new totally unexpected sound - a rich, deep authentic snore. Holy jamolies. There is someone on this stage that is sleeping - really sleeping.
I have never been arrested in the United States but I have been arrested in Paris, Moscow, Havana, Genoa, Belgrade, and Trieste.
Did he want to be buried or cremated? His answer to them was brief - "Surprise me."
"Here and there you'll find a raisin."
I was struck very early by the dramatic possibilities of playing a man who housed within himself two opposite traits.
For me The Princess Bride was a movie without a blemish, perfect for both kids and adults.

An Introduction to General Systems Thinking

is an excellent book by Jerry Weinberg (isbn 0-932633-49-8). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
The average scientist is good for at most one revolution.
"Proof" in its original sense was a test applied to substances to determine if they are of satisfactory quality... Over the centuries, the meaning of the word "prove" began to shift, eliminating the negative possibilities...
They know "better" - which is to say that their illusion is stronger.
We drive more slowly at night to give us more time to observe potentially dangerous situations.
More probable states are more likely to be observed than less probable states, unless specific constraints exist to keep them from occurring.
Things we see more frequently are more frequent: 1. because there is some physical reason to favor certain states, or 2. because there is some mental reason.
The Axiom of Experience can, like all of our principles, be turned around, to become a definition of what we mean by the word "like": Two things are alike if one in the present can be substituted for one in the past.
a "boundary" may not be infinitely thin, precisely so it can partake of both system and environment. Rather than separating, such a boundary connects.
We can learn, if nothing else, proper caution in our speech, which will inevitably lead to proper caution in our thought...

Test-driven development for embedded c

is the title of an excellent book by James Grenning (isbn 978-1-93435-662-3). As usual I'm going to quote from a few pages:
A good design is a testable design.
TDD helps you go faster... Slowing down is exactly what is needed to go fast!
Like TDD, if testing is hard, do it all the time - it gets easier.
Test automation is the gift that keeps on giving.
One test result is worth 1,000 expert opinions [Wernher von Braun]
You get a shot of testability with a portability chaser.
If we can identify a particular code smell, we have a better chance of eliminating the bad smell.
Shifting levels of abstraction should happen for a purpose.
Refactoring should be part of everyday development. It's not on the schedule, and you don't ask for permission to refactor.
The industry norm is for code to incrementally worsen with each change. We need to reverse that.
Dual-targetting, like TDD, has another benefit: it influences your design. Paying attention to the boundaries between software and hardware produces more modular designs.

why do cars have brakes?

I don't remember where I was when Kevlin Henney asked me:

Why do cars have brakes?

but I do remember his answer as a definite light-bulb moment. What's your answer?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A very common answer is

to stop

or some variation thereof. In other words, to brake. It reminds me of the noun-verb thing again. Lights light. Irons iron. Compilers compile. Brakes brake. But that was not Kevlin's answer. Kevlin's answer was:

So you can drive faster.

His answer feels paradoxical which usually means there's a deep truth. Brakes allow you to stop when you want. Brakes allow you to stop where you want. Software tests are like brakes. They help you drive faster.

I'm also reminded of the P.W.Bridgman quote at start of chapter 6 of Jerry Weinberg's Introduction to General Systems Thinking:

...it is better to analyze in terms of doings or happenings than in terms of objects or static abstractions.

Thinking about brakes allowing you to stop is thinking statically. Thinking about braking allowing you to drive faster is thinking dynamically.

If you liked this post you might like the follow up Why do car drivers brake?.

A singleton refactoring

Here's a refactoring I often teach. It's particularly applicable if you're wanting to refactor legacy code. I'll show it in C++ in honour of the excellent developers at Promethean.

I'll start with a typical Singleton:

class singleton
{
public:
    static singleton & instance();
    void f(int value);
    int g(const std::string & path);
private:
    singleton();
    ~singleton();
};

Together with typical piece of client client code that I'm wanting to unit-test:

int client::eg1()
{
    stuff();
    more_stuff();
    int r = singleton::instance().g("Hello world");
    return yet_more_stuff(r);
}

My problem is that singleton leads to one or more external dependencies I'd like my unit-tests to bypass. My first step is to create an interface for the singleton:

class singleton_interface
{
public:
    virtual void f(int value) = 0;
    virtual int g(const std::string & path) = 0;
    ...
};

And then make singleton implement the interface. (The saving grace of singleton is that its methods are at least instance methods.)

class singleton : public singleton_interface
{
public:
    static singleton & instance();
    void f(int value);
    int g(const std::string & path);
private:
    singleton();
    ~singleton();
};

Now I can overload eg1 as follows:

int client::eg1(singleton_interface & instance)
{
    stuff();
    more_stuff();
    int r = instance.g("Hello world");
    return yet_more_stuff(r);
}

int client::eg1()
{
    return eg1(singleton::instance());
}

And finally, I can create singleton_interface sub-classes and use them in my unit-tests:

struct my_mock_singleton : singleton_interface
{
    explicit my_mock_singleton(int g_result) 
        : g_result(g_result) 
    {
    }
    void f(int value) 
    {
    }
    int g(const std::string & s) 
    { 
        return g_result; 
    }
    int g_result;
};

void test_client_eg1_hitch_hiker_is_42()
{
    assert(42 == client().eg1(my_mock_singleton(6*9)));
}


Micro refactoring - from here to there

One of my Mastery book snippets from a few days ago reads:

Masters ... are zealots of practice, connoisseurs of the small, incremental step.

I was doing the roman numerals kata in ruby and something related to small incremental steps occurred to me. Here's three tests:

def test_to_roman
  assert_equal "I", to_roman(1)
  assert_equal "II", to_roman(2)
  assert_equal "III", to_roman(3)
end

and here's the first code snippet:

def to_roman(n) 
  roman = ''
  if n == 3
    roman = 'III' 
  end
  if n == 2
    roman = 'II'
  end
  if n == 1
    roman = 'I'
  end
  roman
end

I can refactor these three if statements into a single while statement, in very small steps, as follows:

def to_roman(n) 
  roman = ''
  if n >= 3
    roman += 'I'
    n -= 1
  end
  if n >= 2
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1 
  end
  roman
end

and then:

def to_roman(n) 
  roman = ''
  if n >= 1
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1 
  end
  roman
end

and then:

def to_roman(n) 
  roman = ''
  while n >= 1
    roman += 'I'
    n -= 1
  end
  roman
end

Ok. Now here's the original again:

def to_roman(n) 
  roman = ''
  if n == 3
    roman = 'III'
  end
  if n == 2
    roman = 'II'
  end
  if n == 1
    roman = 'I'
  end
  roman
end

And this time I refactor in a different direction, towards an array lookup:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[3]
  end
  if n == 2
    roman = units[2]
  end
  if n == 1
    roman = units[1]
  end
  roman
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[n]
  end
  if n == 2
    roman = units[n]
  end
  if n == 1
    roman = units[n]
  end
  roman
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[n]
  end
  if n == 2
    roman = units[n]
  end
  if n == 1
    roman = units[n]
  end
  roman
  units[n]
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  units[n]
end

In this case I can refactor from a sequence of if statements in two directions equally easy - towards a while or towards an array lookup. Ok. Now consider the situation if I was starting from a switch instead of a sequence of ifs:

def to_roman(n) 
  case n
  when 3 then 'III'
  when 2 then 'II'
  when 1 then 'I'
  end
end

From this I can easily refactor towards an array lookup but refactoring towards a while is perhaps not quite so straightforward.

I'm suggesting that a construct is useful not just in it's own right but also in relation to all the other constructs it might get refactored to or from. How easily can I move from one construct to another? Do some constructs live only on one-way roads? Do some lead you down more dead-ends than others?

I'm reminded of the family on holiday in the West Country who got thoroughly lost. Spotting a farmer leaning on a gate they stop the car, wind down the window and ask

Excuse me. Can you tell me how to get to Nempnett Thrubwell?

The old farmer looks at them and says

Well.... you don't want to start from here.


Test-gunpowder-pudding driven development

I was rereading chapter 3, Systems and Illusion in Jerry Weinberg's excellent An Introduction to General Systems Thinking yesterday. On page 56-57 Jerry writes:

If I say: "The exception proves the rule" in front of a large class, there will be a division in understanding... Some will believe I have uttered nonsense, while others will understand "The exception puts the rule to the test"

I've read the book four times. I'm a slow learner but this time something clicked and I immediately understood the earlier passage:

...the exception does not prove the rule, it teaches it.

Jerry goes on:

"Proof" in its original sense was "a test applied to substances to determine if they are of satisfactory quality."

I was struck by two thoughts when I read this. One was the parallel with testing. Of a test as a "proof". The other was the word original. I realized that when I hear the word "proof" I have a strong association with its noun meaning rather than its verb meaning. I tend to think of a proof as a finished proof that completely proves something. It's the noun-verb thing I've blogged about before. I wondered if there were any old dictionaries online so I could get a feel for how the generally accepted meaning of the word proof might have changed over time. There is. http://machaut.uchicago.edu/websters has two Webster's dictionaries. The 1828 dictionary came back with:

Proof [noun] 1. Trial; essay; experiment; any effort, process or operation that ascertains truth or fact. Thus the quality of spirit is ascertained by proof; the strength of gun-powder, ...

The 1913 one came back with:

Proof [noun] 1. Any effort, process, or operation designed to establish or discover a fact or truth; an act of testing; a test; a trial.

and a modern dictionary http://www.thefreedictionary.com/proof said:

Proof [noun]. 1. The evidence or argument that compels the mind to accept an assertion as true.

I find the difference fascinating. The 1828 and the 1913 definitions define the noun as the process whereas the modern one defines the noun as the evidence resulting from the process.

Jerry continues:

We retain this meaning in the "proofs" of printing and photography, in the "proof" of whiskey, and in "the proof of the pudding." Over the centuries, the meaning of the word "prove" began to shift, eliminating the negative possibilities to take on an additional sense: "To establish, to demonstrate, or to show truth or genuineness."

At first I didn't understand the bit about "eliminating the negative possibilities". I think it's partly to do with my ITA spelling at school. But I am persistant. Slowly it came to me. The word that did it for me in...

"Proof" in its original sense was "a test applied to substances to determine if they are of satisfactory quality."

...was the word if. To determine if they are of satisfactory quality. The proof was an act. There was the possibility of failure.

I started thinking about the word proof a bit more. I googled the phrase "the proof of the pudding". If you think this phrase is pretty meaningless then you're right - it's a shortened version of:

The proof of the pudding is in the eating.

Again it's about the possibility of failure. It reminds me of the scene in the film The Cat in the Hat (another film Patrick and I love watching) where the Cat has just made some cupcakes (with the amazing kupcake-inator). He tries one and says:

"Yeuch. They're horrible. Who want's some?"

I love that line. I also googled the word proof as related to alcohol content. The history behind the phrase is just wonderful. In the 18th century spirits were graded with gunpowder. Imagine you're buying some spirits. How would you know if an unscrupulous merchant had watered it down? You couldn't tell just by looking. What they did was pour a sample of the solution onto a pinch of gunpowder. If the wet gunpowder could still be ignited then the solution had proved itself. Don't you just love that?

So let's hear it for pudding and for spirits and for gunpowder and for tests. And for the possibility of failure.

The timeless way of building

is an excellent book by Christopher Alexander (isbn 0-19-502402-8). As usual I'm going to quote from a few pages:
A thing which has the quality without a name never fit any image exactly. What is exact is its adaptation to the forces which are in it.
The fact is that the elements themselves are patterns of relationships.
Any thing which lives can only be achieved as the end product of a process, whose force takes over and replaces the willful act of creation.
The mastery of what is made does not lie in the depths of some impenetrable ego; it lies, instead, in the simple mastery of the steps in the process, and in the definition of those steps.
How does the pattern language, which exists behind this flux, steer it, and enter into it? It hinges on the close relationship between the process of creation and the process of repair.
As in the organism, there is no sharp difference between the process of construction and the process of repair. Each process of construction helps repair some larger whole, of which it is merely a part. No thing is whole unto itself.
Within this process, every individual act of building is a process in which space gets differentiated. It is not a process of addition, in which pre-formed parts are combined to create a whole: but a process of unfolding, like the evolution of an embryo, in which the whole precedes its parts, and actually gives birth to them, by splitting.
The form of the whole, and the parts, come into being simultaneously.
This can only happen if the design is represented in an utterly fluid medium; it cannot happen in any medium where there is even the slightest resistance to change.
No building is ever perfect.