Posts Tagged ‘Winston Royce’

Not That Different, No?

March 7, 2014 4 comments

Check out this slide I plucked from a pitch that will remain unnamed:

Agile Vs WF

Notice the note under the waterfall diagram. Now, let’s look at the original, “unadapted” version and accompanying quote from Winston W. Royce’s classic 1970 paper:

Seq WF

Notice that Mr. Royce clearly noted in his paper that the sequential, never-look-back, waterfall process is a stone cold loser. Next, let’s look at another diagram from Mr. Royce’s paper; one that no fragilista ever mentions or shows:

Iterative WF

OMG! An iterative waterfall with feedback loops? WTF!

Finally, let’s look at BD00’s syntegrated version of the agile, lower half of our consultant’s diagram and the iterative waterfall diagram from Mr. Royce’s paper:

Agile WF

Comparing the agile and “chunked“, iterative, waterfall models shows that, taken in the right context, they’re not that different…. no?

Doc Maturity?

In his classic and highly referenced but much vilified paper, “Managing The Development Of Large Software Systems“,  Winston Royce says:

Occasionally I am called upon to review the progress of other software design efforts. My first step is to investigate the state of the documentation. If the documentation is in serious default my first recommendation is simple. Replace project management. (D’oh!)

Before going further, let me establish the “context” of the commentary that follows so that I can make a feeble attempt to divert attacks from any extremist agilistas who may be reading this post.  Like Mr. Royce,  I will be talking about computationally-intensive software intended for use in these and other closely related types of application domains:

spacecraft mission planning, commanding, and post-flight analysis

Ok, are we set to move on with his shared contextual understanding? Well then, let’s go!

The figure below shows what should happen on a well run, large, defense/aerospace industry system development project. As the recorded info artifact set matures (see the post-post note below), productivity increases and the need for face-to-face communication decreases (but never goes to zero ala the “over-the-wall” syndrome).

Using this graph as a reference point, here’s what often happens, no?

On big, complex projects, mature but incomplete/inconsistent/ambiguous documentation tends to cause an unmanageable increase in face-to-face communication frequency (and decrease in face-to-face communication quality) as schedule-pressured people frantically try to figure out what needs to be built and what elements they’re personally responsible for creating, building, and integrating into the beast. Since more and more time is spent communicating inefficiently, less time is available for productive work. In the worst case, productivity plummets to zero and all subsequent investment dollars go down the rat hole…. until the project “leaders” figure out how to terminate the mess without losing face.

Note: Since “maturity” normally implies “high quality”, and that’s not what I’m trying to convey on the x axis, I tried to concoct a more meaningful x axis label. “Documentation Quantity” came to mind, but that doesn’t fit the bill either because it would imply that quantity == quality in the first reference graph. Got any suggestions for improvement?

Snap Judgments And Ineffective Decisions

In the software industry, virtually all people agree that Winston Royce‘s classic paper titled “Managing The Development Of Large Software Systems” was the first widely publicized work to describe the linear, sequential, “waterfall” method of building big systems. He didn’t coin the term “waterfall“, he called it a “grandiose process“.

Here’s one of the pics from Mr. Royce’s paper (note that he shows stage N to stage N-1 feedback loops in the diagram and note the “hopefully” word in the figure’s title):

What seems strange to me is that most professional’s that I’ve conversed with think that Mr. Royce was an advocate of this “grandiose process“. However, if you read his 11 page paper, he wasn’t:

The problem is…. The testing phase which occurs at the end of the (waterfall) development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. They are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. – W. W. Royce

This lack of due diligence to dig deeper into Mr. Royce’s stance reminds me of bad managers who make snap judgments and ineffective decisions. They do this because, in hierarchical command & control CLORG cultures, they’re “supposed to look like” they know and understand what’s going on at all times. After all, the unquestioned assumption in hierarchies is that the best and brightest bubble up to the top. But, as Rudy sez…..

“You have to know a lot to be of help. It’s slow and tedious. You don’t have to know much to cause harm. It’s fast and instinctive.” – Rudolph Starkermann

Of course, all human beings suffer from the same “snap judgments and ineffective decisions” malady to some extent, but the guild of management-by-hierarchy, fueled by its ADHD obsession to jam fit as much attention/planning/work into as little time as possible, seems to have taken it to an extreme.

%d bloggers like this: