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

Toyota kata

is an excellent book by Mike Rother (isbn 978-0-07-163523-3). As usual I'm going to quote from a few pages:
As the field of psychology shows us, with practice, behaviour patterns are changeable, learnable, and reproducible.
The improvement kata does not come to life in an organisation simply because it is a good idea.
In many cases the normal operating condition of an organisation - its nature - is not improving.
A process will tend to erode no matter what… A process is either slipping back or being improved, and the best and perhaps only way to prevent slipping back is to keep trying to move forward, even if only in small steps.
Ideally we would utilise the human intellect of everyone in the organisation to move it beyond forces of natural selection and make it consciously adaptive… At Toyota, improvement and adaptation are systematic and the method is a fundamental component of every task performed, not an add-on or a special initiative.
At Toyota, improving and managing are one and the same.
Systems theory tells us that we cannot optimise a system by trying to maximise its individual parts.
If the prevailing philosophy is to "make production", then the first process with four operators seems preferable. This process can work around problems and still make the target output, which is why you find this kind of arrangement on so many shop floors. On the other hand, at Toyota this sort of flexibility is considered negative, since problems go unresolved and the process gets into a nonimproving, firefighting cycle… A 1x1 is not just part of the ideal state condition, it is also a means for helping to get there.
The "Forrester effect"… any unevenness in assembly is increasingly amplified as the demand is transmitted to upstream processes.
Just introducing a kanban system by itself will improve very little; the system only mirrors and sheds light on the current situation.
Engineers, for example, often try to define target conditions in terms of solutions… You have to learn to hold yourself back and first define where you want to go before you get started on moving there.
It matters more that you take a step than what the first step is.
What we are actually doing with a plan is making a prediction.
We learn from failures because they reveal boundaries in our system's current capability and horizons in our minds.
Thinking that an abnormality or problem is neither positive or negative shifts the focus from the individual to the process.
Consider for example, the dieting quote, "I got fat slowly, then suddenly."
It is not possible to objectively assess one's own performance and see what skills you need to work on.
Observe, don't interview.
Everyone at Toyota has a mentor.
An organisation's intentionally cultivated behaviour patterns are a fragile thing.
You cannot reorganise your way to continuous improvement and adaptiveness… It surprises many people, in fact, to find that Toyota is largely organised in a traditional, functional-department style…Repeated practice - conditioning - creates neural pathways and, over time, an organisation's culture.
What is your improvement kata?

97 things every programmer should know

is an excellent book edited by Kevlin Henney (isbn 978-0-596-80948-5). As usual I'm going to quote from a few pages:
Pay off technical debt as soon as possible. It would be imprudent to do otherwise. Seb Rose
Users don't think like programmers. Giles Colborne
Comment what the code cannot say, not simply what it does not say. Kevlin Henney
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. Jon Jagger
the Golden Rule of API Design: It's not enough to write tests for an API you develop; you have to write unit tests for code that uses your API. Michael Feathers
Professional programming is usually not like running hard for a few kilometres, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. Olve Maudal
What are you working on right now? Is it all needed? Pete Goodliffe
By making sure that the build is always clean, I will not have to decide that a warning is irrelevant every time I encounter it. Ignoring things is mental work, and I need to get rid of all the unnecessary mental work I can. Johannes Brodwall
An estimate is an approximate calculation or judgement of the value, number, quantity, or extent of something… A target is a statement of a desirable business objective… A commitment is a promise to deliver specified functionality at a certain level of quality by a certain date or event… Giovanni Asproni
If your project is apparently on track, and one week later it's six months late, you have problems - the biggest of which is probably not that it's six months late, but the invisibility force fields powerful enough to hide six months of lateness! Lack of visible progress is synonymous with lack of progress. Jon Jagger
Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard. Burt Hufnagel
The Singleton Pattern… What's not to like about this classic design pattern? Quite a lot, it turns out. Sam Saariste

The C Programming Language

