Fallacy Of Omniscient Design

See also: OnlyForesightMatters

This is a term I first heard from BillFelton, who was a VP at both KSC and Jumpstart Systems. He now owns his own company, Gryfon Technologies. Bill realized that a big part of the problem with the "waterfall" methods was not that the order of things was out of whack, but that the problem was that in the waterfall (at least in older versions) the assumption was that you COULD know everything up front. In reality that never worked out. In fact later versions of the waterfall process (and a few of the earlier versions that were often overlooked) had feedback from later stages of software development back to earlier stages.

The fact is, that designers aren't omniscient. An analysis can be nothing more than a best guess as to what requirements are. A Design can be nothing more than a best guess as to how something should work. In fact, code is usually nothing more than a best guess as to how something WILL work.

The great thing about spiral development models is that they free designers from the burden of their supposed omniscience. Once they can admit that they don't know everything, they can get on with working out what they DO know.

--KyleBrown

Unfortunately, many customers/clients expect the designer to be omniscient. I am working on defense contracts where they expect an accurate (final) design and time to completion estimate up front. Some contracts still require a lines of code estimation before a design has been approved. Of course, lines of code estimates are practically useless, but they are even more so with Object Oriented Development and modern programming languages.

It is very difficult to do spiral development in an environment where the customer expects the developer to have all the answers up front. Because I am constrained by contract procedures, my development efforts are usually spiral on the inside (reality); waterfall on the outside (illusion).

Scary, but true...

-- ToddCoram

Why is it scary? Relax, it's okay. The actual activity maze on a real project with lots of knowledge to apply and still lots to learn is too complicated to capture with a word like "waterfall" or "spiral", yet those words are both valid abstractions of what's going on, and they are valid concurrently with each other, surprisingly.

With the broad brush, a project moves generally from requirements to implementation details and verification. What this means is not that code mustn't be written in the earlier stages, but that the code written then is more likely to be in service of firming up requirements than polishing up the final result. So is it code or requirements? It's both, and it depends on the model you're looking at your project through. It's the coding step of a small turn around the spiral, while it's some detailed requirements work on the waterfall scope.

The relationship between stability and change, planned versus improvised, cut and dried versus torn and wet will always exist in living systems, including software development projects. It's folly to try to drive this flux out of the system. What you want instead is a balance. Use waterfall models to remind you of things you DO know but aren't making use of (it happens all too often). Use spirals to remind you that you can't know everything until you're dead. Avoid labeling models as enemies just because you can find a problem where they don't apply. Even the most useful tools sometimes sit on the bench.

-- WaldenMathews