Art

account for 90% of what I use regularly, the differences
are miniscule between the current version of
Microsoft Word that I use today under Windows
and the Wordstar program I used in 1980 running
on CP/M. There has been little increase in basic
abilities or performance from the user perspective.
In fact, today’s application leviathans often take as
much time to launch from our ultra-fast hard drives
as those lean but effective programs of yesteryear
loaded from pitifully slow 8-inch floppy
disks.
Ironically, even as hardware has become increasingly
reliable and dependable, software has become
far less so. It has been years since I’ve had to deal
with a disk crash, yet hardly a day passes without
the operating system and application software conspiring
to crash one or more of the machines in
my office. A six-year-old machine that serves as
our firewall sits with its disk spinning away 24/7
for years with nary a glitch, yet Windows goes
brain-dead if it is not rebooted at least once a
week.
We have been peppered for decades with claims
about the accelerating pace of change, yet many of
the processes that shape the practices in computer
science and software engineering grind glacially
slow. Today, for instance, the core software engineering
concepts of coupling and cohesion are
cited in nearly every basic text and are taught in
colleges and universities around the world, yet it
took nearly a decade to get anything published in
an academically respectable journal and another
decade before significant academic adoptions
occurred.
Ultimately, the true pace of change is not dictated
by the evolution of science or technology or
of ideas, but by the capacities of humans and
human social systems to accommodate change. A
product, a service, a practice, or a perspective—
however new and innovative—can have no impact
without acceptance; no significance without change
in people and their institutions.
Hiding in Hardware
The true problem with software is hardware. We
have been seduced by the promise of more and
more and have become entranced under the spell
of Moore’s Law. Continued progress in hardware is
not a friend, but our nemesis. We have been
shielded by hardware advances from confronting
our own incompetence as software professionals
and our immaturity as an engineering profession.
Contemporary programmers will point to the
operating systems and protest that programming
environments today are enormously more complex
than those of yesteryear, but the real problem is in
how we deal with this situation, in the discipline—
or its lack—through which we attempt to overcome
complexity.
Some years ago when one of the then-leading
computing companies surveyed its own internal
software engineering practices, the most mature,
systematic, and disciplined programming
processes were found among application programmers
producing business software for internal
consumption. Next in line were those creating
engineering applications. On down the line and
rock-bottom last were the so-called professionals
writing the core operating system and its utilities.
Where discipline counted for the most, it was
least evident.
The story has changed little today. Our profes