Showing posts with label courage. Show all posts
Showing posts with label courage. Show all posts

a man called Ove

is the title of an excellent book by Fredrik Backman. As usual I'm going to quote from a few pages:
He felt one should not go through life as if everything was exchangeable. As if loyalty was worthless. Nowadays people changed their stuff so often that any expertise in how to make things last was becoming superfluous. Quality: no one cared about that any more. Not Rune or the other neighbours and not those managers in the place where Ove worked. Now everything had to be computerised, as if one couldn't build a house until some consultant in a too-small shirt figured out how to open a laptop.
'They've bumped up the electricity prices again,' he informs her as he gets to his feet. He looks at her for a long time. Finally he puts his hand carefully on the big boulder and caresses it tenderly from side to side, as if touching her cheek. 'I miss you,' he whispers. It's been six months since she died. But Ove still inspects the whole house twice a day to feel the radiators and check that she hasn't sneakily turned up the heating.
'Now you listen to me,' says Ove calmly while he carefully closes the door. 'You've given birth to two children and quite soon you'll be squeezing out a third. You've come here from a land far away and most likely you fled war or persecution and all sorts of other nonsense. You've learned a new language and got yourself an education and you're holding together a family of obvious incompetents. And I'll be damned if I've seen you afraid of a single bloody thing in this world before now.' ...
'I'm not asking for brain surgery. I'm asking you to drive a car. It's got an accelerator, a brake, a clutch. Some of the greatest twits in world history have sorted out how it works. And you will as well.'
And then he utters seven words, which Parvaneh will always remember as the loveliest compliment he'll ever give her.
'Because you are not a complete twit.'
Men like Ove and Rune were from a generation in which one was what one did, not what one talked about.
Ove has probably known all along what he has to do, but all people are time optimists. We always think there's enough time to do things with other people. Time to say things to them. And then something happens and then we stand there holding on to words like 'if'.
'But serious, man. You do this every morning?' Jimmy asks cheerfully.
'Yes, to check if there have been any burglaries.'
'For real? Are there a lot of burglaries round here?'
'There are never a lot of burglaries before the first burglary,' Ove mutters and heads off towards the guest parking.
'There is no hope for these boys and girls,' the headmaster soberly explained in the interview. 'This is not education, this is storage.' Maybe Sonja understood how it felt to be described as such. The vacant position only attracted one applicant, and she got the boys and girls to read Shakespeare.


courage

Back to quotes table-of-contents

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

From eXtreme Programming explained
Communication supports courage because it opens the possibility for more high-risk, high-reward experiments...

Simplicity supports courage because you can afford to be much more courageous with a simple system.

Concrete feedback supports courage because you feel much safer trying radical surgery on the code if you can push a button and see tests turn green at the end (or not, in which case you can throw the code away).

From The Road Less Travelled and Beyond
One thing that never ceases to amaze me is how relatively few people understand what courage is. The absence of fear is not courage; the absence of fear is some kind of brain damage. Courage is the capacity to go ahead in spite of fear, or in spite of pain.

From Quality Software Management. Vol 4. Anticipating Change
Ultimately what helps you most in managing system size is courage and realism.

From The Tao of Pooh
From caring comes courage.

From The Alchemist
"I had to test your courage," the stranger said. "Courage is the quality most essential to understanding the Language of the World."

From We Seven
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]

From The Teachings of Don Juan
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.

From The Conquest of Happiness
Every kind of fear grows worse by not being looked at.

From Mastery
The courage of a master is measured by his or her willingness to surrender. This means surrendering to your teacher and to the demands of your discipline. It also means surrendering your own hard-won proficiency from time to time in order to reach a higher or different level of proficiency.

From Stuka Pilot
Little by little I discover all the tricks. Skill is often the result of getting hurt.

From Existentialism and humanism
What produces cowardice is the act of giving up.

From Zen Bow, Zen Arrow
Gratitude will make you brave.

you need to tell this to our managers

