Skip to content

SDBP ’08, Habitable Code and Early Registration

See Me at SDBPI’m going to be talking at this year’s Software Development Best Practices in Boston with Paul Julius. Our talk is Creating Habitable Code, and we’ll be drawing on our experience with CruiseControl as our central example.

My interest in topics like continuous integration, developer testing and mundane excellence have the common thread of “how do we maximize our sustainable (and sustained) velocity?” All too often I’ve worked with teams who find their velocity (and their sanity!) suffering because their codebase has grown beyond unwieldy into unlivable. These seems especially common on projects that are long lived, have large teams, or long lived projects with large teams — the common denominator really being the code passing through many hands.

Paul and I think CruiseControl provides an interesting study here because it is a long lived project that has had over 200 successful contributors. The patterns and practices that enabled this would help many of the projects I’ve seen.

(If you’re interested in SDBP but aren’t registered, this a gentle reminder that Early Registration ends this Friday.)

Making software like intensive care or bombing missions

Today Ben Simo twittered a link to Cem Kaner‘s keynote slides from CAST 2008 on The Value of Checklists and the Danger of Scripts. This was timely for me because I’d been trying to describe to a friend about why I thought manually executed scripts are worse than useless.

Even better, at least for general inspiration, Kaner’s slides included a reference on using checklists in intensive care units, described in this New Yorker article The Checklist. This is a fantastic article and you should go read it now. Go ahead, I’ll wait.

Back? Excellent, wasn’t it?

Ok, for the cheaters who didn’t read the article here’s one example:

In December, 2006, the Keystone Initiative published its findings in a landmark article in The New England Journal of Medicine. Within the first three months of the project, the infection rate in Michigan’s I.C.U.s decreased by sixty-six per cent. The typical I.C.U.—including the ones at Sinai-Grace Hospital—cut its quarterly infection rate to zero. Michigan’s infection rates fell so low that its average I.C.U. outperformed ninety per cent of I.C.U.s nationwide. In the Keystone Initiative’s first eighteen months, the hospitals saved an estimated hundred and seventy-five million dollars in costs and more than fifteen hundred lives. The successes have been sustained for almost four years—all because of a stupid little checklist.

(More in the fine article, which really is worth reading.)

What I found so exciting about that article is it is such a strong evidence that simple simple change in practice can yield wildly improved results, and in an area that is every bit as complex and demanding as creating software.

I had a similar insight this summer while I read The Mundanity of Excellence, an article by Daniel Chambliss. Chambliss studied the difference in performance among swimmers to explain why some excelled and others did not. He found that it didn’t come down to any of the things you might expect: unusual personalities, qualitative differences (doing the same things but faster) or talent. Instead “excellence requires qualitative differentiation“, that is, doing different things. But not exceptionally different things, just habitually different:

… there is no secret; there is only the doing of all those little things, each one done correctly, time and again, until excellence in every detail becomes a firmly ingrained habit, an ordinary part of one’s everyday life.

I love this message! It doesn’t take magic, it doesn’t take a miracle. It takes decision and discipline and will and learning something new and putting it into practice. This is why I love agile coaching, and teaching engineers TDD and refactoring, and product managers how to use cases and personas, and all those other simple practices that are now considered part of the agile/lean toolkit.

And why it is thrilling to come across an article like this one in the New Yorker that offer a new analogy: the B-17 phase.

Substantially more complex than previous aircraft, the new plane required the pilot to attend to the four engines, a retractable landing gear, new wing flaps, electric trim tabs that needed adjustment to maintain control at different airspeeds, and constant-speed propellers whose pitch had to be regulated with hydraulic controls, among other features. … The Boeing model was deemed, as a newspaper put it, “too much airplane for one man to fly.” … Medicine today has entered its B-17 phase. … I.C.U. life support has become too much medicine for one person to fly.

Airplanes haven’t become more complex since them. Instead the belief of what is needed to pilot them has moved beyond the heroic “Right Stuff” to a sort routine mundane excellence. ICUs are doing the same. I’m ready to join them.

Good progress on CITCON Amsterdam

Eric Lefevre posted a message to the CITCON mailing list today sharing some information about the upcoming CITCON Amsterdam. We currently have a very similar registration level to where CITCON Brussels ended up last year, but we have more than 2 months to go! I think we’ve every reason to expect great things out of this event… Interested in joining us in Amsterdam in October? Then sign up!

A Quick AlphaLabelIncrementer

On the CruiseControl users mailing list Adam asked for a simple label incrementer that would work with a single character in a series (“a”, “b”, “c”, etc.). Simple enough, but not worth adding to the project, so here it is, test (first) and code.

(Suggestions for better sites for sharing code snippets?)

Tic-Tac Change Slides

Back in 2006 Alistair Cockburn and I gave a talk at SDBP on “Creating Change one Tic-Tac at a Time”. As I wrote at the time this talk incorporated ideas from lots of different sources, and I’ve drawn on these ideas on many occasions since then. Most recently I shared some of the slides at CITCON Melbourne during a session on “The People Side of CI“. one big change vs. small changes

I’ve always intended to write a longish blog/article/thing explaining and expanding on the ideas from the original talk and what I’ve learned since (including what came up at the Agile 2007 discovery session). But this isn’t that thing. Instead David Smart, one of the facilitators of the CITCON session, reminded me that I said I’d share the slides. So here are the slides as pdf, and a public commitment to provide more explanation in a future entry.

