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
