By
Arle Lommel
LISA Publications Manager
www.lisa.org
Get the List of 4,400+ Translation Agencies Now!
No Recurring Membership Fees!
I imagine
that most readers of the Globalization Insider
know the story of the term “bug” in
computer programming: it is a staple of high-tech
etymologies. The story goes that the Mark-II, one
of the first modern electronic computers, was having
problems, and that Grace Hopper, one of the machine’s
maintenance engineers found that a moth had flown
too close to circuitry and had shorted out two components.
When the moth was removed, Mark-II worked again.
Thus was born the term “bug” for an
error or glitch that causes a program to malfunction.
It’s
a nice story, but unfortunately, it just isn’t
true. While it is true that a moth did land in the
Mark-II and cause a problem, and that Grace Hopper
described it as a “bug,” the term had
been around for a long time before the legendary
moth left its mark on the Mark.
The
story everyone knows about where “bugs”
come from just isn’t true.
According
to the Oxford English Dictionary, the earliest known
use of the term “bug” in the modern
sense actually predates the Mark-II by almost half
a century, and was probably coined by Thomas Edison:
Mr. Edison, I was
informed, had been up the two previous nights
discovering ‘a bug’ in his phonograph
- an expression for solving a difficulty, and
implying that some imaginary insect has secreted
itself inside and is causing all the trouble.
(Pall Mall Gazette, 11 March 1889)
While
bugs may not have originated with computers, the
source “bug” was certainly high-tech
(wax cylinder phonographs being the iPods of the
day).
The
first bugs appeared in wax cylinder phonographs,
the iPod of the late 19th century.
There are also early
occurrences of the term to describe problems in
World War II combat equipment (although the general
term at the time was “gremlin” rather
than “bug”), and it was clearly in somewhat
common use in the 1940s. So when the moth in the
Mark-II incident occurred, Hopper probably found
it funny. Here was a literal occurrence of a metaphor
that was already fairly well known at that point.
So Hopper wrote it down (“Relay #70 Panel
F (moth) in relay. First actual case of bug
being found” - emphasis mine) in the Mark-II’s
logs (log files were hand-written in those days),
and she even taped the unfortunate lepidopteron
to the page in the logbook. (A picture of the actual
log entry is available online here.)
However,
those who did not know the term then started citing
her description as the source of the term, and thus
was born the folk etymology of the term “bug.”
By now, almost every computer science student “knows”
that bugs originated with the Mark-II, and the story
is widely accepted, even though it has nothing to
do with the real origins of the term.
I find
this story instructive because it illustrates the
tendency we have to see our problems as unique and
to see them as originating in our field of work,
just as computer programmers naturally claimed their
field as the source of the term “bug,”
unaware of the fact that the term had been in use
for a long time before they discovered bugs in their
programs. Right now, we are doing the same thing
in our own industry. Go to any industry event and
you will hear speeches about how we are on the cutting
edge of content management and that translation
memory was content management before there was content
management (whatever that means), etc., etc. We
explore the difficulties of dealing with content
and the growing pains we face as we figure out how
to fit CMSs (content management systems) and GCMSs
(global content management systems) and GMSs (global
content management systems), and whatever acronym
we’ll come up with tomorrow, into our processes.
Then we pat ourselves on the back for being ahead
of the curve and cleverer than those who don’t
understand the content mandate.
In
LISA 2011, you won’t hear a single speech
about why we need to use CMSs.
Of course,
the fact that we have to talk about content management
so much only shows that it isn’t nearly as
ingrained as we would like to believe, or we’d
be talking about other things. No one talks about
whether or not to use TM at LISA events anymore,
even though in 1997, when I first attended a LISA
event, that was a major topic. I predict that in
LISA 2011 you won’t hear a single speech about
why we need to use CMSs since that subject will,
by then, be as out-of-date as talking about whether
or not to use TM.
After the recent LISA
Global Strategies Summit in Foster City, California,
I shared a shuttle ride to the airport with Hanspeter
Siegrist, a member of LISA’s Executive
Board, and Siegrist made a telling comment. He said
that attending a LISA Forum today is like attending
a programming conference in the late 1970s. At that
point, everyone was grappling with the difficulties
due to the lack of reusability in computer code
and promoting code management systems and code modularity
(just another word for “chunking”).
Many of the solutions arrived at then have descended
to become the architecture of programming languages
we use today and have had a tremendous impact on
how computer programs are written. They even created
the conditions necessary for the tech boom that
started in the 1980s and that has, with a few minor
hiccoughs, continued to this day.
Admittedly,
human language is not the same as computer programming
languages, but the issues Siegrist described to
me were not just similar to those we discuss today
at localization events — they were the very
same issues, and the solutions we are arriving at
(such as content “bursting” described
by Mark Bierle of P.H. Brink at the recent Summit)
have close analogues in the solutions that were
arrived at by programmers who faced these problems
thirty years ago.
We
are like guests who arrive after the party is over
and conclude that the lack of people means we’ve
shown up early.
So next
time we congratulate ourselves for being ahead of
our time, we should consider that we are like guests
who arrive after the party is over and conclude
that the lack of people means we’ve shown
up early. Unfortunately, if we believe we’re
“there” before everyone else, we naturally
look to ourselves to solve the problems we face,
when we should be looking at how others have dealt
with the same problems so that we don’t reinvent
the wheel. Will all the solutions arrived at by
programmers over the past few decades work for us?
Clearly not: human language is different from computer
language, and our tasks are different, so even if
the problems are the same, the solutions may well
be different. But will some of the programming solutions
work? Probably yes, but we won’t know if we’re
so busy trying to create our own solutions that
we don’t look at what’s already out
there.
The good
news though is that if we’re in the same place
the software industry was thirty years ago, maybe
we can look forward to the coming “language
boom” and in LISA 2030 we can really pat ourselves
on the back for having been the first to see it
coming.
-Arle Lommel
P.S. We would like
to recognize E. Smith Yewell, CEO of Welocalize,
who was named
winner in the “Realizing Business Potential”
category of the Ernst & Young Entrepreneur
Of The Year 2004 Awards in Maryland. Smith was selected
from among 28 finalists in Maryland by an independent
panel of judges comprised of local community and
business leaders, and is eligible for the national
award, which will be given in November. Congratulations,
Smith!
Reprinted
by permission from the Globalization Insider,
15 July 2004, Volume XIII, Issue 3.1.
Copyright
the Localization Industry Standards Association
(Globalization Insider: www.localization.org,
LISA: www.lisa.org)
and S.M.P. Marketing Sarl (SMP) 2004
Read
more articles - Free!
E-mail
this article to your colleague!
Need
more translation jobs? Click here!
Translation
agencies are welcome to register here - Free!
Freelance
translators are welcome to register here - Free!
Subscribe
to TranslationDirectory.com newsletter - Free!
Take
part in TranslationDirectory.com poll - your voice
counts!