Field Note #13 ∷ Reading the Seams (A Postmortem on a Postmortem)

On the last night of 1999 I was twenty-two years old, in a house with ninety days of drinking water in plastic barrels, and a year of dried food stored in the cellar.

It was not my food.

I had been working in IT since I was fourteen. I knew my way around a Unix prompt. I was completely certain that the whole thing was nonsense.^✾

I was partly right. I could not have told you which part.

I. A report worth rereading¶

There is a printed copy of Y2K Aftermath: Crisis Averted. Final Committee Report. on my desk.^‽ Fifty-odd pages, laser-printed government-issue Times New Roman. Dated 29 February 2000, which is a leap day.

I have had it four days. It is now full of pencil markings.

A word on the subject, for anyone coming in cold. In the late 1990s a great deal of software stored the year (in a date) as two digits, which meant that after 1999 it would count on to 00 and behave as though it were 1900. The remediation effort ran for years and cost, by the Committee’s own estimate, around a hundred billion dollars in the United States alone. Then the date arrived and very little happened, which is the reason Y2K is now widely remembered as a fuss about nothing.

This report is the American post-mortem on that. And on its thirteenth page, in a section asking whether the crisis is over, is a paragraph about a different date-handling problem due in 2038, which the Committee expected to be minor.^¶

That particular paragraph is why the document reached me, and why I read it.

II. What close reading is¶

The term comes from literature, where it means paying attention to what a text is doing rather than only to what it says. The technique transfers to institutional documents better than you might expect, because the mechanism it exploits is structural, not literary.

As plainly as I can put it:

A document says more than it means to.

Not because anyone is being dishonest. Because documents are made, and made things carry the record of their making. The joins show. The spackle sits at a slightly different angle, often perceptible in the right light.

A report of this kind is written by several people over several months, in sections, to a deadline, from material gathered at different times for different purposes. One section may be drafted in January. A chart made earlier for another purpose may be carried forward. The conclusion may be written late, once the shape of the thing appears settled. An appendix may be compiled from whatever has arrived by the printer’s deadline.

Each piece can be defensible on its own terms, and the finished document can still place them in front of the same reader in a way nobody designed.

This leaves seams where two passages sit awkwardly together. Places where an exhibit is still arguing an older case the text has moved past. Places where the document is confident about something it has elsewhere admitted it cannot see.

There is information located in the seams; not hidden, simply not highlighted.

What follows are six ways of reading the seams. Five of them require no special expertise in the subject matter.

I am not a historian of Y2K, and most of what follows does not depend on adjudicating the Committee’s technical conclusions. Everything below came from reading the document with a pencil.

III. Test whether the categories actually divide¶

The 2038 paragraph does not merely assert that the problem is small. It gives a reason:

The Y2K problem was generated by a widely used programming practice, whereas other problem dates are associated with limitations of software systems.

There are two boxes here. Y2K goes in the first: a habit, everywhere, in everything anyone had written. The 2038 rollover goes in the second: a limitation of particular systems, bounded, thinning as those systems age out.

Sort them that way and the conclusion follows cleanly. The paragraph is well reasoned from a faulty sorting.

A widely used programming practice and a limitation of software systems are not alternatives. The second is what the first becomes. Two-digit years were a widely used programming practice, and by 1998 they were a limitation of software systems. That is not two categories, but rather one thing at two points in its life.

Apply the Committee’s own test to the thing it was dismissing. Is representing time as seconds elapsed since 1 January 1970 a widely used programming practice?

The C standard defines a type for holding a time value but leaves the encoding to the implementation. POSIX supplies the specific convention: seconds since 1 January 1970. That design pattern is consequently pervasive across Unix and Linux systems, many language runtimes, database schemas, file formats and protocol fields, in shared libraries that new and old software link against alike, and embedded firmware in devices whose manufacturers no longer exist.

Seconds since 1970 is not an implementation detail of some operating systems. It is one of the most widely replicated design decisions in the history of software.

The Committee applied its own distinction at the wrong layer. What it treated as a limitation of certain systems was also the consequence of a widely propagated programming convention.

Strip the false partition and see what remains of the argument:

