ItInsightsWorld Deep Dive: Blue Screens, Vanished Documents and Rotting Media — the Case Against Software Nostalgia

Multiply the volume of code being written by 10x, fail to divide the defect rate by 10, and whatever ships to users can only get worse. That arithmetic is why the "software is decaying" argument lands so easily. This review at ItInsightsWorld decided to stress-test the other half of the claim instead — the half that insists the past was better — by pulling up an archive of what computing actually felt like for anyone who has sat at a keyboard since 1990.

The case for the defence arrives as a set of slogans: "software used to be better in the past", "we've forgotten how to program like we used to", and "software quality has been declining for decades." It is rejected here, and the rejection begins with a single word: horrible. Crashes were not incidents, they were ambient conditions. There were, unquestionably, extraordinary engineers — John Carmack is the standard example, a person who could keep an entire program in his head and refine thoughtful codebases over decades. Those people did not write most of the software everyone else used.

The Operating System Everyone Actually Shared

Dominance here was not a niche story. Windows peaked around a 95% market share, plus or minus a few percentage points depending on the source cited. Yes, you probably knew someone with an iMac who insisted it beat any Windows machine, and they could have proven it if anyone had ever released applications for Macs. Yes, real computing was possible on Linux distributions such as Debian. From my own attempts to install Debian during high school, the most popular app on Linux was anything that could edit XF86Config.

Those cases were exceptions. Nearly every computer user had a Windows machine driven by an Intel or an AMD processor, and Windows carried a long list of problems.

One structural feature did work in the industry's favour, though: a company got exactly one chance to ship its software. At a certain point it was going to be loaded onto a floppy disk, burned onto a CD or a ROM, put into a box and mailed out. That version had to work out of the box, which imposed a quality floor you could not fall below.

An Inventory of Failure Modes

What follows is a collection of things remembered from 1990 onward. It is deliberately not linear.

Blue Screens as Background Noise

For most of my childhood, Windows had extreme stability issues.

Allow me to introduce the song of my people: the Blue Screen of Death.

The blue screen of death in Windows XP, Vista and 7, courtesy of Wikipedia

This was Windows' version of a kernel panic. It happened right when you were in the middle of something. Or when you were doing nothing at all. It made no difference: the blue screen was coming.

The causes multiplied. First, device drivers. Buy a new peripheral such as a joystick and it arrived with a floppy disk or CD containing drivers, which you installed dutifully. Their role then was the same as today: helping the operating system understand how to interface with the hardware. That invites a thought: "Oh wow, so they sent out the device drivers on physical media? You can't update a physical disk once you ship it. Surely they took extra care to get everything right." My friend, this could not be further from the truth. Good drivers and bad drivers both existed, but overall they were buggy, and only one marginal device driver could destabilize your computer.

The Windows operating system also had its own code quality problems back then, sometimes failing to fully reclaim resources from programs that had exited. Your computer therefore degraded slowly over time until the rot eventually took the machine down.

Net effect: your computer would simply blink out of existence from time to time, and that was accepted as a cost of ownership.

Documents That Disappeared With the Machine

Guess what pairs well with a computer that crashes all the time. Applications that do not autosave. Even worse: applications with an autosave feature that does not flush buffered writes and corrupts its own save files.

The pattern was reliable. You got into the zone, worked on a document for hours, and then received either a Blue Screen of Death or a pop-up announcing that your application had a problem and had to exit. You screamed and double-clicked your document over and over, to no purpose. You started over. There was a consolation prize, though — your turn to tell everyone, "I was working on a document for THREE HOURS! And then the computer crashed and I lost everything. It was all gone. I had to redo it." There was always that one asshole who said, "why didn't you save?" You did not get mad, because you knew he was 2 weeks from having the same thing happen to him.

How deep that trauma ran became measurable. When I joined the Google Docs team back in 2010, we instrumented the Ctrl+s keyboard shortcut for fun: it did nothing but record a metric saying it had been pressed. That "save" keyboard shortcut ranked in the top 5 non-editing user actions, just behind things like "move the cursor with arrow keys." Google Docs autosaves. Everyone was so conditioned from years or decades of losing work that they reflexively saved anytime they edited anything.

