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:

Information is neutral but people's reactions to information are rarely neutral.

I'm not in the proof business; I'm in the evidence and inference business.

A process description is just that, a description ... not of what has actually been done.

To qualify as a test, an action has to seek information that will influence an action.

Fixing under pressure tends to raise the fault-feedback-ratio.

Anyone who makes promises about the future must be some sort of devil.

Errors are made, not born.

In a moment of weakness it is difficult to resist infantile suggestions.

Good tools amplify effectiveness; if your effectiveness is negative, adding tools will amplify only the negativity.

enums in C

Enums are notoriously weakly typed in C. While pondering this the other day it occurred to me that instead of writing an enum like this:

enum suit { clubs, hearts, diamonds, spades };

you could write it like this:

struct suit
{
    enum { clubs, hearts, diamonds, spades } value;
};

The struct wrapper adds a modicum of type safety. It also allows you to forward declare suit (you can't forward declare enums). The enumerators (clubs, hearts, diamonds, clubs) are still visible and can be used when a compile time value is required (e.g., switch cases). As usual, caveat emptor.

The Mythical Man Month

is the title of an excellent book by Fred Brooks. It's well worth rereading every year or so. As usual I'm going to quote from a few pages:

The accumulation of simultaneous and interacting factors brings slower and slower motion.

Human beings are not accustomed to being perfect and few areas of human activity demand it.

Our estimating techniques fallaciously confuse effort with progress.

No part of the schedule are so thoroughly affected by sequential constraints as component debugging and system test.

Take no small slips... Trim the task.

I will contend that conceptual integrity is the most important consideration in system design.

...the total creative effort involves three distinct phases: architecture, implementation, and realization. It turns out that these can in fact be begun in parallel and proceed simultaneously.

Any software system should be grown by incremental improvement... Nothing in the past decade has so radically changed my own practice, or its effectiveness.

Unless we teach people how to design, the languages matter very little.

The Mythical Man Month is only incidentally about software but primarily about how people in teams make things.

BOSE - today you were RUBBISH

I bought a pair of BOSE noise canceling headphones at Oslo airport on 29th August. My first BOSE purchase. The left earphone has stopped working. I rang the service number and briefly explained the situation. The assistant asked for some information, some of which I'd just told her. She typed into a computer and her computer crashed. She didn't know what to do so she put me on hold. While I waited I replied to a couple of emails, made an entry to my wiki, and started reading from a book. Then she was back. She apologised. She told me that everyone's computer has crashed! She asks me for the information again. I provide it again. She types it in again. It doesn't crash this time!

Then she asks for the serial number. "Where is that?" I say. "What kind of headphones have you bought?" she says. "How can I tell?" I say. It seems you can't tell by looking at them - they have a minimalist design with only the words BOSE on the headphones. "Try looking inside the ear cushion" she says. I can see a number in the left one. I start reading it out. "No that's not it". Eh? You have a serial number in both earphones but only one is the actual one? Are you trying to be rubbish I wonder. So I look in the other ear cushion. Indeed - another number. So long and so small I can't read it. So I put my glasses on and read it out. "Ah" she says that's the such-and-such model. "They're discontinued". Why am I not surprised. She can't do a like for like replacement for that. So they'll replace it with the nearest equivalent. But before they can do that they'll post me an audio cable - could I try the new cable to see if that fixes it? it will be delivered in 5-7 working days, all I have to do is sign for it. If I'm not in when they deliver it they'll put a note through the door so I know which depot to drive to pick them up from. By now I'm losing my patience. I ask if she's really telling me I'm going to have to stay in all day to receive an audio cable that in all probability won't solve my problem and is merely creating extra weeks when I have no working BOSE headphones despite having paid over £200 for them only 2 months ago? And besides that I won't be in anyway since I'll be in another country on business. On business without my BOSE headphones. She says she'll ask someone. I'm on hold again. No, she was wrong. They'll send them regular post. They don't have to be signed for. She's very sorry but there's nothing else she can do. That's what she has to do. I'm so fed up with BOSE at this point I can't face wasting anymore of my time so I tell her to send the damn audio cable.

Do BOSE think that people willing to pay £200 for a supposed quality pair of headphones value their time so little that they're happy to waste even more of it just because the headphones don't work?

BOSE products are expensive. They are pitched as high quality products. My experience today tells me their customer service computers and their customer service process is not high quality. I don't in any way blame the girl on the phone. She's trapped inside a rubbish system, forced to follow rigid procedures like a robot.

BOSE, today you were RUBBISH.

Becoming a Technical Leader

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

Underlying organic models is the fundamental idea of systems thinking: "It is impossible to change just one thing at a time."

Leaders are leaders of change in themselves.

People don't become leaders because they never fail. They become leaders because of the way they react to failure.

If you are a leader, people are your work.

There is no conflict between people and task.

Doing something new heightens awareness, which is stimulating, but also a little uncomfortable.

If you intend to grow you cannot avoid some pain.

Very few of the classic leadership studies have been done in environments even vaguely resembling the technical work situation.

The only way we can see ourselves is through other people. This inability to see ourselves as others see us is the number one obstacle to self-improvement.

Becoming a leader means shifting the focus from your ideas to the ideas of others.

30 Great Systems Thinkers

Systems Thinkers is a book by Magnus Ramage and Karen Shipp which has just caught my eye. The blurb on Amazon says:

Systems Thinkers presents a biographical history of the field of systems thinking, by examining the life and work of thirty of its major thinkers.

Annoyingly it doesn't mention who the 30 people are. A bit of googling reveals the missing information:

Early Cybernetics

• Gregory Bateson
• Norbert Wiener
• Warren McCullough
• Margaret Mead
• W. Ross Ashby

General Systems Theory

• Ludwig von Bertalanffy
• Kenneth Boulding
• Geoffrey Vickers
• Howard Odum

System Dynamics

• Jay Forrester
• Donella Meadows
• Peter Senge

Soft and Critical Systems

• C. West Churchman
• Russell Ackoff
• Peter Checkland
• Werner Ulrich
• Michael Jackson

Later Cybernetics

• Heinz von Foerster
• Stafford Beer
• Humberto Maturana
• Niklas Luhmann
• Paul Watzlawick

Complexity Theory

• Ilya Prigogine
• Stuart Kauffman
• James Lovelock

Learning Systems

• Kurt Lewin
• Eric Trist
• Chris Argyris
• Donald Schön
• Mary Catherine Bateson

Whole > Sum(Parts)

I was chatting to my friend Mark today. He's retired and spends his time doing exactly what he wants to which is mostly making tools and using them to make more tools and lots of beautiful things. Today he was showing me his newly finished rose cutter which allows him to create wood turning patterns you wouldn't think possible. Anyway, at one point we were chatting about shooting rabbits. He mentioned that making a gun was easy, a couple of evening's work he said! Making ammunition was more tricky though. He said you can buy all of the separate bits you need to make bullets without a license. But when you put them together then you need a license and face a jail sentence if you haven't got one. I thought was a nice example of the whole being greater than the sum of the parts.

A Tale of Two Sessions

I attended this years excellent AYE conference in Phoenix. Powerpoint style presentations are not allowed at AYE; many session are instead based on simulation and role-playing led by an experienced facilitator. The two sessions I attended on the Wednesday remain in my thoughts. Don Gray led the morning session and Steve Smith led the afternoon session. The task in both sessions was broadly similar (sorting decks of cards), but the contrast between the two sessions could hardly have been greater.

Don added arbitrary time pressure as part of the game and the participants accepted it. Steve's exercise had no time pressure. Well actually that's not quite true. I think there was time pressure but Obie who played the role of Steve's project manager shielded the workers from it very effectively. The feeling of being rushed was palpable in Don's session, whereas a feeling of general calm pervaded Steve's. There was a noticeable difference in the noise levels!

Don's exercise was initially more or less impossible to complete because of some confusion and contradiction in the requirements (quite possibly deliberate). The requirements seemed to be in much greater state of flux and quite a few participants (me included) sensed this and asked the customers various questions. This didn't help. In Steve's exercise Obie again did an excellent job of keeping things simple for the customer and the workers by being the only point of contact between them.

In Steve's session Obie explicitly said to the workers that if they didn't have anything to do at some point that was ok, they should just step back, observe and try to see where they could help. They should try not to interfere. This helped to emphasize the primary importance of the team and the overall goal.

In Don's session some people sensed the chaos building up and tried to intervene individually to help. It didn't help. All it served to emphasize was individual action rather than team co-operation. In Steve's session there was never a sense of chaos and any time any problems arose the participants were generally much more willing to follow a direction for the good of the team. They may not have agreed with the direction but you don't have to agree with a direction to support it as if it were your own. Following can often be a powerful act of leadership.

There were roughly the same number of people participating in both sessions. However, in Don's session several people disengaged from the exercise precisely because it was so chaotic. They were experiencing real discomfort. In its own way this too was an act of leadership - by removing themselves from the game they created a much better chance for the smaller team to overcome the chaos.

When technology pisses me off (5)

I went into my local Orange shop today. I simply wanted to upgrade my phone to one with a higher resolution camera. The assistant asked me some details and typed them into a computer. Nothing happened. She asked a colleague if the computer was working. He said try rebooting it. So she did. Then she asked me the same details again. And typed them in again. Still not working. Long pause with nothing happening. Decided not to get frustrated. Looked for a chair to sit down while I waited. No chairs. Sat on a low shelf instead. She asked me for the same details for a third time. This time I wrote them on a piece of paper. I decided to mention something I hadn't been asked - that I was on the Virgin tariff. That seemed to be an important piece of information and the computer was abandoned as she tried to ring someone for help. She couldn't get through. I went to sit down again. She kept trying. Eventually she got through. She passed the phone to me. The man on the other end asked for the same information for a fourth time. Then he asked me the post code of the shop I was in! I remained calm and handed the phone back to the assistant. I sat down again. The call ended. After all that I was told I couldn't upgrade my phone unless I switched to a different tariff. I was near the end of my tether by this point but I decided to at least look at the new tariffs. All more expensive than the one I'm one. I said simply "It's not going to happen. You've lost a sale." and walked out. Orange - today you were RUBBISH.

#exclude - a testing idea for C/C++

Suppose you're working on a legacy C/C++ codebase and you want to introduce some characterization tests. One seam you might consider exploiting is #includes. It's quite easy to exclude includes. For example:

# excluder.rb
include = Regexp.new('(\s*)#(\s*)include(.*)')
STDIN.readlines.each do |line|
 if include.match(line)
   line = "#if 0\n" + line + "#endif\n"
 end
 STDOUT.write line
end

This small Ruby program reads in a source file and writes out the same source file, except the #includes are commented out. Each line like this:

#include <stdio.h>

is replaced like this:

#if 0
#include <stdio.h>
#endif

This enables you to create an "isolated" version of a source file. One where all the dependencies arising from the #includes, to any depth, are slashed in one swift cut. One where your tests clearly and visibly have to recreate all those dependencies in a custom mock environment.

This is just an idea. I might not be a good idea. I only thought of it last week. Caveat emptor.

Incomplete types oddity in C

Here's something odd from C. It's to do with incomplete types. This compiles fine in gcc:

typedef struct wibble wibble;
void f(wibble * ptr);

but this does not:

typedef struct wibble wibble;
void f(wibble array[]);

A bit of searching in the Standard reveals

6.7.5.3 Function declarators
paragraph 12 - If the function declarator is not part of a definition of that function, parameters may have incomplete types...

This suggests the [] based declarator is ok. However it's not because...

6.7.5.2 Array declarators
paragraph 1 - the element type shall not be an incomplete type

Which leads you ask what is an incomplete type?

6.2.5 Types
paragraph 22 - An array of unknown size is an incomplete type.

Which is interesting because it says nothing about an array of unknown type being an incomplete type. This is a shame. Particularly because of the new [] array declarator syntax in c99.

Showers are lean-agile; baths are not

In the shower a few days ago I realized that showering vs bathing is a nice example of being lean-agile or not. Imagine 10 people bathing sequentially vs showering sequentially...

With a bath you have to wait (in a queue) while the bath fills up. Not so with a shower.

If you do something else while you wait for the bath to fill up you're likely to find the bathwater too hot or too cold.

Or the tap turns itself off (I have a hot tap that does that sometimes) and the bath is still virtually empty.

Or that might be the time you discover the overflow pipe is blocked.

Or that a fully-on tap releases water faster than an overflow pipe can drain it.

With a bath the water stays in the bath and gets dirty.

With a bath the water gets cold as you lie in it.

With a bath you have to drain the water before you can refill it so the next person can bath in clean water.

With a bath you use more water.

A bath takes up more floor space.

In a shower you stand up, you stay more awake.

A bath is less encapsulated.

Bath leaves a ring of scum that has to be cleaned.

Birth of the chaordic age

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

All things, even life itself, are a seamless blending of chaos and order.

By structure I mean the embodiment of purpose, principles, people, and concept.

The results of the best organizations are apparent, but the structure, leadership, and process and transparent.

Information multiplies by transfer and is not depleted by use.

Knowledge becomes understanding when related to other knowledge in a manner useful in conceiving, anticipating, evaluating, and judging. Understanding becomes wisdom when informed by purpose, ethics, principles, memory of the past, and projection into the future.

All knowledge is an approximation.

The information age is primarily an extension of mental power.

We are at that very point in time when a four-hundred-year-old age is rattling in its deathbed and another is struggling to be born.

Out of Our Minds

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

People are not creative in general but in doing something concrete.

Spontaneity sometimes has to be carefully planned.

Creativity is not just a matter of letting go: it involves hanging on.

Creativity is as much a process of finding problems as solving them.

Trying to put some experiences into words is like stringing clothes on a washing line when in practice they are worn one inside the other.

Creativity is a process not an event.

We classify at our peril.

Creativity is incremental.

Creativity relies on the flow of ideas.

Important - do not rub off

In one of his books Jerry Weinberg mentions a cleaner who wasn’t allowed to wipe the whiteboards. The story conjures familiar images of whiteboards full of stuff labeled “important - do not rub off”. It’s likely the stuff has lain untouched on that no-longer-white-whiteboard for weeks or months. It’s no longer important but there it stays, filling the whiteboard. A whiteboard full of stuff discourages its use in exactly the same way an empty whiteboard encourages it. And a whiteboard with the words “important - do not rub off” positively discourages use. It's really saying "keep away".

The whole purpose of whiteboards is that you wipe them. Perhaps they should be called wipeboards! Buying a wipeboard and its special pens and its special erasers and then filling it with stuff just the once is silly and expensive. If you want something permanent why not use a permanent pen on a big piece of paper stuck to the wall?

Filling a wipeboard with stuff labeled “important - do not rub off” is also silly if the stuff genuinely is still important. Someone might be desperate for a wipeboard and decide their new definitely-important stuff is more important than somebody else’s existing possibly-important stuff. So they wipe it. Wipeboards are so easy to wipe after all!

Le Chatelier's Principle says "[good] systems tend to oppose their own proper function". What is the proper function of a wipeboard? To be written on. How do you oppose being written on? Simple - wipe them completely clean every so often. Ruthlessly. Even if someone's written "important - do not rub off" on them.

With this use-clean use-clean use-clean dynamic set up the wipeboards give a clear visual impression of their dynamic use since anything on a wipeboard must necessarily have be written fairly recently. If they remain mostly unused most of the time you get to see that very clearly too.

Le Chatelier's Principle revisited

I was chatting about Le Chatelier’s principle with Hubert Matthews at an accu meeting in London yesterday evening. Hubert is a very smart guy and explained to me that losing your boarding card is a nice example, but not necessarily of Le Chatelier’s principle. What did I misunderstand?

Le Chatelier’s principle says "systems tend to oppose their own proper function". I incorrectly read this as a description of a poor system, an unorganized system, a system with no feedback, no control, (you get the idea), a system straying further and further out of balance at the slightest touch. In other words the system opposes its own proper function - but only in the sense that it never really had a chance of functioning properly in the first place! A system likely to die a quick natural death. That was the kind of systems behaviour I was looking for a name for. But I’ll come back to that.

So what is Le Chatelier’s principle really saying? As always an example helps. Every cell in your body requires a constant supply of glucose for energy. If your blood sugar level rises (e.g. after a meal) special cells in your pancreas produce insulin. Insulin causes the liver and muscles convert the extra glucose to glycogen and store it away, helping to reduce blood sugar levels. This is normal functioning. This is proper function. Ok. Now, what Le Chatelier’s Principle says (assuming I've got it right this time) is that your body will oppose this proper function! And your body does indeed start this opposition, and for a very good reason – if the insulin is left unchecked it continues to drain glucose from the blood and your blood sugar level gets too low. So when this happens different special cells in the pancreas start to produce glucagon. The glucagon works in opposition to insulin, causing the liver and muscles to convert the stored glycogen back into glucose thus increasing your blood sugar level.

In a healthy person these mini-systems operate quite properly, just like a thermostat, keeping your blood sugar level safely between fairly strict limits. Not too much (hyperglycemia) and not too little (hypoglycemia). They do this by opposing each other. It reminds me of the Goldilocks Principle. Goldilocks didn’t like the bed too soft or too hard, or the porridge too hot or too cold. Goldilocks knew her own mind.

So what have I learned from this? I’ve learned that I understand Le Chatelier’s Principle a bit better if I reword it ever so slightly to start with the word good. Good is a bit weak but I’m a bit pushed for time so it will do for now.

So what is my boarding card example an example of? Does The Inverse Le Chatelier’s principle apply? If a system does not oppose its own proper function is it more likely to be a poor system? I think there's an element of truth to that. If so we have Le Chatelier’s Principles. There are two of them, in opposition to each other, which somehow feels appropriate!

Good systems tend to oppose their own proper function.

Bad systems tend not to oppose their own proper function.

Thanks Hubert.

Predictably Irrational

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

We don't have an internal value meter...rather we focus on the relative advantage of one thing over another

Our first decisions resonate over a long sequence of decisions.

With everything you do you should train yourself to question your repeated behaviour.

Humans are intrinsically afraid of loss.

For market norms to emerge it is sufficient to mention money.

Money, it turns out, is very often the most expensive way to motivate people.

We fall in love with what we already have.

Expectations can influence nearly every aspect of our lives.

The majority of people cheated, and they cheated just a little bit.

What a difference there is in cheating for money versus cheating for something that is a step away from cash!

Thought for the Day

From Small Memory Software by James Noble and Charles Weir.

The fundamental difference between code and data is that programmers care about code whereas users care about data.

Le Chatelier - Systems tend to oppose their own proper function

One of the principles of Systems Thinking is Le Chatelier's Principle.

Systems tend to oppose their own proper function.

A nice example of this is checking your passport and boarding card at the airport. The comedian Michael McIntyre has a very funny sketch pretending to walk through an airport. Every three or four paces he has an uncontrollable compulsion to check that his passport and boarding card are still in his breast pocket. At one point he thinks he's lost them and goes into a mild panic.

Your passport and boarding card are completely safe in the pocket. They are not going to suddenly jump out of the pocket all by themselves. Gravity is not suddenly going to go into reverse. You're unlikely to start walking around on your hands. Pretty much the only way they're going to get out of that pocket is if you take them out yourself. Which is exactly what you do to check you haven't lost them!

On more than one occasion I've seen someone unknowingly drop their boarding card while checking they still have it. This is Le Chatelier. You have a goal in mind, you act to achieve that goal, and your action creates the opposite effect!

So now you know about Le Chatelier. You know that the time you're most likely to lose your boarding card is when you check whether you've lost it. So immediately after checking it you'll remember this blog and start to worry you lost it when you checked it. You'll probably have to check it again. Very soon you'll be checking it every three or four paces like Michael McIntyre. And of course, the more you check it the more likely you are to lose it! Le Chatelier again!

UDPATE: Losing your boarding card is NOT an example of Le Chatelier's Principle. It's an example of a different Systems Law: The Law Of Unintended Consequences! See Le Chatelier's Principle Revisited for what Le Chatelier's Principle really is (I think!)

Thought for the day

I think I read this on James Grenning's site somewhere:

It’s easier to act your way into thinking differently than to think your way into acting differently.

I think the origin of this quote might be Richard Buckminster Fuller:

You cannot change how someone thinks, but you can give them a tool, the use of which leads them to think differently.