Home | Login | Recent Changes | Search | All Pages | Help

WaterfallDejaVu

Waterfall Deja Vu

In earlier threads, we discussed the Waterfall model of software development: WaterfallIsSilly and WaterfallFolklore. A week ago I attended a Boston SPIN presentation on the origins of the SCRUM methodology presented by Jeff Sutherland. He quoted Paul Bassett: "Why are systems late, over budget, wrong? The Waterfall Methodology!" Sutherland and Bassett appear to belong to the camp that believe Waterfall is, not just silly, but the cause of the "Software Crisis". Sutherland distributed an IEEE article -- Craig Larman & Victor Basili, "Iterative and Incremental Development: A Brief History", Computer, June 2003, pp 47-56. The article quotes Jerry on the Mercury Project as saying "... waterfalling a huge project was rather stupid ...". That jarred as I remembered Jerry saying things somewhat differently. I later checked the threads and QSM4. Sure enough, on page 316 Jerry says "Always use the Waterfall Model when it applies." The italics are his. Then the adjective kicked in: "... a huge project ..." I wondered if the Waterfall strawman was really a surrogate for something else. I listened to the lecture and am reading the article and think I have finally stumbled across what may be the heart of the matter.

Apparently, DoD-Std-2167 required a "strict, document-driven, single-pass waterfall model" (Larman, p. 52) until the end of 1987. Those on DoD projects were not allowed another choice. I believe Sutherland noted that the author of that documentation, when asked why, answered that it was based on the recommendations of a number of then practicing consultants. DoD-Std-2167A (2/88) attempted to fix this, but, humans being what we are, "overseers and contractors often view ... 2167A, ..., as the epitome of a waterfall specification." (Larman p. 53).

So, I ask for the trans-1987 experience of those gathered here. Was 2167 such a document? More important, how was it enforced? Did 2167A change things? Most important for me, could 2167 be what people really mean when they denigrate Waterfall?

MikeMelendez 2004.09.22

1. the life-critical nature (which had never been done before in such a clear way)
   
2. the shortage of technology (which today would be considered pitiful)

We were under no strictures as to HOW to do it. The government had specified that with great precision, and we showed in our bid that what they required could never have worked, so we got the contract over 109 other bidders. I think that's key; if you have a better way, but a new way, you have to be ready to defend it by showing:

1. that the old way won't do the job
   
2. that your new way will (or at least has a chance)

I think a lot of proponents of new ways get so wrapped up on (1) that they forget (2), or at least don't do it very well. - JerryWeinberg 2004.09.22

Project Mercury much pre-dates Mil-STD-2167. In practice, 2167 could be gamed to allow something that worked like incrementalism, and worked pretty well. The big deltas in 2167a vs. 2167 were two, as I recall,

• Relaxing of some of the strictures that made incrementalism under 2167 challenging.
• Relaxing some of the strictures on re-use.

2167a moved a bit toward descriptions of the system that had to tie out without so much enforcement of strict order of execution and less enforcement of single pass and done. Granted this movement was from a stating place that was pretty extreme. I suspect that many discussions of incrementalism (vs. "big bang" more or less) get entangled because they comingle these three things.

• Are there multiple descritions of a system that must tie out? When must these descriptions tie out?
• How do these descriptions relate to project plans and completion?
• How are these descriptions developed, one from another. There are at least three axes on which "derivation" gets interwingled:
• * Derivation in strict sequence? Feedback and mutual influece?
• * One pass? Multiple passes?
• * A strict mechanical process of derivation? Something less explicit?

Discussions that spring from the "agile" methodologies seem to me to skip among these three things, which are realated, but different. The formalists are no better, conflating descriptions and traceability with project phases, with passes through development and a learning model (that is mainly notable for being a non-learning model.) Is there such a thing as "document-heavy incrementalism?" With the definitions-in-use that I have seen, yes, there is. I have done it. And it was appropriate. (IMHO, of course.)