is an excellent book by Dennis Ritchie and Brian Kernighan (isbn 0131103628). As usual I'm going to quote from a few pages:
C provides no operations to deal directly with composite objects.
Any characters between /* and */ are ignored by the compiler; they may be used freely to make a program easier to understand.
The precision of both int and float depends on the particular machine you are using.
Individual statements are terminated by semicolons.
Statements controlled by the while are indented by one tab stop so you can see at a glance what statements are inside the loop.
We recommend writing one statement per line, and (usually) leaving blanks around operators.
It's bad practice to bury "magic numbers" like 300 and 20 in a program; they convey little information to someone who might have to read the program later, and they are hard to change in a systematic way.
Nesting an assignment in a test is one of the places where C permits a valuable conciseness. (It's possible to get carried away and create impenetrable code, though, a tendency that we will try to curb.)
Expressions connected by && or || are evaluated left to right, and it is guaranteed that evaluation will stop as soon as the truth or falsehood is known.
Array subscripts always start at zero in C.
A function provides a convenient way to encapsulate some computation in a black box, which can then be used without worrying about its innards… C is designed to make the use of functions easy, convenient and efficient; you will often see a function only a few lines long called only once, just because it clarifies some piece of code.
You should note that we are using the words declaration and definition carefully when we refer to external variables in this section. "Definition" refers to the place where the variable is actually created or assigned storage; "declaration" refers to places where the nature of the variable is stated but no storage is allocated.
The evaluation order is not specified for associative and commutative operators like * and +; the compiler may rearrange a parenthesized computation involving one of these. Thus a+(b+c) can be evaluated as (a+b)+c. This rarely makes any difference, but if a particular order is required, explicit temporary variables must be used.

TDD == PDCA



It's no doubt completely obvious to everyone else but yesterday I was struck by the parallel between Deming's Plan-Do-Check-Act and test-driven-development, in particular test-first-development:

  • Plan - write a failing test (red-grape)
  • Do - write code to make it pass
  • Check - run the test to see if it passes (green-grape?)
  • Act - what was the outcome? what will you do now?
The photo of PDCA is from page 143 of Toyota Kata by Mike Rother.

No abstraction



Years ago, when my children were still at primary school I was asked to dress up as santa. I stuffed a few cushions under a big red santa costume, lalloped into the room where all the bright eyed kids were waiting, and after a few ho ho ho's I said

Do you know who I am?

to which one of the kids at the back shouted

You're Patrick's Dad.

Kids are great like that.
They're so direct.
They say it exactly as they see it.

John Seddon's Bristol University talk

This was a very enjoyable talk from a very good speaker. There was quite a lot of overlap with John's 2010 Øredev conference keynote but it was well worth going. There's something about seeing someone speak in person. The occasional thing they've said before suddenly somehow makes more sense.

Here's what I jotted down, in no particular order:
  • MBA - maybe best avoided.
  • If you give it a name [eg Lean] then managers will think it comes in a box.
  • [failure] demand went up. It should have been a signal.
  • Telephone work is not a separate part of the system.
  • Understand the problem - build understanding into the system.
  • Cost is in flow - not in activity.
  • If you measure cost, cost goes up.
  • The only plan is get knowledge.
  • Culture change is free [because] it's a product of the system.
  • Experience is not the same as knowledge.
  • Change is emergent. Don't think 'we can't make a change without a plan'.
  • Trust is not a point of intervention. It's a consequence.
  • You don't learn counter-intuitive ideas in a classroom.
  • Taiichi Ohno - "he never explain".
  • Don't persuade. Make them curious.
Those last three reminded me of the old chestnut about acting your way into a new way of thinking rather than vice-versa. John's point was that if you are trying to teach a counter-intuitive idea (a new way of thinking) then it's probably not such a good idea to start from the current way of thinking. That's trying to cause a big change in someone's behaviour (something counter-intuitive) by persuasion alone. Much better to get them to experience what you want them to experience directly and then they'll start to naturally think differently without any persuasion at all.

John also emphasized that service organizations can change fast because they don't make anything. That made me wonder to what degree his message applies to software-development (in isolation) since software developers very definitely do make something.

Kanban 1's Game Notes

Some notes from Kanban 1's Game's I've played at a few clients sites...

First, some teams have been exploiting the splitting rule. If they have a 4-work-item with 2 bugs on it, they simply split it into a 3-work-item and a 1-work-item and put both bugs onto the 1-work-item and then abandon it, and carry on with the bug-free 3-work-item. They have to check for bugs on the abandoned buggy 1-work-item but otherwise it doesn't affect velocity. This is obvious in hindsight but I hadn't foreseen it. It is amazing how simple rules can create complexity when used in combination. To counteract this I introduce a rule that when you split a work-item into two smaller work-items both new work-items get the bugs. So, for example, if you split a 4-work-item with 2 bugs into a 3-work-item and a 1-work-item, then the 3-work-item and the 1-work-item both get 2 bugs.

Second, the way backlog work-items are created (without any 1's cost), and then moved onto the first table (also without any 1's cost) creates another unintended (from my point of view), but nonetheless very interesting possibility that a few teams have also recently exploited. What they've done is simply created masses and masses of backlog work-items and immediately pulled them all onto the first table. They effectively move the entire backlog onto the first table. The price they pay for this is having to check for bugs on every work-item. Naturally lots of bugs accumulate on the masses of work-items on the first table. However, this does not directly affect the velocity since they can simply any abandon any buggy work-item on the first table and pull in a newly created bug-free backlog work-item at any time.
So I'm currently wondering if it's better to have to pay a 1 to create a backlog work-item and possibly also pay a 1 to move a backlog work-item onto the first table. I think this will be effective for two reasons
  • it simplifies the backlog rules a bit since I can now drop the rule that backlog work-items have to move onto the first table in strict creation order.
  • I can allow 1's thrown from any table to create backlog work-items. This will give players on tables other than table 1 something to do during the early days of the sprint.
It seems clear to me that the game should somehow take into account the total number of bugs on all work-items on all tables. I'm pondering that.

Thirdly, rather than recording the bugs on an index-card paper clipped to the work-item, simply use the paper clips! Two paper-clips on a work item (as in the photo) means two bugs. Much simpler. Again this is obvious in hindsight.

Litter bugs

When my kids were at our local primary school I often used to collect litter on the school run. They've all left primary school now but I still walk to the local shops and post-office and pick up litter on the way. I did post-office walks in successive days recently and decided to collect litter on both days. Normally I wouldn't bother on the second day, since I figure it takes a while for new litter to accumulate. As always when doing something new I discovered something new.


I discovered that on the first day I collected the most obvious litter and on the second day I collected the less obvious litter, which, the day before, had been invisible because it had been hidden by the more obvious litter.


I also discovered that sometimes I see a piece of litter but don't pick up. My monkey mind creates a rational explanation for not picking it up. Perhaps because someone else is walking by. That's a bug - I'm not satisfied with that behaviour. I have resolved to use picking up litter as a discipline-practice. From now on the litter run will only count as successful if I pick up every piece of litter I see. I'm going to use the technique Jerry Weinberg reminded me of when he coached me in a previous blog entry comment. When I see a piece of litter I'm going to say the word litter. That I can easily do. And I'm going to associate saying the word with the action of picking it up.



Nearest exits x 2

As best as I can recall, on every flight I've ever been on, when the safety announcements are made in two languages they are done sequentially. First the whole thing in Norwegian (say) with the accompanying demonstrations; nearest exits, floor lighting, decompression air masks, lifevest strap, lifevest inflation, lifevest whistle, lifevest light, etc. And then the whole thing again in English with the same demonstrations again.


On my little KLM flight from Linköping to Copenhagen it was different. This time the two languages were interleaved. The steward demonstrated the nearest exits whilst the canned audio spoke the appropriate nearest exit words in Dutch, but then rather than moving on to demonstrating the floor lighting (with appropriate floor lighting canned audio in Dutch) he immediately demonstrated the nearest exits again whilst the canned audio spoke the appropriate nearest exits words in English. Nearest exits taken care of, the steward and canned audio moved on to the next topic, floor lighting - again first in Dutch with a demonstration, then in English with the demonstration again. The effect was that even though I don't know Dutch I saw each demonstration twice.



Utility surprises

One of these photos is of the cutlery drawer. I know exactly what it contains: knives, forks, and spoons. Its the cutlery drawer. It's name tells you what to expect when you open it.


The other photo is of.... well it doesn't really have a name in our house - it's just "the drawer" - but it's what Michael McInyre hilariously calls the man-drawer (start at 1 minute 30 seconds). I thought it would be interesting to see what's in it:

  • keys, 15, of which only 4 have a known current use
  • plastic coin bank bags, 5, all empty
  • glue, 4 x super-glue, 2 x glue-stick, 1 x bostik, 3 still usable
  • pens, 4 black, 1 grey, 1 red, a few still usable
  • spanners, 1 x 7/16", 1 x 10mm
  • chalk, 1, yellow, an escapee, we have a chalk box elsewhere
  • radiator bleeding keys, 1 yellow, 1 red, 1 black
  • drill chuck key, so that's where it is!
  • drill bits, 3, I never knew they were there
  • tape, 1 x sellotape, 1 x black electricians - aha, useful, pilfered for fishing
  • paper clips, about 50, loose, box-escapees
  • drawing pins, about 100, loose, box-escapees, be careful when rummaging
  • string, ah yes, would have been handy a few days ago
  • screwdrivers, 1 x 7" blue thin phillips, 3 x 4" watchmakers, plus 3 x 2" from an xmas cracker - never used, put in the drawer simply to keep the other screwdrivers company
  • screws, a few, loose, also keeping the screwdrivers company
  • tape measures, 1 x blue plastic non retractable, 2 x orange metal retractable, 1 x yellow metal retractable, clearly excess tape measures have been purchased when existing ones were temporarily lost
  • matchbox, large, half full
  • electrical lead, black, unknown use


Once you start a "utility" drawer it has an unstoppable force. All things can then be classified as being possibly of utility. It becomes a magnet for all things. If utility-drawers could expand infinitely they would turn into black-holes and consume everything in the known universe.


If you have a utility-drawer, unless it was born very recently in a house you've just moved into, it's almost certain to be completely full. Frequently you can't even close the utility-drawer because it's so full. When this happens a second immutable law kicks in - taking anything out of the utility-drawer is strictly forbidden. Possible work-arounds include brute-force drawer closure, crushing items flat, and jiggling the whole utility-drawer in a kind of simulated-annealing fashion in a vain attempt to get everything to settle down a bit.


Once your utility-drawer is full it will bud out into new forms. For example, I also have a utility-tin (batteries of indeterminate age live here), a utility-folder (instructions for 10 year old appliances live here), and a utility-cabinet (coins from out of circulation currencies live here). Michael would be proud.



Hotel room to train carriage

Appeared in the ACCU magazine CVu, Vol 22, January 2011

Paul has asked me to write something for CVu. I don't have a clear idea of what to write about so I thought instead I would just write about stuff I'm doing. Tonight I'm currently sat in a hotel room in Langley (Berks) after a thoroughly excellent day at a client's site. I've been teaching day one of my C Foundation course. John and Ed suggested some ways the slides, and the words I use to describe the slides, could be improved. So the first thing I've been doing is making some mods to the slides. The first was a simple int to pointer conversion where I initialised an int pointer with the hex integer 0xBEEF. I chose 0xBEEF because it spells a word but didn't think about alignment. 0xBEEF is an odd integer number and the address of an integer is likely to be, at the very least, even. The second was something I said. In the chapter about pointers I said that an invalid pointer doesn't have to be dereferenced for bad things to happen. That's too strong. You only need to think about the free() function to realise that. After you've called free(ptr) then ptr no longer points to an object but as long as you don't dereference ptr you'll be ok. What I should have said is that when you do pointer arithmetic any sub-expressions must always be valid.



Something I try to do regularly is to examine what happened during my day and to learn from it. A sort of retrospective. So I'm looking at the C course mods and wondering what I can learn from them. I'm wondering, in the first example, why I chose 0xBEEF in the first place. Choosing a hex number that spells an english word is overly clever. Overly cute. So now I'm thinking I'd be better off choosing a hex number that doesn't remotely even look like a word. One that would align correctly. I'm struck but how hard it is to avoid being overly clever. By how hard it is to recognise and take into account context. From the second example, I'm reminded how hard it is to say clearly what I'm thinking. Or rather, how difficult it is to have sufficient clarity in my thinking that the words are naturally clear.



As well as learning from the day's mistakes it's also important to think about what went well. I recently did a "60 minutes in the brain of" presentation for SkillsMatter London on deliberate practice (the topic of one of my entries in Kevin's 97 Things Every Programmer Should Know). SkillsMatter videod the talk and I've watched it a couple of times. Watching yourself on video is a tremendously valuable thing. It allows you to see yourself how others see you. Not how you see yourself. For example, something I noticed was a tendency I have to say "ok?" rhetorically at the end of a sentence. Ok? Doing that once or twice is fine but I did it perhaps a dozen times. It was almost becoming a tick. So one of my tasks today was to try not to say "ok?" at the end of my sentences. It's hard to know if I achieved that but I at least feel I didn't say it so often it became a noticeable tick. And I recall a couple of times where I was conscious I had not ended the sentence with "ok?" when previously I might have. But, interestingly, as I write this, I'm thinking how can I know? Perhaps I'm still doing it but don't realise because I can't see myself. So I'm wondering if, tomorrow, I will explicitly ask the guys on the course to tell me if I do it. I think I will. I'm reminded of the line from Robert Burns's Poem To a Louse, "To see oursels as others see is!". I remember Jerry Weinberg mentioning the connection in one of his books. And I notice bagpipe music is playing on my iTunes as I write now. I wonder if my subconscious made the scottish connection? It's the Skye Boat Song (Speed Bonny Boat). My mother used to sing that to me as a bedtime lullaby when I was a small boy.



It's now the next day. I'm on a train heading home. I'm reading some of Weinberg on Writing by Jerry Weinberg. I always carry a book. Usually three. I try to read a lot. Craig Larman once said to me that one of the main things that marks a consultant as a consultant is they read a lot. I have an odd reading habit. I don't read one book from start to finish before starting another book. Instead I read a small chunk from one book, and then put it down, and read another small chunk from another book. I often have about 20 books all partly read. Today the other two are A Little Book of f-Laws by Russell Ackoff and Herbert Addison, and Culture Against Man by Jules Henry. I don't have any fixed rules about switching from one book to another. I just try to sense when it feels right. And I don't have any fixed rules about which books I pop into my travel bags either. It may sound strange but I am trying to cultivate by subconscious so again I just try to sense what feels right. As I'm reading I highlight text that speaks to me. For example, in Jerry's book I've highlighted the following:

  • A trigger is a small amount of input energy that sets off a large amount of output energy.
    That caught my interest. I recall Jerry discussing triggers in some of his other books. So I've made a note to reread what he said about triggers there in the light of that quote. An actual note that is - I also always carry a pen and paper.
  • Raise your typing speed by ten words per minute. This will give you an extra six hundred words for every hour you work. If you work an hour a day, two hundred days a year, you'll type an extra 120,000 words - a couple of books' worth.
    That's quite illuminating.
  • You know, there would be no problem raising kids if only you could throw away the first one.
    That made me laugh.
  • Writer's block is not a disorder in you, the writer. It's a deficiency in your writing methods - the mythology you've swallowed about how works get written - what my friend and sometime coauthor Tom Gilb called your 'mythology'.



It took me a while to find that last one. I knew I had read it but I couldn't find it. I searched in the chapter I read most recently. No luck. I flicked through looking at the marked passages. No luck. Then I stopped and thought about what to do next. (It's almost always better than repeating a failed approach.) I wondered if Tom Gilb had an entry in the index. And he did. And it was exactly the passage I remembered. It was on page 19, not anywhere near the chapter I was reading most recently. And it was a passage I'd marked as I read it. And yet I looked at the marked passages trying to find it. I clearly missed it. That's reminded me that I have a tendency to only see something when searching for it if matches my pre-formed idea of what it will look like. My lovely wife Natalie tells me that's a typical male trait. That last snippet about Tom Gilb has sparked something in my mind. Partly I'm attracted to the word myth because one of my favourite corny jokes is the old chestnut "what is a myth?" the answer being "a female moth". But it's more than that. I think it's because my subconscious is connecting the word mythology with the word methodology. That's an interesting connection. A Mythodology perhaps?



Anway, when I've finished reading a book I copy the bits I highlighted into my personal wiki. Then I copy the dozen or so highlights that speak to me the loudest into a small book "review" snippet for my blog site 'Less Code, More Software'. Then I put the book onto a pile to take to the next accu conference to raise some money for charity. We'll be coming into Taunton any moment now so I'm going to sign off.

The book of five rings

is an excellent book by Miyamoto Musashi, translated by Thomas Cleary (isbn 1-57062-748-7). As usual I'm going to quote from a few pages:
Preface: In common parlance, to do something with a real sword means to do it with utmost earnestness… The Book of Five Rings… explicitly intended to symbolise processes of struggle and mastery in all concerns and walks of life.
The martial way of life practiced by warriors is based on excelling others in anything and everything.
Fourth is the way of the artisan. In terms of the way of the carpenter, this involves skilful construction of all sorts of tools, knowing how to use each tool skilfully, drawing up plans correctly by means of the square and the ruler, making a living by diligent practice of the craft… practice unremittingly.
You should observe reflectively, with overall awareness of the large picture a well as precise attention to small details.
Having attained a principle, one detaches from the principles; thus one has spontaneous independence in the science of martial arts and naturally attains marvels.
As human beings, it is essential for each of us to cultivate and polish our individual path.
Observation and perception are two separate things.
It is essential to be relaxed in body and mind.
If you get to feeling snarled up and are making no progress, you toss your mood away and think in your heart that you are starting everything anew.
In my military science, it is essential that the physical aspect and the mental state both be simple and direct.
Whether in large- or small-scale military science, there is no narrow focus of the vision. As I have already written, by finicky narrowness of focus, you forget about bigger things and get confused, thus letting certain victory escape you.
Things stick in your mind because of being in doubt.
The practice of all the arts is for the purpose of clearing away what is on your mind. In the beginning, you do not know anything, so paradoxically you do not have any questions on your mind. Then, when you get into studies, there is something on your mind and you are obstructed by that. This makes everything difficult to do.


Writing left handed

Tom Gilb lent me a book about Leonardo Da Vinci a few months ago. Inspired by the great artist's ambidexterity (and something I read in Drive by Dan Pink) I've been learning to write left-handed (I'm right handed, ooops I wrote write there at first). At first I practised my alphabet with separated letters. Then with joined up letters. And more and more recently, with joined up words. It's starting to actually look like writing, and feel smooth when I write.

Wit and Wisdom from Poor Richard's Almanac

is an excellent book by Benjamin Franklin (isbn 0-486-40891-4). As usual I'm going to quote from a few pages:
Observe all men; thyself most.
At 20 years of age the Will reigns; at 30 the Wit; at 40 the Judgement.
Laziness travels so slowly that Poverty soon overtakes him.
He that never eats too much will never be lazy.
He that resolves to mend hereafter, resolve not to mend now.
Friendship cannot live with Ceremony, nor without Civility.
Men take more pains to mask than mend. Bad Gains are truly Losses.
A good wife and Health, is a Man's best Wealth.
Buy what thou hast no need of, and e'er long thou shalt sell they necessaries.
He that would catch Fish, must venture his Bait.
Learn to be skilful; He that teaches himself, hath a fool for his master.
Tis easier to suppress the first Desire, than to satisfy all that follow it.
He that would live in peace and at ease, Must not speak all he knows nor judge all he sees.
He that cannot obey, cannot command.

The way of the leader

is an excellent book by Donald Krause (isbn 1-85788-137-0). As usual I'm going to quote from a few pages:
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).
We can never know everything there is to know about a complex process… The knowledge that we really need to optimise a complex process is unknowable. Therefore, we can only approach optimisation a little bit at a time as our understanding grows.
Battles are won by great execution, not by great plans! Great execution can save a mediocre plan; poor execution will always ruin a great plan. [George Patton]
A person who practices self-discipline and continuously develops his level of skill seldom fails in the long term.
Listen carefully. Observe closely.
When the chips are down, the main question is not how you go about meeting your objectives, but whether you succeed in doing so.
For an effective leader, determination is more important than intellect.
Perfection is the enemy of effectiveness.
The art of leadership is an art based on simplicity, and all success is rooted in performance.
Learn by observing the behaviour of other people. If you observe good behaviour, copy it. If you observe bad behaviour, look for the same behaviour in yourself and eliminate it.
There is no surer road to disaster than to fit past solutions, however successful, to current situations.
Discipline is not intended to kill character, enthusiasm, and initiative, but to develop them.
Minimize form and maximise substance.
It is better to be alone than in bad company.
It has been just so in all my inventions. The first step is intuition - and comes with a burst, then difficulties arise... Persistence is the key [Thomas Edison]
Character is a habit. It is created through the daily choice of right and wrong. It is a moral quality which grows gradually to maturity. It does not appear suddenly.