Alistair Cockburn has been recently interviewed by ITConversations.com. The interview is available here as both audio recording and a transcript. Most of the conversation, unsurprisingly, rotates around themes from the seminal "Agile Software Development" book and the Agile Manifesto stuff. Alistair's soon-to-be-published book on Crystal methodology also gets some airtime. Alistair is as sharp as ever and gives a nice overview of the whole agile philosophy for those of use who doesn't yet have enough of it.
My personal favorite in the interview is Alistair's explanation of Agile Manifesto basics. I love the following paragraph most (emphasis added):
Second one: “Working software over comprehensive documentation.” It's a pretty obvious reference to ISO 9000 and the software engineering institute, the CMM levels where you see massive amounts of documentation being required. And while there's value in documentation — and I talk about that especially in the cooperative game theory — the punch line is, software has got this ruthless honesty to it. And you could have the nicest looking document in the world, and someone once said, “Bubbles don't break,”
the bubble-and-arrowdiagram, so they all look good, but you can't debug them. They don't execute, so they don't break. So we keep coming back to, “Show me the software, show me the software! Does it run? Show it to me!”
In my opinion, the inability to debug any type of documentation presents one of the biggest challenges for the involved project roles. Moreover, the very impossibility to execute a document or a diagram, as compared to a piece of code, is actually a demotivating factor for their authors and, in my opinion, one of the main reasons why documentation activities are disliked and neglected.
One can recall the early days of software development when batch processing and limited CPU availability required programmers to read their code a few times before submitting the job for processing. I vividly remember doing this myself, although I was born too late and wasn't around during the golden days of mainframe technology. One skill that those code readings really sharpened was the ability to execute code in your mind, spotting bugs, bottlenecks, or other problems. Of course, it was (and is) never possible to catch all problems this way. Nevertheless, such practice definitely makes you a very competent and efficient code reviewer.
I'm often asking myself, if the same ability could be cultivated and applied to documents and diagrams. We can't literally "execute" a UML diagram, much less a requirement specification or, say, a CMMI process area definition, because, as Steve Mellor pointed out, they all lack strict action semantics. However, I'm pretty sure that the same skills that a good code reviewer possess – namely, the ability to evaluate a complex
As a next step in these reflections, we might assume that, once this ability is in place, the exercise of "
The weak spot of it all is that I personally do not know any systematic way, besides a continuous practicing, to actually cultivate the discussed ability. Maybe, some fellow psychologists may help us all with that – at least, by pointing to some research of human