Slashdot Mirror

Those who have never read "The Psychology of Computer Programming (Weinberg, 1971)" are doomed to re-invent small parts of it over and over and over. http://www.geraldmweinberg.com...

I don't mean to sound like I'm picking on you, fm6. You sound younger than me, so I wanted to clarify some history and give some thoughts on the points you raised. (Credit is due you for knowing this history; most of the programmers I work with, even some of the older ones, wouldn't know what you're talking about!)

• [TP] was designed to run in a single 64K 8086 segment - which was a lot of memory in the 70's and 60's. Pascal was also designed for one-pass compilation, which helped. Of course, there were also C (Mix and Turbo) compilers and a very fast Ada compiler (Meridian?) that ran on PC XTs. Anyone remember the 1K and 2K Tiny Basics of DDJ fame?
• Pascal is the quintessential block-structured language. The real problem is that the designers of FORTRAN were totally ignorant of the principles of language design. - Algol was, I believe, the original block-structured language and largely a contemporary of FORTRAN (see the Algol 1960 Report).
• Every programmer who's grown up with block structured languages would take it as a given that Dijkstra was right. - yes, the jump-on-the-bandwagon-I-want-to-use-XML-too-type programmers. A subsequent issue of ACM's Computing Surveys was devoted to the GOTO controversy and included a long article by Knuth that took issue with Dijkstra's edict. (I think it was in this article that Knuth said that good programmers, by nature, always write structured code, no matter what the language.) In real-world code, where, for example, error checking and handling is required (and using languages without exceptions), mindless structured-programming adherents often went to great lengths to avoid using GOTOs, producing unintentionally obsfuscated code in the process. Every technique, even GOTO, has its place for reducing the complexity of code.
• ... Crowther and Wood were still using computed gotos in 1976! - My memory is hazy, but wasn't it FORTRAN 77 that added block-structured control flow, etc. to FORTRAN? Also, when you think about it, computed GOTOs were FORTRAN's equivalent of C's switch(){} statement. Yes, you would get the occasional hacker mashing up computed GOTOs into spaghetti using techniques such as Duff's Device, but most of us could restrain ourselves!

You learn something new everyday! I'm currently reading Gerald M. Weinberg's Exploring Requirements and, just this morning, while reading the chapter on measuring user satisfaction, I came across his example of the FORTRAN FREQUENCY statement as something the users didn't like. I had never heard of the FREQUENCY statement, but it was required after 3-branch IF statements in early FORTRAN programs to hint to the compiler what branch(es?) were most likely to be taken. According to Weinberg (or his co-author Donald C. Gause), the increased compilation times incurred by performing IF-statement optimization were annoying to users who, like most of us, had to compile their program many times during debugging and then would run the final working program just once.

I think you can attribute that to Gerald Weinberg.

Would suggest reading Jerry Weinberg's Quality Software Management, Volume 1 (at least) if you want to know more. Almost as funny as Dilbert.

It was a good start, but is too widely regarded as the be-all and end-all of software patterns. Jim Coplien has some pretty damning criticism of the cargo cult that this book has become. Hint: get some Gerald Weinberg in your bookshelf, start with "An Introduction to General Systems Thinking" if you can find it anywhere.

If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.

Define "quality" before trying to make "quality" code. "Quality" doesn't mean one single thing. It can and does mean different things to different people. I've seen people use "conformance to spec", "fully documented", "feature rich", "crashproof", "fast", "easy to use", "surprising", "first to market", "bug-free" as all or part of what "quality" means.

Figure out what you mean by "quality", then find out what your boss means by "quality". You may be talking across each other. You might want to look at Gerald M Weinberg's Quality Software Management for a better discussion of the meaning of "quality". I'm not sure about the rest of the book, but the section on what "quality" means is relevant.

My other advice: ignore consultants and companies who peddle a Process (a process to reach SEI CMM level 5, or ISO 9000 status, for example) as a means to acheive "quality". They often leave "quality" undefined or vaguely defined because then they get to use opposing meanings as convenient. When convincing programmers to use The Process, quality consultants will use "bug free" or "speed to market" as the implied meaning of quality. When talking to managers, they use "feature rich", "on schedule" or "completely documented" as the implied meaning of quality. When talking to corporate leadership, the use "cheap", "speed to market" as meanings. Often, some tension exists between various definitions of "quality". "Cheap" often opposes "bug free" or "fully documented". "Feature rich" can oppose "high performance". "Speed to market" can oppose "fully documented". You get the picture.