Software Project Patterns
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. -- Christopher Alexander
I can say with some confidence that most people who might read this blog already know what software design patterns are. If not then I kindly provided a link for you to go figure it out. Go me. It recently dawned on me that in addition to software design problems there are living, breathing software project problems that occurred over and over again too. A typical reoccurring project problem might be a person on the project throwing out some whacked out idea for solving a problem and somehow getting the rest of the team to sign on to the idea even though it'll cause the project to hit the mountain - hard. Usually we'll address the problem each time is shows its ugly head. I think there are repeatable solutions to such problems that can we codified, written down, and shared amoung like-minded developers. Much like Management Mind Tricks, Volume 1 below that can used to overcome the problem of being right about something and having to overcome someone who has no real idea of the problem space there are numerous other patterns to discover and share.
Each of these patterns will have the following format and attributes ( thanks go out to Patterns and Software: Essential Concepts and Terminology for helping me define each):
- Name - A single word or short phrase to refer to the pattern
- Problem - A statement of the problem
- Context - The preconditions under which the problem and its solution seem to recur, and for which the solution is desirable.
- Forces - A description of the relevant forces and constraints and how they interact/conflict with one another and with goals we wish to achieve (perhaps with some indication of their priorities).
- Solution - Static relationships and dynamic rules describing how to realize the desired outcome.
- Example - One or more sample applications of the pattern which illustrate: a specific initial context; how the pattern is applied to, and transforms, that context; and the resulting context left in its wake.
- Resulting Context - The state or configuration of the system after the pattern has been applied, including the consequences (both good and bad) of applying the pattern, and other problems and patterns that may arise from the new context.
- Rationale - A justifying explanation of steps or rules in the pattern, and also of the pattern as a whole in terms of how and why it resolves its forces in a particular way to be in alignment with desired goals, principles, and philosophies.
- Related Patterns - The static and dynamic relationships between this pattern and others within the same pattern language or system. Related patterns often share common forces.
- Known Uses - Describes known occurrences of the pattern and its application within existing systems.
That should do for a start.