Agile Lab - Training, Coaching and Consultancy Blog

Thursday, 3 September 2009 at

You Keep Thinking Butch

I went to a talk by Tom Gilb last night at the BCS. It was a really curious curate's egg of a talk. First of all he hardly did any of the things that he said he was going to do in billing for the talk. I don't think in any way he "proved" that Agile was dead, although I suppose he did say that very loudly, several times.

Here are some of the bad bits of the egg:

  • His slides are terrible - I wouldn't be surprised if some of the text on them was actually 10 point. Apparently randomly justified, if not just un-justified, with shrunk-down diagrams that themselves, therefore include illegible text. I wonder what people intend when they put up a slide with text so small it's unreadable and then say "You can just scan that." Well actually, no Tom that's exactly what I can't do.
  • His response to questioners is shouty, sarcastic and in general not an answer to the question. Handing people a copy of one of your books and saying "it's in there you should read about it" strikes me as rude. I was particularly unimpressed by his response to my question about two quotes from William Goldman - author of the screenplay for "Butch Cassidy and the Sundance Kid": "Nobody knows anything." This is Goldman's explanation for why people in Hollywood behave in such a paranoid fashion. If everything is measurable, how come in Hollywood nobody knows anything? Surely some engineer would have come along, figured out what it is about movie like ET that makes it successful, measured it and then just made lots more movies like that (even Spielberg made Batteries Not Included)? And aren't a lot of software projects, especially web ones getting to look a lot more like movies? Big unwieldy confluences of marketing, PR, software and community? I think this might be a realisation that people who started thinking about software projects in the 70's are trying to avoid.

This final is my main problem with Tom Gilb and all he claims to stand for.

The notion that everything, or almost everything that is valuable is measurable or quantifiable is false.

And Tom Gilb doesn't strike me as stupid, so I think he probably knows it's false. If he doesn't, maybe it would be OK to just hand him a copy of Plato's republic and a copy of Wittgenstein's Philosophical Investigations and say (in the most crushingly condescending voice we can manage) "It's all in there Tom, you go away and read about it." But instead I'll have a go at explaining it in a footnote [1].

Efforts to come up with necessary and sufficient conditions for important concepts - beauty, justice, comfort, cuteness, grunginess - often fail.

Here are some good bits of the egg:

  • He's right to say the values that are used to prioritise what gets worked on in a project from iteration to iteration need to be informed by a wide range of stakeholders. Unfortunately he didn't say how you go about making sure that you get input from those stakeholders. He especially didn't answer the question of what to do about "unreachable" stakeholders - people who are too busy or important to get involved in prioritisation of work.
  • He's right that moving away from adding features to improving performance on existing features has to happen at some point in a project (interestingly, the two case studies that he talked about were mature, existing pieces of software). And it might be that this can be driven by a metric, like the examples he gives of performance times or set-up times. And of course, focus on this kind of improvement, things like getting the time it takes to change a die used for pressing car body parts down from a week to 3 minutes that contributed to Toyota becoming the world's biggest car company.
  • He maybe right that far more of the world is susceptible to quantification and improvement on quantifiable metrics than we might think. He may be right that it's a good heuristic approach, a good strategy, to approach the world as if most values can be quantified.

Footnotes

[1]

Very often there seems to be some counter example that doesn't quite fit with whatever definition is offered. This is especially the case with big, important concepts, like true, justice, beauty. And it's not a new problem, people have been struggling with it for some time. Plato struggled with the problem of defining justice and eventually came up with the explanation that the problem arose because the world was a pale shadowy reflection of the true concepts that exist somewhere else - the forms. I sometimes think this is how engineers are thinking.

After 2000 years of struggle to come up with a better answer to this problem of definition, Wittgenstein pointed out that there was no reason why there should be a universal, necessary and sufficient definition of any concept: language isn't a perfect map of the world.

Wittgenstein's explanation is that words accrue meaning through use. The meaning of a concept comes out of its use in everyday cases and those everyday cases have some kind of family resemblance to each other, they may have some features that overlap but that is very different from saying that there is a definition - a set of necessary and sufficient conditions - that would coral all the correct cases and rule out all the improper cases. Famously, the concept that Wittgenstein uses to illustrate this is that of games.

Where words particularly struggle to be useful is when we take them away from these everyday cases in which they are regularly used and try to rely on their definitions to guide us about their use in brand new situations.

Unfortunately, this would tend to be exactly where value words are being used when discussing a new project.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , , ,

Monday, 27 April 2009 at

The Meaning of Common Sense

"We are asleep. Our life is like a dream, but in our better hours we wake up just enough to realise that we are dreaming" - Ludwig Wittgenstein.

My brain has been readjusting only slowly from the tasks of navigating an SUV around Athens at high speed (if you drove slowly they would just run into the back of you).

But for most of that time, I've been mulling over Paul Dyson's post about Pair Programming and Common Sense. It reminded me of a couple of things. First, it reminded me of the Vikings and the Inuit in Greenland as it is described in "Collapse" by Jared Diamond and this white paper that I wrote after reading it ages ago. The upshot is: even if something is happening right in front of you, that you have to notice to save your life, there may well still be cultural and religious reasons why you can't see it.

The second thing it reminded me of was my experience of reading Wittgenstein. When I was a second year at university, I would chat to some of the older students and they would try to tell me "But, you see, for Wittgenstein, the meaning of a concept, is it's use!" And I would have no idea what they were talking about. Then I spent a year or so (only in my spare time of course) reading the Philosophical Investigations. At the end of that year, I found myself saying to many many uncomprehending people, "But don't you see? The meaning of a concept is its use!"

In many ways what Wittgenstein says about meaning is so forehead-smackingly obvious that when you hear it and understand it, it seems almost unremarkable - you might even say, common sense, but that didn't stop it taking about 2300 years for anybody to come up with an answer to Socrates's problem of how we define "good". One of the reasons is that Socrates sets the problem up so that it's looking for a definition, and it takes a genius like old LW to come along and climb out of that culture, that mindset and point out that abstract definitions are precisely the problem. Obvious when you understand? Yes. Common sense? maybe. Easy to figure out for yourself? Possibly, if you've got 2300 years to think about it.

Perhaps this is why so many people fail to see the "common sense" of pair programming, they're in a culture where, as managers, they're supposed to get the most out of their people - as one of my management consultant friends sometimes rather unpleasantly puts it "sweating assets". In order for pair programming to make sense, they have to be in a culture of solving software problems in the most efficient and resilient way possible irregardless of team groupings. The Vikings wouldn't realise they were in the survival business and start fishing like the Inuit even when it killed them, so perhaps persuading people to do what can be regarded as "Common Sense" isn't that easy.


For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , ,

© Agile Lab, 2007-2009. All rights reserved.

sitemap

Powered by Blogger

Subscribe to Posts [Atom]