A Brief History of Waterfall Software Development
How did Waterfall come about?
The software industry pre- and during the 1970s was very different than it is today.
Most software projects were large software packages, often coupled to infrastructure, and so were managed and developed in the same way – applying infrastructure-based (hardware) development methods to the creation of software. Some examples include government projects and large projects for NASA, such as the software development that went into the rockets to go to The Moon.
Due to the rigidity of specifications needed to be met for these current projects, there was little room for variation in the process. Any changes made to the specifications during development would have resulted in high costs, so the very rigid and structured approach of Waterfall worked well.
The Waterfall model was believed to be the first software development process model to be introduced to the software engineering industry. This belief is supported by the timeline of events surrounding the emergence of the Waterfall model.
What is Waterfall software development process?
Under the Waterfall methodology, the software development process is chunked into phases, which can only be completed in chronological order.
The output of each phase must be completed and signed off before the next can start, so progress is seen as a flowing downward stream through the line of handovers, like a waterfall. The only way to return to a previous phase is to start over at the beginning of the Software Development Life Cycle (SDLC). The completion of each phase marks key milestones in the SDLC, and the lead time to completion of the final product can be predicted based on the estimated time to complete the remaining phases.
Phases of Waterfall:
- System Requirements: The first phase in the Waterfall software development process is creating comprehensive documentation of the customer’s requirements and specifications for the software. This is a key aspect of Waterfall and it is assumed that the customer has a robust picture in mind of what they want to achieve with the software and all specifications required. The documentation will include a plan for acceptance testing, so further customer involvement is not needed until the product is complete and all specifications will be met.
The Birth of Agile
How Agile came about
The Agile approach to software development emerged in the 1990’s as a result of the increased usage of software by businesses, and eventually end-users.
Waterfall, while adequate for large infrastructure projects, was inadequate for developing commercial software which contained much more variation to specifications.
Software developers of these modern commercial products found the traditional processes were too heavy on the infrastructure and created a number of problems:
- long coding runs which led to increased lead times and increased resistance to rework
- long periods of time between review so errors propagated throughout the project
What is Agile software development process?
Agile is an incremental and iterative approach to software development that has become widely used in the software industry. Although you will have most likely heard people talk about ‘being Agile,’ and ‘doing Agile,’ it’s important to understand that Agile is a framework, a set of principles, rather than an exact method.
So, then what is Agile software development?
For most small-to-medium-size software companies, the most practical approach to Agile is Scrum, specifically using the time-based concept of sprints. If you look at almost every software company that uses an Agile approach, they’re using sprints – where they plan out, generally, a fortnight’s worth of development work to create a value drop or deployable piece of code, and then focus and execute on only that planned chunk or increment.
Waterfall VS Agile
Pros and cons of Agile
PROS:
- Faster delivery of a product to market or value to the customer.
- A basic, functioning, piece of software is developed quickly to increase speed to market or value to the customer quickly. The value transfer to the customer is much sooner than in a traditional software project.
- More adaptive and flexible.
- The working software is iterated using feedback on how the customer uses it or feedback about what more they would like from it.
- Customers don’t need to make all the decisions about the final product up front – they can make decisions, changes, or adjustments based on what they discover from using the early versions of the product.
- Software will be more aligned and tuned with customers’ needs based on what is discovered during iterations.
Is Waterfall project management dead?
It’s very easy to jump to conclusions and say, “Yes, Waterfall is dead!” But if you take a step back, it’s not so simple.
It’s not difficult to see why many people think the Waterfall approach is dead. Waterfall has been vastly overtaken in popularity by Agile; all the conversations in the software space are about ‘doing Agile’ or ‘being Agile’ while very few are about doing or being ‘more Waterfall.’ But the interesting thing is that very few software companies (if any) are implementing 100% of one approach or the other. Most companies take a hybrid approach that is somewhere in the middle.
Yes, it’s probably true that Waterfall, in its exact form, is no longer relevant in the software industry. However, many of the Waterfall principles still have their place in some applications.
And the winner is…
Waterfall advantages:
- Developers have a more robust picture of what the software needs to achieve, which makes planning, design, and testing more straightforward.
- For large projects with bigger setups, Waterfall ensures all specifications, requirements and milestones, or due dates, are achieved. There is better adherence to the initial project plan.
- The software development plan is structured and can be lined up with a project plan for any infrastructure or hardware components also being made, e.g. a long-term Waterfall-style project plan that the car development or product (hardware) is going through. This ensures software components are ready for integration with hardware components.
- Easier to track overall project progress and time to completion.
Beyond Agile
Pace: a new approach to software development
In some areas of software development projects, we need to go back to being less agile, and more rigid and robust with our planning. In other areas, though, some of the benefits of Agile aren’t agile enough; we need to push to be even more agile. For example, sprints in many cases are planned off what the team’s capacity is. A sprint aims to get x amount of work completed in a certain amount of time, i.e. 10 days’ worth of work completed by the team in 10 working days.
Pace is an approach to software development that has emerged as a solution to the negative side effects of the Agile approach. It’s not a radically, out-of-nowhere, different approach from Agile.
Rather, it’s much like the previous ‘evolutions’ of methodologies in the software engineering industry, where it seeks to address unresolved challenges.