George Allen Miller One Geek's take on all things SciFi

I am employed as a Software Engineer. Recently I attended a two day SCRUM training session. For those that do not know, SCRUM is an AGILE software development methodology. It was developed out of a need from the failures of the traditional methodology commonly referred to as the water fall methodology. How the waterfall methodology came to be used as the central software development method used by most companies is simply astounding. I have to post this story with the hopes that everyone sees it, reads it, exonerates poor Dr. Royce and perhaps even learns to read between the graphs.

In the 1970′s, the DOD was being faced with projects that included software development. The time spent for software development projects were represented on Gantt charts as a large block of time. The DOD required more insight into this time and what they were spending money on. They decided to research methods to handle software development.

A member of this team went to the IEEE, Institute of Electrical and Electronics Engineers, to look for articles on the subject. What did he find? An article by the name of “Managing the Development of Large Software Systems: Concepts and Techniques”. GREAT! This person thought, I’m sure. Here is an article talking about what I need. OK, let me see about this author. Wow, he’s a PHD. Perfect. Now, let me read it.

Do you think he actually read it? If your answer was no, then you’d be correct. What he did do was flip to the first graph. Guess what it was. A graph representing the water fall technique. The title of the graph was “Implementation steps to develop a large computer program for delivery to a customer”. Jackpot. Now, the DOD has an article, written by a PHD, giving details of how to behave in the realm of software development. The DOD established the Military Standard 2167 which required all vendors to develop software using this article by Dr. Winston Royce as the template. Basically, the DOD said, if you do not follow this standard, with documentation, we will not pay you. So, all the vendors that supported the DOD had to accept this new way of development software. NATO was soon looking for a way to work with software and found the DOD had just done a big research project and settled on the advice of a PHD on the subject. Soon, the software industry also followed suit and before you knew it, everyone was working with this new method, called the Water Fall method.

Well, guess what. Dr. Royce was writing about how NOT, I repeat NOT, to develop software. On the next page of this article, Dr. Royce goes into detail about why the ‘waterfall’ method does not work. Dr. Royce did not coin the term waterfall by the way, it was made later due to how the descending pattern of boxes and arrows looks. The next few graphs on this article show exactly why this method is a failure. Namely, when developing, the waterfall method has the testing and documentation at the end of the project. It assumes that all the preceding stages were accurate.  Also, in any project, things take longer than was anticipated. What happens? Things get pushed out, and those things at the end of the project are done quickly or dropped. What’s at the end of the project? Testing and documentation. What do you do? Test less, document less.

For the next several decades the DOD recorded 60-90% failure rates on their projects that dealtwith software development. Eventually, in 1996 I believe, they rescinded the Military Standard 2167. The software community as a whole is still largely using this method. New methods are being developed, they fall under the AGILE development umbrella. One of the most notable styles is SCRUM.

For the rest of his life, Dr. Royce fought to clear his name. Every speaking event he stated that he was mis-quoted, which he was, and mis-represented. He would go to his grave fighting the waterfall method and that he was never supporting it and attempting to argue for it’s demise.

In defense of the lonely researcher that found the article. It was edited very poorly. The title indicated it as a study on how to manage software development. The title of the first graph suggested the author was supporting this method.

All in all, the moral of this story is, read your articles, cites your sources correctly. Small mistakes can have long felt problems. Also, when you write a story, be very clear on your point. Leave no ambiguity in your title or graphs. It can and will be taken out of context.

Read DR. Royce’s article here: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
Read about AGILE here: http://www.agilealliance.org/
Read about SCRUM here: http://www.scrumalliance.org/
Read about the military standard 2167 here: http://www.barringer1.com/mil_files/DOD-2167.pdf