A friend of mine is a sports physiotherapist. He's pretty good at this and has worked with premiership footballers, Belgian international Squash players and others. Apparently it's common knowledge in his world that all top sportspeople put in around 10,000 hours practice before they reach the top. That's about 20 hours a week for 10 years. He emphasises that this was practising as distinct from playing the sport. One key difference is the continuous involvement of a coach to make you do it right.
What does this mean for programmers? I think that pair programmers have a coach present, and so they're building their 10,000 hours. On this basis, 10,000 hours of pair programming makes you an international. No amount of lone programming gets you there though - you're just programming.
Sunday, 4 January 2009
There's no comparison
XP Day 2008. XP Day isn't really about XP any more - it's about whatever the people that go every year are currently obsessed with. On this occasion, that seemed to be two topics. One was that old favourite, how shall we know good code when we see it? Not much to say about that except that I was pleased to find lots of other people in the middle of Bob Martin's "Clean Code", which is focused thereabouts.
The other obsession was lean thinking. This is one of those myriad attempts to improve software practice by copying something that worked somewhere else. In this case, Toyota came up with a bunch of practices that helped them to make cars more cheaply in the immediate post-war era. I mentioned this over the weekend to a friend whose job consists of trying to make various car factories run more efficiently. As you might expect, he knows a lot about value streams, kanbans, and the rest of this stuff, and he immediately came back with "but what has all that got to do with software?".
I was reminded of an OOPSLA in the late nineties. At that time, pattern languages were all the vogue, and Chris Alexander - the architect who invented pattern languages to capture architectural knowledge - had been invited to give the keynote. He shambled on stage, and expressed himself vaguely bemused to be there. Why would you all be interested in something designed for use with architecture? he asked us.
It seems to me that we do this a lot in software. Apart from lean thinking and architecture, other past efforts have included the SEI models (one of many other attempts to compare software with manufacturing), making movies, mountaineering, oil exploration, collaborative game playing, building buildings, and plenty more besides.
These can be sources of entertainment. I've spent some happy hours annoying movie-making friends by trying to make comparisons. But mostly, I don't think these analogies help much with the goal of getting better at writing software.
Years ago I saw Bertrand Meyer give a talk in which he said that the significance of a piece of advice was inversely linked to the plausibility of the opposite. If someone advises you to choose readable variable names, that's not advice: you were unlikely to make an effort to choose unreadable names. On the other hand, if you're advised to "choose names that express what is to be done rather than how" then you have real advice, because it's not immediately obvious that "how" is the wrong answer.
Much of the advice that comes from these analogies seems to me to fail the Meyer test. I was initially taken by someone talking at XP Day about applying the principles of lean applied to software. One outcome was the notion of not having any more than a small number of tasks on the go at once. But then I took a step back to consider the alternative. Deliberately strive to do lots of things at once? Was I about to do that? About the best you can say is that this changes the emphasis, but then you have to wonder, away from what?
Other debates about the management process had this same unsatisfactory feel. Reminders of lots of common sense stuff, but nothing that might change your practice. Breakthroughs in software development - the move from waterfall to iterative, for example - I don't think come from analogies. All the "good stuff" for me at XP Day happened where the topic under discussion was software development, in and of itself. I sat for an hour in an open space discussion about what makes software programs easy to read. I came away with some genuinely useful insights that will make me do something different in future. From here on in, I think I'm going to try and get better at software by doing and talking about software.
The other obsession was lean thinking. This is one of those myriad attempts to improve software practice by copying something that worked somewhere else. In this case, Toyota came up with a bunch of practices that helped them to make cars more cheaply in the immediate post-war era. I mentioned this over the weekend to a friend whose job consists of trying to make various car factories run more efficiently. As you might expect, he knows a lot about value streams, kanbans, and the rest of this stuff, and he immediately came back with "but what has all that got to do with software?".
I was reminded of an OOPSLA in the late nineties. At that time, pattern languages were all the vogue, and Chris Alexander - the architect who invented pattern languages to capture architectural knowledge - had been invited to give the keynote. He shambled on stage, and expressed himself vaguely bemused to be there. Why would you all be interested in something designed for use with architecture? he asked us.
It seems to me that we do this a lot in software. Apart from lean thinking and architecture, other past efforts have included the SEI models (one of many other attempts to compare software with manufacturing), making movies, mountaineering, oil exploration, collaborative game playing, building buildings, and plenty more besides.
These can be sources of entertainment. I've spent some happy hours annoying movie-making friends by trying to make comparisons. But mostly, I don't think these analogies help much with the goal of getting better at writing software.
Years ago I saw Bertrand Meyer give a talk in which he said that the significance of a piece of advice was inversely linked to the plausibility of the opposite. If someone advises you to choose readable variable names, that's not advice: you were unlikely to make an effort to choose unreadable names. On the other hand, if you're advised to "choose names that express what is to be done rather than how" then you have real advice, because it's not immediately obvious that "how" is the wrong answer.
Much of the advice that comes from these analogies seems to me to fail the Meyer test. I was initially taken by someone talking at XP Day about applying the principles of lean applied to software. One outcome was the notion of not having any more than a small number of tasks on the go at once. But then I took a step back to consider the alternative. Deliberately strive to do lots of things at once? Was I about to do that? About the best you can say is that this changes the emphasis, but then you have to wonder, away from what?
Other debates about the management process had this same unsatisfactory feel. Reminders of lots of common sense stuff, but nothing that might change your practice. Breakthroughs in software development - the move from waterfall to iterative, for example - I don't think come from analogies. All the "good stuff" for me at XP Day happened where the topic under discussion was software development, in and of itself. I sat for an hour in an open space discussion about what makes software programs easy to read. I came away with some genuinely useful insights that will make me do something different in future. From here on in, I think I'm going to try and get better at software by doing and talking about software.
Subscribe to:
Posts (Atom)
