Every piece of software goes through the same broad phases — understand the problem, design, build, verify, ship, maintain — but real teams loop through them constantly rather than walking through once. The gap between the textbook diagram and how it actually happens is the useful part.
3 min read
Regardless of what process a team calls its own (Scrum, Kanban, or nothing formal at all — covered from the team-process angle in the Agile & Project Management domain), software moves through the same broad phases:
Textbooks (and this lesson's own numbered list above) present these phases as sequential — but in real software development, you loop through this cycle constantly, often at wildly different scales simultaneously: a whole product might be in its third year of "maintain," while one specific feature inside it is currently at "design," and a bug fix inside that same feature is at "implement," all at the same moment. Waterfall — doing all of phase 1 for the entire project, then all of phase 2, and so on — is the textbook version; almost nothing real works that way end to end, precisely because you learn things in later phases that change your understanding from earlier ones.
For most software that survives past its first release, maintenance — fixing bugs, adapting to changing requirements, handling new edge cases users actually hit — consumes far more total engineering time over the software's life than the original build did. This single fact is the actual justification behind nearly every other lesson in this domain: code that's easy to maintain (readable, tested, its decisions documented) pays that investment back repeatedly over a maintenance phase that usually dwarfs the initial build.
"Understand the problem" sounds like a one-time information-gathering step, but in practice, a meaningful fraction of real requirements only become clear once something concrete exists to react to — a stakeholder seeing an early version and realizing they actually need something slightly different than what they originally described. This is exactly why iterating in small, shippable increments (rather than building the entire imagined final product before anyone sees it) reduces risk: it surfaces the gap between "what was asked for" and "what's actually needed" while there's still time and budget to adjust.
"Verify" includes automated testing (its own deep subject in the Testing & QA domain) but also code review, manual QA, and — often the highest-leverage check of all — simply demoing the feature to someone who represents the actual user, before it ships. A feature can pass every automated test and still solve the wrong problem; only a human check against the original intent catches that specific failure mode.
Every remaining lesson in this domain zooms into one specific phase or the seams between phases: reading and debugging code (deep inside implement/ verify), technical debt and refactoring (the tension between shipping now and maintaining later), code review (the human side of verify), and writing down decisions (documentation that survives the transition from design into maintenance, long after the original reasoning would otherwise be forgotten).
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why does real software development loop through the lifecycle phases instead of proceeding straight through once?
2. Why does the 'maintain' phase typically consume more total time than the initial build, for software that survives past release?
3. Why does the lesson say requirements are often 'discovered,' not just 'gathered'?
Software Engineering Fundamentals