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 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 and recall 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) of which Royce has very fond of but then he was also dealing with spaceflight and probably peoples' 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 over 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 in nature, new features being added with 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 get to see resumes with "skills: waterfall, agile, ..." etc but I do wonder if waterfall is an actual real-life process or if it is just used as a placeholder for when the SDLC is heavy-process, not-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 is 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.