I did a very enjoyable live coding presentation using cyber-dojo at XP Days Ukraine last week. At the start I asked the XP question and, as usual, the audience told me lots about the XP practices (such as pair-programming) but struggled to name the four XP values, and failed to name courage.

On more than one occasion, while consulting or training at a customer's site trying to help explain and convey "an agile mindset", I've been told

you need to tell this to our managers

If I did tell their managers I'm pretty sure I know what would happen.
Can you guess?
Scroll down for my answer.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
I think their managers would say

you need to tell this to our managers

.
.
.
.
.

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.


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]

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

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

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.


viking laws


Several years ago I bought this postcard from Olso airport.

be brave and aggressive

  • be direct
  • grab all opportunities
  • use varying methods of attack
  • be versatile and agile
  • attack one target at a time
  • don't plan everything in detail
  • use top quality weapons

be prepared

  • keep weapons in good shape
  • keep in shape
  • find good battle comrades
  • agree on important points
  • choose one chief

be a good merchant

  • find out what the market needs
  • do not promise what you can't deliver
  • do not demand overpayment
  • arrange things so you can return

keep the camp in order

  • keep things tidy and organized
  • arrange enjoyable activities which strengthen the group
  • make sure everyone does useful work
  • consult all members of the group for advice


stuka pilot

is an excellent book by Hans Ulrich Rudel (isbn 978-1908476876). As usual I'm going to quote from a few pages:
He tells me that a large scale offensive is in preparation in my sector... approximately three hundred tanks are to be employed in this operation... The number three hundred flabbergasts me... I reply that I find some difficulty in believing it... He says to me, half in earnest, half in jest: "If I didn't know you, for two pins I would have you put under arrest for saying such a thing. But we will soon find out." He goes to the telephone and is connected with the Chief of the General Staff. "You have just given the Fuhrer the figure of three hundred tanks for operation X." "Yes I did." "I want to know the names of the divisions concerned with their present strength in tanks. I have somebody with me who is well acquainted with the position." ... the Chief of the General Staff has the bad luck to begin with the 14th armoured division. He says it has sixty tanks. Goering can hardly contain himself. "My man reports that the 14th has one!" A lengthy silence at the other end of the line. "When did he leave the front?" "Four days ago." Again silence. Then "Forty tanks are still on their way to the front. The rest are in repair shops on the line of communications, but will certainly reach their units by zero day, so that the figures are correct." He has the same answer for the other divisions. The Reichsmarschall slams down the receiver in a rage. "That is how it is!" The Fuhrer is given a totally false picture based on incorrect data and is surprised when operations do not have the success expected... The South Eastern zone with its network of communications is being incessantly blanketed by the enemy's bomber formations. Who knows how many of those forty tanks, for example, will ever reach the front or when? Who can say if the repair shops will get their spare parts in time and if they will be able to complete their repairs within the specified time?
In ministries and departments, however, mistakes are denied on principle.
Another confirmation of the truth of our old Stuka maxim: "Nothing comes off - except what you have practised."
We have long since ceased to develop practice from theory; we do just the opposite.
The fitters have their hands full, for the aircraft have been heavily damaged by flak. The life of such an aeroplane will always be limited.
Little by little I discover all the tricks. Skill is often the result of getting hurt.
I now see that perfectly plainly. We are alone to possess this knowledge; the responsibility is ours.


the mind of war

