Just to give you a little background on our environment, when we were developing Unix we actually had a couple of rooms in the attic at Bell Labs with Model 33 Teletypes and a couple of Tektronix 4014s, which actually were very nice for software development because they had big screens and they refreshed fast. We had no Ethernet and no network ex cept UUCP. What was important from the software development point of view was that you released your software into that environment. Presumably you tested it, and if you didn’t, guess who yelled at you? It was all the guys in the room who were using it. You got instant feedback on whether there were bugs in it and whether people liked it or not. If it didn’t work, guess what? It was your reputation at stake and that was pretty instant peer-review feedback, which I think is extremely important in software development. Some of that has gotten lost in some of these big projects, where the engineers essentially have no personal or any other kind of accountability for the quality of the code they deliver into the environment. EA One of the Extreme Programming XT rules is either you have customers who work with the programmers full-time or who are always available, depending on how extreme they want to get. In Steve’s example his peers were his own customers. BC The best software is always developed by those who actually need it themselves. That was certainly the motivation for us in developing mdb and DTrace. It was the software that we needed, so we designed it for what we wanted, and when you can have those two in the same brain, you can develop the best possible software.

Obviously, we’re not developing a banking system for ourselves; and for developers out there in the world, I think Agile and XP attempt to rectify that by having that customer voice as close as possible to the developer.

I think the trick, in any environment, is how do you assure that you are your own consumer? Maybe it’s by having the customer sitting over your shoulder. Maybe it’s what Steve did in the Unix environment at Bell Labs, and what we do here, which is to be sure that those inno-

vations are pumped back into the common environment. Everyone is using a common environment, so even if you are not the most immediate consumer, the person next to you is, and that feedback helps you become your own customer.

SB I would just like to underline one thing. The customer
has two roles here. One is: what does the customer want?
The other involves peer review. There’s a responsibility
and a reputation that you have in a group, which is really
important and doesn’t involve the external customers so
much as it involves the engineers whom you’re working
with. You release to your own group and they’re using the
stuff that you’re using, and that provides instant feed-
back on the work that you

STEVE do. I believe it actually helps improve the quality of the overall group output, as well as the quality of the products that the group is producing. BC That peer pressure is incredibly powerful. We’ve got a very public model at Sun, where failures are very public. That can be too powerful at times, because it can punish failure more than it rewards success. You have to balance the two, and you need both the positive reinforcement and the negative reinforcement. I do wonder, though, when you’ve got development efforts online, with collaborators who are spread across multiple geo-

graphic areas, whether some of that face-to-face positive and negative reinforcement disappears.

EA It depends on the group. Some distributed companies out there make an effort at least once, preferably twice, a year to get everyone together into one room so that instead of just being an e-mail address, they actually have faces. It’s a lot easier to say something inappropriate to somebody who is just an e-mail address than to somebody whom you have actually gone out drinking with. I think that kind of cohesion really helps. For a lot of open source development, which is what I’ve been doing pretty much all of my life, you don’t have travel budgets most of the time so that’s not feasible.

SB I was surprised that the open source model and distributed development actually appear to work quite well.