Security a Child Could Walk Through

When my sister and I were little, we loved stores with display units. The computers often had games installed that you could play, and worst case you could always open up MS Paint or Solitaire and mess around for a few minutes.

Once we found a store whose display models had password-protected screensavers. My sister was undeterred: she hit Ctrl+Alt+Del, selected the screensaver application, and clicked "End Task." And we were in. The best minds of Microsoft were nothing next to the hacking talent of a 9-year-old.

That was the level of security your computer gave you. Use the Internet long enough and your machine started collecting advertising malware. Power it on and you were greeted by pop-ups and pop-unders with random ads, even when you were not using browsers. So you ran another antivirus scan, or later you visited websites that could also run malware scans for you.

Then there were the viruses that dropped the Internet to its knees once a year by doing trivial things like "adding a macro to a Word document that sends emails."

The Defragmentation Pilgrimage

Any techie remembers visiting a nontechnical relative's house and finding, in some dusty corner, an ancient Windows computer barely hanging on by a thread. It would literally take 20 minutes to turn on.

You would sigh and say, "let me fix this for you."

You would open two programs, which took about 5 minutes. The first emptied cache files and the Recycle Bin. The second was Disk Defragmenter.

Your computer slowly became unusable if you never saw this window.

Back in the day, hard drives in Wintel boxes stored data on spinning magnetic platters. The drive had a retractable arm with a little magnetic reader, which retrieved data by retracting the arm to the right position and then moving the disk to the start of a sector.

As you added more and more files, the game of Tetris stopped working: the rest of your file did not neatly fit onto the disk before the next file's record began, so it ended up in two places, or more. That was fragmentation. A little was unavoidable, but as more files fragmented, your computer grew slower and slower until eventually Grandpa's computer took 20 minutes to start.

Many modern filesystems, Windows' included, automatically handle defragmentation in the background nowadays. Windows did not back then; you had to start the defragmentation process yourself, periodically.

By the time I reached college I discovered that Windows had a scheduler and could run Disk Defragmenter whenever I wanted, so I left my computer on all the time and let it defragment at 5 in the morning.

Bit-Saving and the 255-Unit Wall

Applications were heavily memory constrained, so programmers tried to save bits and bytes everywhere.

This should have been invisible to me, but it was not.

At one point I owned a crappy video game version of Axis and Allies for the PC, released in 1998 — imagine Risk but World War 2. The AI was really bad and generally easy to beat, but the game had a major flaw: if a country had more than 255 units, the whole game would crash. Naturally the AI also loved to turtle, so it was common for it to hold a territory with over a hundred units that was impossible to wear down. Because of this programming choice, the game became a race to wipe out the enemy before it could force a stalemate by crashing the game.

The details might not be exactly right, but this is what happened, to the extent that the memory survived 25ish years.

This kind of thing happened all the time. During my first programming class in my freshman year of high school, one lesson was effectively "here's why you all recognize numbers like 128, 256, and maybe 65536."

Software That Physically Decayed

Even if the software worked perfectly, you might scratch your game CD and lose the ability to play it. Then you started asking your friends whether anyone had a spare copy of Red Alert or something, just so you could finally finish the single-player campaign.

This was not unique to CDs. Anything physical could degrade. My half-brother had a NES game called Dragon Warrior or something, but the cartridge was corrupted and there was no way to leave the first room. And even games kept in perfect condition could fail, because the contacts inside the NES that connected the cartridge to the console could rust and stop working. This kind of thing happened all the time.

"But Jake, that's hardware and not software." All I am saying is that your software was fragile and it needed to be protected and preserved. It is not like you had the option of a physical disk or the online install and you chose the disk. By the nature of distribution, the software itself would degrade and rot away from you.

Shared Servers, Assumed Decency

