Good is up

A mailing list recently reminded me of the so-called “Peter principle”, which avers rather sarcastically that in terms of careers, everyone rises to the level of his incompetence. While I was trying to figure out whether this makes any sense, I realised that there’s a huge assumption built into the principle: Good is up.

Somehow, furtherance of one’s career is mapped to “higher”. Is that because most organisations are viewed hierarchically, or is it why most organisations are hierachical? Which came first, I wonder — the shape of our organisations, or the metaphors we use to describe them? We use phrases such as “at the top of the tree”, “top brass”, “a long way to fall”, “social climber”, “high flyer” — all of which reinforce the metaphor that success is “up” and lack of success is “down”. Little wonder that so few organisations escape from this and use non-hierarchical structures.


So the Peter principle says that, as our careers evolve, we climb the corporate ladder until we reach a level that’s too high for our abilities. Again, making the assumption that there’s some kind of linear mapping between “height” in the hierarchy and “ability”. Presumably this is the ability to be “high up” and to have more people and things “under” you? Which also seems to assume that all other kinds of ability are useless or irrelevant. In which case, I think the Peter principle is correct: people tend not to be given more of the kind of work they have shown they are not good at. And in a hierarchical organisation, that means people will stop rising when they get too high.

Sad, though, that multi-dimensional, multi-talented people can be categorised in such a one-dimensional way.

when lower means higher

Last week a metaphor nearly fooled me into buying a household appliance I don’t need. Let me explain…

For historical reasons I do most of the ironing in our household, and recently the steam-iron had been causing me problems by overheating. It seemed to be getting gradually worse, to the point that I was increasingly afraid of burning something. Over the course of a couple of weeks I had gradually moved the temperature setting further and further down the scale until it was at the lowest setting – but to no avail. I identified the replacement model we should buy, but before doing so I thought I would make sure the thermostat wasn’t simply furred up inside (we live in an area of very hard water, which had already accounted for a steam-iron and two kettles, so this was a distinct possibility). I don’t de-scale the iron often, so I dug out the instruction manual to remind me what to do. And as I was scanning the little diagrams showing the iron’s controls I realised what was wrong. I had set the temperature control to MAXIMUM!

The temperature scale consisted of a vertical slider on which the markings had become illegible (to my eye). As it turned out, LOWER on the scale meant that the temperature of the iron was set HIGHER. With no words or symbols to guide me, I had assumed the opposite – that LOWER would mean LOWER. No that’s wrong, because “assumed” implies conscious thought. I believe that metaphorical structures such as this – LOWER = LESS – are laid down when we are babies playing with blocks. I simply expected LOWER to mean LOWER.

Okay, mea culpa for not reading the manual etc etc. But why design something in such a way that the user is forced to read instructions in order to overcome an innate metaphorical response? Why design against the flow?

building space-stations

Almost a year ago InfoQ carried an interview with Jim Johnson of the Standish Group, in which Jim used a term I hadn’t heard before:

Agile must bring in new issues: how do you say when “planned” scope is accomplished, for a project using adaptive planning?
That’s a good question. With companies like Webex, Google, Amazon, eBay, it’s a challenge – they’re doing something called “pipelining” instead of releases. “Whatever is done in 2 weeks, we’ll put that up.” They’re successful because users only get small, incremental changes. And their implementation is proven – remember, some projects only fail after the coding is finished, at the implementation step.
Pipelining? Sounds like variable scope..
Yes. It’s very enlightening to work on variable scope – it makes people a lot happier to see things getting done. People like to see progress and results, and Agile embodies that.”

The metaphor “pipelining” is interesting, and at first I liked the different slant it gave me on incremental delivery. But having lived with it now for a couple of days I’m no longer so sure. The image of the relentless drip-drip-drip of new features is compelling, but the metaphor conjures no representation of the growing system or product. In my mind’s eye I’ve always likened software development to building a space-station: because there’s no gravity we can add, remove or rebuild any part we wish. The time-lapse film of our activites would show something that was unmistakably space-station-ish from day one, whose features and capabilities gradually expand like a flower opening. (There – I just used a simile to help explain a metaphor; who said language was dead!)

Anyway, “pipelining” as a metaphor seems to me now to offer an incomplete view of agile/lean development. And building space-stations seems to be more fun, too.

(Hat tip to C. Keith Ray for the link.)

an apparent case of specific anosmia

A couple of weeks ago I discovered I had missed dozens of smells in a piece of code I thought I knew well. And today I discovered yet another smell in the same code, this time a really big one. What’s wrong with me?

I have a bunch of code, code that I wrote a while back. I revisited it a couple of weeks ago, because there was a smell in the the back of my mind and I wanted to scratch it. (Equating problems in code with bad smells has always struck me as an awkward metaphor, and somehow I can sense this post being more awkward than most.) However, the remedy for the smell that had been gnawing at me was large and complex, so before tackling it I thought I would look for anything simpler to tackle first. Low-hanging fruit to get my coding muscles warmed up. I put on my code reviewer’s hat and within a few minutes I had found around a dozen other smells. As is my wont, I marked them in the code with <SMELL> comments, and pretty soon there were long sections of the code with a comment on every line!

