the psychology of computer programming

is an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:
I've read this book twice before, once here, and again here.

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.

Now that hardware has grown cheaper whilst labor has grown more expensive, group members are much less likely to share a machine and system than there were years ago.

The requirement to develop capability cannot be met adequately by a single person. We learn much faster and much better with the active cooperation of others.

Has anyone ever thought of asking appplicants whether or not they like programmming?

With adults, however, the barriers to learning have usually become internalized, and the average adult learns very little of left to his own devices.

It is a well-known psychological principle that in order to maximize the rate of learning, the subject must be fed back information on how well or poorly he is doing.

Such companies are sitting ducks for anyone who comes along with a fancy package of promises - and with lots of sitting ducks, can the hunters be far behind?

An increase in salary only motivates for a short time it is the raise, not the salary level which is a symbol of current value.

To a surprising degree, the only time we fail to learn is when there are negative forces set up against it.

Because the machines are rigid, the people who use them must, if they are to be successful, supply more than their share of flexibility.

We are trying to make the machine help people take advantage of the immense psychological resources they have in overcoming their immense psychological shortcomings.

software blending

Here's a story from the book Dr Deming by Rafael Aguayo.

In the early 1950s, American coffee roasters faced a dilemma. The price of coffee beans had risen dramatically, and they were faced with two distasteful choices: either absorb the increased price, partially or totally, hurting profitability; or pass the cost on to their customers and risk losing market share or having customers switch to other beverages.

They came up with an innovative alternative. The coffee roasters' business consists of buying, ageing, roasting, and blending coffee beans to achieve the desired state and smell. Coffee beans, like all agricultural commodities, are highly variable. Two beans can be quite distinct. Even beans picked at the same time from the same tree can be different. A bean picked from the top of the tree, which receives more sunshine, tastes different than a bean from the bottom of the tree.

Blending is a critical part of the process. The leading roaster of the time tried experimenting with different formulations. It found that gradually changing the formulation, substituting lower quality beans, was unnoticeable to the customer. It begins to slowly change the blend. Every two weeks a few more of the less expensive beans were substituted for the heartier, more expensive ones. Most consumers couldn't notice the difference in coffees bought two weeks apart. But if they had tasted, side by side, two batches made six weeks apart, they would have noticed a slight difference.

In effect, the roaster started training customers to accept an inferior blend of coffee. The other roasters noticed what was going on and responded in kind to avoid losing market share. In a few years the American consumer's standards for a decent cup of coffee were radically altered. The managers did their jobs and enjoyed their bonuses. At the time this response was viewed as a triumph of ingenuity. But a funny thing began to happen. Per capita consumption of coffee began a slow but steady decline. The business stopped growing. The roaster that started it all began to experience profitability problems. It is now part of a huge conglomerate and is still experiencing problems in its coffee business. Consumers have discovered gourmet coffees. But ironically, the coffee drunk by Americans during the 1940s was on a par with what we now call gourmet coffees.

Isn't it great! It reminds me of the Fast Food Fallacy from Jerry Weinberg's The Secrets of Computing:

No difference plus no difference plus no difference plus ... eventually equals a clear difference

I emailed the story to Jerry and he replied:

Great story. Even though I've never had a cup of coffee in my life, I can appreciate the dynamic. Indeed, the same dynamic has occurred over and over. I've written about white bread's deterioration - and now we have "gourmet" breads.

And, I suspect, the same thing is now happening in software - gradually lowering the quality of apps, as expectations lower. Then we will have software selling on the basis of freedom from those annoying bugs. Same thing in security, I think.

the power of example

Last week I attended another excellent Jerry Weinberg course in Albuquerque. Here's one of the nuggets I learned. It's related to the famous Solomon Asch social psychology conformity experiment.