One of the earliest online games I played was Diablo II, which means that I have seen the true heart of darkness inside of humanity.

Online games have a strange problem: gamers often do not want to be together. They just happen to share a space. And Diablo II shipped design features that invited chaos:

• There were rampant client-side hacks. On PVP servers, people used hacks to fire tracking arrows far beyond the range they should have been able to.
• All item drops were equally available to everyone on the server. Get close to killing an act boss and you and your party transitioned from allies to rivals, spam-clicking when the boss finally popped.
• With a corpse on the ground, dying again meant losing everything you had equipped. People tried to force you into a full inventory by dropping many cheap items onto your corpse, hoping you would accidentally pick up common items before picking up the corpse. Then you would try to pick up your corpse, pick up only some of the items, and they would kill you a second time so you lost everything you had managed to recover.
• The game had many item duping glitches. As you can imagine, this ruined the in-game economy, which became dominated by duped items, and it enabled many scams. A scammer would pretend to have just duped an item and wait for someone to ask how. Then they would walk the user through it step-by-step, with one step involving dropping your item on the ground — which the scammer then picked up.
• There was no guild system, but people still ran guilds. That meant there was no trusted way to identify guaranteed friendlies.

Many of these were fixed by the time Diablo III came around. There were extra guards against duplicated items. Bosses gave players individual drops, so there was no competition for items when you killed bosses. And you no longer needed to recover items from your corpse in a way that risked losing them. These were all hard-won lessons.

A Button Whose Job Was to Slow the Machine Down

I started using my family's computer around 1990, when I learned how to read. It was a beige 286 that sat on our desk with the monitor perched on top. It had a 5.25" floppy drive. It had a power button. It had a reset button. And it had a TURBO button, meant to be ignored most of the time but available whenever you needed to slow the computer's processor down.

Why would you need that? Because IBM's first desktop computers ran on the 8088 processor at 4.77MHz. Not GHz, MHz! It did not stay this way for long. The problem: many programmers wrote their applications assuming that 4.77MHz processor, synchronizing animations and video game frame rates and generally relying on the assumption that they were working with a fixed clock speed. Run one of those applications on a faster processor and it was likely unusable.

Computer manufacturers devised a simple solution: add a TURBO button that would slow your CPU down on demand. Whenever you hit an application with timing issues, press that TURBO button and watch it slow down to a comfortable speed.

I never needed to actually press the TURBO button in anger. My understanding is that most applications that benefitted from it were games, and we only played newer educational games without those timing issues. Editing this post, I considered dropping this section a few times. But can you imagine having an "Original iPhone" button on the side of your iPhone so that the Notes app could work? Good grief.

The Honest Ledger of the Present

Modern software is not perfect. It is bloated. It is slow. It was written by too many people. It is too complex. It has too many cooks in the kitchen. And now we are losing our grasp on how it works under the hood as we delegate more and more to the agents.

Then	What answers it now
One marginal device driver could destabilize the whole machine	Process isolation
Release onto floppy, CD or ROM and live with it	Online updates, Steam and Windows Update
Manual defragmentation on spinning platters	Automatic background defragmentation in modern filesystems, Windows' included
Pitfalls left exposed by C and C++	Higher-level programming languages that abstract those common pitfalls
Frame rates tied to a fixed clock speed	Game designers handling timing using the system clock

The trade being offered is not perfection, and that distinction matters. What it is, is an end to the ambient failure: no more slow rot, no more boxed releases that cannot be corrected, no more documents lost on an hour's notice. You can keep your old release process that fell by the wayside; the arguments for it were mostly about distribution mechanics that no longer exist.

The sentimental reading of computing history asks you to forget the crash screens, the vanished work, the rusted cartridge contacts, the defragmentation marathons and the annual virus that brought the Internet to its knees. ItInsightsWorld has been using computers since 1990 and would rather remember them. Every complaint about modern software above is legitimate; none of them is a reason to return. So the next time someone tells you software used to be better, ask them what their last blue screen said — and check how long ago the TURBO button came off the front of the case.