Y2K was pervasive because it was pervasive. 2038 is not, because it is not.

Two things are worth saying lest this becomes a verdict.

The first is that the sentence they wrote, timers in some UNIX operating systems, is what a careful non-specialist might well write down after a technical briefing. Some. A property of certain products. That is a reasonable thing to take from an hour with an expert who assumed you knew what a system call was. The error is not sloppiness. It is the ordinary compression that happens when knowledge crosses from experts to the people who must write it down.

The second is that the pattern shifted significantly after they wrote. In 2000, time_t was a Unix-family convention that had spread a long way. It became near-universal partly because of what happened next: Linux went everywhere, the web got built on it, and embedded devices acquired a networking stack and a libc. That is how a class of hardware which earlier mostly had no concept of a calendar date at all came to inherit one, and inherited the broken one.

The Committee mislocated the pattern. But the pattern also grew.

Neither observation rescues the argument, and neither settles the prediction. Whether 2038 causes pervasive problems is not yet knowable; it is 2026. What can be said now is narrower: the stated reasoning of the Committee does not support the confidence of their stated conclusion.

So the first move: when a document sorts things into kinds and then reasons from the sorting, check that the kinds are real.

This is the most portable of the six, because it needs no domain knowledge at all. You do not have to know what time_t is to notice that practice and limitation are not opposites. You only have to take the two categories seriously enough to ask whether anything could go in both.

A great deal of institutional prose runs on partitions that dissolve when you push them. Strategic versus operational. Technical versus policy. Legacy versus modern. Each does real work in the right context, and each, used carelessly, will sort a thing into a box and let the box do your thinking.

IV. Read the dates¶

Appendix II of the final report is thirteen pages of Y2K incidents drawn from seventy-four countries. Taxi meters in Nanjing. Cash registers. Utility bills printed with due dates in January 1900. Godiva Chocolates in New York, total systems failure, back in operation within three hours.

It is the closest thing I have found to a contemporary public catalogue of what actually broke.

And whatever went into it, nothing that surfaced after 29 February 2000 could. That is its horizon, and it sits a mere eight weeks past the rollover.

The Committee flagged this in the appendix’s own opening paragraph:

The full extent of Y2K problems will probably never be known because only a small fraction of the actual occurrences will be reported. There is no incentive for corporations or countries of the world to openly report computer problems... While the sources are considered to be reliable, the Committee was not able to verify each incident or specifically attribute it to Y2K.

They knew what they had, and they said so plainly.

What they could not know is what had not yet surfaced.

In Sheffield, England, a Y2K defect caused hospital software to calculate maternal ages incorrectly during Down’s syndrome screening. Between 1 January and 24 May 2000, the system processed 6,996 tests. When the results were recalculated, 158 women who had been classified as low-risk fell within the hospital’s high-risk category. Contemporary reporting when the inquiry was released said that two terminations had been carried out as a direct result, and that four children with Down’s syndrome had been born to mothers who had been told they were in the low-risk group.^❈

The defect was not found until 24 May 2000.

It had been quietly producing correctly formatted wrong answers for nearly five months. By the time it came to light, the Committee report that was supposed to record what Y2K did had already gone to the printer.

This is not an oversight. It is a property of the instrument.

An eight-week horizon strongly favours failures that are loud and fast: the ones that stop a cash register, halt a train, or produce an error message somebody files a report about. The Sheffield failure was quiet and slow. It produced a number, in the expected format, in the expected place, and the number was wrong.^❦

So the second move, and the simplest one: look at the date on the document, and ask what it could not have known at the time.

Every report has a horizon. Most do not say where it is. This one does, to its credit, and the horizon is still just eight weeks wide.

V. Ask how they could know¶

The report is honest about what the Committee did not know. It says so directly, in a section explaining why its international predictions had been wrong:

It was difficult to obtain accurate and current information about the technological dependencies and Y2K preparedness of other countries. The Y2K experience revealed that little is known about the level of automation in other countries’ infrastructures, such as electric power or telecommunications.

That is a clear, creditable admission. The Committee had spent two years and thirty-five hearings trying to see abroad, and it is telling you plainly that it could not see well across borders.

Two paragraphs later, in the same list, it says this:

