The Bluffer’s Guide to Managing The Development of Large Software Systems

In today’s super-compact summary of a seminal work in software development, we’re going to open the can of worms that is Winston Royce’s 1970 paper Managing The Development of Large Software Systems.

Royce’s paper is often credited with introducing the Waterfall model of software development. Royce outlines a sequential design process with distinct phases such as requirements, design, implementation, verification, and maintenance. He emphasizes the importance of thorough documentation, rigorous step-by-step development, and early stage planning.

However, Royce also identifies the obvious shortcomings of this model, particularly its inflexibility and the difficulty of accommodating changes after the process begins. The paper has had a significant impact on software development methodologies, shaping how large-scale projects are approached.

It is often misinterpreted as an endorsement of the Waterfall model. In reality, Royce did not advocate for the Waterfall model in its strict, linear form. While he presented what later became known as the Waterfall model (he never named it as such in his paper, but others used “Waterfall” to describe this linear model later – it’s kind of like “flying saucers” in that respect), he actually highlighted its limitations and risks, particularly the challenge of accommodating changes once the project is underway.

Royce’s key argument was for the incorporation of iterative elements, such as feedback loops and overlapping development phases, to address these shortcomings. He emphasized the need for more flexibility and adaptability in the software development process. Thus, his paper, often cited as the origin of the Waterfall model, was more a critique and a call for a more iterative approach than an endorsement of the rigid, linear process that the Waterfall model is known for.

In the decades that followed, many managers continued to misinterpret the intention of the paper, forcing teams to attempt the impossible – i.e., get it right first time. And in this sense, Royce’s paper has unintentionally caused considerable misery for countless thousands of development teams. Those managers, of course, probably never actually read the paper. Hence my parallel with “flying saucers” (the private pilot whose sighting in 1947 of unidentified aircraft moving at supersonic speeds never said they looked like saucers. But after news outlets reported them as “flying saucers”, suddenly everybody was reporting saucer-shaped craft.)

There are still many, many teams out there looking for “flying saucers” when in reality no such thing likely exists. In practice, we never get it right first time – we always have to iterate. The main difference being that teams who claim to be following a Waterfall process have a first iteration that’s reeeeaaally long, and then in the run-up to a release (the “testing phase”), they start iterating rapidly to “get the ball in the hole”. In reality, there’s no such thing as “Waterfall” software development.

Key Points

1. Sequential Phases: Royce described a sequential approach to software development with distinct phases: requirements specification, design, coding, testing, and operations.
2. Documentation Importance: He emphasized the importance of documentation at each phase for effective communication and coordination.
3. Early Stage Planning: Detailed planning in the early stages of the project was highlighted as crucial for success.
4. Testing and Debugging: The paper stressed the importance of thorough testing and debugging in the later stages of development.
5. Client Involvement: Royce advocated for involving the client at early stages and maintaining constant communication.
6. Model Limitations: He identified limitations of the sequential model, particularly its inflexibility and the difficulty in accommodating changes.
7. Iterative Elements: Royce recommended iterative elements, like overlapping development phases and prototyping, to address these limitations.
8. Risk of Sequential Approach: The paper pointed out the risks associated with a purely sequential approach, especially for large, complex projects.
9. Critique of Linear Models: Royce’s critique of linear, non-iterative models underlined the need for more adaptable and flexible methodologies in software development.

While Royce does indeed advocate for a more iterative approach to development, it’s doubtful he ever envisaged the level of iteration that’s been favoured since (he talks in the paper about “doing it twice” – yeah, and then do it some more!). And he still places great emphasis on the importance of planning and documentation: two activities we now know have limited value compared to feedback and active collaboration.

But for those who actually read the paper, there’s no denying it would have been a light bulb moment back then. Its influence in later thinking about the software development life cycle (e.g., Barry Boehm’s Spiral Model, proposed in 1986) is apparent. At the very least, “Managing The Development of Large Software Systems” started a conversation that’s still going on today.