of patterns and frameworks
Like many of you reading this, I walk to work every workday. My walk, from the bus station to the Fraedom office in downtown Auckland, New Zealand is on the edge of the harbour. Auckland — nicknamed “the city of sails” has a beautiful waterfront, but I’ve taken this route so many times I generally don’t take much notice of my surroundings. Again, you may relate to this!
Since becoming aware of patterns I’ve started noticing the patterns I pass each day. Just in this short ten-minute walk there are hundreds of patterns to be seen, and likely thousands more I’m not seeing. A boat pulls out of the dock, leaving swirling patterns in the water behind. Man-made patterns are there as you would expect in the inner city. Cranes hang over high-rises under construction and form triangles. Faded red railings on the fence separating the street from the port form a regular series of oblong shapes.
This post describes how patterns apply to the jobs we do in software, and how being aware of these patterns can help our teams and our companies.
what is a pattern?
“A pattern is a regularity in the world, in human-made design, or in abstract ideas” — Wikipedia
Take a look at this photo:
How would you describe this pattern? When I look my eye is drawn to the middle of the photo, an oval shape of blue where the tree tops converge. At the very outside of the photo is another circle, formed by the base of the tree trunks, a trick of perspective.
Here is a key point about patterns. They do not announce themselves, rather they are there to be observed. There is also an element of subjectivity; you may see a pattern that I don’t. We are looking at the same thing, but noticing different things. So it is in the Volatile Uncertain Complex and Ambiguous (VUCA) world of software development. The patterns are there for the observing. Why do some teams thrive and others struggle? Why do some software projects succeed but others fail? The causes are many and complex — if you look closely you will see patterns there, patterns of success, patterns of failure.
fractals
Lets take a closer look at the photo above — outside of the top core circle I notice that the branches of the trees themselves form circles, some are irregular, but their circular outline is evident.
“Visual patterns in nature are often chaotic, never exactly repeating, and often involve fractals.” — Wikipedia
A fractal, referred to in the Wikipedia quote above is a pattern that contains similar patterns, which themselves may contain similar patterns, and so on.
The Sierpinski triangle above is a classic fractal pattern, a single triangle decomposes into smaller identical triangles, and so on.
So it is with patterns in software development. A large pattern is a collection of sub-patterns, these patterns can be broken into smaller patterns and so on. Consider the concept of splitting work into manageable chunks: a large project can be split into a number of releases or phases, which can be split into stories.
some patterns I’ve noticed
Having worked in software for a long (long!) time, here are some patterns I’ve noticed:
- A motivated, empowered and autonomous team with a clear and consistent vision, more than tools or processes, is how meaningful work gets done.
- When starting a project, product or feature often the best way to start (your first “story” if that is your language) is (in the language of improvement kata) to grasp the current condition.
- A team with clear leadership when it comes to product, process and technical domains has a better chance of success than a team where these roles are absent or unclear
- Discovery > Design > Execution > Operation
There are of course many, many more. Patterns I’m aware of and patterns I’ve yet to observe. Patterns and patterns of patterns.
patterns vs frameworks
A framework defines boundaries and processes. A framework is something you work within. A pattern is something you work with.
To make use of a pattern is to begin to create order out of dis-order. There are no prescribed ‘rules’ as to how this order is created.
Although framework authors may not agree, my perspective is that a framework is best seen as an example of a pattern. The Framework author or authors have, through research and experience, drawn out patterns for success, and (to varying degrees) codified these patterns into a written framework. See Mike Burrow’s post on this.
open your eyes
The challenge I will leave you with is simple. Open your eyes and start observing patterns where you work. What team roles work and what team roles don’t? Are there particular processes or ways of working that work better than others? When a project succeeds or a milestone is reached, what were the ingredients?
The patterns are out there.