Many countries and organizations simply rolled back computer clocks, which allows the temporary claim of compliance but fails to address long-term date dependency problems.

And on page four, earlier and more flatly:

Internationally, most fixes were temporary clock rollbacks that ultimately must be fixed permanently.

Most.

That is a quantitative claim about the distribution of remediation techniques across the very population the Committee had just told you it could not observe well. Automation levels were poorly observed. Remediation methods, which are harder to see because they are decisions rather than infrastructure, were apparently known well enough to characterise the majority.

This is most likely a reasonable inference: countries that began remediation in the final months of 1999 could not have completed full end-to-end repairs, so they must have done something cheaper. That reasoning is sound, but it does not support the word most. Once you see what the report is defending, that most becomes understandable.

The awkward fact in February 2000 was that many countries reported outcomes resembling America’s despite apparently spending a fraction of the effort. They did not really fix it, they only deferred it dissolves that difficulty entirely.

The inference itself may still be true. But it is load-bearing for the report’s own defence, which is precisely when a reader should hold it with tongs.

So the third move: when a document admits it cannot see something, note where it looks confident anyway — and ask what the author would have had to do to know it.

Observed, been told, or worked out: three different warrants, rendered identically in prose. Nobody writes we infer where we found is available.

Whatever the drafting history, the finished document places both claims in front of the same reader.

VI. Read the exhibits against the text¶

Page thirteen carries a chart, credited to the Gartner Group, titled Projected Y2K Failure Timeframes. It runs from before 1998 to 2003, and beneath a peak at the rollover it carries a label: Embedded Systems Spike.

Embedded systems had been one of the loudest elements of the Y2K campaign: chips in machinery that could not easily be inventoried, reached or patched.

Three pages earlier, however, the report gives a strikingly different number:

Analysis of testing during the last quarter of 1999 predicted an embedded chip failure rate of .001%, rather than the 2–3% failure rate projected in late 1998 and early 1999.

That is a reduction by a factor of roughly two to three thousand.

There is an important distinction here. Embedded system is a category of machinery, not a category of date exposure. A controller that never represents a calendar date cannot fail because it represents the year with two digits. The relevant population was therefore not every embedded chip, but the much smaller subset whose software stored, compared or acted upon dates.

That helps explain how an alarming estimate for the broad category could collapse as testing became more specific. It does not explain the Committee’s precise figure. The final report does not tell us what population was tested, how it was sampled, or exactly what counted as a failure. The number is reported without the instrument that produced it.

The chart is not logically contradicted by the later estimate. It depicts when failures were expected to occur, not how many systems would fail; a spike within a very small population is still a spike.

But the visual emphasis remains. A reader looking at the page sees Embedded Systems Spike. A reader following the text back three pages discovers that the expected failure rate had fallen by a factor of thousands.

Both statements can be true. They do not leave the same impression.

So the fourth move: look at what the exhibits claim, separately from what the text claims, and ask what each causes the reader to carry away.

Charts, tables and appendices can preserve an earlier emphasis even when the prose around them has become more qualified. That does not make them wrong. It makes them worth reading separately.

VII. Read the absences¶

Introducing the 2038 rollover, the report reaches for a comparison:

Another potential problem has been predicted for 2038, when timers in some UNIX operating systems roll over much like the GPS systems clocks did in August 1999.

Every word of that is true.

The GPS week-number counter is ten bits wide. It counts weeks, wraps at 1,024, and returns to zero. In August 1999 it did exactly that, and some receivers reported dates from 1980. The Committee is right that this is the same class of failure as the one waiting in 2038: a fixed-width counter reaching its limit.

What the report fails to mention is that GPS rollovers recur.

The counter wraps every 1,024 weeks, a little under twenty years. August 1999 was not a historical event that happened and concluded. It was one instance in a series. The next fell in April 2019. The one after that falls on 20 November 2038. Ten months after the time_t overflow the paragraph was dismissing.

Why the recurrence is absent I cannot know. The effect of the absence is easier to describe. A reader in 2000 comes away with 2038 is like that GPS thing, which was fine. A reader who knows the counter recurs comes away with something closer to the opposite. The comparison the Committee reached for to explain why the class was not a concern is itself a member of the class, and its next instance lands inside the window the paragraph was dismissing.

