Boehm’s Spiral Revisited

Comments (1)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Twenty years ago this month, in response to the problems associated with waterfall-style approaches to software projects,

Barry Boehm proposed his Spiral Model of Software Development.

Which bore some resemblance to Deming’s “Plan, Do, Check, Act” cycle.

Boehm’s insights have had a huge positive impact on how we think about software development. But the spiral itself lost some of the beauty of Deming’s model: the simplicity, self-similarity at different scales, and the balance between activities in the quadrants. Which, perhaps, has caused Boehm’s model to be underused as a tool for introducing people to how creative engineering works. This is unfortunate, because the waterfall model, being more obvious, continues to be where most people start. Only then, after they have personally experienced the pain of struggling projects, do they search for a more appropriate model.

The Simple Sprial

Here is a simple love-child between Boehm’s and Deming’s views which has been very helpful to me in keeping a visual model in mind when thinking about how effective software development (or any creative engineering) really works.

Customer Plan
Test Design

How does this work?

  • The more iterative your development process, the more times you spiral around
  • You spiral inward from the high-level descriptions down to the lower level implementation details (note: this directionality is inverted from Boehm – this model doesn’t try to convey the amount of cost or work in each loop around the spiral)
  • As you spiral down, the activities change. “Design” at the high level might be on paper. But as you spiral down, design is about turning those paper documents into executable code. Same for the other quadrants.

Quadrants

  • Customer. What does the customer think? In one of the better trends of the last 20 years since Boehm’s paper, agile methodologies have recognized the customer as an essential direct participant of the development process. We can try to guess what the customer ultimately will find valuable. But if we don’t regularly check back with them, we’ll get enough wrong to sink our product and company over time.
  • Plan. What do we plan to do? This includes requirements analysis, priorities, risks, and schedules. At the very high level, it may be corporate goals. At the very low level, it might be writing an automated functional test before writing the code to make that test pass.
  • Design. How will we do it? At the high level, design is done via documents, diagrams, and discussion. At the lowest level, design is expressed as the executable code that constitutes the product.
  • Test. Have we done it right? At the high level, we discuss and review ideas and documents. At the lowest level, we execute tests against the functioning product.

The four quadrants align with how we tend to specialize our people and organizations as we grow. In a Microsoft organizational model, it aligns with customer, program management, development, and test.

The “Simplistic Spiral”

The simple spiral is useful, because it is flexible enough to encompass many approaches to development. Take the waterfall model from the top of this post, and wrap it into one loop through the spiral, and you get “the simplistic spiral.”

Customer Plan
Test Design

Wouldn’t it be nice if projects could reliably just work this way?

But we know if we apply this model to a large product, we’re nearly certain to have a disaster on our hands where many assumptions made in planning are discovered to be poor in design or test.

But apply it to a queue of appropriately-sized (small) and well-understood functional requests, and it may be an appropriate model for each kanban in a lean production workflow (or perhaps each kanban should be two or more loops round the spiral). In any case, the model is helpful in visualizing all these cases.

The “Product Spiral”

It also helps us create useful visualization of product lifecycle models at various scales.

Company
Product
Project
Feature
Change

At the company level, we are constantly cycling: seeing what the customer/market reaction is to our products, planning new products and enhancements, designing and testing them.

At the product level, it’s the same, but from the perspective of the evolution over a lifecycle. But even when a product enters later lifecycle phases like maintainence, the model is still the same: the customer finds bugs, we prioritize, fix, and test them — and it goes back to the customer for the cycle to start again.

At the feature level, we recognize that this has a lifecycle of its own. Before committing a feature to a product, all aspects (including feedback from the customer) should be covered, likely with several iterations. Perhaps one of the secrets of success to many open source ecosystems is that they encourage/allow individual features to evolve independently and iteratively, before committing to integrate them.

At the change level, we have gotten the granularity small enough that each change may appear to be its own mini-waterfall of plan, design, and test. But even that is a simplification — chances are, the person making the change looped through many interrelated planning, design, and test alternatives in their head before committing the change.

Applications

In future posts, we’ll apply this model to take a look at other aspects of the engineering process.

So — is this a useful model for thinking about engineering, particularly software? Or is this model dangerously simplistic for helping to think about how your organization works?