WDIM - SDLC

Introduction

It has been said that all companies are now software companies in the sense that they either make or rely on software. Some of this software is external-facing (revenue or brand-recognition impacting) while others are internal facing (productivity impacting); each having its own complications and benefits. What this tells us is that the way in which software is developed becomes one of the most important processes for every company, considering the direct impact to revenue, brand-recognition, and productivity.

History of SDLC

SDLC (Software Development Life Cycle) is the umbrella term to define how any group works through the process of gathering requirements, designing software, implementing the software, testing the software, planning how it will integrate with other systems, how will a user or company install and use the software, and how the software will be maintained or improved upon. The chosen SDLC methodology is a direct representation of how the company or group communicates at a business level (known as Conway's law). If a company or group typically communicates from a top-down trickle approach, then their software development style will follow that same process. Additionally, if each business unit or group requires formal meetings or documented processes with oversight in order to interact with each other, then the software that is developed will naturally follow that same flow within its own components.

Types of SDLC

Different major styles (and multiple minor styles and branches of those major styles) have been used and adopted over the course of software development. Initially this started with a process called "Waterfall" which mimicked the business models of the day (and unfortunately is still used in today's development world). Waterfall is the process of walking through the steps mentioned above (requirements analysis, software design, etc.) in a linear and sequential order, where the completion of one step leads to the next without overlap. As you can imagine, this process is prone to errors, time loss, budget issues, and scope creep, simply because there is no re-evaluation throughout the steps since there is no testing or user integration attempts until later in the process (which leads to starting the whole waterfall over again, or sometimes scraping the project entirely). This lead to a slew of other styles of SDLC to mitigate the issues of Waterfall, including spiral development, offshore development, and agile development (with the last one being the current main-stream SDLC methodology). Most styles attempted to mitigate the lack of testing and user integration by imposing incremental testing throughout the different phases, or prototyping the solution early on and seeing what users thought, and even sending the project to offshore companies to reduce the cost without thought to how the offshore company might develop the product.

Agile and DevOps

The current main SDLC methodology is Agile, which focuses more on people, mvp (minimally viable product), collaboration with people, and consistent checking requirements and potential change and adapting to that change or requirement (Check out the agile manifesto here). This is all done in as short of time as possible (usually referred to as a sprint) which contains three important concepts, also referred to as "The Three Ways" in DevOps. By continuously developing and delivering the software (known as CI/CD or continuous integration and continuous delivery) with routine checks and testing, the development team will "shift right" the solution or build as quickly and succinctly as possible without including any defects or bugs through sufficient testing.

Once the build or solution is done and shifted to the right, the next team (sometimes the QA team) will try different testing processes or scripts and then "shift left" the response or result as quickly as possible for the previous team to improve and/or fix the next solution/build. As all of this shifting happens, all of the teams in the process should also work to improve their own process with new styles, tools, or practices to make as much of their processes as automated and faultless as possible.

Why does it matter?

When developing software for either internal or external users, the main point should be to focus on those end-users through continually involving them in the process of creating their perfect tool or solution. Additionally, only when the group or business that develops the software continues to improve the software and the process of developing the software will that software see successful adoption AND longevity in that market. What we are seeing in today's world are software solutions that started as quick and agile solutions and slowly became so massive that they can no longer be quick or agile. This results in "market disruption" through other solutions that are quick and agile and can adapt to the changing needs of their users. If you are in the business of building software or involved with a company that builds software always be wary of the methodology in which the software is developed and how quick and agile the software development is. If you find that the software is no longer quick or agile, it is either time to fix that process or question whether that solution has long to live.