A euphemism for the concept that complicated systems have complicated behavior, and that every time you add a feature to a system, it is likely to have unpredicted and unwelcome effects on the behavior of existing features. The term is often used in the telecom industry.

The problem can be particularly acute in systems that allow independently developed components to share resources. For example, "plug-ins" created by multiple vendors can interact in ways not envisioned by either vendor, and in ways not predictable by users and system administrators.

An FAQ is available here: http://www.research.att.com/~pamela/faq.html. Another simple introduction is here: http://staff.science.uva.nl/~mdr/Projects/FI/.

----

'''An example of Wiki FeatureInteraction'''

What was special about MyPage? Why was it that it couldn't be edited or deleted? -- WayneConrad

The link remained because one of the SisterSites held the page. I deleted that. Then the link remains because the sister index is only updated once a day. Pretty confusing, eh? The telecom guys call this FeatureInteraction. -- WardCunningham

----
I call it "OhShit" - as in "Oh shit, I didn't think about THAT..."
----
Feature interaction can be seen as part of a larger concept, that of EmergentBehavior. I've often thought that you can measure the quality of a system by its reaction to FeatureInteraction not explicitly considered by the original designer. To anthropomorphize, good systems don't mind if you try using their features in new ways; mediocre systems prevent you from using them in new ways; bad systems break.

* But it is important to distinguish two kinds of breakage: it is much worse when they break in the sense that old features cease to work, than when they break in the sense that emergent new features are undesirable. Usually. Perhaps not, on some security topics. Maybe it's better to have a completely nonfunctional system than an insecure system. But otherwise, usually it's not so bad if old features continue to work as before, even if the new features aren't what is wanted.

This concept is, incidentally, being explorer more in more in modern online and offline computer games, from Deus Ex, to TheSims, to A Tale in the Desert.
----
Sometimes Feature interaction can lead to useful phenomena. One of the first tank games for Atari had you shooting at your oponent on a 2D (all they had in those days early 80s) screen behind barriers from opposite ends of the screen. You could drive around but if you went out in the open you would likely get blown up by the guy still behind his barrier. But sometimes if you hit the corner of your barrier at a certain angle your tank would jump over to the opposite side giving you a clear shot. I doubt this was intentional but it certainly made the game more fun. It was hard to predict where the jump would occur so did not always work. It seemed to be a mix up between movement, layout and positioning features of the game. In modern games, feature interaction is intentially used, i.e., PhysicsEngines allow (any available) 3D object to be thrown and smash "glass" to escape a room, similar to what would happen in real life. 
----
See also FeatureCreep, CreepingFeaturitis, SideEffect