June 12th, 2019 by inflectra
A user on Quora recently asked the potentially incendiary question: "is agile development better than waterfall?". Rather than getting into a potentially religious war about software development methodologies (almost as contentious as deciding on coding standards in C++, curly braces on the same line or next line? anyone? ) I thought this question might be a good place to discuss some of the benefits of each approach (agile vs. waterfall) and ways to choose which parts of each methodology make sense for you and your project.
We have to remember the evolution of the software development industry. In the 1970s, computers were large mainframes where you had to rent time on the computer, encode your software into punched cards and feed them in for batch processing. A scary thought is that some of the systems we rely on today (banks, airline reservation systems) at their core are still based on such systems. Why else would credit cards get batched up each day and then captured for payment at 8:00pm each day. Behind every whiz bank web service and REST API is often a 1970s COBOL program with more patches, steps and workarounds than a Rube Goldberg device.... anyway I digress!
[Creative Commons: https://www.flickr.com/photos/jurvetson/10438860]
In this environment, the cost to make any changes was prohibitive. You wrote the requirements, designed the software specifications, wrote the code, sent it for processing, and tested the results to make sure it worked as expected. You repeated the testing and fixing until the results were correct. Then you repeated the same steps on the production environment with live data.Hence the waterfall methodology was born.
If you wanted to change things (for example handle a new type of bank account), you had to write up a change request, meet with the requirements analysis team, submit the design for review, code the changes, test on the development environment, and finally (after much fixing and retesting) go live.
This was all based on some assumptions that were true at the time:
As technology improved in the late 1990s, these assumptions were no longer valid (faster compilers, concurrent source code tools like CVS, continuous integration tools like CruiseControl, automated unit test frameworks), but still the methodologies (RUP, V-model) were holdovers from the past
Things have changed a lot since then, the cost to make changes is much lower than the cost of development requirements that no one needs or doesn’t meet the real needs of users (vs. what they think they want). That being said, there are benefits from some upfront analysis and requirements gathering, and for many industries, you cannot simply “fail fast”, imagine if you did that with a bank or a airline flight safety system… so there are things we can learn from both approaches.
With the publication of the Agile Manifesto and the adoption of agile methodologies such as Extreme Programming, Scrum, Kanban (and now scaled frameworks), the methodologies finally caught up with the technology. When you also throw in DevOps, and the ability to take a new requirement (aka user story), have it designed, developed, testing and integrated and deploy into production many times each day, you can see how far we have come, and why agile is now the dominant methodology. However to be able to use such an approach, there are a new set of assumptions that need to be true:
That being said, even if your situation precludes fully embracing agile, there are practices that are good software engineering regardless: