Simple and Usable

is an excellent book by Giles Colborne (isbn 0-321-70354-5). As usual I'm going to quote from a few pages:

If you ask people they'll say everything is important and anything is feasible.

We tend to keep things, even when they're broken.

Your first design may seem like a solution, but it's usually just an early definition of the problem you are trying to solve. [Luke Wroblewski]

Broken gets fixed. Shoddy lasts forever. [Jack Moffett]

Feature lists sell so as long customers don't get a chance to use the product.

Mainstreamers want "good enough quickly;" experts want "perfect in as long as it takes."

People prefer to be pilots, not passengers.

"Seven plus or minus two." Many psychologists now believe short-term memory may be rather smaller - perhaps just four items.

Simple organization is about what feels good as you're using the software, not what looks logical in a plan.

Designing simple user experiences often turns out not to be about "How can I make this simple?" but rather "Where should I move the complexity?"

The secret to creating a simple user experience is to shift complexity into the right place, so that each moment feels simple.

Don't try to fill your user's mind with your design.

Nudge

is an excellent book by Richard Thaler and Cass Sunstein (isbn 978-0-141-04001-1). As usual I'm going to quote from a few pages:

School children, like adults, can be greatly influenced by small changes in the context.

There is no such things as a 'neutral design.'

Roughly speaking, losing something makes you twice as miserable as gaining the same same thing makes you happy. In more technical language, people are 'loss averse'... Loss aversion helps produce inertia.

Most teachers know that students tend to sit in the same seats in class, even without a seating chart.

Eating turns out to be one of the most mindless activities we do. Many of us simply eat what is put in front of us.

Social scientists generally find less conformity, in the same basic circumstances as Asch's experiments, when people are asked to give anonymous answers.

On average, those who eat with one other person eat about 35 percent more than they do when they are alone; members of a group of four eat about 75 percent more; those in groups of seven or more eat 96 percent more.

Self-control issues are most likely to arise when choices and their consequences are separated in time.

Even hard problems become easier with practice.

The best way to help Humans improve their performance is to provide feedback.

For most of their time on earth, Humans did not have to worry much about saving for retirement, because most people did not live long enough to have much of a retirement period.

public: footpath

You know you know C++ when you see a sign like this and you think, "there's a colon missing after public."

rules of thumb

don't rush

I don't think I can put it any better than Jerry Weinberg did when I interviewed him:

Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.

As a self-employed software coach/consultant I get to travel a lot and visit a lot of companies. At the best companies there is a palpable sense of not rushing.

think team

Software development is all about collaborative learning. I think one of the weakest points of the Agile Manifesto is it's lack of emphasis on teams. The very first word of the four "X over Y" statements is Individuals :-( XP at least takes a firm step beyond programming as an individual activity by mandating pair programming. I look at Sit Together, a practice from XP1 and I think s/Sit/X/. In other words, whatever X is, X Together.

increase visibility

Software and the process of developing it can be, to paraphrase Douglas Adams, mostly invisible. You think more clearly when you have something concrete to tie your thinking to. You manage things better when you can see them and see them constantly changing. It's no accident that Kanban boards are as popular as they are.

Things are the way they are because they got that way

If you're working on a complex codebase and you're trying to understand the complexity by looking at the codebase then you're looking in the wrong place. That's like the man in Peopleware who loses his keys in a dark street and looks for them in the adjacent street because, as he explains, "the light is better there". A codebase is the way it is because it got that way. Slowly. Over time. If you're looking at the code your looking at the effect and not at the cause. It was the developers that did it!

Things are the way they are because they got that way.

Increase visibility

My sister Alix and I were chatting about work-related stupidity we'd imagined and experienced. Strict quotas on how much time you're allowed for going to the toilet for example. Naturally the time-allowed for no 2's would be longer than the time allowed for no 1s. But how would the managers police the quotas? The answer, we realized, was specialist plumbing. Take out the old copper pipes and put in clear perspex pipes instead. Plumb them through the managers office, at eye level. Purpose built hardware probes, available at reasonable cost, would measure the volume of shit. The probes would wirelessly connect to ShitLogger (tm) an app for monitoring the volume of shit against the quotas. To log the logs, as it were.

Recency

I've written before that:

Human beings have evolved a very strong association that cause and effect are simple and linear; that cause and effect are local in space and time.

One of example of this is when contestants on Who Wants To Be a Millionaire phone a friend. It's easy to think that the friend could simply watch the program and start trying to find the answer before they're called. They can't. What you're watching happened some time in the past. The program is not live.

Another example is this blog! At the recent ACCU conference several people commented on what a fast reader I was. I often blog three or four book snippets in a week. And I am learning to increase my reading speed. And I do read a lot. But it's an illusion. I have a stock of hundreds of books I've already read and all the best bits from them are already marked. I simply take a book from my shelf and blog the best of its best bits as a book snippet. And then put the book onto the ACCU charity book-stall pile.

Bad captcha

I had this yesterday. I doubt any human could read that! As my friend Niklas Bjornerstedt tweeted

captchas are getting so hard to read that only robots will be able to solve them soon

Accu conference charity book stall

Once again a big thanks to everyone at the accu conference who took a book and made a contribution to the two charities - Water Aid and The National Autism Society this year. The total raised was a smidgen under £600 which will be split equally. Thanks also to my son Patrick (he has Aspergers Syndrome) for lending me the safe. And thankyou too to several people who brought some books for the stall during the conference. I plan to repeat the stall again in 2012.

Deliberate practice booklist

Kevlin and I have just finished the accu pre-conference tutorial. A big thankyou to all the participants. The origin of some of the quotes was a little hard to read as the printed handouts were a little small. Here is a list of the books quoted:

• The Fifth Discipline by Peter Senge
• Talent is Overrated by Geoff Colvin
• Surfing the edge of Chaos by Richard Pascale
• Quality Software Management Vol 1: Systems Thinking by Jerry Weinberg
• Authentic Happiness by Martin Seligman
• Implementing Lean Software Development by Mary and Tom Poppendeick
• Switch: How to change things when change is hard by Chip and Dan Heath
• Mindset by Carol Dweck
• The Princess Bride by Bill Goldman
• The Autobiography of Martin Luther King Jr edited by Clayborne Carson

discipline

Back to quotes table-of-contents

From Extreme Programming Explained

XP is a communal software development discipline.

From The Way of the Leader

A person who practices self-discipline and continuously develops his level of skill seldom fails in the long term.

Discipline is not intended to kill character, enthusiasm, and initiative, but to develop them.

From The Road Less Travelled and Beyond

The essence of this discipline of balancing is unlearning and "giving up" something in ourselves in order to consider new information.

All discipline is a form of submission.

From Zen Soup

Discipline is simply a matter of doing what we must, without wasting time or energy worrying whether or not we feel like it.

From The Long Walk to Freedom

I could compensate for lack of natural aptitude with diligence and discipline. I applied this to everything I did.

From Gandhi an Autobiography

Experience has taught me that silence is part of the spiritual discipline of a votary of truth.

From Good to Great

The purpose of bureaucracy is to compensate for incompetence and lack of discipline. Avoid bureaucracy and instead create a culture of discipline.

Feedback

Some feedback quotes from previous blog entries: From Agile development in the large

Quick feedback should be the first thing you introduce.

From What did you say?

We structure our world so we will not receive feedback that threatens our view.

We don't even wait to ignore feedback, but actively take steps to prevent such feedback from ever happening in the first place.

Don't concentrate on giving feedback; concentrate on being congruent - responding to the other person, to yourself, and to the here-and-now situation.

From The dance of life

All societies depend for the stability on feedback from the people. Depersonalization reduces feedback to a minimum, contributing to instability and lowering the overall level of congruence in the society.

From Understanding the professional programmer

Many programmers… work in environments in which they receive essentially no real feedback embodying the consequences of what they do. Lacking no real feedback, they lack the motivation to attempt changes, and they also lack the information needed to make the correct changes.

From Quality Software Management. Vol 2. First-Order Measurement

Software development is not primarily a manufacturing operation for we (ideally) never develop the same software twice. This uniqueness of product means that Deming's "statistical signal" - though necessary - is not sufficient for feedback control, because there often isn't enough repetition - enough stability - to generate meaningful statistics.

From Quality Software Management. Vol 4. Anticipating Change

In a feedback control system it's only our perception that determines which is controller and which is controllee.

From The systems bible

Just calling it "feedback" doesn't mean that it has actually fed back. To speak precisely: It hasn't fed back until the system changes course. Up until that point it's merely sensory input.

From Talent is overrated

Practicing without feedback is like bowling through a curtain that hangs down to knee level. You can work on technique all you like, but if you can't see the effects, two things will happen: You won't get any better, and you'll stop caring.

From the Principles of product development FLOW

Fast local feedback loops prevent the accumulation of variance.

From the Aesthetics of change

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

Context

A road sign. Up a tree. In the middle of a park.

Mozart a biography

is an excellent book by Piero Melograni (isbn 0-226-51961-9). As usual I'm going to quote from a few pages:

Mozart was great (among other reasons) because he knew how to have fun.

Some people believe that music flowed from him almost spontaneously, thanks to his genius. In reality, from earliest childhood he practiced for thousands of hours every year.

He lived only thirty-five years, but he lived them at a wolf's pace and went far in that short time.

In a letter dated 20 August 1763, Leopold Mozart relates that in many places in Germany the well water was so bad, smelly, and muddy that it was habitually mixed with wine. It was worse in Paris. Parisians drank the repugnant water of the Seine, into which the city's garbage was thrown. The Mozarts, like many others, let it settle in a pitcher for a few hours, where it formed a worrisome solid layer.

