The waterfall model of software development was formally described in 1970. It was critiqued decisively by the early 1980s. It was officially succeeded by iterative and incremental methods through the 1990s and rendered obsolete, in many professional contexts, by the Agile Manifesto of 2001.
However, it is still alive and embedded in the structure of the work in many organizations, not as a named process but as an unexamined assumption. Not "we do waterfall" — nobody says that. But: "the feature goes to QA when development is done." "The sprint doesn't end until QA signs off." "We're blocked on QA." "QA found twenty bugs; we can't ship until they're resolved."
A Three-Part Field Manual on What Actually Determines Production Outcome Quality
This is the introduction to a three-part series. It frames the conviction, names the production failure modes that motivated the series, and previews the three parts that defend the argument with engineering specifics.
The Backdrop
After eighteen months of hands-on designing agentic systems in production — multi-agent platforms in regulated industries where context-window collapse means a compliance violation, not a UX bug — I have stopped paying attention to which model the team picked. In production, model choice does not predict success. Three other things do, and the field is underinvesting in all three.
The request-response model that defined back-end engineering for two decades is being stretched into something different. Back-ends still serve requests, but increasingly they also set goals, call tools on their own initiative, and run for a few minutes or hours before returning anything. That changes a lot of what back-end engineers have to think about: orchestration, async pipelines, tool governance, state management, and a different shape of failure.
Here’s what is actually shifting, and what stays the same.
Comments
Post a Comment