There are many ways to organize the workflow of software development. You might have already encountered a few of them, but not realize it. Maybe you do, but don’t know what the name for it is.

Among the many methods of organizing workflow for software development, a popular one is the Waterfall method. You can even call the waterfall method the “traditional” approach to software development. So, what exactly is the waterfall method?

What Is Waterfall Methodology

The waterfall methodology is a linear approach to developing software. More formally, it is a linear software development life cycle (SDLC). It operates in phases and requires the completion of the previous phase before moving on to the next phase. This means there will not be any overlapping of phases throughout development. In general, the waterfall method consists of the following phases: requirement gathering, system design, implementation, integration and test, deployment, and maintenance.

Requirement Gathering

All the possible requirements of the system are established in this phase. The requirements are documented and for the most part stay the same until the end.

System Design

In the System Design phase, the requirements from the Requirement Gathering phase are analyzed and a system design is prepared from it. The system design helps identify what hardware and software to use. In addition, it defines the big picture for the overall system architecture.

Implementation

The Implementation phase is where the development of each individual feature occurs. In addition to the development of individual features, each feature is tested in isolation for functionality. You will often hear this refer to as “unit testing”.

Integration and Testing

All the units (features) from the implementation phase are combined in this phase. After integrating all the units together, the entire system is tested for any faults and or failures.

Deployment

Once all the testing of the system is done, it is time to deliver the product to the customer. The system is packaged up along with everything else that makes it work. It gets deployed in the customer environment or released into the market.

Maintenance

Now the product is out in the market or in the customer environment there are going to be feedbacks. There might be some issues that need fixing. There might be some improvements that can make the product better.

In the maintenance phase, changes to the product are made and pushed out to customers through updates and patches.

When Is Waterfall Methodology Applicable?

There is no such thing as one size fit all. So, you might be wondering when exactly the waterfall method is applicable. Well, here is a non-exhaustive list of when the waterfall method is appropriate.

• The requirements are well documented, clear and fixed. You know for a fact that the requirements will not change for the duration of development until release.

• The technology is understood and will not change.

• There are no ambiguous requirements. There are no questions on what a feature should do. For example, instead of “show user an indication” it was “show the user an indication by flashing a blue LED at a one-second interval”.

• The project is short and or small. The larger and more complex a project is, the less effective waterfall become.

The Positives of the Waterfall Model

Here are some of the positive side of the waterfall model:

• Simple and easy to use and understand

• Developers and customers agree on what will be delivered early in development. This, in turn, makes planning and designing more straightforward.

• Aside from reviews, approvals, status update meetings, and etcetera, the customer is not required after the requirement phase.

• The design of the system is completed early in development. This allows for multiple software components to be designed for integration with external systems.

• The full scope of the work is known in advance. This means a measurement of progress is easier.

• Throughout the development life cycle, there is only one active phase. This means it’s possible for some members of the team to work on other work. For example, testers can prepare test scripts from the requirements documentation, while the developers are writing the software.

• All the requirements are known upfront, which allows for better software design. Better software design helps in reducing the chance of adding pieces of code that may not fit well in the system.

The Negatives of the Waterfall Model

Here are some issues with the waterfall model:

• The requirements must be well-defined and documented. Customers usually do not actually know what they need and don’t need. They have a hard time giving details because they are not exactly sure what they need or want. They also have a tough time visualizing an application from the requirements.

• There is a chance that the customer is not satisfied with the result. All the deliverables are based on the requirements documentation, so it is possible a customer may not see the deliverable until it is about done. At that point, making changes will be difficult (and costly).

• There is a high amount of risk and uncertainty.

• No working software is produced until late development. The integration phase is when everything starts coming together. Before then there is only functioning standalone features.

• Can’t accommodate changing requirements. Requirements must be clearly defined at the start and stay the same throughout.

• Integration happens all at once late in development. This makes it difficult to identify technical or business bottleneck or challenges early in development.

Why Should This Matter to You?

As a developer, you will likely encounter the waterfall method. It is the popular choice to default to when the development team you are part of doesn’t want to try something else. Even when you are told that waterfall is how the project will go, there is a high chance that it is not pure waterfall. Instead, it is probably something like waterfall (phases) and then the details in each phase become very loose. For example, after the requirement gathering phase, you probably will have a huge list of ambiguous requirements.

For you, that is not enough to start developing something concrete. But hey guess what, you are expected to start developing based off something vague. So, what can you do? Build something generic to be the base of a requirement and then wait until there is more info. You’re probably tempted to make assumptions and continue developing, but that can lead to a pile of wasted time and effort. So, use that time to give yourself a break and take care of your mental health instead.

When the requirements are not ambiguous it does not mean it is set in stone either. Chances are requirements will change. Sometime it will be a small change and sometime it will be a big change. All the hard work you put into developing feature X — get rid of it. It can be tough to do when you spent a few sleepless nights banging your head against the wall or tables to finally get feature X to work.

Technical bottleneck or limitations are also a problem you’ll likely encounter. The hardware and software were chosen from a vague list of requirements. This means there can be a hardware change mid-development. What does that mean for your code? Well, it means you can probably try to salvage as much as you can or start all over on the new set of hardware and software.

The bottom line is that you should try not to get too emotionally attached to your code.

What are your experiences with software development methodology? Was the methodology follow throughout development or at some point it starts to stray away?

To stay in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.