The Architecture Cant Do That

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.