SEI Reactions
Dear DDJ,
I read with interest your editorial "Swaine's Flames" in the November 1988 issue of Dr. Dobb's Journal. I regret that your experience has given you a negative impression of the Software Engineering Institute (SEI) and would like to explain that situation from my perspective.
According to your account, the SEI did not meet a commitment to produce an article for your September issue. As best as I can trace your telephone odyssey through the SEI, your request for an article was initially turned down because of the prior commitments of those staff members who could have either written the article or committed resources to having it written.
Unfortunately, the person who finally accepted your request thought he was making a personal commitment, but you thought you were getting an SEI commitment. We did not perceive that problem until a draft of the article went to review. This is where SEI communication failed, and we apologize. Reviewers found the draft incomplete -- not ready for publication without significant effort. Meanwhile, your deadline was rapidly approaching.
At this point, one of our program directors called to let you know that the draft did not meet our standards and that we could not revise it in time to meet your deadline. In later conversations with you, SEI staff agreed to produce an article sometime in the future but made no specific commitment, or so they thought. Obviously, you felt otherwise.
I am surprised by the inference you draw from this experience about software engineering and bureaucratic delay. I see the situation quite differently. An important characteristic of a successful software engineering organization is that it meets commitments with quality results on time and within budget. At the SEI, we take commitments seriously: We don't make one unless we intend to honor it. Ironically, this caution in making commitments is what prompted staff members to turn down your request in the first place.
We undoubtedly have made and will in the future make mistakes at the SEI. I regret that this instance of miscommunication left you with a poor opinion of us. If you are still interested in publishing an article from the SEI, please call.
Larry E. Druffel
SEI Director
Pittsburgh, Penn.
Jon responds: Thanks for the offer Larry and, yes, I'd still like to see the article. Believe it or not, I do think the SEI serves a useful function and that many fine people are associated with it. I wish the organization well. However, I stand by my description of my experiences with the SEI, experiences that were substantiated by readers who have also had to deal with the organization's bureaucracy.
Dear DDJ,
I was entertained by your page in the November 1988 Dr. Dobb's ("Swaine's Flames" by Jon Erickson) about your difficulties with the Software Engineering Institute (SEI). I don't know much about the SEI but, yes, the government software world is that bad. I've been dealing with it for 25 years. It's always bad, and it's been getting worse lately. The last project I worked on had maybe five technical people trying to modify code, 10 or 15 people trying to test it, and maybe 30 people running around to meetings and stumbling over each other making decisions whose quality is best left to the imagination. Aside from an abnormally large number of test people -- which for reasons too complicated to go into here made some sense -- this show is not atypical.
If you'd like some real entertainment, obtain a copy of DOD standard 2167A, which describes how software is to be developed for mission critical software. This gem and the descriptions of the associated documentation include virtually every idea (good or bad) ever espoused about the software production process. Now try to imagine what will happen when a bureaucracy gets a hold of it.
As for software engineering: Are you sure it exists? I'd submit that the difference between engineers and tinkers (used in the original non-pejorative sense) is that engineers know pretty much what should happen when they fire things up, whereas tinkers know what they hope will happen. Engineers understand why what they are building/fixing works, whereas tinkers understand what to do to make things work a lot of the time. From what I've seen, most "software engineering" is really software tinkering. To pick just one example, the people I've seen "engineering" real-time software rarely seem to understand the difference between synchronous and asynchronous systems, and do not understand enough about queuing systems to predit the performance of asynchronous systems. Not surprisingly, the performance characteristics of the systems they build often comes as an unpleasant surprise to them.
It seems to me that a process that can't predict size, performance, or cost with any precision isn't engineering. Don't get me wrong: Tinkering is an honorable art and a necessary one. But there are a lot of situations where I'd prefer a little more determinism in the results.
It particularly disturbs me that I don't know where to send someone who honestly wants to learn about software engineering. For algorithms, I can send them to Knuth's books. For information on testing, I can send them to Boris Beizer's excellent books. But where can I send someone for information on how to design a system that will work and how to predict how well it will work? I missed your SE issue. I'll dig up a copy and read it, and I'm ordering a copy of your SE Source-book. Perhaps it will help, but I'm not optimistic.
Donald Kenney
San Diego, Calif.
XREF Examination
Dear DDJ,
Kent Porter's December 1988 "Structured Programming" column, with the XREF program, was entertaining and instructive, as his articles usually are. Some of the material calls for a little further discussion.
All line number references are to Kent's Listing Three.
- 1. In describing the "binary B+ tree" as a combination of a binary tree and a B+ tree, the article may have confused data with links. The structure appears to me to be a simple binary tree with nodes containing, among other data, pointers to singly linked lists of line numbers. The fact that data points to a linked list in no way affects the nature of the tree.
- 2. XREF's opening comments declare that the program "uses binary trees and doubly-linked lists to effect B-Tree." Neither the article nor the program deals with doubly-linked lists or B-Trees. I often use such comments to describe what I'm going to do, then do something different. One of Al Steven's recent crotchets addresses that type of program comment.
- 3. Because XREF operates on Modula-2 as well as Pascal files, line 137 should test for DQuote as well as Quote, and line 139 should set ScanChar : = ch. The program logic appears to successfully prevent ch from containing DQuote when processing a syntactically correct Pascal file, so Kent would be justified in leaving PComment as declared in line 35, rather than manipulating it in response to a command line switch for file type.
- 4. If Token (line 119) finds an opening comment or quotation marker, it calls procedure FindEndOfComment (line 48). FindEndOfComment then searches for a matching closing comment or quotation marker. If it fails to find the matching marker, it will read beyond the end of the file.
- 5. If the tests in lines 268 through 282 are to "weed out nuisances" reliably, they should be made against UpShift(Symbol) rather than just Symbol. As written, they fail to weed out While, at line 323 when making a case-sensitive listing.
- 6. When making a case-sensitive listing, XREF avoids placing the nodes in their final order until just before making the report. A call to the Alphabetize procedure (line 342) then builds a new tree, disposing of the old one as it goes. Kent is to be commended for making his case sensitive ordering follow a human collating sequence, but this approach seems redundant. I am tempted to build the tree in its final order on the first pass.
The tree only needs be built once if the symbols are compared according to the case sensitivity flag rather just testing "if s1 > s2," and so forth. Comp, shown in my Listing will do the job. My Listing also contains BNode, modified to use Comp.
Building the tree in a single pass, the Alphabetize procedure (line 342) can be eliminated, and a few other places can be simplified. But does this approach really accomplish anything useful? Maybe, maybe not.
Results from sample runs of the original and modified XREF programs, using the original XREF.PAS as an input file, are in Table 1. The modified version performs fewer string comparisons than the original version does: 52 percent fewer without case sensitivity, and 70 percent fewer with case sensitivity. The modified version performs as expected regarding node creation. The original version, however, makes 47 percent fewer calls to the UpShift function in the case-sensitive trial.
Table 1: Sample runs of the original and modified XREF programs
XREF Case String{1} Calls to Calls to{2}
Version Sensitivity Compares NewNode UpShift
-------------------------------------------------------
Original insensitive 11,660 143 1,462
Modified insensitive 5,560 143 1,462
Original sensitive 18,921 296 443
Modified sensitive 5,638 148 831
- 1. "String Compares" is a count of the number of times that symbols are compared for for equality or inequality. 2. The modifications made some of the original calls to UpShift pointless. They were removed from the modified version and are not included in this table.
Clearly, getting reliable benefit from the modifications would require finetuning UpShift. Then I would fine-tune Comp. Then I would ... well, instead of considering changes to dealing with case sensitivity, I am considering details of optimization -- not the present point. The most I can say about the benefits of the modifications is that they justify further study.
As usual, Kent has provided material to stimulate his readers' thinking. My thanks to him and to DDJ for that. Please keep it up!
Karl Brendel
Hutchinson, Kansas
Columnist's Comedy
Dear DDJ,
I bought the December 1988 issue of DDJ at a software store and was delighted with Al Stevens' column ("C Programming"). It's refreshing to see his droll treatment of the C language's imaginary portability and Intel 8X86 architecture in the "C Tool Set Errata," and then his sarcastic declarations that C is "language of choice," to be "the best programming language ever devised," and that he is "C purist." Naming a word processor "twerp" is cute too: What does it really do? Play the Mickey Mouse Club theme song with a brightly colored screen and bouncing ball?
So many microcomputer magazines and columnists seem to be overly serious. Thanks for bringing a bit of humor to this often drab and tedious business.
Jim Miller
Nashua, New Hampshire
"Find That Function" Revisited
Dear DDJ,
It made me smile to read all of the "mine-is-better-than-yours" letters regarding "Find that Function!" So far we have been shown "better" ways of doing this task using AWK, GREP, LEX, and C. All of the examples showed improvement on the original, given one assumption. The programmer must know AWK, GREP, or LEX.
Perhaps my mind is not as powerful as those of some of the AWK wizards in the world, but it would take me much longer to do this job in AWK than in C because I don't know AWK.
The list of helpful programmer's tools is long, and it grows daily. These tools can be fantastically helpful for tasks such as "Find That Function!" but most programmers don't have the time necessary to get over the learning curve of such tools. The only programmers who know them all are the gurus whose jobs are not to write code but to know stuff.
If I took the time to learn every useful tool that is available to me, I would be much less productive than I am today. This is because I would spend a significant portion of every day piddling with the latest tool that came across my development platform.
It is up to every one of us to determine where to draw the line on "productivity" tools. I prefer to invest my time in management, database management, and communications. I am able to save myself weeks and even months by learning and using tools such as these.
Many of the other productivity tools seem to me to be little more than typing tools. And because I type well, I don't spend much time using this type of tool. A good editor, a source code control system, and my trusty Norton Utilities do everything I expect out of my typing tools. Perhaps I would spend a minute or two less a day if I knew AWK, LEX, GREP, YACC, and so forth, but it is a long return on investment for the time I must put in to learn them.
My "mine-is-better-than-yours" solution to the "Find That Function!" problem is to write programmer's documentation that includes the source file for the function. Then when I need to find the function, I just RTFM (Read The [Darn] Manual). When that won't work, I use a simple text search utility and my eyeballs.
Tim Berens
Dayton, Ohio
_Letters to the Editor_
[LISTING ONE, FROM KARL BRENDEL]
Copyright © 1989, Dr. Dobb's Journal<a name="00e2_0008">
TYPE CompType = (LessThan,Equal,GreaterThan);
FUNCTION Comp(VAR s1, s2, sh1, sh2 : SymString;
CaseSen : BOOLEAN) : CompType;
{ sh1/sh2 are UpShift(s1/s2) }
BEGIN
IF CaseSen THEN BEGIN
IF sh1 < sh2 THEN
Comp := LessThan
ELSE IF sh1 > sh2 THEN
Comp := GreaterThan
ELSE IF s1 < s2 THEN
Comp := LessThan
ELSE IF s1 > s2 THEN
Comp := GreaterThan
ELSE
Comp := Equal
END
ELSE BEGIN {not CaseSen}
IF sh1 < sh2 THEN
Comp := LessThan
ELSE IF sh1 > sh2 THEN
Comp := GreaterThan
ELSE
Comp := Equal
END
END;
The BNode function (line 186) can then be rewritten as
FUNCTION BNode(VAR sym : SymString) : SymTreePtr;
{ Find sym's node in binary tree, or add it if it doesn't exist }
VAR Node, Parent : SymTreePtr;
UCsym : SymString;
co, parentco : CompType;
BEGIN
Node := Head;
IF Case_Sensitive THEN
UCsym := UpShift(sym)
ELSE
UCsym := sym;
{ Note that calls to NewNode have initialized all Node.UCSymbol }
co := Comp(sym,Node^.Symbol,UCsym,Node^.UCsymbol,Case_Sensitive);
WHILE (Node <> NIL) AND (co <> Equal) DO BEGIN
Parent := Node;
IF co = LessThan THEN
Node := Node^.LLink
ELSE
Node := Node^.RLink;
parentco := co;
co := Comp(sym,Node^.Symbol,UCsym,Node^.UCsymbol,Case_Sensitive);
END;
IF Node <> NIL THEN { Node exists for this symbol }
INC (Node^.Count)
ELSE BEGIN { Else add new node to binary tree }
Node := NewNode (sym);
IF parentco = LessThan THEN { Update parent's pointer }
Parent^.LLink := Node
ELSE
Parent^.RLink := Node
END;
BNode := Node;
END;
