Thursday, March 27, 2014

Software Development Methodology Patterns

“I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.”
-- The Oath of Non-Allegiance, Alistair Cockburn, Co-Creator of the Agile Manifesto

One of my current interests is enumeration of common patterns within software development methodologies that might become part of a standard toolkit. I do not assume that all patterns apply equally well in every circumstance. I reject the idea that there is a silver-bullet methodology that will work for all types of projects – even considering that one might be defining patterns to be used at a single company with a single culture. The idea that strict methodologies apply well to all projects in all companies I reject with even more vehemence.

So if each situation has some uniqueness, should we reject methodology altogether? Of course not. But rather than assume a monolithic prescriptive methodology can succeed, the methodology can be itself a fabric of patterns. Some will be used in all situations, some followed in most and some followed only under special circumstances.

Why use the term “pattern”? Like the concept of a “design pattern” made popular by the Gang of Four, the patterns apply only in context. Just as one would not use the Observer pattern without a context that merited it, the same can apply for an aspect of the development process such as the creation of a technical design document. Might it make sense to create a technical design document for a new, complex system interface? Absolutely. Might it make sense to create a technical design document for adding a new, clearly-defined field to an existing report? No – this is a perfect example of documentation for documentation’s sake – a common source of waste that both Agile and Lean methodologies eschew.

Most of the things that I’ve seen work are borrowed from established methodologies such as RUP, Scrum, XP, Lean and Kanban. I have no interest in an ivory tower methodology that somehow purports to be the new, unique way to develop software, period. I make every effort to include those portions of existing methodologies that I've seen work and leave behind those that I have seen fail. Beyond the contributions of formal methodologies, patterns can and should also be infused with tribal wisdom and collective experience – things that just work, regardless of whether you’ll ever read them in a book. By forming a library of patterns we can create the ability to define methodologies dynamically based on the class of project at hand or even based on the needs of individual projects themselves. This is a simple but powerful idea.

I plan to wrestle with this theme (among others) in future blog entries. And like all good ideas, this one came from someone else – it is well-articulated in SDLC 3.0, a fabulous book by Mark Kennaley, which I highly recommend.