- The waterfall method, is the oldest style of software development. Early software engineers simply adopted stages from the hardware world, predominantly manufacturing.
- And over time, this approach became more refined. In 1985, the U.S. Department of Defense formalized the waterfall process, which specified that its contractors would use this approach, and only this approach, to write software along with detailed descriptions of how they use it, and the deliverables they create.
- As you may guess, the waterfall method is very structured with explicit stages. It's even called waterfall because you can't move to the next stage until the current stage is done.
- Everything goes from one stage to the next in a big dump; like water over a waterfall. Waterfall development starts with the requirements phase, where the product manager has the most to do; finding the right opportunity, and writing a very detailed P.R.D.
- After the requirements phase, engineering and design takes over, beginning with the design step and moving all the way through testing and integration.
- Waterfall has a number of benefits.
+ For one, everyone will have a great idea of what the final product will look like early on since you create a detailed specification.
+ Furthermore, since you do a lot of work up front creating the requirements, you might find and fix an issue in that phase. It's significantly cheaper to fix a problem early on. Because the scope is fixed early on, engineering can make close to optimal design decisions for the project rather than designing for potential unknowns.
+ Third-party development firms often like working with waterfall with clients because they can budget a project based upon the work they agreed to do.
- Product managers often like it because they don't need to be involved in the day-to-day managing of the project. Management may also like it because it's clear and easily understood.
- There are also drawbacks to waterfall that have caused many software teams to move away from it. These problems include the following.
+ Because waterfall focuses on specifying in building something complete rather than on fasted rations, what you build initially might not meet the customer's needs. And by the time you have a new version addressing their needs, you might find that the customers have long since stopped using your product and sought out another answer.
+ Secondly, after the requirements stage, you might find new data that affects the product and waterfall doesn't let you go back upstream to change decisions in the earlier stages.
+ Third, one of the most common problems is that there were technological unknowns and coding the solution took much longer than intended. So a three-month project actually took six months to complete. You had to invest those extra three months, because otherwise you wouldn't have a product.
+ Lastly, for example, maybe you thought customers wanted a certain product, but after building it you discovered the market condition's changed, and they no longer wanted it.
- If you're working on a product, whether requirements and technologies are well-known, waterfall is a reasonable approach. If your company is using a waterfall system, the best thing you can do as a product manager is validate the P.R.D. as much as possible initially, to prevent changes later.
- And try to learn quickly if the market likes your idea. In most cases, waterfall's shortcomings outweigh its benefits. Many software tools, including that of the Department of Defense have since switched to more iterative development approaches.
- There are numerous ones with various names, but eventually you'll encounter the second main development methodology: agile development.