In a letter dated 1 April 1764 Leopold reported that when an eclipse of the sun had occurred, Parisians rushed into the churches to protect themselves from being poisoned by the air during the temporary disappearance of the sun's light.

Wolfgang fell seriously ill with smallpox. He was blind for nine days and hovered between life and death, for the second time, after his bout with typhus in 1765.

Mozart performed several times on the harpsichord, astonishing his listeners with the agility of his hands, his left hand in particular. Some Neapolitans, perhaps influenced by a culture that tended to superstition and like mysteries. asserted that the boy played as well as he did thanks to a magic ring that he wore. When they demanded that he take off the ring and play without it, they saw that his playing depended on talent rather than spells, and they applauded all the more.

In those days, a composer would not dream of writing the arias for an opera without consulting the singers who were to interpret them… composers were craftsmen, paid by the piece, and were completely subservient to the true superstars of the age, who were the singers.

In those days no one hesitated about applauding in the middle of a work of music.

His fingers were deformed, either because of continual keyboard exercises from childhood on or from arthritis.

Only artists capable of innovation can give a long life to their works. Innovation prompts tension, curiosity, and awe.

complexity

Back to quotes table-of-contents

From The Way of the Leader

Do the essential things well: Be proactive (do through action), Reduce complexity (concentrate effort on the essential things), Seek improvement (get the essential things done better).

From Everyday Heroes of the Quality Movement

Automating complexity is never as effective as removing it.

If you automate without first getting rid of complexity, you cast the complexity in concrete.

From Simplicity

The human brain is a very simple system that is capable of working in a complex way, rather than a complex system.

From Patterns of Software

In the modern era, we have come to favor simplicity over complexity, perfection over imperfection, symmetry over asymmetry, planning over piecemeal growth, and design awards over habitability.

From The Gift of Time

Complexity isn't an attribute; it's a relationship.

From General Principles of System Design

Complexity is a relationship between system and observer.

From The End of Certainty

A nonequilibrium system may evolve spontaneously to a state of increased complexity.

From The Systems Bible

A complex system that works is invariably found to have evolved from a simple system that worked.

From Surfing the Edge of Chaos

Recent study of evolution, both in the natural world and in computer based complex systems, has demonstrated the surprising result that the presence of parasites in a system accelerates evolution dramatically.

From Consilience

Complexity is what interests scientists in the end, not simplicity.

From Adapt - why success always starts with failure

Complexity is a problem only in tightly coupled systems.

From General Principles of Systems Design

There is a tendency for complexity in models to rise as the time between sensing and acting grows.

Photo by Kevin Wong.

Effective leadership masterclass

is an excellent book by John Adair (isbn 0-330-34785-3). As usual I'm going to quote from a few pages:

Every person and thing is only what it is in relation to others. [Lao Tzu]

It is this quality of doing things spontaneously and in an unselfconscious way, without regard to their effects upon other people's perceptions of oneself.

The natural badge of such inner humility towards all things is silence.

I believe the first test of a truly great man is his humility. [John Ruskin]

I cannot hear what you are saying because you are shouting at me. [Zulu proverb]

So many people are loath to make irrevocable decisions, are tepid in their enthusiasms. [Ordway Tead]

I do not say that the men of the 14th Army welcomed difficulties, but they grew to take a fierce pride in overcoming them by determination and ingenuity. [General William Slim]

Change and leadership are closely linked.

Leadership is of the spirit, compounded of personality and vision; its practice is an art. Management is of the mind, more a matter of accurate calculation of statistics, of methods, of time tables, and routine; its practice is a science. [General William Slim]

Leadership is bound up with culture.

As a natural leader, he [Gandhi] led by example - spinning for at least an hour every day.

We'll never survive!

One of the books for the accu charity book stall is my copy of Extreme Programming Explained by Kent Beck (1st edition).
One of the entries in its bibliography is a quote from The Princess Bride.
Buttercup and Westley are about to enter the Fire Swamp and face it's three terrors: the Flame Spurts, the Lightning Sand, and the Rodents Of Unusual Size (R.O.U.S.'s).







Buttercup says to Westley (Kent misquotes slightly here):

We'll never survive

and Westley replies:

Nonsense - you're only saying that because no one ever has.

I just love this line. And I love Kent's idea of putting a film quote in the bibliography. I love that it's in the bibliography in a section called "Attitude". I think Kent is hinting at their courage - that depending on your attitude life can be an adventure. After surviving the flame spurts Westley says to Buttercup:

Well now, that was an adventure.

And a bit further on he says:

The Fire Swap certainly does keep you on your toes.

Just before facing the R.O.U.S.'s Buttercup says:

We'll never survive - we may as well die here.

To which Westley replies:

No. No. We have already succeeded.

I love that line too. (I pretty much love every line of the film.) Again it's about attitude. As they make it out of the fire swamp Buttercup says (almost in disbelief):

