Would you like to know the process behind building software solutions? (please don't say "no" 🥺). Thank you for saying "yes" 😅. before I get started with this, I need to share some statistics that will help you better understand the IT world. It is estimated that between 50% to 77% of software projects fail and of the successful ones, McKinsey posits that large, successful IT projects are 45% over the budget cost, 7% over the time predicted to build them and deliver 56% less value than predicted 😓. Basically, we can estimate that for every software solution out there, there are three more that didn't make the cut. This drives the question; "how are these software solutions built". Well, it turns out that there are two major methodologies used in building software solutions.
A RELATABLE EXPLANATION
We have the waterfall and the agile methodologies, it seems like most things in tech comes in twos 🤣 (monolithic and microservices, frameworks and libraries, stateful and stateless servers, frontend and backend, SOAP and REST API, etc.). Methodologies can be looked at as the thought process and strategies that are used to create software solutions, it can affect everything from the architecture used to the type and amount of employees used on a project.
WATERFALL METHODOLOGY
The waterfall methodology has been around a lot longer than the agile methodology (which is gaining ground quickly). Waterfall methodology involves a top to bottom approach that involves knowing everything about a project and factoring everything involved in building the project before actual building. Think of it like urban planning or building an estate. The waterfall methodology is one where the project is fully developed on paper before actual production starts, once production starts, everything is built according to the content of the document produced, it can sometimes take years to build a project with waterfall methodology, sadly, waterfall methodology is said to have a 10% success rate 😱.
AGILE METHODOLOGY
Agile methodology is one that involves starting lean with the basic concepts and features of the product after which the rest is developed along the way, it's kind of like the mentality of "we'll cross the bridge when we get there". Agile teams are typically smaller with mostly 5-6 members and they have meetings that are called "standups" which should normally be a very short meeting (max 20 minutes) daily where everyone talks about what they're working on and everyone gets to work. Agile methodology has a 64% success rate 🤑, which is touted to be at least 1.5 times faster than the waterfall method, which by extension saves money. Because competition and innovation move rapidly in the tech industry, Agile is mostly the best methodology for tech projects and nothing is cast in stone and everything can be improved on the go.
FINALLY...
Be that as it may, waterfall still has its use-cases and is very successful for a project that has a definite audience and where the demand/use-case of the project isn't likely to change like internal applications used by a company or projects that are aimed at solving a challenge in a specific way. Everything in tech (and probably life) involves tradeoffs, we typically don't have our cake and eat it where tech is concerned.