The early days

It doesn't seem that long ago that I had my first job as a software developer. Yet, many things have changed since. I still remember my first software release in the early 2000s. I had worked for months on software for our customer. I had finished all the requirements, and I was ready to ship all this to them. I burned the software and an installer on a CD-ROM; I jumped in my car and went to the customer's office. As you've probably guessed, when I tried to install the software, nothing worked. I had to go back and forth between my workplace and the customer's office many times before I finally managed to get it up and running.

Once the customer was able to test out the software, he quickly found that some parts of the software were barely usable. His environment was different and caused issues that I could not have foreseen. He found a few bugs that slipped through our QA processes, and he needed new features since his requirements had changed between the time he'd listed them and now.

I received the list of new features, enhancements, and bugs and got back to work. A few months later, I jumped into my car with the new CD-ROM to install the latest version on their desktop and, of course, nothing worked as expected again.

Those were the times of Waterfall development. We'll learn what this is about in the next section.

Waterfall model

The Waterfall methodology consists of a series of well-planned phases. Each phase required some thorough planning and that requirements were gathered. Once all these needs were established, shared with the customer, and well documented, the software development team would start working on the project. The engineers then deployed the software according to the specifications from the planning phase. Each of these cycles would vary in length but would typically be measured in months or years. Waterfall software development consists of one main phase, while agile development is all about smaller cycles based on feedback from the previous iteration.

The following diagram demonstrates the Waterfall methodology:

Figure 1.1 – Waterfall versus Agile

This model worked well on some projects. Some teams could do wonders using the Waterfall model, such as the Apollo space missions. They had a set of rigorous requirements, a fixed deadline, and were aiming for zero bugs.

In the early 2000s, though, the situation was quickly changing. More and more enterprises started to bloom on the internet and having a shorter time to market than the competition was becoming even more important. Ultimately, this is what led to the agile manifesto of 2001.

So far, you've learned how software development was done at the turn of the millennium. You've learned how those long cycles caused the releases to be spread apart. It sometimes took months, if not years, for two releases of a piece of software to be released. In the next section, you will see how agile methodologies completely revolutionized the way we build software.