We did it.

And Westley says:

Now, was that so terrible?

Attitude.
Caring about yourself.
Caring about others.
Caring about the code.

The nature and art of workmanship

is an excellent book by David Pye (isbn 1-871569-76-1). As usual I'm going to quote from a few pages:

Design is what, for practical purposes, can be conveyed in words and by a drawing: workmanship is what, for practical purposes, can not.

The essential idea is that the quality of the result is continually at risk during the process of making.

The care counts for more than the judgement.

Much of what is ordinarily called skill is simply knowledge.

There is a strong incentive to design only in terms of shapes which are easy to communicate.

No two leaves of the same tree are precisely alike, each is individual: yet every one of them conforms to a recognizable pattern characteristic of the species.

Design - the music of design - depends on the relationships between distinguishable and separable features of things.

It [workmanship] takes over where design stops.

You must not torture your material.

We can have no direct rapport with the nature of any material, but have to judge what it is by looking at the surface. We can never see the thing, the material itself, but only the surface, which our vision, unlike X-rays, will not penetrate.

Forward declaring std::string in C++

One type you can't forward declare in C++ is std::string

class string; // Computer says no

This does not say a lot but what it does say is that string is a class and unfortunately it's not - it's a typedef of basic_string<...>

If I compile a file containing just the line

#include <string>

then g++'s -H flag tells me that pulls in over 100 other header files! Avoiding those #includes might make an appreciable difference to build times in some C++ codebases. You can fake an std::string forward declaration by using a type wrapper. For example:

#ifndef EG_HPP
#define EG_HPP

class fwd_string; // instead of #include <string>

void eg(const fwd_string &); 
// instead of
// void eg(const std::string &);

#endif

Where fwd_string.hpp looks like this:

#ifndef FWD_STRING_HPP
#define FWD_STRING_HPP

#include <string>

class fwd_string
{
public:
    fwd_string();
    fwd_string(const char *);
    fwd_string(const std::string &);
    std::string string;
    ...
};

#endif

You can also use this "type-tunneling" technique to forward declare enums in C. I've never seen this used in anger in an actual codebase. It's just an idea. Caveat emptor.

Accu conference charity book stall

Once again I'm going to give away a load of books at this years ACCU conference. As before I'll choose a charity and ask everyone who takes a book to make a voluntary donation. I've already collected two boxfulls. If you're coming to the conference please consider bringing along some books and contributing them to the stall.

The logic of failure

is an excellent book by Dietrich Dorner (isbn 0-201-47948-6). As usual I'm going to quote from a few pages:

The English psychologist James T. Reason thinks that this kind of error is the result of a general propensity for "similarity matching," that is a tendency to respond to similarities more than differences.

The effectiveness of a measure almost always depends on the context within which the measure is pursued.

A rule such as … is too general to be useful, and measures based on it will be wrong much of the time.

We often overlook time configurations and treat successive steps in a temporal development as individual events.

Go make yourself a plan,
And be a shining light.
Then make yourself a second plan,
For neither will come right.

People look for and find ways to avoid confronting the negative consequences of their actions.

If we never look at the consequences of our behaviour, we can always maintain the illusion of our competence.

The results also support the idea that activity may foster an illusion of competence.

Other investigators report a similar gap between verbal intelligence and performance intelligence and distinguish between "explicit" and "implicit" knowledge.

Mistakes are essential to cognition.

We humans are creatures of the present.

It is impossible to do just one thing alone. Any action in one area affects others.

On becoming a person

is an excellent book by Carl Rogers (isbn 978-1-84529-057-3). As usual I'm going to quote from a few pages:

The first stage… There is an unwillingness to communicate self. Communication is only about externals… He is structure-bound in his manner of experiencing. That is, he reacts "to the situation of now by finding it to be like a past experience and then reacting to that past, feeling it".

The concept of "cure" is entirely inappropriate, since in most of these disorders we are dealing with learned behaviour, not with a disease.

Thus scientific methodology is seen for what it truly is - a way of preventing me from deceiving myself...

It is a type of learning which cannot be taught. The essence of it is the aspect of self-discovery.

Involved in this process of becoming himself is a profound experience of personal choice. He realises that he can choose to continue to hide behind a facade, or that he can take the risks involved in being himself.

He is more open to his feelings of fear and discouragement and pain. He is more open to his feelings of courage and tenderness, and awe.

Such living in the moment mean an absence of rigidity, of tight organisation, of the imposition of structure on experience. It means instead a maximum of adaptability, a discovery of structure in experience, a flowing, changing organisation of self and personality.

The good life is a process, not a state of being. It is a direction, not a destination.

He has changed, but what seems most significant, he has become an integrated process of changingness.

The process involves a shift from incongruence to congruence.

The incongruence between experience and awareness is vividly experienced as it disappears into congruence.

Separation of concerns

Freedom from command and control

