Sponsored Link •
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.
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:
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.
|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.|