Absences are harder to find than errors, because a document gives you no marker where something is missing. There is no contradiction to notice, no seam to catch. You find them only by knowing something the document itself does not tell you, which means you cannot find them systematically. You find them when your own knowledge happens to intersect the gap.

That asymmetry is worth being honest about. The other five moves can be run by anyone on any document. This one cannot. It depends on what you already happen to know, which means the absences you can find are a fact about you as much as about the text.

So the fifth move, with that caveat attached: ask what the document does not say, and whether the omission is load-bearing.

And then ask what you are not equipped to notice.

VIII. Ask what the document is defending¶

By the time you reach Appendix II, you have read the same number twice.

The U.S. spent an estimated $100 billion. And, both times, immediately after: In the Committee’s judgment, the level of effort was justified, and the expenditures of the public and private sectors were indeed necessary.

Nobody writes that sentence unless the question is live. It was. In February 2000 the most awkward fact available was that the sky had not fallen, and the obvious inference was already circulating.

Then the report produces its evidence.

Appendix II reads less like a curated exhibit than a compilation. It runs to thirteen pages, covers seventy-four countries, and swings in granularity from a nuclear weapons plant to a chocolate shop.^❧ There is no severity field, no duration, no consistent attribution standard, city names are given without their corresponding states, and one entry consists of just the words Grand Prairie terminating in a comma.

That is exactly why it repays attention.

Now look at what the summary paragraph contains, each item granted exactly one clause:

Degradation of a spy satellite system.

A nuclear weapons plant system anomaly.

Those are the two entries carrying the gravest nouns in the document, and the two about which it tells us almost nothing.

I do not know why. It may be classification, or another agency’s equities, or an unverified account, or incidents that were genuinely minor. The document does not say, and I am not going to guess. Either way the effect is the same: they receive less space than a chocolate shop that we are reassured was back in business within three hours.

The Committee also knew its evidence was thin, and said something remarkable about why:

Because there is no incentive for corporations or countries to openly report problems, the full extent of Y2K’s impact may never be known. Indeed, it is interesting to note that official government reports from around the world report far fewer incidents than reported by news services. For example, 32 countries including Australia, Brazil, Great Britain, Canada, Germany, and Norway reported no incidents on the official International Y2K Cooperation Center’s website despite the fact that many incidents were reported in these countries by reliable news services.

Thirty-two countries told the international coordinating body nothing while journalists in those same countries were reporting incidents. That is not an inference. It is a measured gap between what was known and what was declared, published by the body doing the measuring.

And here is the finding, which took me two readings to see: the exhibit works against the case it supports. Read as evidence that Y2K was serious, what Appendix II gives a reader is taxi meters. It now reads, and is often treated, as evidence that the whole thing was overblown.

So the sixth move: work out what the document is defending, and then look at what it is defending itself with.

Almost every document is defending something: a decision, a budget, a position, a reputation. That is not a criticism, it is a condition of documents existing at all. But it tells you which claims are load-bearing, and those are the ones to hold most loosely — and it tells you where to look, because a document under pressure reaches for its strongest available evidence. If the strongest thing it can print is a single unexplained clause about a nuclear weapons plant, that is worth knowing too.

IX. What they were up against¶

It would be easy to finish with a verdict, and the verdict would be wrong.

The Committee was not careless. It was not captured. It was not, so far as I can find, dishonest in any particular. It was a serious body doing serious work, and where its reasoning fell short, the reasons had little to do with the quality of its thinking.

Consider what it was working with.

The horizon closed too early. Its authorisation ran to 29 February 2000, which meant its record strongly favoured failures that surfaced within eight weeks of the rollover. The Sheffield incident, the most consequential publicly documented Y2K failure I have found, came to light only in May.

The evidence came to it filtered, and it knew. At a hearing in October 1998, sixteen months before the final report, Bennett said this from the chair:^◊

the witnesses we get before us are the witnesses who know what they are doing. And they give a false impression that things are better than they really are because the witnesses that do not know what they are doing refuse to come forward.

The witnesses were positively selected; Bennett knew it, and there was little to be done.