is an excellent book by John Seddon (isbn 978-0-9546183-0-8). As usual I'm going to quote from a few pages:

You cannot 'motivate' someone… You can provide conditions in which employees are more likely to be motivated or demotivated, but it is a conceit to believe that managers can motivate people.

There are two jobs: job one to serve the customer and job two to improve the work.

If design is separated from process, work becomes a prescription.

Deming often asserted that knowledge should not be thought of as experience.

The value of knowledge is its use not its collection.

Leadership , in my view, is about influencing.

Some followers of Deming are unhappy with this adaptation [Check,Plan,Do] of his cycle. I believe Deming wrote about 'plan-do-check-act' on the assumption that managers who started at 'plan' were already systems thinkers. He saw 'plan' as 'have an idea based on what you "know"'; 'do' was followed by 'check' to see if the idea was right; finally 'act' meant 'put it in the line'. His model was built on manufacturing, where changes were tested off-line.

Without doubt the most important system condition affecting performance is measurement. It goes hand in hand with command-and-control hierarchical structure.

The first-level manager works with people on the work, not on the people.

Consultants who see culture change as something distinct from the work and, as a corollary, something that can be the subject of an intervention, miss the point. When you change the way work is designed and managed, and make those who do the work the central part of the intervention, the culture changes dramatically as a consequence.

The psychology of computer programming

is an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:
I know I've snippeted this before, but I've read it again and I don't see why a really good book shouldn't get repeat snippets. It was published in 1971. If there's an earlier software-related book still in print I don't know what it is.

We must deal with one other problem, which is important because of a seldom questioned view of programming - a view which this book will spend a great deal of time questioning. That view is that programming is an individual activity.

In the end though, it's their method of learning that distinguishes teams from groups… team members always have a common goal, regardless of the product - the goal of helping each other learn to perform better.

If egoless programming is used, everyone in the group will have the opportunity to examine the work of everyone else at some time, thereby tending to prevent the establishment of strong hierarchy.

The greatest challenge, then, is not creative thinking, but creative communicating: representing our thoughts in a way that other persons - each with a unique style - can understand.

The programming business relies more than any other on unending learning.

The XP question

What can you tell me about XP?

That's the question.

Take a moment to think about it.

What thoughts immediately pop into your head?

What words would you use if I was an alien and you were telling me about XP?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Pair Programming is a common first choice. Also common are Testing (TDD), Refactoring, Collective Ownership. These are all fine things but notice that they're all directly related to the code. Programming the code in pairs, testing the code, refactoring the code, ownership of the code.

When I'm coaching or consulting I often ask the XP question. The overwhelmingly most common replies relate to the technical practices and not to the underlying values. I think that's a shame. I feel my understanding of XP's technical practices became much deeper when I thought about them in the light of XP's values.

Can you name the Four XP Values?
That's what the question is really about.
Can you name one XP Value?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
If you did name a value what was it?
Was it Simplicity or Feedback, the values with a technical aspect?
Or was it Courage or Communication, the values with a stronger social focus?

Reading chapter 7 of Kent's book it's clear to me that the four values are core to XP. Kent writes (my emphasis)...

We need some criteria for telling us if we're going in the right direction... Short term individual goals often conflict with long-term social goals. Societies have learned to deal with this problem by developing shared sets of values... Without these values, humans tend to revert back to their own short-term best interest.

The four values - communication, simplicity, feedback, and courage... tell us how software development should feel.

How you should feel!
Do those words surprise you?
How do you feel about your answer to the XP question?

Bordeaux kanban 1's game

Philippe Launay is an Agile team lead and Coach for AGFA in France.

Phillipe recently organized a Kanban 1's game in Bordeaux after he and Fabrice Aimetti translated the slide-deck into French.

Way to go Phillipe.



Phillipe gave me some great feedback

• printed handouts of the rules on each table.
• instead of story-cards with numbers on why not have story-card with dots on. Instead of a 4 have 4 dots.

He writes:

We really had some fun and we learned a lot. The feedback is very very positive... All attendees, the two observers, and the two organizers are more than satisfied with the result. So again thank you to for providing the game.

It's my pleasure Phillipe. And in case any else is wondering, please feel free to translate the Kanban 1's Game slide-deck if you want to. Just send me an email and I'll collect links in this blog.

Understanding comics - the invisible art

is an excellent book by Scott McCloud (isbn 0-06-097625-X). As usual I'm going to quote from a few pages:

Do you hear what I'm saying? If you do, have your ears checked, because no one said a word.

For now I'm going to examine cartooning as a form of amplification through simplification.

Since cartoons already exists as concepts for the reader, they tend to flow easily through the conceptual territory between panels. Ideas flowing into one another seamlessly.

These first symbols - cartoons really - gradually evolved away from any resemblance to their subject, toward the highly abstracted forms of modern languages… and eventually to our totally abstract sound-based system.

The longer any form of art or communication exists, the more symbols it accumulates.

