We field-tested the tale of J. Random Newbie on a number of
experienced programmers. If you the reader are one yourself, we
expect you responded to it much as they did: with groans of
recognition. If you are not a programmer but you manage programmers,
we sincerely hope you found it enlightening. The tale is intended to
illustrate the ways in which different levels of pressure against reuse
reinforce each other to create a magnitude of problem not linearly
predictable from any individual cause.
So accustomed are most of us to the background assumptions of
the software industry that it can take considerable mental effort
before the primary causes of this problem can be separated from the
accidents of narrative. But they are not, in the end, very
complex.
At the bottom of most of J. Random Newbie's troubles (and the
large-scale quality problems they imply) is
transparency
— or, rather, the lack of it. You can't fix what you can't see
inside. In fact, for any software with a nontrivial API, you can't
even properly
use
what you can't see inside.
Documentation is inadequate not merely in practice but in principle;
it cannot convey all the nuances that the code embodies.
In Chapter6, we
observed how central transparency is to good software.
Object-code-only components destroy the transparency of a software
system, On the other hand, the frustrations of code reuse are far less
likely to bite when the code you are attempting to reuse is available
for reading and modification. Well-commented source code is its own
documentation. Bugs in source code can be fixed. Source can be
instrumented and compiled for debugging to make probing its behavior
in obscure cases easier. And if you need to change its behavior, you
can do that.
There is another vital reason to demand source code. A lesson
Unix programmers have learned through decades of constant change is
that source code lasts, object code doesn't. Hardware platforms
change, service components like support libraries change, the
operating system grows new APIs and deprecates old ones. Everything
changes — but opaque binary executables cannot adapt to change.
They are brittle, cannot be reliably forward-ported, and have to be
supported with increasingly thick and error-prone layers of emulation
code. They lock users into the assumptions of the people who built
them. You need source because, even if you have neither the
intention nor the need to change the software, you will have to
rebuild it in new environments to keep it running.
The importance of transparency and the code-legacy problem are
reasons that you should require the code you reuse to be open to
inspection and modification.[140] It is not a complete argument for what
is now called ‘open source’; because ‘open
source’ has rather stronger implications than simply requiring
code to be transparent and visible.
