The Development Methodology Lifecycle

Posted by Keith McMillan

March 25, 2008 | Leave a Comment

I’ve been thinking lately that software development methodologies are a funny thing. In some ways, their lifecycle mirrors the very software that they produce.

There’s a phenomenon where software gathers entropy over time, sometimes called “bit rot”. Bit rot requires you to refactor your software occasionally, even regularly, tuning it up and keeping it working at its best. Without this sort of maintenance, your software has a decreased lifespan. Many refactorings focus on making things simpler, easier to understand.

As with the software that comes out of a development methodology, the methodologies themselves start out all lean and efficient, as a kernel of good ideas. Sometimes the newborn methodology is inspired by what some other methodology is perceived as doing wrong. Over time, methodologies seem to accrete all sorts of things. These are good ideas, typically, special approaches to problems, or things that people find as complimentary practices. The problem is that these become enshrined in the canon, as it were. People who have less attention to what the methodology actually says about when to use these tools, or who have less experience and can’t understand when a tool applies, begin to apply all the tools, all the time. As a result, methodologies get rather bloated, become inflexible, and eventually fall out of favor because they become too unwieldy, or at least that’s the perception people have about methodologies. I think it’s because practitioners don’t really understand when to apply the tools in question.

As a concrete example, assume you have some methodology that espouses iterative development. Iterative development, that’s a good thing, but it’s better if the iterations are short, like say two weeks. So all our iterations should be two weeks long. Great! Oh, and we had this project once that failed to recognize that had a lot of technical risks, and they couldn’t keep track of them efficiently, so they established a log file, with categorizations and assignees, and then were able to handle it more efficiently. That worked well with the other tools in the toolbox, so we added it in so others could use it if they needed to. Then the next project thought they had to do that too, and you see where I’m going.

As these things become a “standard” part of the process, there’s a natural tendency, in the interest of keeping the amount of complexity that we as individuals have to deal with, to just take what’s written down as “the process” instead of a tool to use if you have a particular problem. We have so many things to think about, that if we can short-circuit and not think about one more thing, that’s a savings.

Once we start viewing the lifecycle this way, it’s easy to understand how a process starts out young, lean and strong, is gradually enhanced by additional tools that are complimentary, and end up being viewed (wrongly in many cases) as inflexible and unwieldy. It’s a matter that people can’t or don’t want to understand what their choices are, or how to decide. All this argues for better education. The problem is we’ve been teaching methodology for years now, and it hasn’t seemed to help much.

I think that perhaps what’s needed is more of the “refactoring” approach for methodologies. In fact, we see this very sort of thing happening in the field now. As a concrete example, take IBM’s Rational Unified Process, which has been a victim of just this sort of treatment. RUP never advised that you do everything in the toolbox for every project: in fact customization is an activity within the methodology itself! Many practitioners view RUP as “heavyweight”, and so now we see refactorings of the process into OpenUP, EssUP, and probably a slew of new variants that I haven’t even heard of yet.

Given that education hasn’t seemed to produce a good lifespan for your typical methodology, and they end up being (viewed as) bloated and unwieldy, perhaps refactoring the process itself will yield better results. Maybe by regularly pruning away the non-essentials and making them simple as you can we can prolong the lifespan of what a lot of organizations and people have invested in. Maybe that way we can avoid throwing out both the baby and the bathwater.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.