What about the waterfall methodology? ➡️

‍When dealing with large projects it's good to stick to a plan, have a guideline and deadline for the different aspects of your development. Today, two methodologies coexist, one of them is known as the Waterfall Methodology, because of its linear type of progression.

This type of development was the first type of method used in software development and is now often used for simple, planned unchanging projects rather than the flexible, customer-involved Agile methodology.

Let’s try to understand what the Waterfall Methodology is.

What is the waterfall methodology?

The waterfall methodology is a linear software development process. We call it linear because of its sequential nature, every step leads to a new one. Progress flows through the phases of the project toward the conclusion, like a waterfall. This particular model requires to fully understand a project in advance, to create the different steps, plan them, and set deadlines. Thinking about the outcomes, the feature variations aren't always a possibility and that limits the model’s capabilities.

In that model, the emphasis is set on distinct goals for each stage, completing one will lead you to the next task and so on. The top-level tasks which then have to be further developed could look and often look like this.

Analysis > Design > Manufacturing > Multiple tests and verification > Sales > Maintenance

Every phase influences the other phases down the line, this means that the Analysis phase has to be extremely well prepared as any mistake could introduce failures in the Design stage but also in the maintenance stage.

If a mistake is made, its effects might not surface immediately, it's only when doing the maintenance that you realize a particular design choice is inappropriate or makes your life difficult. In that sense, the Waterfall model is useful because it's easy to understand, and gives a clear timeline for your project.

However, in this framework, any mistake can be very costly because you then have to go back to the stage where the mistake was made and go through all the steps once more.

Why would you use it?

As we just saw, the waterfall methodology is a double-edged sword, if you know when it's appropriate to use, it can be very effective, if not, you could damage yourself.

Let’s look at when these methods are appropriate:

• Project with well documented, clear, and fixed requirements
• The product has a stable definition
• The technology in play is not dynamic
• There are no ambiguous requirements
• The product is supported by people with the right expertise
• The project is short

In these cases, the methods are appropriate, if not the most appropriate as you should be able to start the research phase straight away and get working on understanding the project.

This methodology does have a couple of things going for it. Things that make it particularly worthwhile in the previously mentioned cases.

Most importantly, it allows you to carefully segment the work and control the progress. These steps can then be scheduled and have to follow deadlines which help guide the project.

But that’s not it, here are other benefits of using this methodology:

• Easy to use
• Easy to manage as each step has specific requirements and review process
• Phases happen one at a time
• Adapted to small teams where requirements are well understood by everyone
• Clearly defined stages
• Milestones help guide progress
• The tasks can easily be assigned

As you might have realized by now, the model isn’t applicable everywhere as it doesn’t allow for reflection or revision. Once in the testing stage, it’s very difficult to go back and change the choices that were made previously in the preceding stages.

Here are the other disadvantages of the model:

• The end result is achieved very late in the development cycle, if the result is not what the user wants, any change is going to be very costly
• It introduces high uncertainty and risk
• That risk is too high and the methodology not applicable to complex projects
• Model doesn't work well with ongoing or long projects
• Doesn’t work for models that are uncertain and might change midway
• The final product is delivered as a whole at the end of the project which makes it difficult to identify potential bottlenecks

How you can implement it for your own

If you think these methods are applicable to your project, we’ll look at the different steps and how to start acting:

• Requirement analysis. The first step is the reconnaissance phase, it's important to understand the ins and outs of your idea to make sure the choices you make and the methods you choose to implement are the right ones. This time is absolutely not wasted and will spare you time in the next steps. Start listing the features, the look, the requirements you would need to sell your product, think of the price you’ll sell your product. The clearer your thoughts are on these ideas, the more efficient you’ll be. Now lay those specifications as bullet points and stick to them as any change could have huge implications in terms of costs and timeline.
• Design. Looking at the specifications like the price of your product, its features, start choosing the materials and the look of your product. This step should take into account the supplier and factories that will be the ones assembling your product. All your ideas might not be feasible.
• Manufacturing. This stage might not be your responsibility but try and agree on the quantity of products that should be manufactured.
• Testing. This part is here to check that the initial specifications have been taken into account. Record any issue you find and try to fix it. If the issue is serious enough, you might have to step back to a previous stage.
• Sales. In this stage, customers receive their orders, your goal is to make sure they get what they ordered, check the price and quantities from the warehouse and on the customer side.
• Maintenance. Last but not least, help users that face problems with their products, this will serve you for your future projects, keep track of recurring problems for the next iterations. This step ends when you no longer offer support for your product.

We’ve looked at the waterfall model, one of the most famous systems for product development, but isn't exactly the best! It’s a linear model that is easy to pick up and geared towards smaller projects. Progress can easily be tracked and tasks follow deadlines. However, the model suffers from a lack of adaptability as the different choices are set in stone in the initial research phase.