What Is ‘SDLC’
SDLC is an acronym that means either Software Delivery Life Cycle or Systems Development Life Cycle.
And it is a lie. A fiction. A total fabrication. Somebody made it up out of thin air many years ago and the idea was cemented deep into corporate bureaucracy.
If you don’t read past this section, I want you to at least understand these points:
- If you work with Digital Product Development, you’re likely to encounter this concept.
- Even while the concept is deeply flawed, it’s important you understand that people use the model in an attempt to solve real business challenges — specifically financial governance and resource planning.
- And please don’t believe for even a single minute that this is how products get made.
A Little History
Imagine creating a software program on a punch card when a computer was the size of a bank vault. And, imagine how difficult and expensive it was to change that software or hardware late in development. (Hint: very expensive.) Given that the cost of change was high, significant effort would be made with hopes that early decisions about system design and architecture would not have to be revisited. A linear/sequential notion of SDLC was born…
- Plan ➡️ More planning ➡️ More analysis ➡️ More design ➡️ Then execute the plan and hope for the best!
This simplistic concept of a prescriptive and linear SDLC was famously described in an essay published by IEEE in 1970 called Managing the Development of Large Software Systems, by Dr. Winston Royce. Interestingly, Royce warned in the first paragraphs of his essay that employing the model too strictly was (and I quote) “doomed to failure”. And the remaining pages of his essay offered numerous strategies to employ, instead, a more iterative and incremental approach.
As the cost of change, even late in development, has exponentially decreased over time, one has to wonder why this outdated SDLC concept remains so pervasive.
Why Is the SDLC Concept So Pervasive?
Well, despite their flaws, SDLC models actually solve important problems. Two are outlined below:
In Publicly traded companies, for example, it is important that fiscal accountability can be demonstrated to shareholders.
When money is spent, a manager somewhere must be able to show a direct line from a deliverable to the money that paid for it. SDLC models provide a crude and inaccurate, but nonetheless acceptable, way to meet this requirement.
“Look”, they might say, “as the project was in the Planning phase, a budget of $x,000 was approved for Team A to produce an Architectural Requirements Document. See here, the document was delivered on time and on budget.”
Whether value was produced is questionable, but show me an auditor that will question such digilent book-keeping!
In companies that organize staff into Shared Services departments (e.g., Design, Architects, Dev, QA, Infrastructure, etc.) it becomes necessary to schedule the personnel when it’s *their turn*.
When people believe Products are best developed in a linear sequence, they will take great pains to estimate when each skillset is needed and for how long.
“We’ll start with the architecture and UI design”, they might say, “then we’ll need the developers, then the testers, then the release managers, and then the project will be handed off to the Ops team to be supported after the launch.”
SDLC models provide that sense of predictability and sequencing. The phases of the SDLC can be plotted on a calendar and managers can envision the work being passed from one department to the next.
Both those problems can be addressed in other ways — which explains why many enterprises are providing staff with training in Iterative & Incremental ways of working, such as Scrum, Kanban, Lean Startup, Design Thinking, TDD. But for many organizations, the SDLC habit remains.
Having participated and listened to endless debates on the subject, I offer the following explanation why the SDLC concept just won’t die:
“There is always a well-known solution to every human problem — neat, plausible, and wrong.” — H. L. Mencken, 1920, Prejudices: Second Series.
It turns out the human brain is prone to Substitution Bias. The phenomenon was described by Nobel Prize winner Daniel Kahneman in his book, Thinking, Fast and Slow. He explained that we are prone to substituting a simpler question for a difficult one. Like this:
- Given the complexity of Digital Product Development and an outsized probability of failure,
- a person, when asked to describe how to mitigate risk and assure high return on investment,
- cannot answer the given question simply,
- so instead responds with an answer to an easier question that was not asked. Like, “What are the steps described on page 1 of Winston Royce’s essay?”
But how could the world’s entire population of smart Product Managers and Computer Scientists be so prone to this phenomenon? The answer is depressingly straight-forward.
First, let’s be reminded of one of John Gall’s truisms:
“PEOPLE IN SYSTEMS DO NOT DO WHAT THE SYSTEM SAYS THEY ARE DOING.” — John Gall, The Systems Bible
That is, despite the most eye-catching SDLC diagrams and the countless textbooks on the subject, the people involved are not doing what the SDLC model says they are doing. And everyone knows! It’s a big lie we tell ourselves, but we produce marketable product with just enough frequency that everyone is willing to maintain the illusion.
And, unfortunately for us mere humans, the illusion is reinforced by what psychologists refer to as Hindsight Bias, specifically a concept called ‘creeping determinism’ — the tendency for us to remember past events as having been more deterministic than they actually were.
Kent Beck’s video, The Return of the Waterfall, illustrates perfectly how Hindsight Bias reinforces the SDLC illusion in Digital Product Development.
How Is the SDLC Model Wrong?
As we saw in Kent Beck’s video above, there is just enough truth in the SDLC model that the illusion is strong. But I’ll point out the following flaws to help us all disengage from the fallacy:
It (the generic SDLC model) implies a known end state.
The phases/stages described by SDLC models can easily give the impression that all the work of one phase can and should be complete before moving on to subsequent phases. The question that begs an answer is: how can a plan be complete before development begins? As certain as the sky is blue, we uncover information during development that makes earlier plans obsolete.
For this reason, Iterative & Incremental patterns like Scrum enable us to feed information from past work to future plans (e.g., information from a Sprint Review often leads to changes in the Product Backlog and informs future designs.) We can (and must) change course as new information is uncovered.
It presumes there’s a fixed, linear sequence of activity through which the work proceeds.
Product Development is not like manufacturing; it’s not like an assembly line or recipe. Rather, it’s a creative process that requires iteration. And it’s a risky process that requires incrementalism — small, reversible steps.
The truth about Digital Product Development is that the essential activities may occur in any order. An automated test can be written before the feature being tested; an end user can be presented with a paper prototype before requirements are documented; marketing material can be written and published before business requirements are confirmed, and so on.
It is blind to batch size.
Having had countless talks with steering committees, budget officers, auditors, I say with zero doubt the prevailing mindset reinforced by SDLC models is: the larger the scope, the more important the SDLC phases be rigorously enforced.
For example, companies often enforce a sequential SDLC pattern through their budgeting habits and reporting structures. We often see these incredibly risky behaviours:
- A company might plan for and fund the development of product for many months before testing any part of it in the marketplace. SDLC modelling evokes a false sense of confidence. Decisions made early and fueled primarily by conjecture are trusted more than emergent information. If we just follow the SDLC with more rigor, we’re bound to achieve success, right?
- SDLC models distinguish clearly between phases such as ‘in development’ and ‘operationalized’ and give the impression that unique skillsets are required in each phase, companies often impose risky hand-offs between development staff and support personnel. Often, these are distinct departments each with their own management structures. Such hand-offs make sense only to budget managers and from a particular fiscal perspective, one in which development is thought to be Capital Expenditure (CapEx) and support/maintenance is thought to be Operational Expenditure (OpEx).
Yet, the exact opposite is true: among the best risk mitigation strategies ever conceived in the realm of Digital Product Development is the practice of delivering small batches frequently.
So many SDLC models!!
The SDLC concept breaks easily under scrutiny, but rather than abandon the illusion entirely, people tend to hallucinate new derivations. There are as many SDLC models as there are buzzwords — take TutorialsPoint.com for example (see image), behold an ever-expanding list. Fun thought experiments, perhaps, but each more absurd than the next.
In closing: Here’s a Better SDLC Model
At risk of publishing yet another SDLC derivative the world doesn’t need, I feel urged to suggest a model of my own.
¯\(ツ)/¯
And to close the loop on my earlier point: if you work with Digital Product Development, you’re likely to encounter this concept. I’d like to offer, therefore, a sensible way to map reality upon the endless variety of SDLC models you will experience.
Stage 1: Started, but not a single line of code has yet been written.
Keep this stage brief. All plans are just conjecture. Keep ideas lightweight and disposable. Fund only enough work to test the viability of the product vision / market opportunity.
Stage 2: Some code is written, but nothing is yet in the hands of end users.
Keep this stage brief. Fund a few months at most. Use this time to test initial assumptions about architecture, design, feature set, user needs. Build, measure, learn. Press toward early release of a minimal feature set.
Stage 3: We’ve delivered something to end users and we’ll continue development.
Focus. Deliver. We’ve validated/pivoted our early assumptions and are getting real feedback from end users and customers. This is the bulk of the work and can carry on indefinitely — work toward being self-funded and sustainable. Use inexpensive experiments wherever possible to reveal the information necessary to grow. Use more intensive experiments when necessary to really optimize and fine-tune the product:market fit.
Stage 4: Stuff is in market but we’ve decided not to continue development.
As gracefully as necessary, decommission the Product and help users migrate to a better alternative.
Please discuss!
***
This article is also published at scrum.works.
Closing
What’s your take on this? Is your experience similar to mine?
If you’re interested in learning more from me, visit my site and contact me to explore the opportunities for your organization.
Join me for a Scrum.org course: scrum.works/classes
And consider adding my recent book to your library: davidsabine.ca/phoenix