In the experiment a group of people are shown two cards. The first card has a single line on it. The second card has three lines on it labelled A,B,C one of which clearly matches the length of the line on the other card (and the other two clearly don't). Only one person in the group is the actual subject and is unaware that the other members of the group are part of the experiment. The experiment measures how likely the subject is to conform to the answer given by everyone else when that answer is clearly the wrong one. The answer is "quite a lot". But that's not what I learned. What I learned about is a variation on that experiment. One where Solomon Asch measured how the effect varied depending on how many other people's answers matched, or didn't match, the subject's answer. You can read about this variation (and some others) here. This is the punchline:

The presence of a [single] supporting partner depleted the majority of much of its power. Its pressure on the dissenting individual was reduced to one fourth: that is, subjects answered incorrectly only one fourth as often as under the pressure of a unanimous majority.

Isn't that a great example of the power of setting an example. Of how change happens one person at a time. Of courage. Of how important it is that people feel safe. People are always more impressed by the power of our example than by the example of our power.

more secrets of consulting

is an excellent book by Jerry Weinberg (isbn 978-0932633521). As usual I'm going to quote from a few pages:

Consultants are hired for knowing what others don't know, so a consultant who stops learning soon decays in value.

It's always better to be a do-something rather than a know-everything.

The Wishing Wand reminds me of the ability to ask for what I want, and if necessary, to live with not getting it.

Modern psychology often scorns introspection and has become the study of other people's behaviour.

I personally think that big changes result from an accumulation of small changes.

Incongruence is stereotyped behaviour.

It takes big balance to learn small balance.

Nothing is immutably programmined into my mind - except its programmability. The ability of my mind to program itself is a far greater ability than any particular program.

Fear is one of the brakes on creativity.

In social engineering, as in all engineering, failures teach more than successes.

Understanding the professional programmer

is an excellent book by Jerry Weinberg (isbn 0-932633-09-9) (I've blogged a snippet review of it before.) As usual I'm going to quote from a few pages:

In the past, we depended on meetings because little was written down.

There are very few ways to measure the quality of a programmer's work unless you are a competent programmer yourself.

How do I work on those aspects of my own personality and problem-solving approach that are so personal I can't even see them, even though they may be the most important factor in my effectiveness as a programmer?

The next generation will come when we outgrow our adolescent fascination with toys and develop an adult interest in people.

I believe the first manager failed because she thought that to manage change you must interact directly with the employee.

If you want people to change what they're doing, make sure they are fed back the consequences of what they're doing.

90 percent of all illness cures itself - with absolutely no intervention from the doctor.

It's sometimes hard to know when someone is listening - rather than merely waiting to seize control of the conversation. One way everyone knew Mack wasn't listening was by noticing how seldom he allowed other people to finish what they were saying.

The secret to all good writing is re-writing.

Our tests have shown that certain implanted errors take fifteen minutes for one person to find, fifteen hours for another, fifteen seconds for a third. A few more people can't find the error no matter how long they search. This kind of variation hardly forms the basis for estimating.

The situation is hopeless but not serious.

Rules are not made to be broken, but neither are they made to be not broken. Rules are made so that the organization operates more efficiently.

nothing new ever works

Jerry Weinberg's latest blog is a guest entry from me!
It's an email I sent detailing a personal example of his New Law...

Hi Jerry,

I just had a moment of enlightenment about the New Law I wanted to share with you... I was giving Patrick, my son, some calpol (liquid paracetamol - he's ill off school today). The bottle had a new plastic widget in the top. With the bottle there was a new small syringe with a new plunger. This was a new design - instead of simply pouring the calpol onto a teaspoon you clearly had to fill up the syringe. Try as I might I could not get the syringe through the hole in the plastic widget in the neck of the bottle. So was it The New Law - Nothing new ever works?

My beautiful wife Natalie came to my rescue. It did work and she showed me how.

I just re-read The New Law from your book. I noticed that all the examples, the coffee maker, the pills, the car-battery, the car, the hospital procedure were examples where the new thing was genuinely not working. But in my case the new thing WAS working. It was ME that was not working!

From this I have realized that

1) It's easy to think the emphasis in "Nothing New Ever Works" is on the word "new" but it's equally on the word "works"!

2) Something being new is a relationship

3) Something working is a relationship

4) When I say "it's not working" what I always mean is "I can't get it working"

Also, it might give some insight into the question you pose at the end of the New Law...

"Everyone knows that new things never work."

"Then why is everyone obsessed with changing everything for something new?"

"If you answer that, you'll have something worth writing about"

Well, when things go wrong we can look for the cause outside of ourselves, or we can look for the cause inside of ourselves. But, looking for the cause inside of ourselves would mean WE had failed. Which is unthinkable. Therefore the cause must be outside of ourselves. Viz, if it's a choice between changing the world around us, or changing the world inside us, outside wins. And that's one reason why we create new things!

Cheers

Jon

multi-tasking