is an excellent book about John Boyd by Grant T. Hammond (isbn 978-1588341785). As usual I'm going to quote from a few pages:
…in order to determine the consistency of any new system we must construct or uncover another system beyond it… One cannot determine the character or nature of a system within itself. Moreover, attempts to do so lead to confusion and disorder.
he was always testing the limits - of airplanes, people, science, the military, and, most especially, bureaucracies.
In dozens of interviews, conducted for this book, the most consistent theme and nearly universal comment was that John Boyd was the essence of an honourable man and incorruptible.
Oral, not written, communication and conviction, not accuracy, still rule in military culture.
Boyd liked putting things together (synthesis) better than analysis (taking things apart)...
He also came to appreciate the routine practice and repetition that was required to become really good at something and to overcome the boredom by focusing on minute improvements.
He observed very carefully.
Boyd could go from 500 knots to stall speed, practically stopping the plane in midair, which would force any aircraft on his tail to overshoot him and thus gain the advantage for Boyd. In another trick, he would stand the F-100 on its tail and slide down the pillar of its own exhaust. Fire would come out of the intake in the nose of the aircraft and the tailpipe simultaneously. A seemingly impossible feat, it was challenged by others. Boyd when to Edwards Air Force Base in California, where NASA had two fully instrumented F-100 aircraft, and demonstrated it and other techniques to a series of nonbelievers. The test pilot at Edwards who challenged him at the time was a fellow by the name of Neil Armstrong.
Boyd had never designed an airplane before, but as he told Colonel Ricci and Gen. Casey Dempsey, "I could fuck up and do better than this."
The rule of thumb in the Air Force is that a plane will gain a pound of weight a day for the life of the aircraft.
High entropy implies a low potential for doing work, a low capacity for taking action or a high degree of confusion or disorder… The tendency is for entropy to increase in a system that is closed or cannot communicate with the external systems or environments.
A natural teacher, he understood that if he told you something, he robbed you of the opportunity to ever truly know it for yourself.
We are never deceived. We only deceive ourselves. [Goethe]
Boyd's dictum: "Ask for my loyalty and I'll give you my honesty. Ask for my honesty and you'll have my loyalty."

Quality Software Management
Vol 4. Anticipating Change

