Waterfall is the old school methodology of software development but is still practised by companies throughout the industry. This section will teach you all about waterfall methodology and its shortcomings.
The waterfall methodology is so called because of it is a linear approach to development with each step flowing on from the previous one. These steps are often drawn in a waterfall pattern.
The typical steps in a waterfall project are:
- Requirements gathering All the requirements for the entire project are gathered in advance. This usually takes the form of one or many very large documents. Each document details in very low level detail the entire system and every function it will perform. This is called the functional documentation.
- Design Once the requirements for the project are delivered, then the architectural design can commence. The architect team usually produce many diagrams and more detailed documents describing how the requirements will be met. These are the technical specification documents.
- Implementation Once the detailed functional documentation is complete and the detailed technical specification documents are written, then the development team starts to build the application.
- Testing Once the development of the application is complete, the testing team then test the system and pass any bugs back to the software team to fix.
- Delivery Once all the bugs are fixed, the software is then delivered back to the stakeholders.
In practice, this approach does not work very well for anything but the simplest of projects (projects taking less than 4 weeks).
The system breaks down due to the following:
- Complexity of software
- Length of time taken to deliver anything useful
- Requirements changing due to changing business environment or details are uncovered in later stages of the process. (E.g. a developer finds out that the architects plan can’t work due to limitations in the coding language chosen).
In reality waterfall projects have the following side effects:
- Slow pace of work to begin with as everyone knows it is months or years before the deadline.
- Huge rush and panic towards the end as the deadline draws near.
- As testing is not done during development, the list of errors is usually huge and takes much more time than was allocated to testing which causes the project to overrun or code that is not stable is released. This is compounded by the fact that testing comes at the end and if the project overruns, it is the first thing to get cut.
- Change becomes a problem as the process doesn’t allow for going back to a previous phase. Any change causes the entire project to be re-estimated and re-scheduled. For this reason the project team do everything they can to dissuade the business from making changes.
- As the business wants to make change, and the development team doesn’t, the development teams usually force the business through a long and costly change request process.
- When the project is finally delivered, in most cases the functionality is no longer required, or the understanding of the original requirements has been lost along the way and the functionality wasn’t what was intended by the stakeholders. This is because there was no way for the stakeholders to check as the project proceeded.
- The project is described in technological language which the stakeholders / business don’t understand. This causes disconnect between the project team and the stakeholders and errors due to translation.
Stay away from waterfall projects
When looking for your role, I strongly recommend finding out if the project you are going to be working on is run with a waterfall methodology or an agile one. If it is waterfall one, I would recommend not taking the role.
Get certified!
Learn more about agile on our highly-impactful and certified agile training courses in London and online.