EA I’ve definitely seen great improvements—particularly considering that when I started programming, there was no support for it whatsoever. It was just human intelligence, or sometimes not so intelligent. There is support now. I still haven’t seen anything that actually solves the problem. It always gets something wrong or it depends on you to fill in something, but it’s a lot better.

SB Can you find listed dependencies, and do they have names, and do you know who owns them and when they’re going to change? Those seem to be all the important questions.

BC I think as a practical matter, you don’t need to know all those things. Our dependencies are always within the same source base, so there are very few dependencies. We have a luxury because we are the operating system, so for us there aren’t a whole lot of dependencies that are outside the source space. Most projects are going to have dependencies outside the source base—namely, the operating system, certain system libraries, and so on.

Within our group you need to be aware of your dependencies, you need to be aware of what else is going on, but if you have a model where you are constantly in sync with the principal trunk of whatever work everyone is engaged in, you will catch that breakage earlier rather than later.

So, for example, all of a sudden my code doesn’t work and I’ve got two weeks of changes that I need to review. I know it worked with the last build. It doesn’t work with this build. I’ve got no idea why. The failure mode is crazy. I can whittle the problem from one side and actually debug it. I can begin to whittle the problem from the other side, actually going through two weeks of changes and say, “Well, did the XML library change over the course of the last two weeks? Was there a change in the subsystem? Oh, wow, there was a change in the subsystem, let me look at the diffs for this; maybe I can zoom in on this really quickly.”

In some cases—we have had to do this from time to time—you start backing stuff out of your branch. You say, “I’m going to take the stuff that I synced up and rip out half of it and see if I solved the problem.” Those are extreme cases, but by having that two-week granularity it’s still tenable.

SB This has been a good conversation. It’s clear that the software we’ve been talking about in this discussion is mostly system software and really not that far up the food chain in terms of applications. There are doubtless a bunch of things in more layered software that we haven’t addressed here.

EA You’re absolutely correct. In some sense, what we’ve talked about may not be completely applicable to the usual business app or Web site. But I think, actually, a lot of it is transferable. The basic concepts of good hygiene on getting code written are not really any different for server code versus user-interface code.

BC Actually, much of software is system software. I think the stuff that’s higher up in the stack still has a lot of properties of system software. As long as you have soft-ware-software interactions, you’re writing system software at some level, and even when you’re off doing graphics or AI or these other domains, often the problems end up being the same because those projects are themselves integrated into larger software systems. So, I’m going to hope that what we have said here is germane to more than just those folks writing at the lowest level of the system, but I would certainly agree with the caveat that we tend to write at lower levels of the system—but then again, I do write a lot of JavaScript.

The other closing remark I have is this: I think the interesting commonality that we have is that all three of us at some point in our careers wrote a tool that we needed for ourselves. I would say that was incredibly empowering. We solved interesting problems, and we came up with lasting solutions. So, when you have a problem for which you think, “Boy, it would be great if a tool did this”—especially given the plug-in architecture of things like Eclipse and NetBeans—go innovate it! Invent a tool that you need. You will do your best work and you will quickly prove to yourself that the time invested in those tools is time well spent. You’ll prove it to yourself and to your management, and you’re going to make the world a better place.

EA To that, though, I would add one thing, which is to avoid the “not-invented-here” mind-set. Don’t implement a tool that somebody has already implemented. A lot of people don’t do the research to see if there’s a tool out there.

BC Do the research; find the tool. A lot of that stuff is open source. Contribute to a tool that is halfway down a trajectory that you envision. But view your tooling as part of your responsibility as a software engineer. Q

LOVE IT, HATE IT? LET US KNOW

feedback@acmqueue.com or www.acmqueue.com/forums

© 2008 ACM 1542-7730/ 08/0900 $5.00