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.
-- 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.
The most important thing to know when you know enough to diverge
ReplyDeleteYep. Having a framework should help you, not hand-cuff you.
DeleteWhat school of software development methodologies did you go to? ;)
ReplyDeleteLooking forward to seeing what you come up with.
I went to the "do what works" school. :-)
Delete> Might it make sense to create a technical design document for adding a new, clearly-defined field to an existing report? No [..]
ReplyDeleteLike you, I cringe at absolutes. So at the risk of splitting hairs, I would say that documenting a field in this scenario MAY be a waste of time, but it may not. It depends on what other information is available. There should be easy ways to track the requirements and specs for the new field. If the source code is clear, possibly commented; if there is issue-tracking or change control; if there is a full history of the code in the source-code repository; one or all of these might make formal documentation redundant.
I will say that if a subtle bug arises one day in that new field, and you need to figure out if the problem is in the design, implementation, or even in the user expectations of that field, you can almost never have too much information. :-)
I think we're on the same page. What I'd be opposed to is making a "technical design" (because it's so trivial) separate from the "functional design". The "functional design" role can be fulfilled by an issue in an issues list, for example. I'm rarely a fan of losing track of "functional" documentation however thin. But there are some cases where I am in favor of skimping - developer utilities, rapid experimentation, etc. There are absolutely no absolutes. :-)
DeleteI agree that adding a new field should not require a new technical design, but I think it should result in UPDATING the functional and technical design as necessary. This will ensure the technical design will be up-to-date and will allow others to review it without having to review the code.
DeleteThis then brings up the issue of what kind of lifetime a design document should have. Should it live forever (I've seen this fail over and over)? Should it die once you hit UAT or rapid-change mode? I tend to be of the opinion that design docs have a shelf life and that we eventually have to deprecate them. They are a snapshot-in-time understanding that we should evolve only up to a point. We somehow want them to live forever and be always up to date but that never seems to work. Should we give up on that? A user guide / integrated help replaces the functional design. And the code replaces the technical design.
DeleteInteresting blog, I am looking forward to reading a more detailed analysis on which methodologies (or parts thereof) work best in which case from your experience.
ReplyDeleteLooking forward to seeing what comes out of this. Sure I'm going to learn a lot. Even in this first intro post, I learned something: never heard of Kanban before!
ReplyDeleteI suspect that you'll really like Disciplined Agile Delivery (DAD)'s process goal driven approach. The idea is to help people understand that they have choices and what the trade-offs are of those choices. See http://disciplinedagiledelivery.wordpress.com/2013/06/26/disciplined-agile-delivery-is-pragmatic-agile/ for more details.
ReplyDeleteAbsolutely. I've read your DAD book and it had a great deal of influence on my thought process. I often use it as a reference and will continue to do so. It's very refreshing to have someone that is willing to take a balanced look at canned agile approaches and admit that they aren't perfect for all cases. (Though I fear the agile thought police may come and put me in jail for such heretical views!) Thanks Scott for all of your work in this space.
Delete