After discussing ChatGPT with Andy, who had had good results collaborating with it in writing projects, I decided to try it out on documenting my claim to origination of the subject phrase. Here is what we came up with.
It’s Not a Bug; It’s a Feature
My employment at Digital Equipment Corporation began in October 1969, just after my graduation from MIT (as Sandra Mathes), and ended in May or June 1972. In 1971, I was working at the DEC headquarters in Maynard, Massachusetts. After growing up in the IBM family, life in The Old Mill was a refreshing, comfortable change. The floors and the 16-inch square (estimate) pillars were soaked in lanolin. Where sunlight shone on the floor, the lanolin would rise in pools. Listing piled on the floor soaked up the yellow. Navigating the building in high heels was fraught with danger, and the dress code was much more relaxed than the IBM suit-and-tie (white shirts only) that Dad wore so many years.
The employee populace drew from both the local towns and from the colleges in Boston and Cambridge. The building itself was a labyrinth of, as I recall, about three floors. The lower floor could have housed a dungeon—I do recall at least one bay with jail-type bars. There were rumors that someone had opened a long-locked door and uncovered two piles of wool blankets: blue and gray. And, in the midst of the gloom, an area was enclosed in glass and fitted with a raised floor and air conditioning for the PDP-10 computer we used to speed our work on occasion. DEC had established its main offices and manufacturing facility in an old New England textile mill about 20 miles west of Boston, where 1 million square feet of space could accommodate the lot.
My job was to fix bugs in FOCAL-8, a programming language designed for the PDP-8 minicomputer. The assignment was clear: no new features, just clean up the bugs so the system could pass QA.
I was handed a thick stack of bug reports and change requests—some cryptic, others adamant. But it wasn’t just a list of problems. It was a map of contradictions. The program behavior, the user documentation, and the functional specifications often didn’t align. One would say X, the code would do Y, and the documentation might pretend it was doing Z.
To make sense of it, I developed a set of criteria for evaluating whether something was a bug or a feature. These represented a working understanding in 1971—insights that I would later formalize in my own management practices. At the time, however, I was operating with very limited documentation. The only specifications available to me in useful detail came from a general marketing giveaway titled Introduction to Programming. I had to figure out FOCAL largely through trial and error and by reading sparsely commented source code. It was a deep dive, and these guiding principles emerged from necessity. It was simple, but grounded:
- All three aspects—spec, code, and documentation—must align. If not, there’s a bug.
- Unexpected terminations must be graceful. A crash wasn’t acceptable.
- Calculations must be correct to the stated precision. No fudging the math.
FOCAL itself was an interpreter, much like BASIC, which was being developed around the same time. The user would write a program and execute it line by line, omitting the usual stage of compiling or assembling source code into binary instructions for later execution.
The PDP-8 was a stout workhorse of a machine. The core memory, thankfully, would retain its data when shut down. Still, a programmer had to be able to execute a cold start on a blank or assumed-blank machine. This involved providing the RIM Loader the hard way: set a 12-bit address on the switch register; input that; set a 12-bit instruction on the switch register; load that to the address specified; repeat. About a dozen instructions were provided on a card.
Then load the Binary Loader from paper tape by executing the RIM Loader.
Once that was completed, you could load whatever application was desired using the Binary Loader.
We were very careful in our programming to protect the section of memory containing the Binary Loader, and the dozen or so words containing the RIM Loader were sacrosanct. Other than the space for the loaders, the rest of 4096 words was available for our programs.
A lot of times, programming was describable as “bit-squeezing.” Since any of those 4K of words could hold an address, an instruction, or data, we might sometimes use a known instruction in a known location as a needed piece of data—a constant, for example.
Output was typically directed to paper tape, printer, or both.
But here’s the thing: FOCAL-8 had been built before I arrived, by someone no longer with the company. It bore the marks of early collaboration between engineering and marketing—a language shaped as much by sales demos as by design principles. Some of its quirks were inherited, some intentional, some… unknowable.
I needed a way to communicate to management what I had found inside the system, and what I could or could not change. So, as part of my documentation, I began distinguishing between bugs and features—as a precise classification based on technical analysis and project constraints.
Some of these “features” had been part of the system from the beginning, whether or not anyone wanted to admit it. Others could be repaired if management chose to spend the time. My job was to make the difference clear. Features don’t always arise from intentional design changes or decisions. Often, they emerge unintentionally as available resources and capabilities are juggled to achieve desired functionality without major additional engineering.
So I wrote it plainly:
“This is not a bug; it’s a feature.”
It was a way of managing expectations and ensuring accountability—a shared understanding between engineering and management. And while I’ve seen the phrase used broadly since then, I believe most people who use it today still mean what I meant then: an acknowledgement of the system’s behavior, deliberate or otherwise, that falls within the scope of accepted operation.
One example comes to mind that illustrates the balancing act between hardware behavior and software workarounds. When the PDP-8 sent output to a printer—especially an ASR-33 Teletype—at the end of each line, the print head would pause and “chitter” about 10 times. Customers sometimes objected. What was happening was that the program doing the printing was sending a carriage return/line feed plus multiple nonprinting characters. This was a remedy to the discrepancy between processing speed and the physical speed of the carriage return. On some hardware, the carriage might not finish returning to the start of the next line before the first characters were typed, resulting in misplaced output. The nonprinting characters provided a buffer of time to allow the carriage return to complete.
Newer teletypes and faster PDP-8 models made this behavior erratic and more noticeable. But there was no impetus to redesign the software to sense which models were in use and fine-tune the printing routines accordingly. The workaround was good enough. Not a bug. Not quite a feature. But definitely a reflection of resourceful, system-aware engineering.
And of course, I would be remiss not to acknowledge the most famous computer bug of all: the one recorded by Admiral Grace Hopper, who found an actual moth trapped in a relay and taped it into her lab notebook. The moth had interfered with the operation of the machine, producing incorrect results—a literal bug, now enshrined in computing folklore. It’s a delightful and symbolic origin story, but what came afterward in the world of digital systems was often more abstract, more conceptual, and—frankly—more open to interpretation.
In recent years, I added a short snippet about the phrase to the Wikipedia article on “Bug (engineering),” providing historical context and origin. That contribution has so far remained in place, and I’m glad to see the phrase taken seriously in technical circles even today.
Annotated Sources
- Wikipedia – Bug (engineering): The article includes a note on the historical origin of the phrase, referencing DEC and my own work with FOCAL-8.
- WIRED – “It’s Not a Bug, It’s a Feature”: A 2023 article tracing the phrase’s cultural and technical evolution. It notes the tension between user experience and intentional design.
- MIT Jargon File: Although not written by me, the Jargon File has long documented the phrase as part of hacker and programmer lexicon.
- Wikipedia – Undocumented Feature: Covers related territory, especially the blurred lines between bugs and features in early software.
- John Millikin’s Archive – The Jargon Book (early version): An archived version of the original hacker lexicon, providing detailed usage of the term feature (including the classic “That’s not a bug, that’s a feature!”) and adjacent terminology like misfeature, kluge, and win.
Leave a comment