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.