Debugging History – Origins

Whether you are working, sitting on your couch, watching TV, shopping, or booking a vacation ticket. The world around is full of software. Applications that were built by someone by making them an idea, then plan, then executed into existence. Some that know how software development works, understand that as long as humans are responsible for building apps, there will be errors – bugs that need to be debugged. But how all that started? Let’s talk about debugging history.

The first actual case of bug in debugging history

Let us jump into our Wayback Machine and go back to 1945. A significant year for the entire world for the socio-political reasons, but not many know – it is also the year where the first bug was found.

The first computers were overgrown calculators, and The Harvard Mark III was undoubtedly one of them. Also known as ADEC (Aiken Dahlgren Electronic Calculator) has been developed at Harvard University for the US Navy. It packed a fantastic power of 16 bits, allowing it for the multiplication time of 13,200 milliseconds.¹ Genuinely incredible beginnings for the Computer era to come.

Grace Murray Hopper was developing Mark III, and its predecessor – Mark II, while she encountered a problem. After some tests, she has decided to look inside and have found an actual moth – a bug. Thus the term “debugging” was born, as she did (literally) remove the bug.²

Although I once found a dried leaf inside my CD-ROM, having absolutely no idea how it ended up there (for the record, I blame wormholes) – thankfully, I do not have to debug my computer or applications with anti-insect solutions. Although some of them seem to like my monitors. Let me know if you have ever found a real bug in your PC. Perhaps you have a photo?

Debugging history: The Battleship method

The game of Battleship has its origins most likely in World War I game, called L’Attaque.³ Players have their turns, where they are calling the “shots” to sink other players’ ships, often starting randomly.

Thus debugging with the Battleship method is a hit-or-miss approach. In the beginnings for some years, debugging meant dumping data of the system or output devices – literally printing, or displaying some flashy lights if there’s an error. A very patient programmer then would go step-by-step through the code, reading it to see where the problem may be. Imagine the frustration!

Some long, looking through the code years later, the CRT terminals appeared, removing the need to punch the card. Such on the go results from the code allowed the much-needed change for the computer programs. They evolved from being batch-oriented to user interactive. Such massive revolution removed a problem – the need to run them at night or successive days and requiring user input on almost every single step.

Being able to see the output as the program runs instead of nervously waiting for it to finish. It was fantastic. What a leap forward!

Allowing software to help to debug software

The unifying part of the previously mentioned methods is human input. There were no such things as debugging software, the debuggers were a bunch of very patient and talented people. And as we all know, we tend to be non-ideal. After all, human error is the most common reason for most failures.

That is why when command-line debuggers appeared on the horizon, we faced another revolution. Although very simple – they moved the massive boulders of debugging from the programmers’ back. At least part of it. A developer no longer has to play a Nostradamus, touching his crystal bowl. He no longer is required to guess the memory address values of the application. Outsource it to a debugger, let it dump them with given memory locations. What a relief.

Imagine a situation where you travel to another country and want to order a cup of excellent coffee. But to do that, you need to read the entire dictionary and learn every word. Crazy? The necessity to do that on the debugging level was removed by the first debugging software. Now a programmer could focus on the part he needed to concentrate on, look directly at the specific registers and memory blocks containing the address of the local program variables.

Since the correct debugging methods were still being developed, the computers for almost half a decade were prone to many faults and errors. Never to be fully trusted, even while being extremely useful. Perhaps the most terrifying example would be a bug combined with a human error which almost started World War III, and possibly would result in the destruction of half – if not an entire planet.

A historical bug that almost destroyed two superpowers

A North American Aerospace Defense Command (NORAD) is a joint operation between the American and Canadian army. Its mission is to detect and respond to nuclear launches anywhere on the globe. As well as monitoring the entire air space across the North American continent.⁴

In 1979 an engineer inserted a tape into a NORAD computer networked directly into the defense missile warning system. Just three seconds later, all monitors across the room came to life with warnings regarding a missile launch within the Soviet Union. Radars scattered across Alaska, Canada, and Greenland confirm launches all across the Soviet Union. The missiles are still too low in the atmosphere to calculate the origin of their starts or their final trajectory. Twenty seconds later, space-based thermal-imaging satellites confirm hot pings from within the vicinity of known Soviet missile sites.⁵