Many years ago, in a taxi, in Athens, I watched with a mixture of amazement and fear as my driver freed up both hands by steering with his elbows. It was quite an experience!

Multi-tasking is a bad idea when you're doing tasks requiring "immersion". After being interrupted it takes you a long time to get back to where you were. One of the least talked about reasons why pair-programming can be so effective is that a pair seems to be much more resilient to interruptions than an individual. In other words, yet again, pair-programming is partly about programming, but it's mostly about the pairing.

Jerry Weinberg observed that if you have two task to choose from you don't in fact have two tasks to choose from. You have three. Your third task is deciding which of the other two tasks you should tackle!

Recently, on a train, a man sitting opposite me was reading The Telegraph. An article on the front page about multi-tasking caught my eye. It quoted some research by Professor David Strayer from the University of Utah. It said multi-taskers often end up juggling activities not because they are good at it, but because they are easily distracted and cannot concentrate on the job at hand. And in contrast, the most efficient multi-tasker is the person least likely to do so because they can focus on one thing at a time. The implication is that someone who claims to be good at multi-tasking probably isn't!

Perfect Software and other illusions about testing

is the title of an excellent book by Jerry Weinberg. As usual I'm going to quote from a few pages:

Testing a system is a process of gathering information with the intent that the information could be used for some purpose.

Without a process that includes regular technical reviews, no project will rise above mediocrity, no matter how good its machine-testing process.

At least half your testing costs can be cut before anybody ever runs a test, if only your systems are designed with testability in mind.

"We absolutely need this software in place twenty-four weeks from tomorrow. We need two weeks to staff up and get approvals. Then we'll need four weeks for requirements, four weeks for architecture. four weeks for design, and eight weeks for coding. That adds up to twenty-two weeks, so we'll have two weeks left for testing."

If you have ten kilograms of pure uranium-235 and you add another ten kilograms, you'll have twenty kilograms. But if you do this a few more times, you won't have fifty kilograms, you'll have a nuclear explosion. One plus one doesn't always equal two.

The more bugs you find, the more you're going to find, not the other way around.

The human mind craves meaning. If you feed people a random bit of data, they'll struggle to divine meaning from it - and they'll move from the intake phase to the meaning phase so fast they won't be aware of doing so.

You have to know what you're expecting before you give meaning to a test report, otherwise everything looks or sounds right. That's why I'm a strong advocate of the test-first philosophy, whereby developers write their tests to include expected results before they write a line of code. It's what we did fifty years ago, but the practice was gradually lost when industry trends separated testing from development.
That separation occurred initially because it's psychologically difficult for people to test their own programs. There's still significant risk if you rely on test-first without pair-programming or some other process that casts more than one pair of eyes, and more than one brain, on a program.

If test-first is a good idea, then significance-first is even better. Why? … if you actually perform even an enormous number of tests, you would likely lose the valuable information among all the worthless crud. The number of tests performed should be as small as possible, but no smaller.

"We didn't have any problems until we started testing. We were right on schedule. Testing screwed up everything."

"What the American public wants in the theatre is a tragedy with a happy ending." [William Dean Howells]

Experiential Learning 3: Simulation

is an excellent book by Jerry Weinberg. There's no isbn - you can buy it from Leanpub. As usual I'm going to quote from a few pages:

Would be writers commonly trap themselves by speaking their stories, rather than writing them.

The essential principle of the fieldstone method is "energy".

In a few days we can raise the participants' level of both creating and reviewing, which are the yin and yang of such creative work.

Really, the possibilities are endless, so there's never an excuse for saying you can't think of an experiential exercise.

If they cannot overcome their feelings that the simulation is "silly", then that is an important perception which we'll want to examine during the invention.

A simulation doesn't have to be "real" to be successful as an experiential learning too. What has to be real the feelings it stimulates in the participants, for feelings are what drive learning.

Paradoxically, realism often interferes directly with learning from a simulation.

Frequently, a VW company will sell a poem without knowing whether they can build it.

"Rules" are frozen solutions. Rules are solutions to yesterday's problem, carried forward to the present, but usually without reference to the problem they were intended to solve. Each rule is really an "if-then" rule, but "if-then" part is seldom stated.

You are not a grader, but a teacher.

Every time you jiggle one of your control points, you're ruining some of the teaching power of the simulation. Why? Because you're simulating a universe in which there are powerful hidden gods who control the world.

