We met with a prospective client recently, who asked me, “What is your programming philosophy–do you prefer Waterfall or Agile?”
If you’re unfamiliar with the terms, here’s a brief overview:
Waterfall Software Development
The waterfall approach to software development breaks the overall project into several distinct phases:
For Waterfall to work, developers can move on to the next phase only when its preceding phase has been completed and reviewed. We can’t swim upstream, and there are no fish ladders available.
The Waterfall Challenge.
The biggest problem with this approach is that clients seldom have a firm grasp on exactly what their requirements are. If requirements are unclear, the project will never get past the requirements-gathering phase.
But if a client insists on moving forward without completing each phase, software developers will likely end up throwing portions of the code away, as the project scope changes later on.
Agile Software Development
Several years ago, to address the limitations of the Waterfall approach, a group of seventeen software developers met to discuss alternatives. They published the following Manifesto for Agile Software Development:
Agile software development offers an appealing alternative to Waterfall. Rather than scoping out a massive project and trying to address every possible detail, it breaks development down into bite-size chunks. As each new chunk is finished and tested, it moves into production immediately. This approach is known for its ability to deliver working software to customers faster. Then, as end users begin working with the new features, they often provide valuable feedback to drive future development.
Some of the best software we’ve written was developed using the Agile approach; we met with our customer to identify an overall goal, then wrote self-contained modules which performed specific functions fairly quickly.
The Agile Challenge.
But there’s a potential tradeoff. Developing software without an overall project design is akin to building a house without a blueprint. Unless project stakeholders pay close attention to the overall project evolution, the final result can end up looking like the cobbled-together effort that was used to put it together.
Oh, and then there’s one other small (almost trivial) issue: cost. Agile tends to be a pay-as-you-go approach. As a result, Agile projects can end up costing considerably more than anticipated.
Don’t get me wrong–if your company’s goal is quality software written quickly, then Agile makes a lot of sense. Just realize that if you’re working within a fixed budget, you may end up with less functionality than you envisioned. I.e., you may run out of budgeted funds before the evolving goals for your project all come to fruition.
You’ve probably noticed that I haven’t really answered the question. Why? Because I won’t be writing the check for your software project. More important than asking, “What’s I/O Technologies’ development philosophy?” is the question, “What is YOUR development philosophy?” If you need software quickly and don’t have all the details fleshed out, then Agile is the way to go. On the other hand, if you are faced with a fixed, not-to-exceed budget and can put together a well-defined project specification, then let the water fall!