A Pattern Language

Hopefully, after reading this, you’ll come away with:

• An appreciation of how risk underpins everything we do as developers, whether we want it to or not.
• A framework for evaluating methodologies, tools and practices and choosing the right one for the task-at-hand.
• A new way to look at the software development process: it’s an exercise in managing different kinds of risk.
• The tools to help you decide when a methodology or tool is letting you down, and the vocabulary to argue for when it’s a good idea to deviate from it.

This is not intended to be a rigorous, scientific work: I don’t believe it’s possible to objectively analyze a field like software development in any meaningful, statistically significant way (things just change too fast).

“I have this Pattern” - Attributed to Ward Cunningham, Have This Pattern, C2 Wiki

Does that diminish it? If you have visited the TVTropes website, you’ll know that it’s a set of web-pages describing common patterns of narrative, production, character design etc. to do with fiction.

“Sometimes, at the end of a ‘Dream Sequence’ or an ‘All Just a Dream’ episode, after the character in question has woken up and demonstrated any ‘[lesson]’ that the dream might have been communicating, there’s some small hint that it wasn’t a dream after all, even though it quite obviously was… right?. “ - Or Was It a Dream?, TVTropes

Is it scientific? No. Is it correct? Almost certainly. TVTropes is a set of empirical patterns for how stories on TV and other media work. It’s really useful, and a lot of fun. (Warning: it’s also incredibly addictive).

In the same way, “Design Patterns: Elements of Reusable Object-Oriented Software”, is a book detailing patterns of structure within Object-Oriented programming, such as:

“[The] Adapter [pattern] allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class…” - Design Patterns, Wikipedia

Patterns For Practitioners

Design Patterns aims to be a set of useful patterns which practitioners could use in their software to achieve certain goals. “I have this pattern” was a phrase used to describe how they had seen a certain set of constraints before, and how they had solved it in software.

This book was a set of experts handing down their battle-tested practices for other developers to use, and, whether you like patterns or not, knowing them is an important part of being a software developer, as you will see them used everywhere you go and probably use them yourself.

In the same way, Risk-First aims to be a set of Patterns for Software Risk. Hopefully after reading this, you will see where risk hides in software projects, and have a name for it when you see it.

Towards a “Periodic Table”

In the latter chapters of “The Menagerie” we try to assemble these risk patterns into a cohesive whole. Projects fail because of risks, and risks arise from predictable sources.

What This is Not

Risk-First isn’t an exhaustive guide to every possible software development practice and methodology. That would just be too long and tedious.

Neither is this a practitioner’s guide to using any particular methodology: if you’ve come here to learn the best way to do Retrospectives, then you’re in the wrong place. There are plenty of places you can find that information already. Where possible, this site will link to or reference concepts on Wikipedia or the wider Internet for further reading on each subject.