A Pattern Language
for generating independent, product-focused software teams.
In this book, you will discover patterns to design, build and operate web-based applications. This knowledge has been distilled from the experience of the contributors, and from widely-respected works.
If you want to dive into the middle to see what this book is like, try starting at one of these well-known patterns:
The structure of a pattern
As you browse the patterns in this book, you will notice they have a common structure:
A Descriptive Title
An introduction situating the pattern among others which precede or contain it.
A brief summary of a problem encountered when creating software.
An elaboration of the details of the problem and the solution suggested by the pattern.
A succinct summary of a solution to the problem.
Context containing links to proceeding patterns which implement, complement, or complete the current pattern.
This structure is taken from Christopher Alexander's work on pattern languages. The problem statement helps you assess whether a pattern applies to your current work. The links encourage you to navigate the language as cohesive hypermedia, not just as islands of advice disconnected from each other.
Who is this book for?
For novice developers, I hope this book will help familiarise you with the broader context of your work. If you have been tasked with creating some part of a system and you don’t know where it fits in, the links in this book may help you navigate.
For teams, I hope that the names of patterns will help create shared vocabulary and foster communication. When designing new systems, you can directly follow the patterns here, or start with them and adapt them to your own needs.
For experienced developers or team leads, I hope these patterns will put names to concepts you already know. They may provide useful material for you to reflect on, to evaluate your past work and prepare for future work. Maybe they will help communicate your experience with colleagues, mentees, and technically-minded clients.
What is the context within which this book itself is embedded?
This book assumes as its starting point the pattern Self-Governing Workshops And Offices from Christopher Alexander’s A Pattern Language. (The above link is paywalled, but its content is fairly similar to the Agile manifesto.) It elaborates what goes on, and what is produced, inside a self-governing software company or team.
The process of designing software for a domain in which the developers are not themselves experts is given in Domain Driven Design by Eric Evans. The process in that book, sometimes expressed as pattern-like chapters, sits beside the advice in this book. Some patterns will overlap, but I do not attempt to restate or include all Eric’s advice.
There is a wealth of advice on writing code. For example, Implementation Patterns by Kent Beck, Refactoring by Martin Fowler, and too many others to name.
Why did you create this?
There has been a lot of exploration of patterns in software design. As even a novice programmer, you begin to notice repeating structures in code. As you mature, you see repeating structures in architecture, in team organisation, and across projects.
However, I think there are some deficiencies in the existing attempts to apply a pattern-oriented mindset to programming.
1. Missing problem statements. Most works abandon Christopher Alexander’s traditional pattern structure, thus losing both the motivation for each pattern, and the context which surrounds it and links it into the language as a whole. There have been many collections of individual patterns made, but few of them have been woven into a language.
2. Missing connection to architecture. Most pattern collections are low-level, dealing with the syntax of code or with structures involving a few classes. These are valuable, but it can be difficult to connect this tactical advice with the strategic and architectural goals of an entire system or product.
3. Missing connection to people. Because of the tactical nature of most pattern collections, they fail to address the context of the team producing the code. Alexander knew that architecture is not created in a vacuum; his work A Pattern Language contains patterns with names like “Mosaic Of Subcultures”, “Necklace Of Community Projects”, “House For A Couple”, and “Small Services Without Red Tape”. Software, too, is embedded in a social context, and it is important to connect this context to the eventual code which is produced.
This pattern language attempts to correct some of those deficiencies. It is limited in scope, by the author’s experience as well as the bounds of time and effort. But I hope it is inspirational and helps you design excellent software and teams.
How can I contribute?
Each pattern page has a link to the repository where you can contribute by working and merge-requesting your suggested edits to patterns.
If you have suggestions for a new pattern, open an issue with your suggestion. Ideally, you would begin with a problem statement and solution statement. From there we can iterate on the context and elaboration, but it is important to have those two elements in place to ensure the pattern has direction and purpose.
If you have experience running a product-focused team or company, I heartily welcome your contributions in any form. And if you think this pattern language is valuable, spread the word!
I also encourage you to contribute by creating your own pattern languages. Maybe you will be able to reuse some of the patterns in this book, or maybe your field is too different. But the structure and concept may help you in defining the patterns you use in your own workplace.