Despite the best intentions of programmers; oftentimes, in the real world, software systems contain “accidental features” that are accepted as part of a working system.
For example, there may be some process that runs out of memory and crashes before the process exceeds its quota for calls to an external system (which will cost the company money). Though the software team acknowledges that this is an issue, there is simply not enough perceived business value to fix the problem.
Advantageous accidental behavior like this is often lost in any type of significant technical migration.
My question: Is there a term for this type of “feature” that can serve to differentiate it from a run-of-the-mill bug?
9
The Pragmatic Programmer calls these Accidents of Implementation. This term hopefully ensures that the situation will not be mistaken for anything but what it actually is.
“Accidents of implementation are things that happen simply because that’s the way the code is currently written. You end up relying on undocumented error or boundary conditions.”
(I guess I should have consulted the developer canon before I asked this question)
1
I call them “undocumented features”.
It’s a little tongue-in-cheek when such feature is obviously a bug, but it’s broad enough that you can use it for experimental features or features included for backwards compatibility.
It’s generally not a good idea to let your customers know that the feature was an accident. If customers like it, document it for the next release.
8
I’d call them “emergent features”.
In philosophy, systems theory, science, and art, emergence is the way complex systems and patterns arise out of a multiplicity of relatively simple interactions. Emergence is central to the theories of integrative levels and of complex systems…
The term “emergent” was coined by philosopher G. H. Lewes, who wrote:
“Every resultant is either a sum or a difference of the co-operant forces; their sum, when their directions are the same — their difference, when their directions are contrary. Further, every resultant is clearly traceable in its components, because these are homogeneous and commensurable. It is otherwise with emergents, when, instead of adding measurable motion to measurable motion, or things of one kind to other individuals of their kind, there is a co-operation of things of unlike kinds. The emergent is unlike its components insofar as these are incommensurable, and it cannot be reduced to their sum or their difference.”
3
I’ve heard this referred to as “Design by Coincidence”.
Short example: One project I worked on managed MS Office documents on a network drive. It allowed users to open up the documents directly – a bug, it was supposed to copy the file to the local machine. but that meant users would be alerted if another user had the document already open. This was a basic feature of MS Office, and had nothing to do with our software, but our salesforce and CEO started referring to it as a feature. When I was asked to replicate this feature for the web version of the application, the managers were shocked to learn that the ‘feature’ didn’t actually exist.
“Emergent properties” is a correct term. We went over this at university – example was a 4×4 car. Its main purpose is off-road. However, many families decide to buy such a car because it provides safety to their kids (passengers).
Another emergent property of that car is the fact is when you drop your kids off at school, they tend to open a door in a rush. This has caused separate problem where small kids on the pavement were hit by the car door as you couldn’t really see them in a window.
The point is that the term applies to both good and not so good features. It’s also used in a range of industries, not just the IT.