I had begun this exercise feeling fairly confident that the smell I knew about was pretty much the only smell in the code. But I came away wondering why I had missed all those others. One person, one set of knowledge about smells; two different hats, two very different perceptions of the code. Why?

I now believe this is a case, not of specific anosmia (the inability to detect certain smells, aka “smell blindness”), but of not listening to the code. I had one specific refactoring in mind, and my entire view of the code was distorted by the lens of that goal. But the code wanted something different; and many of these newly-discovered smells were clearly more serious and more urgent than mine. Note to self: let the code set the direction.

And so I thought that was that. I had a list of smells to tackle, and I sat down today to pick one and fix it. But as I was reading through, looking for a candidate, yet another smell hit me square between the eyes. This one wasn’t in the comments, because I hadn’t seen it during my review. And yet it was everywhere (I reckon 10-15% of the code is infected). What’s going on? Again, it can’t be anosmia, because I did detect it – albeit third time around. And I don’t believe this time I was blinded by any preconceived ideas, because I really had no idea what I would be tackling today.

So it must be some kind of layering effect: different smells are visible at different mental distances from the code. Today I was more distant, more detached, than on either previous occasion, and so perhaps I saw more. Maybe by placing the smell comments in the code, and out of my head, I had gained some detachment. Perhaps in doing that I had freed my mind from some of its preconceptions; and the two week break had then allowed it to see even more. When I had the goal smell in my mind it seemed like knowledge, but when I was able to devolve to the code itself, only then did the true situation become apparent.

I believe the moral of this story is that I’m a better programmer when I have Beginner’s Mind.

Read more about those metaphors

mocking a singleton

Jeffrey Frederick (link via Robert) highlights a splendid piece of humour by Mike Hill on the Yahoo testdrivendevelopment list. In discussing the use of mock objects to test Singletons, Mike said:

“Mocking a singleton is relatively easy.”To begin with, singleton’s are all alone in the world; don’t be afraid to point this out. Also, most singletons are created, get this, not even in a factory, but merely in a factory method. Finally there is the point that they are little more than dressed-up globals, and IME experience cause more heartache than they’re worth. You can point to the many nasty screeds about singletons there are out on the net. All in all, mocking it shouldn’t be too hard. A word: if your singleton has unusually large body parts, stoop to insulting that. Sometimes, to be kind, you have to be cruel.”

The humour arises mostly from the pun on ‘mock’, of course, but also partly from deconstruction of the term ‘singleton’. I find it fascinating just how quickly and completely a metaphor such as this can come to be adopted as primary language. To the extent that we get a small shock when someone reminds us where the term originally came from.

boot Many of the GoF design patterns have names that are metaphors (Bridge, Factory, Singleton, etc) and I think that’s an important factor in their success. A few lines of code in some software aren’t really a Factory; but the name evokes so many connections with the real world counterpart that we can quickly understand what those lines of code do (or were intended to do). We’ve stolen a word form another domain, so that the baggage it brings along will help us understand something new and more abstract.

Our industry is riddled with metaphors: windows, mouse, boot-strap, object, broker, layers. They help us bring our real-world, tangible experiences to bear on complex, abstract subjects. It would be hard to imagine life without them.

Look out for my conference workshops on the power and use of metaphors later this year. In the meantime, what has been the most useful metaphor you’ve encountered in software development? Which metaphors are the most surprising? Which are the most deeply ingrained?

gravity and software adaptability

stack During my ‘hexagonal architecture’ session at XPday Benelux, the discussion gave me some clues as to why I feel the “standard” layered architecture model is sub-optimal: I realised that I feel as if I’m looking at a picture of a pile of stuff from the side. Contrast this with a hexagonal model of the same system, in which I feel as though I’m looking down on the picture.

Why is this important? And what relationship does it have to being agile?

The answer, I believe, lies in Lakoff‘s theory that metaphor shapes much of our thinking. When I look at any architecture model I subconsciously impose a point of view on the picture, because my mind relates what I see now to previous experiences. A layered model “looks like” a pile of books or building bricks; hexagonaltable a hexagonal model “looks like” an island on a map (another metaphor in itself!) or a table with chairs arranged around it. The choice of metaphor is made deep in my perceptual system, helping me to make sense of anything I see. And once the metaphor has been selected, my mind will then automatically supply it with a whole load of related beliefs, many learned as a baby. Among these are the effects of gravity and mass, together with related implications of downward dependency.

These associations cause me to believe that the things at the bottom of the pile are hard to move or change. Whereas in the hexagonal view I instinctively feel the system’s components are more loosely coupled – perhaps because they are associated only by proximity, and not by gravity.

So because of these deep-seated metaphorical associations, maybe we build less adaptable systems when we think of them in layers…?

‘development’, not ‘engineering’

I hear managers talk about “software engineers”, meaning people who do “engineering” on software. And I don’t like it. In my mind the analogy between software creation and hard engineering is completely broken.

In the agile world, software develops. defines the intransitive verb to develop as “to grow by degrees into a more advanced or mature state.” And the transitive verb to develop, which is what developers do, means “to bring into being gradually.” Just so.