The misunderstanding of Dr. Royce

It’s the year 1970. Dr. Winston W. Royce, director at Lockheed Software Technology Centre decides to write a paper. The paper, Managing the development of large software systems, will become famous. This paper is the origin, the source, the root, of the waterfall model, although he never used the term. Someone in the American Department of Defence reads the paper, and voila a new standard is born; the DoD STD 2167. Adoption in the development world can be compared with a snow avalanche.

Back to the paper. Have you ever read it, or (even) want to read it? Chances are it’s a boring endless explanation of the greatness of the waterfall. WRONG!

It’s a very readable 11 pages thin paper with 10 figures. Royce starts with the basic blocks of the model; analysis followed by coding. Then he mentions;

A more grandiose approach to software development is illustrated in figure 2. The analysis and coding steps are still in the picture, but are preceded by two levels of requirements analysis, are separated by a program design step, and are followed by a testing step.”

So far so good, this is the waterfall method. But then surprise, the first sentence of page 2 (!), we read;

I believe in this concept, but the implementation described above is risky and invites failure.” Backed up with arguments, he continues with;

In effect the development process has returned to the origin and one can expect up to 100-percent overrun in schedule and/or cost.

What? Pardon? He’s not promoting the waterfall? …….Total silence…….please, open the hyperlink, read his paper.


The right to believe

The Ethics of Belief by William K. Clifford. A story from 1877.

A shipowner was about to send to sea an emigrant-ship. He knew that she was old, and not overwell built at the first; that she had seen many seas and climes, and often had needed repairs. Doubts had been suggested to him that possibly she was not seaworthy. These doubts preyed upon his mind, and made him unhappy; he thought that perhaps he ought to have her thoroughly overhauled and refitted, even though this should put him to great expense. Before the ship sailed, however, he succeeded in overcoming these melancholy reflections. He said to himself that she had gone safely through so many voyages and weathered so many storms that it was idle to suppose she would not come safely home from this trip also.

He would put his trust in Providence, which could hardly fail to protect all these unhappy families that were leaving their fatherland to seek for better times elsewhere. He would dismiss from his mind all ungenerous suspicions about the honesty of builders and contractors. In such ways he acquired a sincere and comfortable conviction that his vessel was thoroughly safe and seaworthy; he watched her departure with a light heart, and benevolent wishes for the success of the exiles in their strange new home that was to be; and he got his insurance-money when she went down in mid-ocean and told no tales. What shall we say of him? Surely this, that he was verily guilty of the death of those men. It is admitted that he did sincerely believe in the soundness of his ship; but the sincerity of his conviction can in no wise help him, because he had no right to believe on such evidence as was before him. He had acquired his belief not by honestly earning it in patient investigation, but by stifling his doubts. And although in the end he may have felt so sure about it that he could not think otherwise, yet inasmuch as he had knowingly and willingly worked himself into that frame of mind, he must be held responsible for it.

Let us alter the case a little, and suppose that the ship was not unsound after all; that she made her voyage safely, and many others after it. Will that diminish the guilt of her owner? Not one jot. When an action is once done, it is right or wrong for ever; no accidental failure of its good or evil fruits can possibly alter that. The man would not have been innocent, he would only have been not found out. The question of right or wrong has to do with the origin of his belief, not the matter of it; not what it was, but how he got it; not whether it turned out to be true or false, but whether he had a right to believe on such evidence as was before him.

Pretty good story!

Let’s fast forward the ethics of belief to your current IT project. Just imagine you are the Shipowner. Your role can be project manager, tester, programmer, or an analist. What evidence supports your project to make a safe voyage?

Simple as ABC……

I like well designed workshops. They give me positive energy. The most interesting part for me is where stakeholders discuss which features are included (and some thereby excluded) in next release. Sometimes you ‘just’ have to (gently) push them to make the prioritization. Easy, done it before.

Easy, that little word got me thinking. Thesaurus of easy; piece of cake, effortless, no problem, no sweat, simple as ABC, straightforward…hmmmmm……

I decided to put myself to the test, a.k.a ‘eat my own dog food‘. I love, and I guess the feeling is mutual. Over the years many books filled my bookcase. The test: I have to choose 3 of my precious books.

The long list;

