Copied wholesale from D-Squared
In business circles, particularly among a certain kind of aggressive American businessman (or consultant, or banker, or politician, they’re fairly interchangeable), there is a favourite proverb about a pig:
“When you have bacon and eggs for breakfast, you’ve got your breakfast from a chicken and a pig. The difference between them is that the chicken is ‘involved’ but the pig is committed“
which is of course, true. It should also be noted, however, that when you go out to get your next few breakfasts over the course of the rest of the month, the chicken will have laid another egg every day, but the pig will eventually run out of bacon
I was chatting with Keith about what the Software Craftsmanship event should really be about, in the context of a discussion of whether some of Jason Gorman’s list of guitar heroes are actually worth listening to (you still with me?) 1.
The next obscure piece of evidence is Maurice Murphy’s YouTube masterclass. For those who don’t know, Maurice Murphy has been Principal Trumpet in the London Symphony Orchestra for years (nerds without an interest in orchestral music will nonetheless have heard him on the Star Wars sound tracks). What’s interesting about the video is that what they emphasise most is being musical, making sense of the melody. They have no interest in pyrotechnics and assume that the student knows the basics.
The (barely sustainable) link with master-level coding and performance, we realised, is that both are about being expressive. The master coder/performer has a point of view and they use their considerable technical skills to get it across. The code that really impresses me is almost entirely about the domain, it just reads well. Most of the code most of us see, however, is stuck a level below, I have to read through the implementation to get to the meaning.
Years ago an old friend of mine said that when she first started going to conferences she wouldn’t be impressed by some of the big names because what they said was obvious. Later, she learned that being obvious can be really hard.
1) Disclaimer I never was into rock guitar heroes, so Jason’s post was a bit academic for me.
Just got home after two intense days of XpDay London 2008. There’ll be follow-up materials posted on our new wiki. This year, Keith Braithwaite tried out a largely open format which was really buzzing by the second day.
In the middle of today’s keynote I was suddenly struck by the range of our community. With only about 100 geeks we were talking about subjects such as type systems, coding practices, theories of categorisation, human perception, organisational structure, market analysis, and clinical psychology. And that’s before we dealt with catching up with industry gossip and general horse-trading. Remarkable.
This paper1 from Microsoft’s Empirical Software Measurement group reports that
Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15-35% increase in initial development time after adopting TDD.
Reading the small print, these were not “pure” TDD teams since they did a lot of the requirement and design up-front. Still, a nice data point that suggests that, taking the cost of fixes into account, it’s worth taking the time to get it right.
1) “Realizing quality improvement through test driven development: results and experiences of four industrial teams” Nachiappan Nagappan, Michael Maximilien, Thirumalesh Bhat, Laurie Williams. Empirical Software Engineering Journal, Volume 13, Number 3, pp. 289-302, Springer 2008
From one of the Lean mailing lists. It was posted in the context of Lean adoption, but seems to apply to just about anything…
I believe there is only one pre-condition. The leadership of the company must believe “The status quo is no longer an acceptable way of doing business”. […] One of our associates gave me that quote. She was asked what lean meant, and that was the reply.[…]The rest is just technical details.