Summary
A blog where Michael recounts a number of things that have happened to him this month that are likely of interest to no one but himself, and then finishes with something significant to show late respect for people who've read through the first part after being warned.

---

Advertisement

I've had a busy month and I feel like I'm winding down now. I'm on a flight to the UK to attend the SPA2006 conference, and although it will be another week away from home, I only have a couple of conference commitments there and, well.. I just look forward to this conference when I can get to it.

About five years ago, I did an extended gig working with a team in London and got know many in the London XP community (Rachel Davies, Steve Freeman, Ivan Moore, Keith Braithwaite and several others). They are usually at SPA and I can count on plenty of involved and interesting conversation. The SPA conference itself feels like an extended family.. the sessions are interesting, a bit playful in a way you won't find US conferences, and often very hands-on: there's a hands-on session on the Sun SPOT Technology that I'm looking forward to.

This month has been a real barn-burner for me. I had a chance to teach in Shanghai at the beginning of the month and it was a very interesting experience:

www.flickr.com More of mfeathers256's photos

The next week, I went to SDWest in Santa Clara. Unfortunately, I became about as sick as I ever have been as an adult; it was some sort of a stomach flu. It lasted only a night, but I spent the rest of the week dizzy, nauseous and barely able to cope. I did my class at the conference. I suppose it went over reasonably well, but I'm sure some people wondered why my face kept changing colors. Sadly, I spent most of the time in the hotel room. The program described a great conference. Too bad I couldn't attend much of it. I did get a chance to get out and attend a session that Rob Walsh did on CppFit and Fitnesse. Rob' session was great, and I left resolving to do something to add Rick Mugridge's fixtures to CppFit. I met Scott Meyers and spoke with him a bit about C++, refactoring tools and legacy. I also had a chance to meet Peter Scott, the author of Perl Medic: Transforming Legacy Code. We chatted about legacy issues.

Last week, I was teaching in St. Louis (yes, that's a lot of teaching. I can't wait until May, I'm starting on an extended mentoring gig). I spoke to the St. Louis XP Group (XPSTL) on a topic that I've been doing a lot of work on recently: API Design that supports (rather than thwarts) testing. Testing just isn't on the radar screen for API designers yet. How do I know? Well I've spent a considerable amount of time trying to write unit tests for code that uses APIs by various vendors (Sun, Microsoft and others) and it's nearly impossible. API designers nail down their code tightly, and often for very valid reasons and in the end, testing is thwarted. There are no perfect solutions for this problem, but there are things we can do.

So, I'm winding down and taking some time to think about a few things. I don't like to write laundry-list blogs like this one. If anyone is going to take the time to read my blog I want to say something significant. The significant (in my opinion) thought that I'll leave you with here is one that I heard from Kyle Cordes at the XPSTL group. He mentioned something that his company is doing which looks like it could be very valuable. They've adopted the open source committer model for their commercial development. That is, there are only a few people on a team who have the ability to commit the code. It isn't a new idea; I've heard of teams that do this routinely in mission critical applications, and I also recall hearing that Microsoft does this in house for the OS development. So, I've been aware of the practice, but like most ideas, sometimes you need to hear someone say them in a very convincing way, a way that forces you think about them. The committer model seems like a good fit for teams with wide disparities in skill set. It seems better than code review because bad code never gets into the code base to begin with, and beyond that it can galvanizes the team around a set of standards. Could there be downsides? I'm sure there are. Open source projects are voluntary. Introducing this sort of a power relationship shouldn't be done lightly. I'd expect someone to do it if, for instance, they are creating missle guidance systems, or nuclear control systems, but what about a system with many junior programmers that, say, just controls your enterprise and is responsible for millions of dollars worth of transactions a day? Would you do it then? Probably.

Ideally, I think everyone on a team should be able to commit, but it seems like it would make sense to make sure that everyone who does commit can commit responsibly, that they are able to decide whether a change is good enough to make it into the build. For some teams, it may take a while to move everyone to the point where they are able to commit.

Kyle mentions that this model works resonably well with continuous integration, people often commit several times a day. I can't say I'm completely convinced about this approach, but I'm looking forward to learning more about Kyle's experience.

Talk Back!

Have an opinion? Readers have already posted 1 comment about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Michael Feathers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Michael has been active in the XP community for the past five years, balancing his time between working with, training, and coaching various teams around the world. Prior to joining Object Mentor, Michael designed a proprietary programming language and wrote a compiler for it, he also designed a large multi-platform class library and a framework for instrumentation control. When he isn't engaged with a team, he spends most of this time investigating ways of altering design over time in codebases.