computers should be less friendly

There have been a couple of blogs recently about the waterfall method and it’s usefulness: one from The CIO Weblog, which linked to Eugene Nizker at CIO Magazine which points to an IBM article by Dr. Kruchten on the subject.

For some reason none of these blogs comes right out and says the obvious.  Software development methodologies are like religions:  everyone has one and they all hate everyone else’s for no reason except they aren’t their sworn religion.  In real life, this is dangerous, expensive and prone to the types of failures noted in the blogs.

I haven’t worked in industry for 35+ years like Mr. Nizker but after a few projects it became obvious to me when you can use agile methods and when waterfall is the most appropriate.  Let’s try and do what none of the other blogs tried to do and break it down.

“Roll-out”

A very common thing in large companies (this was found via the CIO Weblog right?) is to take a newly developed solution and push it all over the world to standardize a business process.  These systems are the perfect candidate for the waterfall method.  The users can look at a system and see the gaps and let the people in charge of creating their “copy” of the system know about the changes.  This allows the “developers” to take the requirements in advance and while creating this new “copy” of the system add the modifications required for the new location.  Once the system is ready it can be easily tested with prior business cases and be easily validated for the new location.   I guess this is the “deterministic” task talked about by CIO Magazine.

“I think I need…”

Everything else falls into this category.  The category where the person defining the system has only half of a clue about what they need or want.  I do like the way Mr. Nizker classifies these problems, “[there is a] volatile reality, which changes on them every day [and] the systems we develop influence [that] reality.”  It’s sort of the Heisenberg uncertainly principal of IT systems.  Until we start to peel back the layers the people trying to define the system don’t know the extent of their own delusion.  You should think of it like therapy we must slowly work to the actual root of the problem.  You can only do this in an iterative manner until the user has seen the solution they have no clue what their problem even is.

It is all about using the right tool for the job and being able to tell the different before you start.  Just as using the iterative method is overkill for a roll-out style project, the waterfall spells total doom for the iterative project.  I rarely have a hard time deciding which tool to use.

This entry was posted on Thursday, December 6th, 2007 at 1:44 am and is filed under Methods, SDN blogger. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.