In this chapter, we've dealt with the invisible worlds of senses and emotions, but in fact all aspects of comics show it to be an art of the invisible.

The more an artist devotes him/herself to either of these two focal points (form and idea/purpose), the more dramatic the change if he/she decides to switch.

Symbols are the stuff of which gods are made.

All media of communication are a by-product of our sad inability to communicate directly from mind to mind. Sad, of course, because nearly all problems in human history stem from that inability.

The wall of ignorance that prevents so many human beings from seeing each other clearly can only be breached by communication. And communication is only effective when we understand the forms that communication can take.

The C Standard

is an excellent book (isbn 0-470-84573-2). As usual I'm going to quote from a few pages:

Except when it is the operand of the sizeof operator, the unary & operator, the ++ operator, the -- operator, or the left operand of the . operator or an assignment operator an value that does not have an array type is converted to the value stored in the designated object (and is no longer an lvalue). (6.3.2.1 Lvalues, arrays, and function designators)

object: region of data storage in the execution environment, the contents of which can represent values. (3.14 Terms, definitions, and symbols)

Between the previous and next sequence points an object shall have its stored value modified at most once by the evaluation of an expression. (6.5 Expressions)

At certain specified sequence points, al side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (5.1.2.3 Program execution)

If a "shall" or "shall not" requirement that appears outside of a constraint is violated, the behaviour is undefined. (4. Conformance)

A conforming program is one that is acceptable to a conforming implementation. (4. Conformance)

implementation: particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment. (3.12 Terms, definitions, and symbols)

A full expression is an expression that is not part of another expression or declarator… The end of a full expression is a sequence point. (6.8 Statements and blocks)

The Pragmatic Programmer

is an excellent book by Andrew Hunt and Dave Thomas (isbn 0-201-61622-X). As usual I'm going to quote from a few pages:

A very simple but particularly effective technique for finding the cause of a problem is simply to explain it to someone else.

Fred doesn't know why the code is failing because he didn't know why it worked in the first place.

Chips are designed to be tested.

Design to Test.

Abstractions live longer than details.

Some things are better done than described.

Don't give in to the false authority of a method.

Test Early. Test Often. Test Automatically.

Organize around functionality, not job functions.

When woodworkers begin a project, they cut the longest pieces first, then cut the smaller pieces out of the remaining wood.

The Law of Demeter for functions states that any method of an object should call only methods belonging to: itself, any parameters that were passed in to the method, any objects it creates, and directly held component objects.

courage

I've been thinking about courage. Scott Peck writes:

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.

Courage is one of the 4 values of eXtreme Programming. I was struck by how every mention of courage in Kent's book, and also during a short googling session, has a technical rather than a social slant to it:

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

It's sometimes said that Scrum is very good at surfacing problems, making problems visible, and that if we don't deal with these problems it's not Scrum that's failed it's us. Moments of social tension are exactly like that. Tension surfaces, is felt, but isn't held and openly dealt with, and so slowly sinks out of view.

Problems in software are always a mixture of the technical and the social. I think many developers find it relatively easy to be technically courageous but not so easy to be socially courageous. Being technically courageous but not socially courageous is solving the symptoms but not the root-causes. In every case, if you fail to deal with the underlying causes you create a bad self-fulfilling dynamic.

Courage relates to trust. Holding the issue and not letting it sink away feels risky. But if you never take any risks you're not likely to create any trust. Acting when you feel a little scared is what courage is.

Courage relates to congruence. Congruence is about alignment. If you feel X, it's ok to say that you feel X, to sound like you feel X, and to look like you feel X.

Moments of fear can be precious moments. They can become moments of courage.

My Kanban 1s Game

Update! I've now created a Kanban Board Game around this idea.

Here's the latest slide-deck for my kanban 1s game. Based on feedback from several recent sessions I've changed two features:

• Backlog It now costs 1 unit of work to create a backlog item. Also a worker on any table can create a backlog item at any time.
• Bugs There's now a much simpler way of simulating bugs - simply lose all the current work on the story-card.

Jon Jagger's Kanban 1s Game

extreme Programming explained

is an excellent book by Kent Beck (isbn 0-201-61641-6). As usual I'm going to quote from a few pages:

Without courage, XP just simply doesn't work.

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

Pair programming works for XP because it encourages communication… In my experience, pair programming is more productive than dividing the work between two programmers and then integrating the results.

If people program solo they are more likely to make mistakes, more likely to overdesign, and more likely to blow off the other practises, particularly under pressure.

There are times when problems simply can't be solved by the emergent brilliance of the team, encouraged by a loving and watchful manager. At times like this, the XP manager must be comfortable stepping in, making decisions - even unpopular ones - and seeing the consequences through to the end.

XP is a communal software development discipline.

The best environment is one of mutual trust.

Under stress, people revert to earlier behaviour, no matter how badly that behaviour has worked in the past.

