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.