Schedule and Events

March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email:

Tuesday, February 06, 2007

Rethinking Process Improvement - II

This is image 2 from Winston Royce’s Paper – "Managing the Development of Large Software Systems"

Let’s look at each stage for the process – requirements, design, coding, testing … it’s an assembly line. At each step, someone produces a work product which is handed off to the next person in the line. Only the project manager owns the entire process. In fact, some of our very own job descriptions, like developer, or tester, or requirements analyst, assume that our entire role is to perform one box in the sequence.

Later in the paper, Royce went on to write:

"I believe in the concepts, but the implementation described is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, I/o transfers, and so on are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. … Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple … patch or redo of some isolated code will not fix these kinds of difficulties. The require design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violate. Either the requirements must be modified, or a substantial change in the design is required. In effect, the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and costs."

Royce does not use the term "waterfall" in his original paper. His final recommendation involves writing the program twice; admitting that the first iteration will be problematic, accelerating it, and finding the deficiencies in the requirements and then starting over with design. The term probably came out of the arrows, which kind of look like a waterfall.

Yet too many people never got past page one of his paper. After all, this is familiar; it’s applying Fred Taylor to software. And Taylor’s a genius, right?

It turns out that Taylor’s entire body of work is based on experiments with Immigrant day laborers who had to move raw iron from the factory to box cars. The typical object of that work had a third grade education, which was typically in German.

Software development is not turning a wrench – it is intellectual work – knowledge work – that is different every time. When we do heavyweight handoffs, we lose information. We say "We really need to get the requirements right next time."

Now, one definition of insanity is doing the same thing over and over again and expecting a different result. For thirty years, Process Improvement (in capital letters) has been telling us to get the requirements right up front. And we’ve been failing, for thirty years. That is insane.


Ben Simo said...

Now, one definition of insanity is doing the same thing over and over again and expecting a different result.

Process is Improvement. Isn't it? And if we keep implementing new processes (or even the same old processes with new names), isn't that continual process improvement? ;-)

As long as there is money to be made selling tools to support processes and promotions to be had for managers that implement process, the cycle will continue.

Process is scary when it takes on a life of its own.

Ben Simo said...

Software development is not turning a wrench

Software development is also not an assembly line.

I have never understood why software development is ever treated like an assembly line. Software is not repeatedly assembled the same way that we build cars or bricks. Software development is more like the design process for manufactured goods, than the assembly process. I would not want to drive a car developed with a segmented waterfall design process. I want there to be an interactive design and testing process for cars and software.