Today's design should be done today and tomorrow's design should be done tomorrow.

Nerds aren't generally good at talking.

When you say one thing and do another, bad things happen. This book [Gerald Weinberg, Quality Software Management: Volume 4(sic), Congruent Action] talks about how to be congruent yourself, how to recognise incongruence in others, and what to do about it.

The Trusted Advisor

is an excellent book by David Maister, Charles Green, and Robert Galford (isbn 978-0-7432-0776-8). As usual I'm going to quote from a few pages:

Trust frees us from the need to spend time on inconsequential projects or tedious procedural issues.

You must be willing to give in order to get.

Creating trust entails taking some personal risks. It is the essence of trust. If you're not a little scared on occasion, then you're not taking a risk. And if you're not taking a risk, you're not likely to create trust.

Trust is personal… "institutional trust" is an oxymoron.

It is not enough for a professional to be right: An advisor's job is to be helpful.

…they are, above all, looking for someone who will provide reassurance, calm their fears, and inspire confidence.

Excellence in advice giving requires not only the right attitude, but also a careful attention to language.

"I was amazed at how many fools I ran into until I noticed the common denominator in all those interactions: me."

Trust = (Credibility + Reliability + Intimacy) / Self Orientation

Reliability in this largely rational sense is the repeated experience of links between promises and action… Reliability in this emotional sense is the repeated experience of expectations fulfilled.

The most common failure in building trust is the lack of intimacy… Greater intimacy means that fewer subjects are barred from discussion.

The purpose of listening in building trust is to earn the right to engage in a mutual exploration of ideas.

Effective trusted advisors are very good listeners.

DaVinci Decoded

is an excellent book by Michael Gelb (isbn 0-385-33861-9). As usual I'm going to quote from a few pages:

Ritual is the husk of true faith [Lao Tzu]

Poor is the man who desires many things. Neither promise yourself things nor do things if you see that when deprived of them they will cause you material suffering. [Leonardo]

He prided himself on being a uomo sense letter (man without academic training) and a disciepolo della sperienza (disciple of experience).

I shall continue. I never tire of being useful. Obstacles do not bend me. Every obstacle is destroyed through rigour. [Leonardo]

You can have neither greater nor lesser dominion than you have over yourself. [Leonardo]

The average person "looks without seeing, listens without hearing, touches without feeling, eats without tasting, moves without physical awareness, inhales without awareness of odour or fragrance, and talks without thinking." [Leonardo]

Mindfulness is complete attention in the now, rather than worrying about the past or investing in expectations about the future.

The Jewish tradition, for example, teaches that "the key to everything is the way you start."

Fill the space with objects and images that inspire you to remember your connection to something greater than your own ego.

In his anatomical studies, as in everything else he did, Leonardo was always striving for the most all-encompassing type of understanding as well as the most detailed.

Leonardo himself was known to be even-tempered and optimistic, even when life was hard. He was also meticulous in his daily habits of eating, exercising, and resting.

Modern research confirms ambidexterity promotes balance and brain development. Not surprisingly, Leonardo was ambidextrous.

Wisdom of the idiots

is an excellent book by Idries Shah (isbn 0-86304-046-2). As usual I'm going to quote from a few pages:

Different modes of behaviour on the part of the wise are to be regarded as due to differences in individuality, not of quality.

Only stupid people and pedants imagine that their duty is to instruct everyone, when the motive of the people is generally not to seek instruction, but to attract attention.

Words alone do not communicate: there must be something prepared, of which the words are a hint.

When you have found yourself you can have knowledge. Until then you can only have opinions. Opinions are based on habit and what you conceive to be convenient to you. The study of the Way requires self-encounter along the way.

…people spend most of their time either jumping to conclusions or else taking no notice at all of facts.

Perception without wisdom is worse than nothing at all.

How much of my life is being wasted while I wait for someone to tell me what to do or something to happen which will change my condition and frame of mind?

'Alas', said the Sufi, 'there was only one thing wrong with your attempt to apply Sufi methods. You were not a Sufi.'

The assumption that anyone of worth can explain himself fully and lucidly in the time allotted him by those who want to learn what he knows - is either a joke or a stupidity.

It is learnt by means of practice. If you cannot practice it, you cannot learn it. If you cannot learn it, you do not really want to learn it inwardly at all.

A crooked plan will benefit only the crooked, a wise one only the wise.

Wooden on Leadership

is an excellent book by John Wooden and Steve Jamison (isbn 978-0-07-145339-4). As usual I'm going to quote from a few pages:

Effort is the ultimate measure of your success.

I believe leadership itself is largely learned.

In the end, the choice you make makes you.

Genius is nothing but a greater aptitude for patience. [Benjamin Franklin]

Sometimes during practice he would have the guards switch positions with the forwards - have us do the other guy's job. He wanted everybody to understand the requirements of the players in the other position… I was so impressed by the control of his practice. [Gail Goodrich]