At Eielson Air Force Base in Alaska, the ground crew rushes out into the freezing winter weather to prepare the alert aircraft for emergency take-off. Meanwhile, a separate warning sounds at Strategic Air Command Air Force bases around the globe, and in the United States, pilots rush to their B-52 nuclear bombers. The alert also puts a Strategic Air Command Looking Glass aircraft on alert, holding a general officer with access to every American military network in the world. They start making preparations to take over in case the High Command gets nuked on the ground.

Meanwhile, in Andrews Air Force Base near Washington DC, the National Emergency Airborne Command Post starts preparations to evacuate the President or his successor.

All of this happened within twenty seconds after receipt of the first nuclear launch alert. Thirty seconds after the alarm, Zbigniew Brzezinski – the national security advisor receives a phone call with a piece of information, that there is a confirmation of Soviet nuclear launch – 250 confirmed bogeys with a final trajectory into the continental United States. The President of the United States now has only three to seven minutes to decide on retaliation.⁶

Ten F-104 interceptor jets are being launched from Eielson Air Force Base, carrying air-to-air missiles and a single nuclear-tipped .25 kiloton-yield ones as well, each.

A minute and a half after the alarm a dozen B-52 carrying a nuclear warhead are airborne, heading deep into the Soviet Union. Hundreds of missile silos across the United States prepare for launch nukes at each significant Russian city, each missile is containing up to a dozen independently targeting warheads. They also aim farmlands, making agriculture impossible for decades.

Two minutes after alert, the United States Navy has set up around the globe with nuclear ballistic missile submarines at full alert. Their crews prepare to deliver a deadly nuclear-tipped cargo and to intercept any Soviet subs. Brzezinski then receives a second call alerting that they are detecting above two thousand missiles, however, that there are also some issues with ground-based and satellite assets, which report no missile launches. Time to call the President.

While American planes are speeding to the defense zones, no soviet bombers are inbound. Ground-based radar reports no abnormalities, no sign of enemy aircraft over the Bering Sea, or the Kamchatka Peninsula.

After the call, one minute later, the President issues a stand-down order for all American nuclear alert forces. A few minutes later, the technicians at NORAD will discover that the computer tape inserted into a unit was used as a training exercise to simulate a full-scale nuclear attack. The computer, however, managed to feed false data to an early warning system.⁷

For American readers – do not worry. In 1983 the nuclear early-warning system of the Soviet Union falsely reported the launch of intercontinental ballistic missiles from the United States as well. It was caused by the malfunctioning satellite warning system.⁸ On the second thought, perhaps you should worry even more.

What happened then?

Feel free to contact me with any feedback, some additional debugging history stories, comments, or questions. There are plenty of developments in this field, and I am very keen to find out what I can learn from my readers!

• Azure Functions: Overview and Common Use Cases
• How to enable error reporting and monitoring for Azure Functions

Sources of debugging history:

1. Magazines, Hearst (November 1949). Popular Mechanics. Hearst Magazines. p. 112.
2. “Danis, Sharron Ann: “Rear Admiral Grace Murray Hopper””. ei.cs.vt.edu. February 16, 1997. Retrieved January 31, 2010.
3. Hinebaugh, Jeffrey P. (2009). A Board Game Education. R&L Education. ISBN 9781607092605.
4. NORAD – Fact SheetArchived 1 November 2013 at the Wayback Machine.
5. “Close Calls with Nuclear Weapons” (PDF). Union of Concerned Scientists. Retrieved 5 April 2016.
6.“The 3 A.M. Phone Call”. The National Security Archive. George Washington University. 1 March 2012. Retrieved 4 August 2016.
7. Sagan, Limits of Safety, 228-229, 238.
8. “Another day the world almost ended”. RT. 19 May 2010. Retrieved 17 January 2018.