Wow Brian, amazing bibliography! Much food for thought here – wish I lived near Portland so I could hear the talk itself…
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. Dictionary.com 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.
For reference, here’s a link to Steve McConnell’s great article describing “cargo cult” software development processes.
Many thanks to Bill Caputo for bringing this article about metaphors into my range-finder! Like Bill, I use metaphors a great deal in everyday conversation, and yet I hardly ever set up a system metaphor as recommended in XP. Which is doubly odd, because I’ve read a lot of George Lakoff‘s work and find myself completely captivated by his thinking. The idea that we develop our higher thinking by piling up metaphors on top of the actions we perform as babies is enormously appealing, and I hope he finds the time to demonstrate the effect in most areas of our cognitive lives.
So why is XP’s SystemMetaphor so misunderstood and under-used? My personal view links back to a topic we discussed at length at a recent agile nw meeting: that in order to work successfully XP relies on the presence of at least one, and preferably two, extraordinarily talented individuals. Clearly Kent Beck is one of those individuals, and it would seem that SystemMetaphor is one of his preferred cognitive tools. It would also seem to have worked successfully on a number of his projects. But not everyone can (or needs to) think in such a way about systems. My guess therefore is that this is the one case where Kent’s intuition was more personal than he realised – he can make it work, but most other folks can’t…
Many thanks to Lasse for bringing the following quote to light:
All abstract thought is based on metaphors. The question is
not whether you will think metaphorically or not. The question is whether you will become aware of your metaphors and choose them consciously.
— Kent Beck
It seems to me that one of the principal reasons for the apparent rapid rise of agile methods in software development is the romanticized battle between programmers and managers. Spend any time reading any extreme programming discussion group, for example, and eventually the topic of adopting XP in the face of management resistance will crop up. Agile methods, and XP in particular, would appear to be the saviour of the oppressed programmer; finally the evil tyranny of the waterfall and the heavyweight methodology are crumbling in the face of guerilla resistance from programmers who knew they were right all along! Or that’s how it seems to them.
Does the extreme (sic) zealotry of the programmers represent years of pent-up frustration with the situation in which they found themselves? Do they blame management for controlling them, for keeping them strait-jacketed in heavyweight methods for so many years? If that’s the reason, why were such methods of control deemed necessary in the first place? Two words: manufacturing metaphor.
This week in our yoga class we spent a fair amount of time in tadasana, the so-called ‘mountain’ pose. It turned out that “tadasana” was the only Sanskrit word our teacher used in the whole lesson, and so again I found it echoing around in my head afterwards. Now, if Sanskrit is reputed to be very close to the root Indo-European language, what influence has the word “tadasana” had on modern English – that is, which everyday words are derived from the parts of the word “tadasana”? Conversely the Sanskrit root tada allegedly means “mountain”, and yet the two words don’t sound remotely similar. So where has the word “mountain” come from?