Software Development Life Cycle – SDLC in Real Life

The software development life cycle (SDLC) are the methodologies used by software teams to define, design, create, test, deploy, and iterate software to release new and improved functionality to the customers over time. Through the process of the methodology chosen by the software team, they aspire to go above and beyond customer expectations both in terms of quality and maintainability of the delivered product. Often during the SDLC, feedback of the customers is gathered through various means such as emails, project boards, intake requests, and meetings. This feedback is then used in the SDLC to kick off new loops of the cycle.

It is also worth noting that some teams even within the same organization chose different ways of managing their software development life cycles. These are the various methodologies often used by development teams:

  • Waterfall – This is the old monolithic style where software is broken into linear releases. Think Super Mario 1, then Super Mario 2, no downloadable content here and the 2nd release might even be nothing like the first except for the character names.
  • Spiral model – To be honest this seems overly complex where you try to adapt a little bit of everything from the other methodologies as your software collapses into it’s final form.
  • Agile or iterative – which can be further broken down into Scrum, Extreme programming, Crystal, Kanban, or Feature-Driven Development. Agile is best for long lived software that will have functionality continually built into for growing needs.
  • RAD (rapid application development) – This is a process best suited for software with well defined requirements that can be done in a set amount of time. You go through the same initial and planning for the project with mini-cycles of user design and construction until you ultimately cutover the software for another team to maintain. Many R&D teams may do this without even realizing their “release model”.
  • Devops deployment – This is a cycle based model with more emphasis on testing and gathering quality assurance results of the software. This is best used for software with very large production implications like ATM operating systems, smart phone operating systems and updates, and likely game updates for huge games such as Fortnite releases. But everyone knows even with long runs of QA you can still glitch out games.

Disclaimer that the rest of this article is now a satire loosely based on my real work to demonstrate the SDLC in practice, but for the purpose of this article the work, names, and the stories have been changed. Only the mindset of an overly ambitious try hard mid level software engineer have been left intact. Oh yea, the opinions expressed in this article are my own and I really do love my job and hope you can find humor and joy in everything you all do.

However, while this is always the goal of the SDLC, seldom is this the real world outcome because of scope creep, bugs, and customers’ growing needs over time. Thus creating an unmanageable cycle of life for this software, where the customer feedback may still get recorded and considered; but if and only if it sounds cool enough will the software team have enough bandwidth to do it among their ever growing backlog of cool stuff to do. This is because the longer an ambitious software developer works on a project the more their big ideas branch out. As you build all of these features into the software at a rapid pace, the more maintainability issues creep up as scale grows. Eventually you need to backtrack and strengthen the foundation to add more floors. Meanwhile the customer is asking for a roof deck on floor 5 with a pool and your penthouse on floor 23 is teetering over the edge of disaster.

A day in the life of Mitch the developer in the SDLC

It’s another Wednesday, which means within the software company Mitch works at it’s time to kick off another sprint from the Scrum methodology his team uses. Being the day of sprint planning also means he just spent most of the last night trying to finish all of the work that he boasted he could do within two weeks and didn’t because of all of the other impromptu work that came up during the sprint.

Mitch is likely tired and groggy, maybe disappointed with himself so he buries his shame in an 8$ coffee from the store next to his lobby. Who needs to save money when you’re Mitch. But that doesn’t mean he won’t put on his big boy pants and claim he can finish another 20 days worth of work in 10 days this sprint, gosh why does Mitch do this to himself. Oh wait there’s a holiday this sprint, should we include that? Nah Mitch will just work through it because holidays are for people that don’t want to retire before they’re 50. His choice, not yours, don’t be like Mitch. Even despite Mitch’s actions I promise software development is still a great job.

Coffee savings blowing tangent

8$ fancy coffee’s are highly recommended for ailing developers desk tears

Lucky for Mitch he only drinks his disappointment coffees once every two weeks. Saturdays are for $4 winner coffees where he celebrates the awesome work he did during the week and gets excited seeing his weekly views from his blog increasing, and here you thought bloggers don’t notice their viewers and their comments.

Adding that up you can see he only blows 32$ a month from his early retirement goal instead of drinking the free coffee in the snack areas. You may think we just went off on a tangent but I can assure you that developer peace of mind is very much a part of the software development life cycle as epics and story points are.

The Sprint Planning

Tom Laster leading the sprint planning

Anyways Mitch goes into the sprint planning buried behind his laptop waiting for the team’s scrum master to go through the roll call of still open stories. Maybe the harder he appears to work in his laptop the less attention he’ll draw when he says he hasn’t started progress on 2 of his work items that he wish were done two weeks ago. It’s better than saying he didn’t finish 4 though from the 2 he busted ass to finish last night and close at 2am.

How was he going to know a downstream service was going to deploy a change that broke the service’s assumption with them. Making it so millions of people weren’t going to receive the latest updates until he grinded through a fix that would take others 3 days but he did it in a single night of burning the midnight oil. Surely Mitch will get a shout out for this awesome hot fix right?

