# Waterfall vs Agile.Such a scapegoat is the Waterfall model… So easy to bash for marketing reasons from pseudo specialists with sonorous titles.Nowadays it is all about agility. It is very easy to forget how everything started. The reason I am starting this essay the way I am is that comparative analysis is not possible between these two paradigms.But why?Let’s examine how it all started. Without delving into dates and names to save time for the reader. It all started with the first computer. We have a computer, but there are no programmers. The first programmers were not trained to program. They were specialists in different fields that needed computations to be handled on large scale. Suddenly they had the opportunity to automate this, so they started punching cards and give them to computer operators to put into the computer and run their programs. This process was taking almost always days – even in the time shared environments that appeared sometime later.At some point companies started to show interest in this new and shiny way to optimize their processes and begun investing in people and technology. However, failing a computer program is still very costly. Not to mention debugging paper cards with holes in them, is not exactly easy and complexity grows exponentially with the size of the software. In the meantime, people have already perfected methodology for manufacturing and construction. This type of linear sequential design approach later got to be called Waterfall. In short it is structured like this: requirements -> design -> implementation -> verification -> maintenance. There is nothing pointing towards software development in this model. It is as applicable to software as it is towards building a road or designing a microwave oven. Doing a lot of work at the start and taking everything possible into account to streamline the implementation/construction.For a while, this was working for software development. In terms of time period, we are still at a place where there are few computers around the world, ones in some of the universities and ones in some of the bigger companies. As with everything new we are trying to apply already existing knowledge and processes until we encounter wastes in the processes and adjust accordingly.The more experienced and keen reader would have guessed where I am going with this by now, so I will just state it for clarity. I am talking about the evolution of the software development model. I see the Agile model as an evolution on top of the Waterfall model. The evolution from predictive to adaptive software development is an important change of mindset. It is something that nowaday’s junior and senior developers struggle with during their whole careers. Always focusing on the wrong aspects of software architecture. Today’s programmers have little to no other work experience besides programming. They cannot apply knowledge acquired over the years spent in perfecting another profession. This is why they constantly re-invent the field and repeat the same mistakes generation after generation.Over time computers became more ubiquitous and accessible. And faster. Much faster. Suddenly every developer could enter the program by himself on his personal terminal/workstation and see the result in a matter of hours. Long gone are the punch cards and indefinite waiting times. Now people are able to test ideas and do prototypes without having all the requirements in place. This means that a team is able to do proof of concept in a matter of days or weeks, coming out with a better understanding of the field and knowledge about possible gaps in the requirements. In general, the Waterfall method is still holding its ground during that period.Going back to our story in the past, we take another evolutionary step forward. We get the first frameworks that provide application scaffolding, I/O and other goodies. Developers are writing higher level languages and have static code analysis, compile-time checks, and other quality tools. Reusable software is the hype and coding patterns emerge. There is much less architectural design going on in comparison to the past. Most of the patterns are repeated between different systems. Examples of this are application routing, storage operations, DB management, and others. A huge portion of the Waterfall approach is no longer needed for the common cases. The system design is dictated by the tools and application type the team is going to implement. There are much fewer requirements needed to start the project. More emphasis is put onto the business logic.Another jump of few years and we are starting to get application-specific frameworks and platforms like e-commerce, CRM, ERP, etc. Huge difference in the way we do distribution with cheap shared hosting and cloud computing. Today there are scaffolding solutions for entire IT infrastructures depending on the type of application one is going to build. This puts focus more on the quality requirements of the application. More and more businesses need to specify their non-functional requirements and criteria for the application, together with the desired business logic. And much less “how”, “what”, and “where” is going to be implemented.By removing the burden of the heavy architectural decisions much of the Waterfall model is becoming obsolete for the mainstream development. This is where iterative approaches like the Agile methodology and its derivatives start to get traction. However not without difficulties. The problem is that it is marketed as something new that defies the old.Big companies still largely function in a sequential way and are slow to respond to rapid change. This change of the mindset in management is not a focus of this essay, but it deserves to be mentioned.Getting back to Agile. Let’s examine the word – it is an adjective. One cannot achieve “agile” nor sell it. A lot of effort is done into selling vicious pseudo methodologies under the cover name of Agile. Ones such as SCRUM. However one cannot achieve “agile”, one can achieve agility. Agility in programming can be achieved in many ways neither of which can be streamlined. By definition establishing a process puts you in a place where you need to break rules to be agile.However, if we define an area where we are going to be agile, things dramatically change. As established earlier there are a lot of solutions that offload a huge chunk of the effort involved in requirements conceptualization. This means we can be iterative and flexible in our business logic implementation.The wrong assumptions when people compare Waterfall vs Agile mostly come from their popular definitions.Waterfall:1. Gather requirements2. Design software architecture and UI3. Implement software4. Verify and test5. Maintenanceand then suddenly we no longer speak about steps and process – we are agile, right? So let’s speak of the “inspirational manifesto”:1. Individuals and Interactions over processes and tools2. Working Software over comprehensive documentation3. Customer Collaboration over contract negotiation4. Responding to Change over following a planBut wait – we don’t need to gather requirements when we are agile? That is utterly ridiculous! We don’t need to design our software, both UI, and infrastructure? Since we are agile we suddenly don’t need to do anything else but collaboration… Collaborating on what?! Ah! Might it be that we need to be flexible when gathering the requirements? Or when we do our design, identify what we could do as proof of concept to clear out the grey areas. Versatility during implementation and testing? Agile manifesto suddenly starts making sense when applied to the rigid Waterfall process. In combination with the modern tools, one could offload important architectural decisions almost until the very end. Decisions like the type of data storage, is it going to be SQL database or NoSQL one? Does it matter while we are developing the business logic with mock data? Of course, it does not. However, there is one big benefit of this – our business logic could change its API fast with little consequences. This allows for flexibility and cheap iterative development instead of fixing costly decisions later in the application lifecycle.To summarise. I don’t see Waterfall and Agile as two competing methodologies for development. My firm belief is that we need to see beyond the cheap marketing tricks that aim to sell us certification. Agile builds on top of Waterfall as a complementary methodology. One that aims to improve collaboration between parties and allows for flexibility and creativity into the rigid old sequential structure.The only way to achieve good quality software is by iteratively collaborating on it while following concrete product vision. Flexibility comes partially from offloading architectural decisions until the very end and allowing your software to grow into its requirements and not by forcing it into a rigid pre-defined skeleton.