My first reaction? No, these are ALL good books, all of them are such a good reads, I care about these books. Let’s just change the 3 into a 5, no that would be self-deception. It’s not necessary to lie to myself.

Whatever happens, Becoming a Technical Leader will make the top 3. I love that book, and it’s a signed copy. It must make the top 3. The Mythical Man Month. Does it needs an explanation? It’s Fred Brooks, is it the best software book ever written? Brooks makes it to the top 3. D-E-F-I-N-I-T-E-L-Y.

Lets pick the last book. We have……..Weinberg (2x), DeMarco & Lister (2x), Senge and Humphrey. Simple as ABC, no sweat??? Okay I can survive without Perfect Software, if I must, that book has helped me very well over the last few years. Waltzing with bears, such a great read from DeMarco & Lister (aren’t they all?). So many aha-moments in that little book on risk management. Quality Software Management (QMS) and the Fifth Discipline do cover the same subject (Systems thinking). Senge covers more theory, but QMS is applied to the software business. Both very well written. I choose QMS. Learned a lot from Humprey, it’s a classic. I’m going to regret it leaving these books behind.

What’s left? QMS and Peopleware. Two totally different subjects are covered in those books. That’s why I bought them! O no, my stomach doesn’t feel good, can’t believe it. I have to choose between QMS or Peopleware. Think! 4 hours later on this sunny afternoon.

I choose …..I choose………did I just bite one of my nails off?……… I choose……………..Peopleware. Argh….I left QMS behind, that hurts, feels like I have to make an apologise to Jerry. Let’s roundup.

The short list

  • Becoming a Technical Leader: An Organic Problem-Solving Approach
  • The Mythical Man Month and Other Essays on Software Engineering
  • Peopleware: Productive Projects & Teams 2nd Edition

Thank God it’s just an excersise! Next time I tell the project’s stakeholders I know it’s not easy.

Are you an Aikido expert?

The most common risk strategy appears to be free of cost.

No, not strategies like avoiding, containing or mitigation. I mean evading as a strategy. Evading is easy. Just worry about a risk and don’t do anything about it. That’s it, piece of cake.

You might worry that;

  • your best testers leaving during the project, but they don’t.
  • the hardware will be late but it isn’t.
  • users will not like the performance (or GUI, new features), but they don’t complain.

Lucky you, you have not found out to be wrong.

Applying this strategy doesn’t mean you should face a firing squad. We all apply this strategy once in a while. But evading as your only strategy…hmmm….let’s do some math.

You have a list with 20 risks, each one has a low probability of hitting you, say 5%. The chance that at least one of them will hit you is nearly 65%. That is, one minus the 20th power of 0.95. That’s worth talking about during a project meeting.

As a 7th-dan black belt in Aikido, Steven Seagal is an expert on evading risks. He is……most of us are not.

Hudson Bay start

I like good stories, the Hudson Bay story is one of my favourites. Johanna Rothman tells this story in her excellent book Manage IT.

“The Hudson Bay Start approach was originated by the Hudson Bay Company in the 1600–1700s in north eastern Canada. The Hudson Bay Company outfitted fur traders. To make sure the traders hadn’t forgotten anything they needed, they left Hudson Bay and camped just a few miles away.

By making camp just a few miles away, the traders ensured they hadn’t forgotten any tools or supplies—before they abandoned civilization. With just a short start to their journey, they had a better idea about their ability to endure the winter.

The Hudson Bay start is applicable to our world of software. See it as mini-phase, iteration, or sprint in your project plan. It’s not a waste of time or resources! Just run a “Hello World” program through your whole development process in your organisation. You will learn a lot by doing this exercise.

How would you react to someone who says: Look we have a 12 – 18 months project, don’t expect me to spare a day doing a Hello World exercise. (slap!)

Einstein & Ford

Regardless the outcome of your current project, there is always opportunity to improve. Evaluation time. One of the required deliverables: a list with recommended improvements.

Now what to do? Well, that’s up to you. Just remember Einstein’s and Ford’s lessons.

Einstein gave us his definition of insanity: doing the same thing over and over again and expecting different results. So he teaches us not to do exactly the same if you aim for improvements.

Ford, in the 1950’s, learned a lot, which resulted into a new project: the Edsel. They applied all their improvements in that car. The car is known as one of Ford’s biggest failures. Ford teaches us not to change everything at once.

Enjoy your next project.