There are no big things, only an accumulation of many little things.

What happened is a good lesson in how we can limit ourselves and our organisations without even knowing it - how we can say "no" when we should be asking "how?"

Success breeds satisfaction; satisfaction breeds failure.

Lots of repetition. You can't believe the repetition. [Gary Cunningham]

Things turn out best for those who make the best of how things turn out.

I rarely assigned one player to a basket. Basketball is a team sport, and I felt it was unwise to allow players to practice by themselves. Always I wanted them to be interacting with their teammates.

How you practice is how you "play"… It's only natural for those under your leadership - perhaps even you - to focus on the end result rather than learning and doing what it takes to get there. I attempted to solve this particular problem at UCLA by occasionally removing the siren song; specifically, I made them practice and play basketball without the ball.

A good leader always seeks improvement - always.

Measuring and managing performance in organizations

is an excellent book by Robert Austin (isbn 978-0-932633-36-1). As usual I'm going to quote from a few pages:

When outcomes are revealed so slowly, learning is difficult.

The difficulty of verifying quality is heightened when production activity is largely mental, hence not directly observable, as in many professional settings such as software development.

Empirical work on human motivation (Frey, 1993; Deci and Ryan, 1985, McGraw, 1978) has shown that external motivators often crowd out internal motivation.

Alfie Kohn (1993) observes that measurement connotes comparability which, in turn, fosters competition and even unfriendly feeling between workers, thereby undermining any sense of common purpose.

You manage things, and you lead people. You control things, and you release people. [Ed Tilford]

There is reason to question whether the two intended uses of measurement [motivation and information] can be decoupled in real settings.

W. Edwards Deming, often considered the father of both the Japanese and the American quality movements, has declared performance measurement "the most powerful inhibitor to quality and productivity in the Western world".

Dysfunction's defining characteristic is that the actions leading to it fulfil the letter but not the spirit of stated intentions.

Measured performance trends upward; true performance declines sharply. In this way, the measurement system becomes dysfunctional.

…conclude that no measurement system can be designed to preclude dysfunctional behaviours.

…motivational measurement is, by definition, intended to cause reactions in the people being measured, while informational measurement should be careful not to change the actions of the people being measured.

Russell Ackoff draws a careful distinction between organisms and organisations (concisely paraphrased here by Mason and Swanson): … organisms are comprised of organs that only serve the purpose of the system, whereas organisations are comprised of purposeful subsystems with their own goals.

The quality of a product or service is usually much harder and costlier to measure than its quantity.

If there is a single message that comes from this book, it is that trust, honesty, and good intention are more efficient in many social contexts than verification, guile, and self-interest.

The inclination to interpret control narrowly is due to what might be called a standardisation reflex.

Engineering control does not ordinarily assume self-interested behaviour on the part of components of the control system.

Almost all experts strongly agreed that the primary reason to measure in software development was informational rather than motivational.

do more deliberate practice

This is one of my entries in 97 Things Every Programmer Should Know

Deliberate practice is not simply performing a task. If you ask yourself "Why am I performing this task?" and your answer is "To complete the task," then you're not doing deliberate practice.

You do deliberate practice to improve your ability to perform a task. It's about skill and technique. Deliberate practice means repetition. It means performing the task with the aim of increasing your mastery of one or more aspects of the task. It means repeating the repetition. Slowly, over and over again. Until you achieve your desired level of mastery. You do deliberate practice to master the task not to complete the task.

The principal aim of paid development is to finish a product whereas the principal aim of deliberate practice is to improve your performance. They are not the same. Ask yourself, how much of your time do you spend developing someone else's product? How much developing yourself?

How much deliberate practice does it take to acquire expertise?

• Peter Norvig writes that "It may be that 10,000 hours [...] is the magic number."
• In Leading Lean Software Development Mary Poppendieck notes that "It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts."

The expertise arrives gradually over time — not all at once in the 10,000th hour! Nevertheless, 10,000 hours is a lot: about 20 hours per week for 10 years. Given this level of commitment you might be worrying that you're just not expert material. You are. Greatness is largely a matter of conscious choice. Your choice. Research over the last two decades has shown the main factor in acquiring expertise is time spent doing deliberate practice. Innate ability is not the main factor.

• Mary: "There is broad consensus among researchers of expert performance that inborn talent does not account for much more than a threshold; you have to have a minimum amount of natural ability to get started in a sport or profession. After that, the people who excel are the ones who work the hardest."

There is little point deliberately practicing something you are already an expert at. Deliberate practice means practicing something you are not good at.

• Peter: "The key [to developing expertise] is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes."
• Mary: "Deliberate practice does not mean doing what you are good at; it means challenging yourself, doing what you are not good at. So it's not necessarily fun."

Deliberate practice is about learning. About learning that changes you; learning that changes your behavior. Good luck.


This blog entry is "syndicated" in Croatia on agile.hr