“A key part of patters is that they’re rooted in practice”
~ Martin Fowler
For the last few years I have been witnessing a decent number of hybris projects – from start to end – stretching from concept to realization. It could be my own personal experience, but I've hardly experienced an easy “sunshine” project without difficulties and downsides.
Even more: I noticed that the problems occur over and over again, in every project – like patterns.
Subsequently, I started studying them and recording thoughts on how to solve them. Thus came the idea of compiling a list of patterns that arise in hybris software projects – describing common issues and suggesting suitable resolutions, or better – avoiding the problems in the first place.
The project complications, I observe, are not only technical – on contrary, the technical topics are frequently well handled by a squad of hybris-savvy technicians. I would consider the technical problems as “mild challenges to overcome” in comparison to the other sources of project issues.
In fact, most of the things that “go wrong” happen before and after the development – from pre-sales and scoping all the way to delivery and maintenance. Those issues are related to the way the project is shaped, consulted and lead.
Next to the technical and domain expertise, a great deal of the success depends on mastering the soft-skills within the project; skills like patience, diplomacy, humility, story-telling, presenting, entertaining, drawing, sketching, negotiating, guiding, leading, motivating, and so on.
Similarly to the repeating problems, the patterns are from various natures, but often, they are organisational, methodological and soft-skills.
A (personal) View of Patterns
As technologies mature and the hype and dust they create initially settles, the playing field becomes clearer: a set of best practices (as well as worst practices) and patterns emerge.
A pattern is basically a "template solution" – a way of solving similar problems that appear times and times again, and that has proven to offer a correct and efficient solution.
The term "pattern" has been with us for a long time – it was first used by Christopher Alexander, an architect (in the traditional sense) looking to establish whether quality was something subjective or there were common, objective traits of quality when building structures.
Patterns became widespread as a concept when the so-called "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) published their "Design Patterns: Elements of Reusable Object-Oriented Software" book, which described a set of basic patterns widely used in the software engineering world.
Moreover, Patterns are, by their own nature, generic. Just like a generic description of how to build a cathedral does not depend on its location and the stones used, so patterns are not bound to a specific technology, language or platform.
Patterns are closely related to best practices because they constitute "tried-and-true" solutions that carry a valuable set of benefits extensively attempted in real-live circumstances. Using these patterns in the appropriate situation is a guaranteed way to improve the design of a project – benefiting from the experience of the creators of the pattern and the people who have applied it.
Think of a pattern as the equivalent of a chess opening.
Chess openings are the distilled experience of thousands of chess players - a sequence of instructions that are deeply analysed and guaranteed to leave you in a good starting position for developing your game.
When chess masters play chess, they use chess openings blindly and mechanically, without any further thought: they just follow the script, knowing that many brilliant minds before them have analysed the sequence and they need not repeat this analysis … and even if they did, it is unlikely that they would arrive to something better (especially when under pressure).
The patterns allow building up an expressive dictionary, which can be used in projects. Indeed, it feels comfortable when someone exclaims:
“Your people can advance on Glossary, during the Workshop regarding product Data Model”
and others would recognize that lingua.
Even though patterns can be used independently, very often one pattern is a prerequisite for another or benefits from a preceding one. Relations are important because they ensure the completeness of the whole approach. Therefore, in this series you will find description of project patterns and their collaboration with others.
A rather special feature of patterns is their variability. Even thought project situations are similar, they are never exactly the same. Hence, use the patterns from this category as recommendations, rather than prescribed recipes. And, adapt them to your environments, teams and context. Identify new patterns and grow your expertise.
The situations I write about have been inspired by the projects I observed and participated in. While the solutions I propose are mostly inspired by empirical experience and Agile practices.
I would refrain from claiming that the patterns described here are “all there is to know” in a hybris project. I believe the field is too big to be captured in a single writing – the patterns will evolve and multiply in time. Rather, I would like to initiate a beginning and encourage you to find the way with your own experience, throughout your own unique journey.
Let us start with our first pattern - the Virtual Product ...