Of course the org-bots steeped in 2167 (vs. folks using it as a tool to get work done) noticed that some of the formats changed in 2167a, while ignoring the change in flow, process, and interactions. I suspect that there's no process / prescription or methodology that can't be hijacked by sufficiently motivated martinets. So how much of the abuse of methodologies ties to the methodology, and how much to the people abusing it. Specs don't kill projects. People kill projects. Yet, you don't want a dangerous spec format lyng around for any damaged individual to pick up and bludgeon a co-worker to death with. Nor do you particularly want a wise-acre slogan lying about to feed the righteousness of folks doing development The One True Way (with extra contempt for Everyone Else(tm)).

Would that we could label (and better enforce) development methodologies: "Adult content - not suitable for children or madmen." But, of course you're stuck with decidng who decides.

Interesting to me, 2167a allowed (again, more explicitly - you can force fit anything if you work hard enough) for re-use of componenets, while 2167 better fit a more strict sigle decomosition from a single hierarchy. In the event of my experience we actually found re-use to give us way, way more heartburn than incrementalism vs. not. The mechanim was the same. Folks steeped in one model had trouble reaching to another. "What do you mean a change over here, has impact over there? That's bad design, and BTW doesn't fit my process."

The re-use problem was compounded by social and business factors that would tend to reinforce vs. erode territorialism.

• Multiple departments on the same project were in the past and would in the future be in competition for work. Likely they had been competing for who would be "prime contractor" and who "subcontractors" on this project in particular. Likely they would be competing for the maintenance / support contract associated with this development effort.
• Some of these contracts were fixed-bid, in the billions of $.
• For US procurement (at the time) each contract had a "contract follower" - the guys who came in second in bidding on the RFQ. Their job was to shadow the prime contractor, and be able to take over if the prime contractor faltered. They were paid to do this.
• Most of the time the "contract follower" also had a part of the contract that was let to the prime - they were "on the team" as well.

2167 and 2167a are only in part about "development." They, and similar efforts have a lot more to do with attempting to secure success in situations where the developing of software, even real-time, high-availability, large-scale software, is less of a risk than coordination and transparency into what is going on. They are also attempts at building systems with very high risk of failure and known expected life-spans of 40 years or more.

Very nicely put question. I hope this is helpful. FWIW, I keep getting accused of being a "closet XP-er" (happened again this week) which I vigorously deny. I've less often been called "one who brings order from chaos." Once I got called a "methodologist" which was profoundly distasteful. I'm not a methodologist. I'm a user of methodology, and of methodologies. The study of methodologies absent their use is uninteresting to me.

At my current client they have managed to embrace the standard down-sides of "big bang" development with the standard down-sides of "incrementalism" all at the same time. Remarkable to see. Second place this year where I have seen exactly this. They are also adept (remarkably adept) at using any piece of prescription to avoid doing the actual work, so for example, discussing unit tests is an excuse 1) not to ship anything for a long time, 2) to descend into an endless infrastructure wrangle 3) to revisit the history of why we haven't done this yet, but we talked about it so it's not a new thing, etc. Talk about "plan" or "requirements" and you have the same effect.

I'm sure there's a paper / article in this, although I don't know how to begin writing it. It has nothing to do with the particular artifacts or processes. It's all about the way you choose to engage with each other, and actually doing the work. There is no tool that can't become a smoke-screen. Would anyone believe it?

-- JimBullock 2004.09.23

"I'd rather write software that writes software than write software."

You can extend this about any production part of the software process, and as deeply as you want, as in:

"I'd rather write requirements for writing requirements for writing requirements than write requirements (not to speak of ever writing code from those requirements)." -- JerryWeinberg 2004.09.23

Wow. That 2167 / 2167a related experience went pretty deep with me, didn't it? "It was the best of times. It was the worst of times." as I recall. It generated insights that I still find emerging from time to time. Thanks for listening. I hope this was helpful to Mike and perhaps others who might not be so personally entangled with those particular key-words.

-- JimBullock, 2004.09.24

Jerry, your insight provided hope that inspite of strict (and inappropriate) process requirements on paper, the requirers can be persuaded of that inappropriateness, particularly if one offers and can argue for something better.

