Pattern Chaos

PatternChaos arises when a system, or interacting systems, use different patterns without attention to their interactions or when a single pattern is implemented differently each time it recurrs in the system. This can often happen when patterns are viewed as black boxes. Effort is used to maintain their internal consistency but none used to ensure its consistency with other peer-level abstractions. The result in an overly complex, hard to learn, and inconsistent whole.

Consider the following. A very large reusable framework is being developed that will implement the ObserverPattern in various places. John is working on a foo-observer and Jane is working on a bar-observer. These are peer subsystems and completely decoupled. The classes of bar-observer do not interact with foo-observer. John goes ahead and independently implements the foo-observer with an interface named Observer, he has an explicit Observable interface, and he builds his messages around the verb #notify. At the same time Jane implements her classes using only a Listener interface with the message #handle. Because there is no explicit inter-action between the classes belonging to Jane and John, there is no built-in check for ConceptualIntegrity. As a result, the design inconsistency is not detected. However, a client who uses the system as a whole that has a need to use foo-observer and bar-observer ends up having to learn two different ways to do the same thing. This factorially increases the complexity of the system for that user. The more this occurs in a system (or systems used together as a whole) the higher the PatternChaos factor soars. In actuality, this only has to happen a couple of times to give the user a sense of chaos or inconsistency.

PatternChaos is an impediment to ProgressiveDisclosure. If the foo-observer and bar-observer where design/implemented consistently, then a client would be rewarded for learning bar-observer by knowing how to use foo-observer for free.

Discussion:

Maybe John and Jane should talk to each other once in a while. Maybe they should even have a group StandupMeeting every day, where everyone talks about what they're doing. Maybe they would discover duplication that way, and then follow OnceAndOnlyOnce.

Exactly, that's the whole point of this page -- recognizing the problem so it can be avoided. I think there are many ways to remove or prevent PatternChaos. My only point is that there are non-apparent interactions, such as when no dependency exists between two systems that end up being parts of a whole to a 3rd party client. One idea is to increase the interteam communication and not just concentrate on the intrateam communication. While this is a little anti-brooks, who suggested minimizing inter team communication since it complicates commmunication, I think for small teams that it can result in higher-ConceptualIntegrity (or consistency), especially in peer-based teams with no central architect(s). Of course, the problem becomes more complex when you have maybe 200 people spread over 25 or more teams all working on concurrent parallel parts in distinct domains. --RobertDiFalco

Note that with 200 people, you have 200(199)/2 = 19900 possible relationships to maintain compared to with 8 people (the average team size) where you have 8(7)/2 = 28 possible relationships to maintain. Even if communication between teams was limited to one relationship (unlikely), and team sizes were roughly equivalent, we have 8(7)/2 * 25(24)/2 = 8400 possible relationships to maintain. So, it is not just more complex, but magnitudes more so. -- SunirShah

Exactly true, this is why simply asking them to talk in not a sufficient solution for these kinds of cases. In these cases it is often important to have a central architect or team or architects. This team maybe be made-up of each sub-team lead or may be even more coarsely grained -- but something needs to be done. The poor man's solution is to use naming conventions but these don't speak to semantic consistency, only naming consistency.

The same problem exists when different libraries, components or subsystems from different sources are integrated. Then the problem can not be solved by talking. There is only one - long term - solution. The community of software developers must develop a language standard for naming interfaces in a consistent way. See LanguageOrientedProgramming, ThelopLanguage. -- HelmutLeitner

Not true. You can always wrap them with the AdapterPattern. Or you can go the Java way and push everything into the standard library (let the platform do the work). Mind you, both are ultimately deficient. But so is using one naming convention. Consider the Observer vs. Listener synonmity. Same pattern, different names. You cannot force agreement on things like that because people think differently and both names are "correct."

One of the only benefits of patterns and PatternLanguages is the creation of a standard vocabulary in order to allow peers to discuss things without confusion. (Actually, patterns don't provide this; only canon does. Pattern books seek to become canon, but they don't automatically become so.) However, once again, the Observer/Listener dilemma shows how that doesn't work. Moreover, even in the GangOfFour book, the standard DesignPatterns come with a list of synonyms.

Finally, when a new concept is invented in several diverse, mutually exclusive locations, naming that consistently is impossible. Consider the expressions of a first-order derivative of the function f(x): f'(x) <=> df(x)/dx. We've had centuries to sort this out to no resolution. -- SunirShah

Actually, the Java library is a perfect example of Interface AND Pattern Chaos. If you are implying this is a cure, it is one that is worse than the disease. Also, on another point you brought up; PatternLanguages do provide a common vocabulary, but it is a common vocabulary of design concepts, not class names. --RobertDiFalco

: It isn't a vocabulary until it is used. Only canonical texts influence terminology. I have seen many pattern languages, but they have had no influence on what terms I use. Indeed, patterns (the specific class; not as a member of the larger class of technical literature) don't seem to even help alleviate conceptual redundancy. (By the way, patterns aren't limited to DesignPatterns.) -- SunirShah

Synonyms are not a big problem in languages, neither are two pattern (or words) for the same semantic content.

"...sorting it out..." may be difficult and may take a while. It is unclear why it should take as long as other processes that started centuries ago without efficient global communication. To create a "language of programming" is unavoidable, it may be done in a hundred years or now. It will contribute to make "software engineering" a real engineering discipline. --hl

Less communication means fewer camps to consolidate. Most voices are harder to achieve consensus. How many AthenianDemocracys [sic] vote unaminously? One editor or school can select and enforce one standard by fiat in an communication sparse environment. In the modern world, we end up with the O(n^2) complexity killing you as above. How many language libraries do you keep up on? (Heck, how much of even the Java standard library do you know?) -- SunirShah

I don't even know half of the 300+ exceptions Java is able to throw, do you? :-) -- hl

One can't say "...reach consistency by talking..." and "...consensus is too difficult..." at the same time. Either any programmer is entitled to work his way and create a mess of inconsistencies 'ad infinitum', or any programmer must be obliged to contribute to consistency sooner or later.

Consider that once an interface is published, it cannot be changed easily. People try to do this (e.g. Java's deprecated or through VersionedInterface?s), but it only creates animosity from the development community. Sill, though, backwards compatibility will kill you.

The typical resolution to this death spiral of interface changes is to dump the old framework and rebuild from scratch. However, this is a failure because in the end the same workarounds will be have to be relearnt and the same frobs will have to be created.

Then, the response seems to be a hefty load of BigDesignUpFront, which is not good either. Ideas? I have a couple, but not the $100M to blow to test them. -- SunirShah

That's why DoItRightTheFirstTime is so important for interfaces. -- hl

BTW one should move this to a InterfaceChaos? page, because this really isn't about pattern problems anymore.

What about a Cooking metaphor for Software engineering ? There is no end to the making of new recipes, no single solution to anything, it is a job for artisans (even if some scientific foundation can be seen - nutrition ...), you can reuse components at various levels, and you are often better not to use the industrial ones and to make your owns.

[Or get those microwave pre-packaged goods...]

CategoryPattern