It's a Feature, not a Bug
One thread in the fabric of my life
Of late it appears the distinction between a bug and a feature has become part of the culture. The distinction is important, although the precise criteria for the two conditions vary with the circumstance.
Generally a bug is an oops! — something that prevents proper function. We must fix it or find a way around it, or both.
A feature, on the other hand, is “just the way it is” and changing it requires working out the details of if and what.
I know where the phrase comes from, in my own experience. I first used it myself in 1971, in my first job after graduating from MIT.
As a PDP-8 maintenance programmer at Digital Equipment Corporation (DEC) in Maynard, MA, I was tasked with fixing the bugs in software and releasing programs back to the field once all the bugs were fixed.
It was a matter of professional survival to clarify which items were bugs and which were “well, yes it would be better if . . .”
“This was part of the design, either by omission or necessity. Does the product do what it was built to do? Does the product do what we told the customer it would do?"
Speaking up for that distinction kept me in hot water for most of the 30 years of my systems engineering career. Too many times I was told to sit down and shut up.
When the phrase caught my attention recently, I realized it had survived and spread. It has its own entry in Wikipedia now, and from the references there, I located an article in WIRED that said the earliest reference the author had found was in a dictionary of tech world jargon in the late 1970s, And that book could give no clear point of origin.
Hmm. I think I made my contribution to human advancement.
You heard it here first, friends.
Peace, RedBird


Sounds like Fortran e.g., the bug made it abort