Arash Abadpour/whyAll 42 entries

42 entries · every claim sourced

Everything arbitrary about software was once reasonable.

Why software is shaped the way it is. Each entry takes one detail that looks like nobody's decision, and finds the document where somebody made it.

For a separate operational view of time, ownership and team activity, see Monitask.

Read the entriesHow sources are handled
card — 80 columns
eighty columnsstill the width of your terminal
  • 42entries
  • 6parts
  • 100%claims with a source
  • 0claims without a year

six parts

Where the constraints went.

Each part collects seven entries around one kind of answer. Nothing here is a list of trivia: the point of every entry is the constraint, not the anecdote.

how every entry is built

Written from the record, not from the retelling.

The same four moves every time, which is what makes the entries comparable and what makes it obvious when a story has no document behind it.

  • 01

    Start from the artefact

    A detail of software as it is now: a constant, a limit, a default that nobody chose this decade.

  • 02

    Find the document

    The manual, paper or standard from the period, rather than the version of the story that circulates.

  • 03

    Name the constraint

    The byte, the counter, the sheet of card or the price of memory that made the decision reasonable.

  • 04

    Say what is unclear

    Where no contemporaneous source exists, the entry says so and stops rather than choosing the better story.

published

Start with these.

Entries already written, each one a single question followed to its document.

from the record

The people who made the decisions, on the decisions.

Not testimonials. Short remarks by the engineers involved, each attributed and dated, and each examined in the entry it belongs to.

  • “I call it my billion-dollar mistake.”

    C. A. R. Hoare, on introducing the null reference2009

  • “The implementation is simple and elegant.”

    M. D. McIlroy, on the pipe mechanism1964

  • “Adding manpower to a late project makes it later.”

    F. P. Brooks, The Mythical Man-Month1975

what this is for

Not nostalgia. Prediction.

Several of these entries describe decisions that were correct when they were taken and are wrong now. Several describe designs that lost deservedly. The point is not that the old work was better.

The point is that this field repeats its own arguments every fifteen years under new names, so reading the previous round tells you a great deal about the current one: which objections were already answered, and which were merely forgotten. A structured editor argument returns as a formatter. A capability argument returns as a sandbox. A specialised hardware argument returns with every new accelerator.

The entries are short and the sources are shorter. Most of the documents referred to here are a few dozen pages, written by people who expected to be read by implementers rather than by historians, and in the majority of cases the popular summary is wrong in a specific way the original settles in a paragraph.

how to read it

Every claim carries its provenance.

Beside each passage is the source it rests on and the year of that source. The kind of source is named too, because a manual written at the time and a recollection given forty years later are different classes of evidence and this document does not blur them.

Where the popular version of a story is contradicted by the record, both appear: what people say, then the document that disagrees. Where the record settles nothing, the entry says so and stops rather than choosing the better story, which happens more often than a tidy history would suggest.

Every entry ends with what it cannot verify, including the places where the only account of intent belongs to somebody who knew how it turned out.

Nothing here is a product recommendation, a comparison of current tools, or an argument that anybody should adopt anything. The subject is why things are the way they are, and the use of knowing that is to recognise the shape of a decision when it comes round again.

where to start

Three entries that carry the whole argument.

The one about where the epoch came from, because it is the shortest demonstration that the familiar explanation is usually a summary of the wrong part.

The one about the ratio between programmers, because it shows what happens to a finding when the conditions attached to it are lost.

And the one about the system almost nobody used, because it is the clearest case of ideas outliving the thing that produced them, which is what most of this document turns out to be about.

team operations

Tools for software teams.

Three comparisons for time records, delivery workflows and documentation.

further context

For a primary or institutional reference, see the RFC Editor archive.

Every claim here carries the source it came from.

The source and its year sit beside the sentence they support. A secondary account is marked as one, and where the record is unclear the entry says so rather than choosing the better story.