A common AntiPattern, wherein an unexpected request for a new capability, causes an assumption or requirement of an existing architecture (software or otherwise) to be violated.  The usual retort from developers when such occurs, is:

''Sorry, but the architecture can't '''do''' that!''

Which is seldom true--unless the request is something truly impossible (like solving the halting problem), the system probably ''can'' be reconfigured to meet the new request.

But in many cases, it's expensive:

* Invalidation of an architectural assumption may cause significant rework
* The rework may provide a major maintenance nightmare, if compatibility with currently-deployed systems must be made
* Given constraints of schedule and budget, the claim "we can't do that" may become true.
* If memory or computational power is an issue; resolution may require a more powerful computing platform.  Whether or not the development team provides the platform or the customer does; either way this is a major PITA.

Common causes of this:

* Some parameter, field, protocol, or other entity which doesn't provide ample room for expansion--the FixedQuantityOverflowBug
* Going from one to ''n'' (''n'' > 1) instances of some thing--the SingletonAssumption.  (Going from ''n'' to ''n + k'', where ''n > 1'' and ''k'' isn't so large as to introduce scalability issues, is usually a minor deal, providing proper coding practices are followed--such as not hardcoding ''n'' in a million different places).
* Overtaxing CPU and/or memory.  This is a major issue in EmbeddedSystems especially (though where I work; FPGA space is usually the resource that gets exhausted first, and we often buy the biggest FPGAs we can).

In the context of UI or InteractionDesign:

* Use of a graphics framework or toolkit with a fixed set of widgets, and which makes it difficult to create new ones.
* Introduction of context-dependent UI elements where they are not expected.  Many toolkits/frameworks (and the programmers that use them) consider context dependencies to be icky.  Modular software design often explicitly discourages context dependencies.  Users often love them, however.
* Change of UI paradigm, or introduction of UI elements which require such.  A "back" button, for example--ubiquitous on web browsers, but often a royal beyotch to deal with in heavily stateful frameworks that don't anticipate such a feature.

Ways to mitigate:

* Anticipate future requirements--not just functional, but interface requirements to.  Make sure current requirements are well-known.  
* Parameterize dependencies. 
* Document the limitations of the architecture.  No systems design is limitless; so make sure the limitations are known to all stakeholders.