The recent comment "Dijkstra" [1] is from the famous maven of applied structured programming Edward Yourdon. Although this is "not verified," the style, courtesy and literacy are the Yourdon I knew.

For all you young kids, Ed Yourdon formed a company in the 1970s to teach the structured techniques in a real programming language after Mr. F. T. Baker of IBM found that their consistent use in PL/I had created an on-time, effective system (still in use) at the New York Times for journalistic information recording and tracking.

Yourdon's classes showed clearly how to write Cobol, the most popular business language of the time, in a structured and readable way. In Cobol you could do this with nested Ifs, and and or Boolean operators, and use of Perform (a primitive mechanism for subroutines). Although all data in a Cobol program was global to the program in a serious design error on the part of the 1960 developers of Cobol, you could use naming conventions to show the intent to localize.

I learned from Edward Yourdon how to write pretty good Cobol. By 1980, I was able at Baxter-Travenol to write a five-way match merge for personnel which unified its profit sharing and pension data streams in 24 hours, making my boss Joanne, a wonderful lady, very happy.

The only problem is that there has always been an unwillingness, through misguided desires not to hurt feelings, to discuss the larger social context in which all this bit twiddling occurs.

We know that we're working hard for a company such as Starbuck's, and we rationalize, as I rationalized, that we have kids, or need medical insurance for an aging parent. And, truth be told, companies run by a single compassionate man who likes to build boats are almost nonexistent.

Even in my current job, for that matter, I am giving kids whose parents have money a leg up on their assignments while most kids in Hong Kong have to struggle at the library at Tin Hau.

Where I drew the line was when the social facts prevented me from doing a good job: I'll never forget the "structured walkthrough" at Montgomery Ward, where the manager sat down with us and said "I know your structured programming teacher said 'no managers in structured walkthroughs': too bad."

I'll never forget the ex-Navy officer who was assigned to a late project at Motorola with the mission of finding trouble-makers and who would get in their face about their late code, telling them in so many words that they were swabbies and grunts, nothing more.

Weinberg, who worked with Yourdon, wrote about the ways in which this rage to control damaged the application of structured techniques. If you've been told you are shit, why worry about being structured or object oriented?

Hell, make a mess that seems to work or actually does, and leave it as a legacy to the company. More than one programmer has done this.

I've never done so: yet the paradox is that alienated programmers can and do see what I think is good code and see bad code. In C, I use Hungarian notation and instead of using i as an index, I use intIndex. This enrages programmers who have to code and maintain gargantuan C source programs: it's a waste of time.

Thanks to Dijsktra and to Yourdon, the 1970s were in actuality a time of rapid progress in software, much more rapid than the HTML-ridden 1990s. Yet this cannot be admitted by the powers that be, because the 1970s were also an era in which programmers, as working folks, were less controlled and less monitored and less alienated as a result.

Yes, Edward, I agree that Dijkstra showed us that as responsible applied scientists, we have to prove the correctness of large software systems. The trouble is that a correctness proof of Enron's software would have revealed that it was in part a tool for hiding losses.

The trouble is that a correctness proof of banking software for large and successful banks would show a systematic exploitation, such as occurs in my experience at The Hong Kong Shanghai Bank, of the small saver, the sort of person who *en masse* made the big bank big, in favor of the "premiere" customer.

The trouble in 1962 was that a correctness proof of the United States' new air defense SAGE system wasn't available and could not be available because it was classified. You see, Dijkstra's notion of proof, like that of any decent mathematician, was founded on the fact that ANYONE could see, from Euclid's proofs, that they were true, and a proof cannot for this reason make any reference to secrets.

The trouble today is that a Constitutional correctness proof of the algorithms that may or may not have been applied to aggregate phone data by the US to monitor domestic calls can never show that this data hasn't been used to monitor individuals. I was able to reconstruct calls from atomic phone hardware events, so no Euclidean "proof" can be produced by the administration that the surveillance is aggregate-only.

In other words, there was a real contradiction between the *glasnost*, the openness, of the structured walkthrough, in which people would admit their mistakes and point out other's errors because they weren't, in the 1970s, afraid for their jobs and health insurance, and the natural bias in American business towards shedding workers at-will. Weinberg's and DeMarco's personal solution was to more or less drop out as a lifestyle choice, and accentuate the soft side. I'd say that this shouldn't have to be a lifestyle choice, and that people deserve openness and transparency in daily life.