Blog recursion

Rob Hunter blogged about my blog entry on the iPhone meetup where he showed off Scribular. I remember just enough of my one semester of Scheme to find this blog entry funny.

Post-WWDC iPhone Developers Meetup

Last night I attended a really neat event, the Silicon Valley iPhone Developers mislabeled WWDC Roundup. The only way for the title to make sense is that the speakers were people that organizer Tim Burks (creator of the cool Nu programming language) was able to roundup at WWDC. The panel was composed of:

I loved the event because all of the developers were so charmingly wide-eyed, so stunned and obviously loving what they are doing and the opportunity they see in front of them. David is excited by making novel interactive and social music based software. Steve is still amazed at the response he’s had to the YouTube video of his app Trisim, over 260,000 views. Ramin was showing off PhotoFrolic — take picture, “augment”, share — to people outside his house for the very first time. Rob was able to create on the iPhone an idea he’d had in 2003. And Mike Lee is obviously loving the opportunity to round-up the best developers and pull them into a much more ambitious iPhone startup than the others on display, all for his end goal of reforesting Madagascar.
A couple things I found particularly interesting:
  1. Of all the panelists, only Mike Lee had previous experience with Objective-C and Cocoa. Steve is a .NET developer. Ramin Python/Django. Rob wrote his backend web service in Scheme for god sake. Which brings me to…
  2. All of the applications under discussion have their own backend web service. I’ve ranted to a few friends lately that the future of web apps is native code, and this was an eloquent demonstration
Tapulous’s FriendBook app is a great example. It allows you to exchange contact information by handshaking  your iPhones at each other. But this isn’t some local data beaming! In the coffee shop/airport setting you might be on different wireless networks (3G vs Edge vs WiFi), so you’re making a remote call back to the cloud with your location and it matches two people in the same place making the same motion. Your web app have access to the accelerometer? I didn’t think so.
Anyway, great meeting, great group of people, and from what I saw we’re all going to be blown away with that AppStore finally opens.

WatirCraft announced

Bret Pettichord announced his next big thing yesterday: WatirCraft, a company around the popular testing library Watir. In his announcement Bret explained that WatirCraft is making a few bets:

  • “We are betting that we can build a business around making testers successful with automated testing.”
  • “Pete and I are making a bet …[on] the vision … automation is about code and success requires understanding code, and making code understandable.”
  • “We are also betting that people want and will be willing to pay for a framework that is easier to use.
  • “We are also betting on Ruby.”
  • “We are also betting that the growing use of Agile Development practices will continue.”
  • “We think testers do have a significant role in the future of automated testing.

Based on my experiences over the years, I think that Pete and Bret have made a lot of reasonable bets.

At Agitar we had literally hundreds of companies as customers, which is pretty significant when you realize that our prices started at around $35,000 and went up to seven figures. That’s a good indication that there’s a market for helping people succeed at testing their software.

From my time in QA doing test automation with the Mercury tools, I agree that successful testing required actual coding. I think this has been a barrier to success with traditional automation attempts, at least in Silicon Valley. To be a successful required coding skills, but if you had coding skills there was a higher paying and higher prestige job waiting for you in development. It has gotten to the point that it is actually more difficult to find a good tester than it is to find a good developer because development is such a compelling brain drain.

But Bret’s right that agile development is the future and “testers on agile teams are being hammered by shorter iterations“. Because automated testing is so key to successful agile development I think this means market forces should swell the ranks of tester-developers and developer-testers. (Of course since I used to blog at DeveloperTesting.com it isn’t surprising that I feel this way…)

Finally, I think WatirCraft is right to focus on the tester side of this equation. I was exposed to dozens of teams all over the world while at Agitar and what I saw was very consistent. There was widespread interest in developers testing their code but often only because you were supposed to as part of “going agile”. I saw only a few teams where the testing done by developers was considered to reduce traditional testing to any great extent. Companies want their developers developing, not testing, so I’d agree that the bulk of future test automation will belong to testers.

Heading to Melbourne

In a couple of days I’ll be heading down to Melbourne for CITCON‘s 2008 Asia-Pacific event. While I’m there I’ll also be visiting the Victorian Java User Group on June 26th and giving a talk on (what else) Continuous Integration and Testing.

I’m very curious to see how this year’s A-P CITCON plays out. Last year’s event in Sydney was our largest event to date, but this year we have even more people registered. At this rate, we will need to close registration and turn people away for the first time! It is true that the crowd in Sydney last year was the least familiar with the Open Space concept. While it all turned out fine there was some rough spots (imho) when it came to activities like refactoring the schedule on Friday night. At most events there are enough people who understand the role of “schedule gnomes” that things move smoothly without Paul and I getting involved, but in Sydney it took a bit of coaching to get that to happen. It’ll be interesting to see if this year, the larger crowd means we hit critical mass in terms of attendees with Open Space experience.

Hello world!

I needed a blog to replace DeveloperTesting. It is frustrating to lose the history of posts and the accumulated Google status, but there’s also something refreshing about a new start. Perhaps in time I’ll resurrect some of the posts that used to live there into a “greatest hits”, but until then please enjoy this clean uncluttered space.