Why a Lifecycle: From Idea to Retirement

Nobody builds a real piece of software in one sitting, idea straight to finished. The work moves through stages — figuring out what's needed, designing it, building it, checking it, shipping it, running it — and then it keeps going, changing and being fixed for as long as people use it.

That whole arc, from the first spark of an idea to the day the software is finally switched off, has a name: the software development life cycle, or SDLC. It's the single most useful map in this course, because every chapter ahead is one stretch of it.

Compare it to a building. There's a design phase, a construction phase, then years of people living and working in it — repairs, renovations, upgrades — and eventually it's torn down. The construction grabs the attention, but it's a small slice of the building's actual life. Software is the same.

Why Stages at All?

Building software is, at the start, a huge pile of unknowns. Breaking it into stages turns one overwhelming question — "how do we build this?" — into a sequence of smaller, answerable ones: what exactly is needed, how should it be shaped, what do we write first, does it work, is it ready to ship. Each stage has a clear job, so the team always knows what it's trying to answer right now.

The Arc Is Long

Here's the part newcomers find most surprising: launch is closer to the middle of the story than the end. Once software is live, it has to be kept running, watched for problems, fixed, and changed as needs shift. For most successful software, the years after launch dwarf the months spent building the first version.

This is why "we shipped it, we're done" is a beginner's view. Shipping is a milestone, not a finish line. A product that people depend on is never really finished — it's maintained, which is itself a phase of the lifecycle and a whole chapter later in this course.

Repeatable, Not One-Off

The lifecycle isn't just the shape of the whole product, built once. It repeats at every scale. Adding a single new feature runs through the same stages in miniature: someone decides it's needed, it gets designed, written, tested, and shipped. A team might run the full cycle for the product once and then run smaller versions of it dozens of times a year for each new feature. The pattern is the same; only the size changes.

A Lifecycle Isn't a Method

One thing to clear up now, because it trips people up: the SDLC is the set of stages, not a particular way of working. Whether a team does the stages strictly one after another or loops through them in fast little cycles is a separate choice — that's a "methodology", the subject of the next chapter. The phases are the what; the methodology is the how. Keep them apart and both get clearer.

For the Cadence team, this is exactly where they are. The app didn't appear finished — it moved from Priya's idea, through planning, building, and shipping, to today, where it sits in the "operate and maintain" stretch. That's where Cadence will spend most of its life, and where most of the team's day-to-day work now happens.