V
viewpoints
DOI: 10.1145/1498765.1498777
Kode Vicious
System changes
and Side effects
Comparing the potential benefits of system changes that help
and the detriments of changes made for the sake of change.
Dear KV,
I maintain a legacy system at work that
uses Makefiles for building the code.
Recently my company switched to a different system—SCons—for doing software builds and now I’m being asked
to update our legacy code to build with
this system. Personally, I don’t see that
we will get any benefit switching a legacy system’s build strategy, but it’s an
order from management so I will likely
have no choice. Why would anyone
bother to switch a working build system to a newer one? Are build systems
really that different? Is there really any
innovation here that could matter?
All Built up
Dear Built up,
illustration by ryan alexanDer
Innovation, as someone should have
said, is in the eye, or perhaps hands,
of the beholder. KV rarely condones
change for its own sake: the change has
to have some appreciable benefit to
those who are working with the system.
As this relates to build systems, there
are few things more important to a programmer’s work flo w and therefore productivity than how their system is built.
A poorly implemented build system will
impede progress and lead to wasteful
programmer downtime, mostly made
up of programmers playing games in
the hallway, buying questionable items
on the Web, and learning yo-yo tricks.
All fine pursuits of course—I learned at
least five yo-yo tricks on one job when
it took 20 minutes to build a piece of
software, and the build locked up the
machine we all used for our work. Of
course such crippling times are in the
past now, with the advent of speedy
CPUs, memory, and disks there is no
longer any wasted programmer time,
and we can all depend on a quick com-
pile/link phase. Uh, perhaps not.
There are several reasons why people switch build systems. I think the
most common one is that people hate
and fear Makefiles. Other than the mis-named autotools there is probably no
APriL 2009 | voL. 52 | no. 4 | communicAtionS of the Acm
25
