Psyc+Tech » Blog Archive » Don’t draw diagrams of wrong practices – or: Why people still believe in the Waterfall model is a fascinating and somewhat scary reminder that what everyone knows is right and accepted and smart sometimes is the stupidest thing you could do.
Quick summary: in 1970 a smart fellow publishes a paper about two different approaches to software development, one which seems like a good idea but doesn’t actually work, and another which does work. The one which seems like a good idea but doesn’t actually work is nicknamed the “waterfall” process because the diagram which illustrates it looks like a cascading waterfall.
Later writers apparently remember the diagram but not the comment that it doesn’t work, and the original paper is cited again and again and again and again and yet again as if it approved and recommended the waterfall process.
Engineering and hard science types like to think of themselves as far superior to humanities folks, with their crazy postmodern nonsense. But something like this reminds us that mindless repitition of secondhand quasi-knowledge when it is in direct contradiction to fact is something not just postmodern humanities academics, but humans in general, are prone to. There are plenty of naked emperors parading around the human world, and they sometimes reign unchallenged for decades, even in software engineering…
via reddit.
Another quick link — an awesome article about the Sokal hoax. Highly recommended.
Amen, Ed. I think it’s mainly that geeks cannot escape their humanity, no matter how they try, and often end up acting pretty religious (“evangelists”) in the quest for the One True Practice. I am reminded of people I know who think Java is a good language for text processing.
You bet, man. And the thing with the One True Practice, at least in my own life, is that often the only escape from one One True Practice is finding another that you think is superior. “You use Java? You could be using python.” “You use python? You could be using Ruby.” “You use Ruby? Why not go back to the original best-of-the-best language, Lisp!” “Your lisp is Scheme? Paul Graham says Common Lisp is better!” “You’re using Common Lisp? Haskell is *purely* functional and much faster!” It’s harder to break out of the whole cycle than to just move a step along it.
In the many development environments I’ve been part of, I’ve seen many different “practices” used to varying degrees of fidelity. (I’ve often found that the corporate standard is often bastardized to accommodate the exigencies of the moment.) In almost every case of a successful project the two factors most involved with the success were the motivation of the individual members of the team and the quality of leadership. What “system” we were attempted to use often became more of a hurdle rather than a source of strength. This isn’t good for companies, of course, because they would like some system that they can plug any individual into and get predictable results.
(I’ve often found that the corporate standard is often bastardized to accommodate the exigencies of the moment.)
I know this one – my experience has been that docs go first (“Screw the docs, *I* know how it works, and it goes live in 2 hours”) But, yes, the corporate standard can be neatly condensed to “Get it finished, asshole.”