nothing new ever works

I'm having a new bathroom put in at the moment. The plumber was here doing some plumbing. Then the tiler was doing some tiling. He proudly mentioned that he had a new van. When he said that I thought of the New Law from Jerry Weinberg's The Secrets of Consulting

Nothing new ever works

Then he says he has to go out to get something. He says he'll only be half an hour. Ninety minutes later he's still not back. For a moment I start to think negative thoughts about the stereotype of an unreliable workman. Then I remember his new van. Sure enough, he turns up a few minutes later and he's fallen foul of the New Law. His new van had got a puncture, and being the first one it had taken him ages to change the wheel.

Quality Software ManagementVol 4. Anticipating Change

is an excellent book by Jerry Weinberg (isbn 0-932633-32-3). This is the second (or is it third?) snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

Ultimately what helps you most in managing system size is courage and realism.

Without action things will only get less visible over time.

Human systems don't change unless the individuals change, one at a time.

Growth is always non linear.

... the incidence of test failures is directly proportional to the square of the size of the crowd multiplied by the rank of the senior observing official [Augustine's Laws]
The dynamic behind this law is simple: A large crowd of high dignitaries means that the event is planned according to external, not internal, events.

It is easy to look at this diagram and believe that you're seeing a defined process. You're not. What you're seeing is an optical illusion.

"model" is just another name for a guide to anticipating the future.

Cultural changes have a much greater potential impact than process changes because one cultural change - such as driving fear out of the workplace - can affect hundreds of process changes.

Feedback works on continuity. The pieces in the model cannot be too large (or response will be slow), and they must be stable (or response will not be predictable).

Error prone modules are born error prone and stay error prone.

amplify & dampen

You know how sometimes the universe seems to be trying to tell you something? I had one of those experiences the other day. I was looking through my notes from the ALE2011 conference keynote Dave Snowden gave. I wrote

You know things differently in ordered-systems compared to complex-adaptive-systems. In complex adaptive systems you need discipline, you need safe-to-fail probes. You won't know the effect the probes will have. If the probes have a good effect you need to amplify them. If the probes have a bad effect you need to dampen them. Your strategies for amplifying and damping need to be planned ahead of time.

A short while later I was reading Surfing the Edge of Chaos and I came across this on page 93

The olfactory cells, which provide mammals with their sense of smell, delicately tune receptors to dampen out familiar smells and rapidly amplify receptors with new smells. This is the way the brain is alerted to new dangers or opportunities.

There it was again, amplify & dampen. I was sure this was a theme Jerry Weinberg had written about somewhere but try as I might I couldn't track it down. About an hour or so later I spotted a small red notebook on my bookshelf. I hadn't looked at it in over a year but for some reason I decided to pick it up. On the second page I looked at I'd written the following quote from Quality Software Management, vol 3, Congruent Action on page 95

A basic law of perception is that we tend to minimize small differences (tendency toward assimilation) and to exaggerate appreciable differences (tendency toward contrast). Thus, our perceptions make the world more sharply differentiated than it is, and we're a lot more alike than we are different.

the cat in the hat

I've blogged before about how Patrick and I often watch The Princess Bride. Patrick has Asperger's syndrome and loves to watch the same film many times. Many many times. It would be easy for me to not watch a repeat-showing with Patrick on the grounds I'd find it boring. I think that not that many years ago that's exactly what I would have done. But something Jerry Weinberg wrote (in Quality Software Management volume 1 Systems Thinking, page 111) struck a chord with me. He said:

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

So now I challenge myself to watch the film with Patrick (for the umpteenth time) and change the way I react so I don't find it boring. For example, I can specifically look for scenes or lines that I can relate to software development. I've found there will always be some. Here are some from The Cat in The Hat:

For refactoring and continuous-improvement (the song at the end after they've tidied up the mess they made)

I've got to admit it's getting better.

For attitude (after they make the cupcakes which taste disgusting)

They're horrible. Who want's some?

For gratitude (again at the end)

This day has been amazing. Thank you.

For pair-programming! (when they're in the car)

Two people can't drive at the same time.

For testing! (when they're in the car again)

I think there's something wrong with your brakes. When was the last time you had them checked?

For quick and dirty (which is really slow-and-dirty)

There's no way to explain this to mom.

For QWAN, Quality Without A Name, when they're riding the Mrs KWAN roller-coaster:

Please keep your hands and feet in the KWAN at all times.

It's amazing how what you see changes when you change how you look.

Cause is effect and effect is cause and vice versa

Defects cause lateness.

The more defects code has the more time and effort it takes to get it to done. This seems a self-evident truth. But beware! The Causation Fallacy says it is not easy to know what is cause and what is effect. If a feature misses its deadline pressure often builds to ensure it doesn't miss the next deadline. And under pressure people don't think faster. Extra pressure usually increases the likelihood of defects. This suggests

Lateness causes defects.

So do defects cause lateness, or does lateness cause defects? Or do they rotate around each other like partners on a dance floor?

6000 degree-minutes

If you use the same recipe you get the same bread.

That's the White Bread Warning from Jerry Weinberg's truly excellent The Secrets of Consulting.

I was thinking about that the other day and I realized something important. I realized that when I read the word recipe I thought about the ingredients but not really about the non-ingredient related instructions in the recipe. About time. A recipe doesn't just tell you what to mix with what, and in what order, it tells you how long to apply heat. And how much heat. These two things matter just as much as the ingredients. If you change the ingredients you'll get different bread. But if you change the time or the amount of heat you'll also get different bread. Although it might not look much like bread.

Suppose the recipe says to heat the oven to 200 degrees and then cook for 30 minutes. That's 6000 degree-minutes. Now 1200 degrees for 5 minutes is also 6000 degree-minutes. But the bread will be predictably black. Similarly 1 degree for 6000 minutes is also 6000 degree-minutes. But the bread will still be ingredients. Or rather it won't. You see 6000 minutes is 100 hours. Which is 4 days as near as makes no difference. That matters because ingredients are organic. They have a shelf life. A sell-by/eat-by expiry date. They decay. And even if baking the ingredients for 4 days at 1 degree did produce something vaguely bread-like the extra time would create extra cost. In lots of ways. Extra time does that.

Quality Software ManagementVol 3. Congruent Action

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-28-5). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

Management is the number one random process element.

If you cannot manage yourself you have no business managing others.

Congruent behaviours are not stereotyped behaviours - quite the contrary. Congruent behaviours are original, specific behaviours that fit the context, other, and self, as required by the Law of Requisite Variety.

Congruence is contagious.

It takes a long time and a lot of hard practice to raise your congruence batting average.

A basic law of perception is that we tend to minimise small differences (tendency toward assimilation) and to exaggerate appreciable differences (tendency toward contrast). Thus, our perceptions make the world more sharply differentiated than it is, and we're a lot more alike than we are different.

The simplest idea about curing addiction is to stop the use of X, under the belief that X causes addiction. X does not cause the addiction, the addiction dynamic causes the addiction.

To change the addiction you'll have to use something more powerful than logic.

One of the manager's primary jobs is to set the context in which interactions takes place and work is accomplished.

Management sets the context almost exclusively through the use of language.

Culture makes language, then language makes culture.

In all Steering (Pattern 3) organisations, the team is the fundamental unit of production.

I've learned that there's simply no sense trying to solve software engineering problems, or create software engineering organisations, when I'm not able to be congruent. So I work on that first, and that's what I hope you do, too.

Quality Software ManagementVol 2. First-Order Measurement

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-24-2). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

The update cycle on the project control panel should be scaled to something less than the longest period of time the project can afford to be late.

Large projects always fail when their communication systems fail.

The slowdown of fault removal is a major reason why project times are underestimated.

In the end, it's not the observation that counts, it's the response to the observation. That's why Zen masters teach patience in response.

Culture makes its presence known through patterns that persist over time.

What power corrupts most thoroughly is the ability to make meaning of observations.

Incongruent behaviour is the number one enemy of quality, because it disguises what people truly value.

If you can see it you can review it.

The switch from cost observation to value observation is the strongest indication that an organization has made the transition from Pattern 2 [Routine] to Pattern 3 [Steering].

In my consulting, I frequently talk to managers who seem obsessed with cutting the cost of software or reducing development time, but I seldom find a manager obsessed with improving value.

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

Agile A-Z Keynote

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

An Agile A to Z

View more presentations from JonJagger.

THE Secret of Scrum

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

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

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

Precision Listening

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

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

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

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

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

Hello, Jon Jagger speaking.

Hello, can I speak to Jon Jagger please.

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