You are here: Articles --> 2000 --> Examining and applying what we learned from Y2K

Vous êtes ici : Essais --> 2000 --> Examining and applying what we learned from Y2K

Examining and applying what we learned from Y2K

by Geoff Hart

Originally published as: Hart, G.J. 1999. The desktop wars: year 2000 version. ComputerWorld Canada, Oct. 22:17. Republished as: Hart, G.J. 2000. Examining and applying what we learned from Y2K. http://www.techwr-l.com/techwhirl/magazine/usersadvocate/usersadvocate_y2k.html

Like most computer professionals, you probably had your fill of preparations for the year 2000 problem. You may have even stepped forward, as many technical communicators did, and played a role in addressing Y2K issues at your company. For example, if you worked for one of the many farsighted companies that spotted the problem before it became insoluble in the time remaining before midnight on December 31st, you may have helped do several things: scare Management into providing resources to fix the problem, make every computer Y2K compliant or replace it, update commercial software to the latest (Y2K-compliant) version, and read the riot act to your partner organizations until they reluctantly became Y2K-compliant, too. Or, if you were part of the development team, you may have even helped bring the hardware or software that you documented into compliance and helped verify that your employer's home-grown, company-wide MIS (Management Information Systems) applications were compliant. Even if you weren't one of the detectives, you may have documented their efforts, thereby playing a small but important role in this process.

Whether you were a detective, a fixer, or part of the documentation team, you were part of the solution. And, when the big day finally arrived, all that preparation made the disasters few and far between, and mostly easily resolved. For many of us, the Y2K compliance process led to new discoveries and opportunites, as well as lessons we can apply even today.

One of the more interesting discoveries to come out of this effort was the recognition that far more programmers existed than anyone had ever imagined, and in the words of a recent, culturally iconic film, the problem came down to some simple words: "A long time ago, in a corporation far, far away... Desktop wars: The PC Menace." In this particular civil war, the Rebel forces were represented by the rebels who had embraced personal computers (technical communicators among them), visionaries who escaped the MIS Empire and began subverting the established order by managing our own computers—and in many cases, programming those computers. Spreadsheets such as Lotus 1-2-3, databases such as dBase, and languages such as BASIC (or its modern descendant, Visual Basic for Applications) were easy enough to use that just about anyone could write their own software, whether actual standalone programs or "macros", without having to rely on the Empire. It was as if we'd discovered a mystical "force" that permeated our computers and mastered that force to accomplish miracles seemingly beyond the reach of ordinary mortals. Things formerly beyond the reach of anyone outside the Empire, for that matter.

But for all our claims of superiority over the Empire's software developers, it turned out that even amateur programmers were still programmers. And as the clock ticked down towards Y2K, the teams responsible for averting the crash discovered to their horror that the magnitude of the problem was far greater than they'd feared. The problem was that years of civil war had led the Empire and the Rebels to achieve a state of détente: the MIS people retained their crucial role in corporate computing, but let substantial power migrate downward toward the desktop and into the hands of those rebellious "end-users". This empowerment was certainly a good thing, but "the force" also had its dark side: kludges.

Over the years, the Rebels had created dozens—and in large corporations, perhaps hundreds—of small custom databases and spreadsheets and Word templates. Some of these were applications any developer would have been proud to have written: tightly coded, rigorously debugged, mission-critical (for that person), Y2K compliant, and well documented. Unfortunately, the remainder were sloppily coded, poorly debugged, mission-critical (for that person), not even remotely Y2K-compliant, and lacking in anything resembling documentation. Downright kludgey, in fact. The implications were scary, and companies coped more or less well with alerting users to these smaller-scale Y2K problems and helping to resolve them.

But even in these dark times, a new hope became apparent: the Y2K problem had revealed an opportunity. The expertise developed over years of solving Y2K problems built a bridge between the Rebels and the Empire because the time spent explaining the Y2K problem often opened lines of communication that had long since been closed by the seemingly unshakable antipathy between the MIS Empire and the Rebels. And, perhaps most notably for us, technical communicators often played an important role in that communication. By acting in roles to help identify Y2K compliance issues, help fix them, or document compliance processes and solutions, many of us helped open the lines of communication and created bridges that were previously not there.

With the Y2K panic now over, it's tempting to relax our efforts and return to the old ways, retreating into our isolation and letting the old divisions between MIS and the user community widen again. Instead, we should take the opportunity to use those bridges now established, continue to shrink those divisions, and apply what we learned from Y2K to today's projects. Of course, the civil war between MIS and the workers they support is not going to vanish overnight, if ever, but the modus vivendi inspired by the Y2K crisis can endure. We can and should apply today what we learned from the Y2K experience: the lesson that those who develop or support software and those who use it can overcome their hostility and work together to make things better for both groups. And isn't that what we technical communicators strive to do every day? We spend our hours documenting software that ranges from reasonably friendly to actively user-hostile, thereby building bridges across divisions, and that expertise can and should continue to foster an attitude that those who develop need not inevitably war with those who use.

©2004–2024 Geoffrey Hart. All rights reserved.