Entering SaaS: The Engineering Side of Programming (Part 1: Plan-and-Document)


HOW IT ALL STARTED

This is my third time reading this chapter, and I still cannot get these phases/steps to stay in my head. Maybe writing them in my own words will help. It turns out that programming didn’t always have the “engineering” element it has today. People used to just “hack” away and program. This lack of planning drove the search to find something more predictable in the late 1960s. This is when the Plan-and-Document strategies appeared.

PLAN-AND-DOCUMENT STRATEGIES

I’ve read of three strategies that fall under plan-and-document: Waterfall, Spiral, and Rational Unified Process (RUP). Though it really depends on the specifications of the project to know whether a plan-and-document strategy is right, it seems that there were some big concerns with these strategies. Still, these strategies charged head first into tackling challenges that plagued programming projects, heavily focusing on documentation in order to increase predictability.

Now before I get into the problems people faced when using these strategies, let’s actually go through and see what each strategy had you do. The strategies are covered in chronological order.

Waterfall: It’s called waterfall because it completes each step, one at a time.

  1. What do you need?
  2. Let’s design it.
  3. Time to build.
  4. Does it work?
  5. Let it fly. (Release)

Spiral: It’s called spiral because it goes through each of the phases in a single iteration. There are typically 4 iterations, and each iteration gives you a prototype.

  1. What am I trying to do? What are my constraints?
  2. What are my options? What are the risks?
  3. Let’s build then test.
  4. Plan the next iteration.

Rational Unified Process (RUP): It’s the plan-and-document strategy that keeps business in mind. It’s also a little different in the sense that it has 4 phases with 6 workflows that span the 4 phases (a presence in some more than others). The workflows are business modeling, requirements, analysis and design, implementation, test, and deployment.

And the phases are…

  1. Inception: Get a pretty business plan. Make a budget. Create a schedule.
  2. Elaboration: Design and plan.
  3. Construction: Build, test and release.
  4. Transition: Move to production.

PROBLEMS

Have you heard of the Affordable Care Act (a.k.a. Obama-care)? Apparently, healthcare.gov didn’t work so good when it was first released on October 1, 2013. It was slow, had errors, and was down a lot, which was on top of the fact that the website was contracted to cost $94 M and ended up costing $292 M. The plan-and-document strategies look really good on paper and when companies are negotiating a contract, they can show a plan where everything is documented with deadlines. Where’s the problem?

Here’s the problem. People don’t know what they want. They say they know what they want, but it’s not until they have something in front of them can they tell you what they really want. In the plan-and-document strategies, customer inputs are too far and few between. On top of that, each phase is “finished” before moving to the next. It is harder and more costly to find problems near the end than it is in the beginning. A combination of these two problems led to projects with missing functions and projects that were late, over-budget, and even terminated or abandoned. Unfortunately, this is the company that the Affordable Care Act found itself in, but fortunately they found Agile.