Jim, your experience I'm still processing. It sounds like, you're doing the same with the memories evoked. I'm currently reading Peopleware for the first time. DeMarco and Lister make a strong distinction between methodology and Methodology. The former is necessary to accomplish any end; the later is an attempt to remove the humans from the process thereby losing the self-healing capabilities we humans bring to "knowledge" work. That Methodology might also become a weapon in intra-office politics, I had not though of but I'm not surprised. It seems that we humans are not only the problem, as Methodologists, but also the solution, as thinkers.

Like I said, I'm still processing. Right now, "Waterfall is always bad" seems very like an inverted echo of "Only Waterfall is good". And 2167 was a direct echo of the latter.

MikeMelendez 2004.09.27

Thanks for the patience, Mike. I'm thinking of trying to factor out the war story aspects, and capture some of the more general observations. There are a couple good pieces in the above already: conflating several aspects of "method", for example.

Four thoughts I didn't mention bear some notice:

• While detractors ding 2167 & similar for the big-ness and the bang-ness, and the phase-ness, I have found the descriptions of system descriptions invaluable. In 2167 they're called "DIDs" for "Data Item Descriptions." "Data Items" as in things about the system being developed, not "data in the system being developed."
• A large part of document heavy methodologies (excluding, oddly, RUP, which seems to mostly be about Building Stuff) has to do whith "Poor Schmuck Support" - support for the poor schmucks coming along later. 2167 & 2167a in particular were aimed at program management, integration across multiple vendors, across multiple technologies, and across generations of technology, and support for the majority of the life-cycle which is post-development.
• While a big methodology can be gamed, the problems addressed by "big methodology" exist independently. I'm responding to this: "That Methodology might also become a weapon in intra-office politics, I had not though of but I'm not surprised." While 2167 and 2167a might have become vehicles for inter-office politics (and they were), the politics were already there. None of my bullet list of project constraints is mandated by 2167 or 2167a, but rather by the procurement process, and the industry. "Politics" also has a nasty connotation. They're simply different organizations each with their own agenda, trying to work together. The challenges are structural, vs. venality on the part of the players. The US Defense industry has about enough capacity for the volume of current / recent program development and no more, with exactly one customer. So, everybody "competing" for a contract ends up working on that contract in some sense, win or lose. The contract winner gets a bigger margin, won by demonstrating better estimation and program management skill, the throughput and cost of production being about the same for all of the competitors. It's a fascinating study in a single-customer market with high cost of entry (very specilized skills, with rapid skill turnover.)
• Some methodologies try to address imponderables far larger than "making code happen." The particular "project" I was on - one that spanned more than the typical career of an engineer - was staffing. Given the estimated system size, and the targeted completion there were literally not enough appropriately skilled humans in the world. Building and filling that pipeline takes quite a while, and was a required part of the RFP response - "How you gonna get all this done (throughput)?" vs. "How you gonna do all this (methods / skills)?"

Something I learned from 2167 / 2167a which is "traceability." Royce's schema, not the timing, and the DIDs of 2167 / 2167a have been very useful to me as sets of system descriptions that ought to tie out by the time I think I'm done. I'm OK if some of these never hit paper - hesitant to require that, let alone a particular order. Yet, I find myself catching gotchas when I stop to think: "What is the requirement here?", "What's the concept of operations?". I find more gotchas when I write that stuff down, before or after. And I find myself wanting these additional descriptions when I encounter a system that's been around for a while. Happened earlier this year with a client's system, where I wrote a "concept of operations" after a couple months on site, and got a chorous of "oh wow's" from folks who had been working with that very code for a couple years. All in the same room, BTW.

-- JimBullock, 2004.09.27 (Not compliant with any standard methodology.)

Now, why didn't I remember to say that? My current client is all full of this ritual. One of the things I'm doing is encouraging them to own their traceability (and mutual support) problems differently. If you're not getting what you need to do your job, and let that slide, who's problem is the letting it slide part?

Obviously, they've been buried in bad-management for a long time. They were trained that having something plausable to point at when the crisis-du-jour emerged was a fine way to duck the random wrath. Encourages blame as well as keeping a little pot of other people's bads handy, right in the desk drawer.

Traceability, like other successful communication, is a shared thing. If there's traceability missing, you both, or perhaps all have some work to do.

-- JimBullock 2004.09.28 (Without a trace)