Article for translators: Why CMSs "Bug" Me

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.

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