There’s another XP tenet that I think ties into this, which is to make short software iterations. Two weeks is the one that you usually hear. That sounds great to me for small projects, but I’m not sure how you can, for example, put SMP (symmetric multiprocessing) into the kernel in two weeks.

BC We absolutely do it. In fact, we’ve got as big a software project as you can find out there, and we operate on a two-week model. Every two weeks, you cut a build. You don’t do SMP in the kernel in two weeks, but you have a bringover/modify/merge model for your source base.

DTrace was integrated into a Solaris build that way. We didn’t do DTrace in two weeks, but what we did do is have a DTrace gate that was tracking the Solaris gate.

Every two weeks, we would pull down the changes into our DTrace gate, so we were tracking it for the two-and-a-half years that DTrace was in development. Then as you get closer and closer, you’re obviously tracking that more and more tightly, and then you’re finally integrating.

But every two weeks, you’re cutting a build. Obviously, lots of software takes much longer than two weeks in development, but the key is that you are constantly cutting builds because those builds do force you to get to a certain level of quality.

EA I tend to agree with that, but those builds are necessarily going to have half-implemented features in them and pieces that aren’t completely tested.

BC Our mantra is production quality all the time. There would need to be a business case for a half-implemented feature to be in your source base. Why does the half-implemented feature need to be in my source base and not in a gate that’s tracking my source base? Sometimes there’s a good reason for that because I’m maintaining all these hooks and these subsystems that are changing and it’s killing me and I’ve got to integrate my hooks, but in most cases, you don’t actually need to have a half-implemented feature.

EA When you say a gate, are you talking about a branch? BC Yes, I’m talking about, effectively, a branch that is kept in sync with your main trunk.

EA I would argue, though, that putting things out on a

branch is cheating on some level because ultimately you have to merge it back in. One of the arguments for the two-week model is that there’s always code review and the changes will always be small enough that you can do a pretty quick code review.

Now you suddenly have this branch with a year’s work on it. Do you now say, “OK, next Tuesday, I’m going to merge that into the trunk”?

BC But in that branch,

you code review as you go.

Should you ever go more than two weeks between ^{The basic concepts of} put-backs, to either the good hygiene on getting code ^{main repository or a} written are not really any ^{branch? My answer to that} would probably be only in different for server code versus rare circumstances. There _{user-interface code.} have been times where I needed to go more than Eric Allman two weeks between put-backs.

I’m not putting back to the main trunk necessarily, I’m putting back to all my

branches, which I will then put back to the main trunk in, say, two years. But if I’m going more than two weeks, I’ve got to have a whole lot of balls in the air, which is sometimes the case.

EA One of the things that I’ve felt for some time is the trunk should always build. Branches can be in partial states, but if you’ve got something half implemented, the worst case, of course, is when the trunk won’t even compile.

BC I think that branches should always build, the trunks should always build. Now the branches of a branch—that is to say, your own private work space—well, that isn’t built when you go home at night. Fine, because no one is using it.

 

SB I think one of the things we might want to touch on here is dependency management. You said something earlier that is really important: you need to be able to pull features out of a release if you find that for some reason they don’t work down the road. That gets really difficult, however, depending on what the dependency trees look like, so my question is, have you seen improvements in the tool base and in the IDEs for managing dependencies between the different components of the software that you’re building?