The Codist

Looking over some java ads (which can be entertaining unless you are looking for a job), I kept seeing references to the SDLC process. I'm familiar with many different software methodologies but that acronym seemed new. Once I looked it up (what did we ever do before Google?) I realized it was just the old familiar long-discredited-but-still-popular Waterfall methodology. Instead of doing something that works, let's just rename it something cool!

Two jobs ago we had a similar monstrosity which actually had 15 steps, yet it was never followed by anyone unless ordered from on high (which rarely happened). The methodology only existed to kill projects that IT management didn't want to do (bury it with meetings a paperwork) and apparently to torment developers (at least it seemed that way to us). Successful projects tended to follow a more agile plan, even though such a term was never used or mentioned. In my entire career I can't remember a single successful project that followed a strict waterfall system, most projects I have had leadership into have been iterative in nature since my earliest days as a developer.

So why is the waterfall still practiced, especially in larger corporate entities? The illusion of control. What makes more sense than to plan each step one after another, in an orderly fashion, with predictable results!

"The SDLC process is an eleven phase project life cycle providing a consistent, effective and repeatable practice that serves as the framework for delivering high quality, on time and on budget IT enabled business solutions."

I found this quote and the above picture on a university IT page. It's a perfect example of the fantasy world many upper IT management people live in where if you simply have the perfect plan, everything will work perfectly. Sadly this fantasy is all too common and usually leads to terrible project failures, as it simply doesn't intersect with the reality in most companies. Determining what a customer (be they internal or external) needs and being able to deliver it in a reasonable budget and timeline can never be predetermined perfectly. Better to follow a methodology that assumes imperfection, adjusts to change, and lives in the messy world than people work in.

What type of iterative approach is not the important thing, there are many different ways to follow a cyclical determination-development-delivery process. The important thing is by breaking down the project into smaller pieces, getting input from the customer on a regular basis in response to the smaller deliveries, you are far more likely to deliver something that not only meets the customer's requests, but actually delivers the customer's needs. Customers rarely know what they need and may actually request the wrong thing, as they may not even be aware of what they actually need at the start of a project. This is one of the base fallacies of the waterfall methodology, that people are able to properly and completely (to the point of "signing off") say what they really need before any work is done. Such perfect customers only exist in fairy tales. People can recognize what they need when it's demonstrated to them (either in real code or some kind of functional prototype). Customers always respond to what they can see, rarely to what they hear.

So why do people keep following this fairy-tale process, knowing it will fail? If you have a good explanation let me know. Pigs may be tasty (unless you are a vegan) but they shouldn't be your software development methodology.