is an excellent book by Jerry Weinberg (isbn 0-932633-32-3). This is the second (or is it third?) snippet review for this book (here's the first). As usual I'm going to quote from a few pages:
Ultimately what helps you most in managing system size is courage and realism.
Without action things will only get less visible over time.
Human systems don't change unless the individuals change, one at a time.
Growth is always non linear.
... the incidence of test failures is directly proportional to the square of the size of the crowd multiplied by the rank of the senior observing official [Augustine's Laws]
The dynamic behind this law is simple: A large crowd of high dignitaries means that the event is planned according to external, not internal, events.
It is easy to look at this diagram and believe that you're seeing a defined process. You're not. What you're seeing is an optical illusion.
"model" is just another name for a guide to anticipating the future.
Cultural changes have a much greater potential impact than process changes because one cultural change - such as driving fear out of the workplace - can affect hundreds of process changes.
Feedback works on continuity. The pieces in the model cannot be too large (or response will be slow), and they must be stable (or response will not be predictable).
Error prone modules are born error prone and stay error prone.

The Tao of Pooh

is an excellent book by Benjamin Hoff (isbn 1-4052-0426-5). As usual I'm going to quote from a few pages:
Cottleston, Cottleston, Cottleston Pie,
A fly can't bird, but a bird can fly.
Ask me a riddle and I reply:
Cottleston, Cottleston, Cottleston Pie.
It is useless to you only because you want to make it into something else and do not use it in its proper way.
One disease, long life; no disease, short life.
Unlike other forms of life, though, people are easily led away from what's right for them, because people have Brain, and Brain can be fooled. Inner Nature, when relied on, cannot be fooled. But many people do not look at it or listen to it, and consequently do not understand themselves very much. Having little understanding of themselves, they have little respect for themselves, and are therefore easily influenced by others.
For a long time they looked at the river beneath them, saying nothing, and the river said nothing too, for it felt very quiet and peaceful on this summer afternoon. [A.A.Milne]
I think therefore I am Confused.
All work and no play makes Backson a dull boy.
"But you should be something Important," I said.
"I am," said Pooh.
"Oh? Doing what?"
"Listening," he said.
the Bisy Backson Society, which practically worships youthful energy, appearance, and attitudes.
It's really fun to go somewhere where they are no timesaving devices because, when you do, you find that you have lots of time.
We are determined to be starved before we are hungry. [Henry David Thoreau]
From caring comes courage [Tao Te Ching]
...too many who think too much and care too little.


The conquest of happiness

is an excellent book by Bertrand Russell (isbn 0415378478). As usual I'm going to quote from a few pages:
It will be found that a quiet life is characteristic of great men, and that their pleasures have not been of the sort that would look exciting to the outward eye. No great achievement is possible without persistent work.
Worry is a form of fear, and all forms of fear produce fatigue.

Every kind of fear grows worse by not being looked at.
More and more it becomes possible to choose our companions on account of congeniality rather than on account of mere propinquity.
Like the heroes of Valhalla who spent every day hunting a certain wild boar, which they killed every evening but which miraculously came to life again in the morning…
Fundamental happiness depends more than anything else upon what may be called a friendly interest in persons and things.

To like many people spontaneously and without effort is perhaps the greatest of all sources of personal happiness.

The secret of happiness is this: let your interests be as wide as possible, and let your reactions to the things and persons that interest you be as far as possible friendly rather than hostile.
The more things a man is interested in, the more opportunities of happiness he has.
Events only become experiences through the interest that we take in them.
In the best kind of affection a man hopes for a new happiness rather than for escape from an old unhappiness.
Work, therefore, is desirable, first and foremost, as a preventive of boredom, for the boredom that a man feels when he is doing necessary though uninteresting work is as nothing in comparison with the boredom that he feels when he has nothing to do with his days.
Two chief elements make work interesting: first, the exercise of skill, and second, construction.

All skilled work can be pleasurable, provided the skill required is either variable or capable of indefinite improvement.
We may distinguish construction from destruction by the following criterion. In construction the initial stage of affairs is comparatively haphazard, while the final state of affairs embodies a purpose; in destruction the reverse is the case: the initial state of affairs embodies a purpose, while the final state of affairs is haphazard.
Destruction is of course necessary very often as a preliminary to subsequent construction; in that case it is part of a whole which is constructive.
Few things are so likely to cure the habit of hatred as the opportunity to do constructive work of an important kind.
I should seek to make young people vividly aware of the past, vividly realising that the future of man will in all likelihood be immeasurably longer than his past, profoundly conscious of the minuteness of the planet upon which we live and of the fact that life on this planet is only a temporary incident; and at the same time with these facts which tend to emphasise the insignificance of the individual I should present quite another set of facts designed to impress upon the mind of the young the greatness of which the individual is capable, and the knowledge that throughout all the depths of stellar space nothing of equal value is known to us.
Happiness must be, for most men and women, an achievement rather than a gift of the gods, and in this achievement effort, both inward and outward, must play a great part.
The only man totally indifferent to power is the man totally indifferent to his fellow-men.
It is better to do nothing than to do harm. Half the useful work in the world consists of combating the harmful work.

sprints, time-boxing, and capacity

A team is doing Scrum with 3 week sprints. Suppose at the end of a sprint they've got nothing to done. What should they do? There's a strong temptation to ask for more time. To make this sprint a 4 week sprint. Most of the work in progress is 90% done, they say. Another week and things will have got to done, they say. It seems reasonable.


Trying to run systems beyond their capacity is not a good idea. In this situation Scrum's fixed-duration time-box constraint has served it's purpose admirably. The problem is not the choice of 3 weeks. Changing 3 weeks into 4 weeks is not addressing the problem. The problem is the team planned to pull in an amount of work and get it to done in 3 weeks. But they're not yet in control of their process - they don't know what their capacity is. They pulled in more than 3 weeks worth of work. Probably a lot more. But we just don't know!


In The Toyota Way, Jeffrey Liker writes:

Taiichi Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes.

Advice from a genius with a lifetime's experience. Toyota manufactures cars. It makes cars. Its production line is an actual line. If manufacturers are prone to overproduction imagine how much more prone software developers are! The things we make are not even physical things. In software, things are mostly invisible. It's difficult to manage what you can't see. In Quality Software Management volume 2, First-Order Measurement, Jerry Weinberg writes:

Without visibility, control is not possible.
If you can't see, you can't steer.

Rather than asking for another week, the team should really be thinking about addressing their real problem. Their real problem is that they're pulling in too much work. They have to somehow learn to pull in less work. So they can start to be in control of their process rather than their process being in control of them.