Tom Laster : “Mitch, how’s work coming on feature 1 in service Potatoes” –

M: “Looked at it. Pulled up my IDE to start working on it. Moment I typed the first character of code I was pulled into a fire that started in the Waffle service. It was a big one.”

Tom: “Ok, how about feature 2 in Potatoes”

M: “Looked at it. Pulled up the IDE to start working on it. Moment I typed the first character for that the Potato Fryer caught on fire and I had to help Jim and Jon root cause a jammed message queue. Deployed a fix for that after clearing all the gunk out of the fryer and wrote up a breakdown on why we fubared the launch.”

Obviously none of this was planned last sprint but as a software developer you need to be able to adjust and pivot to get shit done for the sake of a quality product. In hindsight Mitch should have actually typed the 2nd character of the code for feature 1 and made more progress there. If only Mitch could get more undisturbed blocks of time to code and really finish stuff!

Tom: “Ok I remember that. Lets kick them into this next sprint and look at the burndown”.

Or the grand canyon cliff as Mitch likes to call it with a slow descent over the previous two weeks and a steep traumatic plunge where everyone closes the stories from yesterday, Mitch included. Way to set a good example Mitch.

Anyways as a team they look over the burn-down and discuss the expected results verse the actual results. In actuality the velocity is really good and the team dealt with issues that came up well, but when you over commit it makes the overall story look worse than it is. But as they say in golfing you miss 100% of the putts that you aim short on so better to aim long.

The team then goes through and assigns the new work items that they determined they should work on in the previous days planning meeting. Normally that involves pulling potential work up on the display and fighting for why A is better than B is better than C even though the customer needs D and we really need to work on E so that we quit having to do manual work that the team has been doing for the previous 8 weeks.

Meanwhile as this goes on Mitch continues to do work by monitoring if his changes have been deployed to the charlie environment and he sees an integration test failed email caused by a deployment by Jon which is blocking his deployment. He dives into the integration test logs and sees it was a formatting error in the teams automated code style checker. Mitch pings Jon and asks if he ran the release build locally even though he knows the answer. Hopefully Mitch won’t need to wait too long for that to be resolved given that each fix requires sign off from two other developers and everyone on the team that could look at this are all in this meeting together for the next several hours.

Tom circles back to Mitch when they get to the project he is the primary owner over.

Tom: “Mitch we’re bringing in these blocks assigned to you?”

M: “Yep that’s right”

Tom: “That puts you at a lot of points, are you sure you can do that?”

Remember everyone that Mitch did put on his big boy pants today.

M: “Yep I got this, we really need that functionality to unblock the API progress of the other team depending on those items.”

Tom: “Sure thing chief” He says in a mocking almost sinister tone knowing Mitch is digging his own grave.

With all the stories assigned now’s our chance to give the shout outs.

Team member A: “I shout out Jim and Jon for their work unblocking the Potato Fryer”

“Wait didn’t I do that? And I even wrote the Fubar doc.” Mitch thinks to himself

Team member B: “I’d like to shout out Tom for that great meeting he did over why scrum would improve the productivity of our team”

Emm does it? And where’s my shout out for unblocking our sister team’s deployments for millions of users? Surely Jim will bring it up.”

Jim: “I’d like to shout out Jon for completing the half marathon last week”

Seriously Jim? That isn’t even work related.

Tom: “Do you have any shout outs Mitch”

Mitch: “I’d like to shout out myself for burning that midnight oil and unblocking millions of our sister’s team deployments”

Rest of team stares blankly at Mitch.

Tom: “You did what? When?”


While the SDLC definitely helps teams manage how they work on software it’s important to remember that when you are dealing with complex software that edge cases happen, dependencies change, you come across vague customer requirements, and sometimes you have to do jump in and do important work that may go unnoticed. To me it’s that same level of unknown and working through complex problems that makes software development extremely interesting and fresh even after years of working on the same time and same basic services that have ever growing needs.

Don’t get locked into a single SDLC model but do recognize that depending on what kind of software your team makes other methodologies may be more applicable. If the project development model your team is using seems to be not applicable to be productive with your software development life-cycle I highly suggest learning more about the other I recommended at the top of the page and propose change within your team.

I wish you all the best of luck on your software projects and enjoy being your best self when you go into work even if not everything you do gets the attention you think it deserves. As long as you’re bringing value to your customers, your work will always be important.

Written by: Stefan Bradstreet

About Stefan Bradstreet

Stefan is a Senior Software Developer at Amazon with 8+ years of experience in tech. He is passionate about helping people become better coders and climbing the ranks in their careers, as well as his own, through continued learning of leadership techniques and software best practices.

Thank you for visiting!

Please remember if you found this content useful and would like to see more python and software development articles from us, help us conquer the google algorithm in any of the ways below:

If you didn’t find what you expected feel free to use the contact page and let us know ways we can improve or what would help you grow as a developer better! I am honored by every view and it takes a village to really make this great.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s