On Brittleness

On Brittleness -- ThinkingOutLoud JeffMantei 20001204

Brittleness is a property of materials that causes them to break rather than bend when stressed. By analogy, the same property may be applied to systems.

An organizational example: when it is easier for someone to get a raise or more desirable work assignments by leaving the company than by going through internal channels.

A system is brittle if a small change in operating conditions, inputs, or some other factor causes the system to fail completely rather than experience GracefulDegradation.

Brittleness is different than rigidity. True rigidity, at least in materials, actually requires a small degree of flexibility to maintain the integrity of the material under stress.

Perhaps this page can become a documentation of the AnalogyMining? of physical brittleness and rigidity.

There are also some peripheral ideas here that beg for exploring. (I hope I can pin them down enough for others know what I'm after.) For example:

Is it better for a system to have a fixed or flexible set of concepts and functions? How much ambiguity is helpful and how much is harmful?
Is a system that has reflection or scripting facilities more flexible than one that doesn't, or is it just written to a different spec (or both)?
Does making people fit into very rigid, tightly constrained roles create high turnover? Is this a bad thing? (See EveryoneShouldBeaRobot)
Does making objects fit into very rigid, tightly constrained specifications create better systems? Instance thrashing? Is this a bad thing?

[I hope folks don't mind this kind of ThinkingOutLoud on Wiki - please let me know if you do (politely of course, please :-)]

-- JeffMantei 2000-12-04

It may be better sometimes for a system to fail completely. At least then you know something is wrong. --AndyPierce

Depends on the failure mode. If it shatters into a million pieces (analogy: writes random blocks all over your disk), it was no use at all. If it just dents a bit, you can probably hammer it out. --DanBarlow

The question is "how much damage does it do when it breaks?" If it corrupts valuable production data, it's bad. If the failure is visible to the user, but no data is corrupted and an easy workaround is available, then it's not as much of a problem.

Perhaps this is related to how many different people/organizations you have to deal with, and how detail-oriented they can be expected to be. If you're designing hardware specifications, you can be more brittle, because your audience is a bunch of engineers who know how to read a spec doc. If you're designing a macro language that you want every office employee in the world to learn, you might want to allow more flexibility.

A big issue with inappropriate generalization is that the system is flexible in some ways, but brittle in others.

In other words, given that a certain set of "flex points" are built into the software, changes that can be served by flexing at that point can be met by minor changes to the program, or even just changes to the control data. But "unexpected" types of changes cost lots of time and money to implement -- they violate the abstract model the software implements or require changes at "inflexible" points.

Highly data driven programs (including many hard-and-soft-layers scripted programs) illustrate this well: If your change fits within the program's "model," the change will be trivial to implement -- typically requiring only a small change to the control data (or script). But once you step outside the model, you hit real change resistance and high costs. -- JeffGrigg