How we plan and build software is the difference between your job being fun and you looking for another job.

The idea of bad software and tech debt has plagued engineers for years, but luckily, there’s a method of fixing all of the pain - proper SDLC implementation.

The goal of this blog post is to help you learn the SDLC process and how to think about it from a pragmatic perspective, so it will have real-world examples in each section of the SDLC lifecycle.

What’s SDLC

The Software Development Life Cycle (SDLC) should be in every engineer's life. Whether you’re a Software Engineer, SRE, DevOps Engineer, Platform Engineer, or whatever other title is buzzing around at the moment.

The goal with SDLC is planning, understanding what you’re building, design what you’re building, build it, test it, and deploy it.

This could be for any engineering job. You could be writing software code, writing IaC configurations, building a pipeline, or mapping out a new way to run infrastructure in the cloud. In any case, everything around the SDLC process must be used to ensure that how whatever you’re deploying is done correctly.

To make this blog post useful to you and not something that’s “just some more theory”, let’s plan out a story/scenario that we can use to effectively explain the SDLC process.

Here’s the scenario: You’re an engineer at a company that you just got hired at. For your first task, they’re throwing you into the deep end. You’re officially drinking from the fire hose.

Your job is to build out a new feature within your product/application stack that involves writing code, planning out the feature, and efficient implementation.

Planning

The first phase in the SDLC process is Planning. The goal here is, as the name suggests, plan out what you want to build. This is everything from how you’re going to get started to where you’re going to write, test, configure, and deploy the application to everything else that’s needed for the architecture. Another big piece here is understanding what your new feature impacts and who it impacts (what teams are impacted in (hopefully) a positive light?).

The planning phase is a great time for you to sit down and think about the new feature. What cloud is it going to run in? What skills do you need? What’s the cost? And most importantly, what does the architecture look like for this thing to run? In this stage, I love pulling out my Kindle and reading a few pages of a book on this topic with my notebook next to me taking notes and diagraming out what it could potentially look like. A great way to do this is by using something like draw.io.

Requirements

The second phase in the SDLC process is gathering Requirements.

You can think of this phase as the Product planning piece of the puzzle. A big question you should ask yourself is “What are the people using what I’m building expecting to get out of this?”. Is it for external users? Are you building a platform for internal use?

The goal here is to collect information from everyone that’s going to use it. If you can’t collect information directly (e.g., if it’s for external users), collect the information from the data you already have or can find online.

Alright, it’s time to start planning your requirements for your new feature. Your new feature is for external users outside of your organization, so you have to gather some requirements. The best way to do this is by:

1. Ask your Marketing and/or Product department if they have any data for end users wanting the feature you’re building.
2. Browsing the interwebs/social media to see if people are talking about anything specific in regards to the feature/product you’re building.
3. Use your own intelligence. You’re an engineer, right? That means you have some opinion on the feature you’re building.

Design

The third phase in the SDLC process is Design.

Within Design, the goal is to design how you’re going to build the product. The biggest piece to remember here, aside from the diagraming, architecture, and finishing up what the end result will look like, you want to spend a significant amount of time in this phase thinking about user requirements. What are the users of this product/feature expecting?

In the design phase, you’re going to take the architecture you wrote out and bring it to life. For example, you’ll have to plan out what libraries, frameworks, packages, and dependencies are needed. All of the prerequisites to the actual coding phase, which is coming up next. You can also diagram all of that out to ensure that your way of thinking is logically sound. You’re still in the theory phase here, but by now, you should have a good understanding of what’s necessary.

Development/Coding

The fourth phase in the SDLC process is Dev work (coding).

This phase is straightforward. Write the code, see if it works, get others to look at it (code reviews), and collaborate with other members of the team to get the product engineered.

Work time! Pull up VS Code or whatever IDE you like and get coding. Schedule 1-3 hours for yourself each day when you’re in deep work mode. No email, no Slack, no cell phone, no distractions. Just heavy coding.

Testing

The fifth phase in the SDLC process is Testing.

Testing allows you to understand the quality of your code from a usability, security, and end state perspective. In this phase, you will be building multiple test cases to confirm that the functionality you create works as expected.

The testing phase and coding phase often go together, but they’re separate in theory, so now is the time to get all of your unit tests, mock tests, security tests, integration tests, and performance tests in place. Does it work as expected? Is the outcome what you were thinking? The best thing to do is confirm that you’re seeing what the user is going to see. For example, the problem with a unit test is you’re testing a specific output based on what you plan/assume, but that doesn’t always mean that’s going to be the outcome for the user. A great way to combat this is to have trial users test it out and see for themselves.

Deployment/Implementation

The sixth phase in the SDLC process is Deployment.

This is the phase where what you created is deployed.

Code is written, planning is done, and all of the tests are passing (well, maybe one or two failed… ya know how it is). It’s time to get the feature out into production! A great way to do this is canary deployments. Push the new feature out to 30-40% of your user base and see how everyone responds. If the application stack doesn’t light up on fire and your SREs aren’t calling you asking what you did to break everything, you should be in pretty good shape.

Maintenance

The seventh phase in the SDLC process is Maintenance.

You made it! Your feature is in the wild and everyone is shouting “hurray!” from the rooftops… but what about Day Two Ops? Upgrades, updates, different versions - these are all things that you have to think about. You don’t have to implement them right this second, but there will come a time (probably soon with how fast software moves) that you’ll need to perform these Day Two operations. A great way is to design/architect what Day Two looks like for your app (bringing you have to Phase 1 and Phase 2 of SDLC).