The sunset was fixed before the knowledge existed. S. Res. 208 set the end date in April 1998, two years in advance, before anyone knew what the Committee would learn or what would still be open when it stopped. It could not extend its own authorisation.

And then the part I keep returning to.

It would be one thing if the Committee had failed to consider what happened after it stopped. It did not fail to consider it. It wrote the problem down, in a section titled Maintain / Enhance Y2K Networks and Public/Private Partnerships:

There is some degree of risk associated with the rapid deconstruction of successful Y2K programs and the dispersal of the system expertise that was developed.

On page thirteen the Committee report also predicted that the sensationalism around Y2K had raised awareness enough that future IT personnel would not be surprised by date-related problems.

Knowing that a problem will recur is not the same as preserving the capacity to meet it.

The final institutional record of Y2K contained, on its own pages, both the limits of what it could know and a warning that the capacity needed to learn what came next was about to be dismantled.

The report closes with the observation that there was nowhere obvious for any of this to go:

Many congressional committees have oversight over small segments of critical infrastructure protection, and no congressional committee has the jurisdiction over the issue as a whole.

The Committee named a mechanism worth keeping. The International Y2K Cooperation Center, established under United Nations auspices with World Bank funding, is credited in the report with enabling countries that started late to catch up. The Committee notes that it is scheduled to disband, and recommends replication: some type of similar international coordination mechanism could be useful in addressing future IT issues.

The Center dissolved on 1 March 2000.
The report is dated the twenty-ninth of February.

I can find no evidence that a comparable international mechanism was created.

So the Committee warned against the dispersal of expertise, recommended maintaining the networks, identified a coordinating body worth replicating, and observed that no single congressional committee owned the broader ground onto which its work was moving. Then both dedicated coordinating bodies stopped, within a day of each other.

The Committee identified the continuity gap its own dissolution would expose, wrote it down, and stopped.

This was not a wind-down. This was a coordination cliff.

This is an argument for reading closely, not a reason to distrust the report. None of it is concealed. It is simply not the part that gets quoted.

The Committee’s first report, thirteen months earlier, carried a single line on its cover, beneath the Senate seal:

Competing pressures tempt one to believe that an issue deferred is a problem avoided: more often it is a crisis invited.

The Committee chose that to open their work. With the benefit of hindsight, that would have made a fine closing sentence to the final report.

X. On Monday morning¶

To recap the six moves:

Test whether the categories divide. Could anything go in multiple boxes?

Read the dates. What could this document not have known? Where is its horizon?

Ask how they could know. Where it admits it cannot see, note where it still sounds certain — and ask what they would have had to do to know it.

Read the exhibits against the text. Do they still sit comfortably together?

Read the absences. What is not said, and is the omission load-bearing?

Ask what the document is defending. Those claims are the ones to hold most loosely.

Five require little more than a pencil and the decision to look. The sixth rewards whatever you already happen to know.

Every document has a date, an exhibit, a partition, a defendant, and at least one thing it could not say. That is a description of what documents are.

XI. What this essay cannot do¶

It cannot read the document for you.

That is the whole of it. Everything above is a description of an activity. The activity is sitting down with a printed thing and a pencil for four days, and it does not compress, and there is no version of it that can be handed over finished from an automated pass.

I can tell you that a report from 2000 contains a chart forecasting failures through 2003. I cannot give you the thing that happens when you notice it yourself: the small recalibration, the realisation that the summary you had been carrying was in fact a summary of a summary.

That is simply not transferable.

What I can tell you is that the Committee named its own limits in at least four places. It said plainly that it could not see abroad. It admitted that its own evidence was a small fraction of the whole. It warned that dispersing the expertise it had assembled carried a risk. And it closed by observing that the fragmentation of oversight it had been created to span was still there for whatever came next.

All of that is on the page. None of it is hidden. It is only unread.

Every document you are handed was written by people working under constraints, doing their best with an instrument that could not see everything, who could not know the things you now know.

That is not a reason to distrust documents.

It is the reason to read them closely.

— Trey

Footnotes¶

If you received this via email, the canonical archive version lives here: propertools.be/fieldnotes/field-note-13-reading-the-seams/