Before we begin, I assume that some people would come here to take their first steps into the world of Software Development. While you were researching what you need for building your first golden goose of an app, you came across the term Software Development Lifecycle or SDLC.
Let me break it down for you, as in Physics, terminology in software development is often right on the nose. For example, a Blackhole is literally a "Black" hole, a Neutron Star is made of highly condensed Neutrons, etc. Similarly, the Software Development Lifecycle is literally the different stages your software goes through from its ill-fated conception to its untimely deployment (puns intended).
Keeping up with the metaphor of an unwanted child, your software development works in similar stages:
1) Planning: Ironically, the life of your software development child starts with planning all the following stages. It's much like figuring out how your 1-day old baby will pay for its college loan down the line. It's often inaccurate and doesn't account for your child's propensity to drop out of high school and become a rock star.
2) Development: This stage is the mother of all future trauma. It can be very enjoyable watching your newborn go through teething, scraping knees, underage drinking, and finally becoming big enough to go out into the world as a bright-eyed member of society. But this stage can also end up giving you a devil child who goes around breaking the law because you didn't give it enough attention.
3) Testing: The stage your software gets punched in the gut by the experiences of growing up. It can be painful, but if you did your job right, this stage only helps transform your moody teenager into a functioning adult.
4) Deployment: It's finally time, your child is all grown up, lived a life, got shaped by society, no kids though, because all software is inherently sterile. It's never the right time, and you don't want to let go, but when the grim reaper (your client) comes calling, you can never say no.
5) Monitoring/Iteration: Did I say your software is like a child? Well, unfortunately, it's time to step outside of the metaphor, because it's not. Unwanted or not, for most of us, the software development lifecycle is a never-ending cycle, where your deployed software is but the beginning of the next iteration when you start from stage 1 with new requirements.
Dear reader, you might be wondering: "All this forced analogy is all well and good, but how exactly should I go about making the Software Development Lifecycle for my software?" Well, I have good news and bad news. The good news is that there are simply way too many tools out there built specifically to make your SDLC easier. The bad news is that there are SIMPLY TOO MANY tools out there built specifically to make your SDLC easier.
It's like a minefield of Legos. You have dozens of Project Management tools that are meant to help you with planning, task allocation, and monitoring of progress. Dozens of IDEs and version control software to aid in your development. Dozens of Testing tools, both for automation and manual testing. And, you guessed it, Dozens of tools to help you with Deployments. Apart from all this, you have dozens of tools helping you bring all of this together in the form of Continuous Integration and Continuous Deployment Pipelines (CICD).
For our math geniuses out there, that gives you a Dozens^5 combination of tools you can be using. But not all combinations are fiscally or practically useful. Select the wrong one, and you might be drinking from the poisoned cup with the ghost of an old knight telling you "You chose poorly" before you drop into bankruptcy.
Okay fine, it probably won't be that severe for you — I was being overly dramatic just to drive the point home. The point is, that implementing an effective SDLC is a major task. It takes a lot of patience to set up, but is almost always worth it.
The setup of a successful SDLC
As mentioned above, an SDLC has 5 stages, and each of those stages can be as extensive or as minimal as you so choose.
Let's take a use case to make understanding this easier. Imagine you are the manager of the company "iRule" that makes applications for helping Kings and Queens manage their kingdom better.
You receive an order from the Queen of Hearts to make an application that can organise their royal treasury and keep accounts of incoming and outgoing treasures. They tell you that this product needs to have everything — automatic calculation of taxes including which peasant has over or underpaid, incoming and outgoing gifts, a registry of users that have permissions to enter the treasury — on top of all that, a kickass UI/UX. And of course, you have to do a good job, or it's "Off with your heads!"
Planning
You sit down with your team and try to evaluate the terms and requirements of this product. You need to figure out all the minutia, including how much time and labour it will take to make this, which features are the most important, what will be the user flow, and finalise the high-level architecture for your product. You then go back to the Queen to take her feedback and account for any changes requested by her.
You declare this stage of your SDLC is complete, and decide to move on to the next stage. This use case paints a very rosy picture, despite the constant threat of beheading. In reality, the planning stage is full of pitfalls.
| Problem | Explanation |
|---|---|
| Misunderstanding of requirements and changing requirements from client | Clients rarely know the entire picture of what they want. And even if they do, not everyone can communicate their requirements clearly and completely. You might spend a month after the first feedback creating the product, but end up with something the client never wanted in the first place. |
| The software team has no client interaction | Your software team is the one that is building your application, but they are usually never the ones who talk to your client. It's a minefield of misunderstandings and miscommunications that leads to an explosion at every step you take. |
| Client Feedback is not handled properly | The client is the boss, so if they say something has to change, logically you should do it. But many times, the feedback gets buried in busy work, forgotten comments, and miscommunications. |
If these problems are not handled properly, while you might not lose your head, you will lose the client's trust along with your time and money.
So, what can you do?
It is impossible to put the onus on your client. You could try and set up conditions that any additional features after the first set of requirements will be on a charge basis, or try to have extensive planning meetings with your client repeatedly to ensure the first-time-right scenario. By the end of the day, neither of those two options is really in your control.
There is one other option, that is in your control: make sure that the product and stakeholder information is properly recorded, transparent, and accessible to your entire organisation. This helps all your teams to be on the same page while being aware of the bigger picture.
Development
So, you at 'iRule' managed to step over the pitfalls of Planning and finally decided to start development.
You had decided that you need a team of backend developers, frontend developers, UI/UX developers, etc. to develop the Minimum Viable Product within 1 month. You searched far and wide, recruiting the greatest masters from around the world, and rounded up the greatest teams ever seen.
You wonder, each team knows their assignment, they are masters of their trade, and the requirements are as clear as day. So, what in heavens could go wrong?
| Problem | Explanation |
|---|---|
| Inconsistencies due to lack of reviews | A person's way of coding is like a fingerprint, everyone is different. This can lead to software code that is difficult to read and buggy. Reviews help bring conformity to the code, while also catching mistakes at a very early stage. |
| Amending one feature can trigger unintended cascading changes | For example, if you change the date format in one part of your code from mm/dd/yyyy to dd/mm/yyyy without updating the rest of the codebase, some other module might start looking for the 25th month of the year! |
| Unit Testing is incomplete/missing | Unit Testing is the responsibility of the developer. It's the most basic testing suite written in parallel to development and helps maintain a basic bug-free setting for each function. In simpler terms, if you are making a chair, at least test it by sitting on it once to make sure it doesn't break. Unfortunately, it's a very boring and time-consuming task that most developers try to avoid doing. |
| Duplicate work due to work allocation confusion | If you allocate work without properly documenting it, you might end up with two developers building the exact same feature. Then comes the painful decision of whose work to keep and whose to throw out — and someone always ends up with the short end of the stick. |
These problems are universal, no matter if your team is full of amateurs or masters — it's a human condition. If you fail to keep these in check, the next stage will make you wish you had been beheaded in the first place.
So, what can you do?
Some of these issues just need a sterner hand. Enforcing that your team writes unit tests and reviews each other's code on every change might just be the miracle drug your code needs.
While many Project Management tools help keep track of work allocation and task assignments, they are not a one-stop solution. You can still end up allocating duplicate tasks if you aren't careful, and it will definitely require regular manual inputs from you and your teams.
Testing
If Development is the heart of your SDLC, Testing is the soul. In the same way Emotional Damage makes you a better person in the long run, running your software through extensive testing suites makes your software a better person in the long run. And you, at "iRule", pride yourself on always keeping your employees and software as emotionally and mentally damaged as possible!
Testing usually follows the motto: "you shall not pass!". Your testing teams work day and night and extensively test everything the development team throws at them. Every vulnerability, edge case, and input are meticulously checked.
But along the way, you start to see some troubles brewing on the horizon. Your testing starts to slow down. Bugs keep evading all your testing efforts, and soon your development speed starts to be impacted.
Code keeps getting sent back for fixes, and it almost feels like you are building a house of cards that will collapse at the slightest gust of wind.
So, what happened to your perfect plan?
| Problem | Explanation |
|---|---|
| Inadequate testing | Testing is not as simple as clicking a button and calling it done. It covers every possible scenario your software could face — edge cases, invalid inputs, unexpected user behaviour, and more. The scope is so vast that even giants like Google, Facebook, and Amazon are not free of bugs and downtime. |
| Complete absence of automation | Testing is expensive, time-consuming, and repetitive. And as with all repetitive and time-consuming tasks, automation is the only answer. |
| Security issues arise at the testers' end | While in development, the code is rarely checked for security vulnerabilities, which means that even an update to a third-party library could introduce a security vulnerability that goes unchecked till a tester gets to it. |
| Multiple testing tools become confusing | There are dozens of testing tools that can be used by your team to implement the complete testing of your application. Running each one, collating the results, and gathering a complete picture is tough, to say the least. |
| Changes in testing requirements can cause false negatives | Changes in development can often cause a change in the testing requirements. These changes need to be communicated to the testing teams, otherwise, a perfectly working code could be flagged as broken. |
Testing is one of the most important factors that decide the quality of your software. A broken link might not send you to the gallows, but what if a bug causes all the details of the treasury to be leaked?
So, what can you do?
Almost every problem faced by the testing team can technically be divided into two sections:
1) Lack of communication between teams: Adding simple communication channels like Microsoft Teams and Slack might not be enough to bridge this gap if the information itself is too complicated to explain, or if the teams don't know whom to talk to. Your SDLC needs to have owners at each level, and channels that can directly pinpoint the problematic area.
2) Lack of Automation: While not everything can be automated, creating automated tests for everything that can is an amazing way to mitigate most problems. But setting up and maintaining your automation can be very taxing due to the sheer number of tools you need to use. This is where your CI/CD Pipelines come into play — their main purpose is to help you automate your testing and deployments.
Deployment
It's finally time, your first version is ready to be sent over to the Queen. She looks impatient and holds a bag of gold coins in one hand and a sharpened ax in the other.
You feel confident that your software is the best of the best. As you walk up to the podium, all eyes are on you and you think to yourself, "Nothing can go wrong today!" Suddenly your phone starts to vibrate, but you ignore it and keep walking with a smile on your face. As you approach the mic, your phone doesn't stop ringing. All eyes are on you, you can't look right now, so you start talking. Everyone hangs on your every word as you go about your presentation, and the queen slowly starts to loosen her hand on her ax.
The moment has finally come to show your demo. You type out the address of your web application, and press enter. The loading icon starts to rotate. It goes round and round. Everyone is staring in anticipation, but all they see is the loading icon going round and round.
Suddenly the room gasps, and you swiftly turn back. Oh no. Your eyes widen. The queen drops the bag of gold and tightens her grip on the ax. Your worst nightmare has come true.
404, RESOURCE NOT FOUND!!!
You hurriedly look at your phone and see a hundred messages and dozens of missed calls from your product manager.
All you hear is "OFF WITH HIS HEAD!!!" and all you wonder is "What went wrong?"
| Problem | Explanation |
|---|---|
| Application deployment to environments is cumbersome | Deployment Environments are basically different deployment steps an application goes through with the final step being deployed to production. Most companies follow a DEV → TEST → QA → PROD sequence. Keeping track of what code goes where; when is it to be released; are there any special steps involved; etc. requires a lot of attention to detail and becomes cumbersome to deal with. |
| Human error | Most mistakes in your SDLC, like with anything else, can usually be traced back to human error. Forgetting an environment variable, misreading the version number, or even forgetting the date — any of these can be the reason for failure. |
| Incompatible environment | Software that doesn't use containerization like Docker or Kubernetes is highly vulnerable to environment mismatches. Unless exhaustively tested across every foreseeable environment, your application might break for a completely opaque reason — a mismatched library version on the server is all it takes. |
| Miscommunication between Dev and Deployment teams | If the Dev team adds a new environment variable or changes a config and doesn't communicate it to the Deployment team, the deployment will fail in ways that are completely avoidable. Small handoff gaps cause big launch-day disasters. |
Deployment is the whole reason your software exists. If you fail to deliver, your beheading is justified.
So, what can you do?
The same rules apply here as with testing. You need proper communication channels, ownership of tasks, and automation. Deployment automation has a major advantage over manual simply because of how consistent it can be. Every version, every patch, for every iteration, will always be released the same way consistently, and without any human error.
Monitoring / Iteration
Well since iRule is now dead, we can't keep using them as a reference. Oh well, such is life.
In reality, the first deployment is rarely the end of the story. It usually is a pre-cursor to feedback from the client that gets sent back as requirements to the first stage. Alternatively, many companies follow the iterative approach which means that this first deployment might just be a Minimum Viable Product. For them — and most probably for you — the next step would simply be to pick up the next set of functionalities scheduled in the planning and start their development.
And then…
Dear Reader, this hyper-dramatic article may seem too unrealistic to you. And you might feel iRule reminds you of King Joffrey — so unrelatable that you feel like punching them in the face. But frankly, the story of iRule is just an adaptation of what happens to hundreds of software companies every year.
Lost orders, unhappy customers, and buggy software is par-for-course for many. And it's not too complicated to understand why it's hard to actually implement the solutions mentioned above.
Does any of this sound familiar?
"We have tried using all the various tools for our Project Management, Development, Various Testing and Deployment Automations, and CICD, but it's so time consuming, and takes so long to implement and integrate."
"We do basic testing to ensure code sanity, but we have no resources to implement automation and extensive testing."
"The tools available are not intuitive or informative enough, so we don't find the need to use them."
"We mostly use combinations of free or open-source software, although it takes a long time to implement due to lack of expertise and maintaining it is a full-time job — at least it's free!!"
All I can say is that you are not alone.
Author: Akash Mehta, Co-Founder, Apice Tech