SDLC Models, and Meet Cadence

The eight phases are always the same ingredients. What changes from team to team is how they're arranged — and that arrangement is called an SDLC model. The big split is simple: do the phases once, in a straight line, or loop through them in small, repeating cycles?

That choice matters more than it sounds, because it changes when you find out you got something wrong — and, after the last topic, you know that timing is everything. This topic introduces the split at a high level; the next chapter unpacks the real-world methods built on it. Then we'll properly meet the team we follow all book.

An everyday parallel: you can write a book by drafting the whole thing and only then showing anyone (one straight pass), or chapter by chapter with feedback after each (small loops). Same book, very different experience of finding out what's not working.

Sequential vs Iterative

A sequential model does the phases in order, each finished before the next begins: all the requirements, then all the design, then all the build, and so on. It's clear and easy to plan — and it means you don't truly test your assumptions until near the end.

An iterative model loops through the phases in small slices, delivering a little working software each time and learning from it before the next loop. It's messier to plan but catches mistakes early, loop by loop. Most modern teams lean iterative, for exactly the cost-of-change reason from the last topic.

	Sequential	Iterative
Shape	One straight pass through the phases	Many small loops through the phases
You learn you're wrong…	Near the end	Every loop, early
Easy to plan?	Yes	Less so
Handles change?	Poorly	Well

Why the Model Matters

The model isn't just a manager's concern — it shapes a developer's daily life. In a sequential model you might spend months building before anyone uses what you made. In an iterative one you ship something small every couple of weeks and adjust constantly. Same phases, completely different rhythm of work, feedback, and risk. The next chapter is devoted to the specific methods — Waterfall, Scrum, Kanban — that put these models into practice.

Meet the Cadence Team

Now the team you'll follow for the rest of the book. They're building Cadence, a habit-tracking app: you create a habit, check it off each day, and watch your streak grow. Small, friendly, and concrete — the perfect size to see every practice play out on real people.

Who	Role	Owns
Priya	Product owner	What Cadence should do, and why
Marcus	Developer (backend-leaning)	The behind-the-scenes code and data
Lena	Developer (frontend-leaning)	The screens users tap
Nora	QA engineer	That it works before users see it
Theo	Designer	How it looks and feels

How We'll Use Them

From here on, almost every topic ends with a short Cadence beat — the practice it just taught, happening to this same team on this one app: the four who build it day to day — Priya, Marcus, Lena, and Nora — plus Theo on design. Priya writes a user story; Lena opens a pull request; Marcus reviews it; Nora writes the tests. Because it's always the same team and the same product, the examples stack up into one continuous story instead of resetting each chapter.

And the team works iteratively. They build Cadence in small slices — first "create a habit", then "check it off", then "see a streak" — getting it in front of a few real users after each, and adjusting before the next. You'll see why that rhythm beats one big push as the course goes on.