The Traditional "Waterfall" Software Development Lifecycle

You can still see ghosts of the traditional “waterfall” method of software development in modern agile practices. The traditional model involved long periods of planning followed by development and extended maintenance periods – ideal for long-lived systems (I’m shuddering and thinking of COBOL apps running on mainframes).

With today’s rapidly-evolving platforms and business’ intolerance for risk, developers are called upon to deliver solutions faster on changing hardware and software. The focus has shifted toward quick development cycles and constant integration.

At the basic level, the process is the same: plan, build, deploy.

A full understanding of the traditional “waterfall” software development lifecycle (SDLC) can help any programming communicate more clearly with project managers or clients who are more inclined to understand projects in these terms.

Phase 1: Planning (Logic)

The planning phase of the SDLC involves communicating with the project’s key stakeholders in order to understand the project’s requirements. What are the goals of the project, and what are the expected costs?

At this stage there is no program code involved, nor is there discussion of any particular programming language or framework. The goal is to understand what the new software will do and why; not how.

The planning phase is also the time to assess other possible solutions that could meet the client’s recommendation. This is where most analysts fail – rather than let their project stop at this point, many organizations will endeavour to push their own solution. Try to ignore the dollar signs – if you can meet your clients needs by integrating an existing solution rather than developing something new, you will make them happier because they save money and end up with a product that is completely within their best interests.

Phase 2: Design

The design phase brings us closer to writing code, but we still haven’t opened our IDE yet. At this stage our job is to create the software on paper based upon the requirements we came up with in the previous step.

Many clients feel like they are in over their head when your design starts taking form, but you can’t let them off the hook. You need to take the time to explain your design and make sure the client is fully aware and in agreement with what you are doing. Teach them how to communicate with you; learn the terms they use so you can speak their language.

Phase 3: Implementation

photo credit: Seattle Municipal Archives

When we start programming, this is the part we envisioned ourselves doing. In reality, this is the part we do the least (assuming we did our job right in phases 1 and 2). We’re talking about getting down and dirt with raw code.

Phase 4: Maintenance

This is the most expensive part of the project – keeping the software running. If you’re lucky you will be gone after phase 3 – if your successor (the maintenance programmer) is lucky you will have done a thorough job of your documentation in all of the previous phases.

Maintenance deserves special thought because it occurs over time, so it gets absorbed as an ongoing cost to the business. It can be hard to justify spending a lot up-front to develop a new system when the existing one “already works, and costs less”. Always weigh the ongoing costs of developing and supporting features for an aging system versus performance gains and optimizations possible with new software.

Sometimes it makes sense to keep existing software in operation; sometimes businesses hold onto decaying systems far too long. There will always be a point where the newer system costs more to operate than the old would have cost for the same stretch of time; however, the total cost of ownership – satisfaction, new features, bug fixes - needs to be considered, not just the cost of implementing the new system.