I'm going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on-time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.
- Winston W. Royce (Managing the development of large software systems)
The above quote is the start of the paper that to those of us who were taught any form of IT at university in the 80's and early 90's (and perhaps later) has become synonymous with the software development life cycle (SDLC) model known as "Waterfall"; whether this association is correct or not I'll leave to the historians, or in this case Wikipedia. It does seem to me, though, that anyone who has actually read the paper past page 2 would never make the assertion that a waterfall-like model was something Royce was recommending and that what he was describing was actually something rather more familiar to what we try to do today.
Page 2 of the paper shows the classic waterfall model (or something very similar, because Royce never used the term "waterfall" himself) that I recall having to memorise for an exam.
Waterfall SDLC
By the next few pages, the model has gone iterative, and by the time you reach the last page, you have the following, which I am going to call Royce's SDLC.
Royce's SDLC
Now, if you are one to read the words and not just look at the pretty pictures, you will see references to "Prototyping", "Testing" and "Involving the Customer" which I personally don't recall being mentioned during the course and to the current me it also feels a little "agile-y". There is also a long section on documentation (Step 2), which Royce was very fond of, but then he was also dealing with spaceflight and probably people's lives. It is interesting to read that even 40 years ago, developers and documentation didn't seem to mix well, actually I think it is people and documentation don't mix and something that we thankfully do less of nowadays and have instead replaced it with living documentation such as wikis and backlogs.
Has anyone actually worked on a waterfall project?
I also had the chance recently to reflect on my resume, something that was long overdue, and that brought back a lot of memories about the projects I worked on, what practices we used then, and whether I would call those projects waterfall or something else. My first software development roles were at firms where hardware was part of the product, and those engineers I worked with definitely iterated over their designs, so it felt right to me that we did the same with software. All the big projects were somewhat iterative, with new features added through regular releases. The first time I recall seeing a "big" specification was when I was on a UK government project in 2003-2005 (EU emissions trading, Kyoto protocol), but even then, the development team was trying to use agile processes under the hood; not perfectly, admittedly, we were just learning to do the agile-walk.
Some people claim to have done waterfall, as I often see resumes with "skills: waterfall, agile, ..." etc., but I do wonder whether waterfall is a real-life process or just used as a placeholder for when the SDLC is heavy-process rather than agile. I say a placeholder, but I sometimes wonder if it is a straw man or even a bogeyman, as it gives a target for those who dislike the not-agile world. I don't believe I have ever worked on a waterfall project myself, well, not one that followed the flow that we would typically attribute to waterfall. I have, however, been on many-a-project whose process flow would look somewhat like the iterative cascade of Figure 10. I am still surprised that the waterfall model even came into being. It just feels unnatural and not how I, as a mostly self-taught developer, have ever thought would be a good idea. The cynic in me, though, feels it is an ideal process for the sort of company where change control and charging for changes is a big part of their operating/revenue model; it could be, though, that the charging model I am critical of was because of the single direction of the waterfall model and that backing up a step was so expensive.
As always, your feedback is appreciated.