Software development life cycles
Have you ever stopped and wondered why we need to update software so often? Think about the average smartphone for example. Some common apps you’d find in this phone would be Facebook, Twitter, Instagram, and maybe some other apps that might help the user in their everyday life, but let’s focus on the first three for a second. All three of them update on an (almost) weekly basis. Add your other apps, plus OS Security Patches, updates and bug fixes to the equation, and you have a phone that’s updating something almost every single day.
Users might not know this, but these applications are always changing, whether they can see the changes or not. That’s what we refer to when we talk about software development life cycles: the multiple steps that are needed to develop a piece of software. More often than not, these steps are part of a never-ending cycle, which explains why there are so many updates.
Some common SDLC stages include planning, analysis, design, build, tests, deployment, and maintenance. At first it looks like it’s only a series of steps that you go through once, but that last step, maintenance, often means having to start all over again in order to make your program better. Notice that I said often, but not always, and we’ll get to that later.
The whole point of having a “life cycle” is to be able to detect bugs, glitches, or errors in your software before they cause trouble down the road, or even worse, get to the end user resulting in negative feedback (which isn’t really that bad, since negative feedback in the end is still a form of feedback, which you can use to improve, but still). Using SDLC’s to your advantage will more often than not result with you saving time, money, and most importantly, improving the overall quality of your product.
Two of the most popular SDLC approaches are Agile and Waterfall. The main difference between them is that Agile is cyclical, while waterfall isn’t. While it may seem that Agile always beats Waterfall, there are certainly some cases when Waterfall has the upper hand.
Agile
The agile model, while relatively new, has gained lots of popularity thanks to its iterative approach, which allows us to make our software better with each iteration. Nowadays, many software organisations swear by Agile’s way of handling things, because they allow us to adapt to the ever-changing demands of clients, who often want to squeeze in more functionality with each iteration, and its ability to be somewhat flexible compared to other models while still allowing for fast delivery.
Agile’s way of handling a project is somewhat similar to what we see in the divide and conquer algorithms, where we divide a big project into several shorter, more manageable pieces, which allow for shorter deadlines and easier development. These shorter deadlines also allow us to focus in what we call “sprints,” which basically mean focusing completely on solving the task at hand in order to finish faster.
Waterfall
Waterfall, compared to Agile, is way older. It might even be the oldest model for managing software projects. By consequence, this makes it the most straight-forward approach (some might even call it the brute-force approach). With this approach, while we still have several stages to develop our software, we focus only on one stage at a time, meaning you can’t move on to the next stage until you’re completely sure the previous one was completed successfully.
The one-step-at-a-time approach of Waterfall is what doomed it. It’s as rigid as it gets, not allowing you to go back to previous stages if you messed up, resulting in a massive time loss later in the project development, causing engineers to lose more time fixing things down the road, instead of just going back and modifying the approach.
However, as I mentioned before, cyclical approaches aren’t always the solution. Waterfall still proves useful in projects that NEED to be done right from the very beginning. Think about a rocket launch for example. You can’t proceed to launch a rocket thinking “well, if it fails we’ll just do another iteration and get it right… eventually.” Projects that need a perfect solution from the very first iteration might benefit from rigid models like waterfall, even if it means having to spend more time to get things to function perfectly.
