Idea Form Idea FormBut you recognize that not all ideas are amenable to documentation in PatternForm. Your idea may fail one of the PatternityTests: it may not have a specific context of applicability, it may not balance a set of conflicting forces, or it may not be known to be recurring. So, in what form should you document your idea?
There are different forms of knowledge. Every good idea or design is not automatically a pattern, and as a responsible citizen of the patterns community, you don't want to abuse the definition of the term. Identifying true patterns is hard. Principles or heuristics that show up as forces in true patterns may be mis-identified as patterns. Identifying a set of conflicting forces addressed by the solution may be hard: consequences of the solution may be mistaken as forces. And it may even be hard to identify the true problem addressed by the solution (i.e., to identify the real reason why you use the solution), or to identify a specific context in which the problem occurs.
Perhaps your idea passes all PatternityTests except known recurrence. But by BuschmannsLaw you shouldn't document your own idea as a pattern, which creates a chicken-or-egg problem: how will you ever know if your pattern recurs, unless you can document it as a (proto-) pattern and ask "does anyone else HaveThisPattern?"
Furthermore, good ideas that are not patterns should not be dismissed just because they're not! It is still very important to name these ideas, because names create a "conceptual handle" (as mentioned by JohnVlissides on PatternsMisconceptions), and names create a "common vocabulary" (as described by KentBeck in SmalltalkBestPracticePatterns). And in general, the PatternForm is a desirable form in which to document ideas, because it encodes much experiential insight (context, problem, forces, solution, rationale, resulting context, etc.).
Therefore document your idea in IdeaForm. IdeaForm generalizes PatternForm by classifying the form of the idea (the CanonicalForm template is extended to include a "form" element). Possible forms include patterns, ProtoPatterns, solutions, principles and heuristics, AntiPatterns, anti-solutions, and even things like constraints and procedures. If a good idea passes all PatternityTests, it is indeed a pattern. If it passes all but known recurrence, it is a ProtoPattern. IdeaForm is itself a ProtoPattern. If a good idea fails the "conflicting forces" test, it is a solution. If it fails the "specific context" test, it is a principle or heuristic. If some idea passes all PatternityTests but has an undesirable resulting context, it is an AntiPattern. If it fails the "conflicting forces" test and has an undesirable resulting context, it is an anti-solution.
It has been my experience that all of these forms of ideas are amenable to documentation using CanonicalForm template elements, with the exception of principles and heuristics (which basically just have a name and a statement). Patterns, ProtoPatterns, AntiPatterns, solutions, and anti-solutions use the template as-is (although solutions and anti-solutions may have non-conflicting forces or even only one force). Constraints constrain the range of possible solutions to a problem in a context involving forces; they can be documented with the CanonicalForm template by replacing the "solution" element with a "constraint" element. Procedures are solutions to the problem of how (what steps to follow) to accomplish something (think, for example, of the VisualWorksCookbook?). They have a context of applicability because the task to be accomplished is incumbent as a result of a decision sequence leading to some specific context. Therefore they can be documented with the CanonicalForm template by replacing "solution" with "procedure" (and dropping "forces" as it somehow seems irrelevant).
IdeaForm is valuable because it documents different forms of ideas similarly to patterns, and thereby facilitates the creation of conceptual handles to and common vocabulary of a wider range of ideas, without abusing the definition of "pattern".
IdeaForm enables the creation of IdeaLanguage(s), and possibly IdeaCatalog?(s). Wider adoption of IdeaForm could result in a larger body of published, easily-accessible ideas than is possible with PatternForm alone.
Context: You are an experienced practitioner in your field. You have an idea that you'd like to document and share with others, and you're contemplating documenting your idea in PatternForm.
Problem: In what form should you document your idea?
Forces:
It has been my experience that all of these forms of ideas are amenable to documentation using CanonicalForm template elements, with the exception of principles and heuristics (which basically just have a name and a statement). Patterns, ProtoPatterns, AntiPatterns, solutions, and anti-solutions use the template as-is (although solutions and anti-solutions may have non-conflicting forces or even only one force). Constraints constrain the range of possible solutions to a problem in a context involving forces; they can be documented with the CanonicalForm template by replacing the "solution" element with a "constraint" element. Procedures are solutions to the problem of how (what steps to follow) to accomplish something (think, for example, of the VisualWorksCookbook?). They have a context of applicability because the task to be accomplished is incumbent as a result of a decision sequence leading to some specific context. Therefore they can be documented with the CanonicalForm template by replacing "solution" with "procedure" (and dropping "forces" as it somehow seems irrelevant).
Example(s): Ideas in the soon-to-be-published GemStone Professional Services IdeaLanguage.
Resulting Context and Related Ideas: IdeaForm enables the creation of IdeaLanguage(s), and possibly IdeaCatalog?(s). Wider adoption of IdeaForm could result in a larger body of published, easily-accessible ideas than is possible with PatternForm alone.
This page mirrored in WikiPagesAboutWhatArePatterns as of April 29, 2006