Forum

I enjoyed reading Phillip Armour’s column ("The Business of Software," Jan. 2002) regarding the spritual side of project teams. It put into words some ideas I have tried to express to team members over the years. The only area of disagreement is with one of Armour’s statements regarding weaker personnel. He states that a Gaussian distribution doesn’t apply because the personnel are not randomly selected. While this is true, the difference of opinion has to do with the statement that the people "do [the work] because either they like it, they are good at it, or both." There is one other possibility for consideration—some people select their occupation because there is a demand for workers in a field, even if they are ill-equiped for the work. I have seen the resumes for too many software developers who completed a boot camp with the expectation that a high-paying job would follow. Few of those I have worked alongside became team members, possessing the spirit to which Armour refers in his article.

Steven Warshawsky
Aurora, CO

It was a pleasure reading Armour’s January column. I agree with his views that spirituality is an essential and often overlooked factor in any group or team effort. It is nice to see the human aspect of programming, rather than treating it as a mechanical chore. I commend Armour for his efforts.

Kamesh Balasubramanian
Canoga Park, CA

Back to Top

Strength in Stability

Mohamed Fayad’s column on accomplishing software stability ("Thinking Objectively," Jan. 2002) brought to mind a useful concept taught by my psychology mentor, P.G. Ossorio. He found it useful, when describing human behavior, to use a refined version of the concept expressed by the word "significance." Ossorio described the significance of an action as the answer to: "What are you doing by doing that?" For example, I am typing at a keyboard; by doing that I am writing a letter; by writing a letter I am attempting to share a useful insight; by doing that I am engaging in a core practice of academicians (even a retired one, like me).

A significance series like the example I just gave can be useful in a variety of ways in software engineering. For example, I have used it to explain criteria for the creation of useful documentation: it does no good when documenting to parrot the code too closely, because what is needed are descriptions a few levels up the significance series from the code itself. When human behavior changes, the lower levels of significance are generally more volatile, while higher levels are more stable. And that brings us to Fayad’s column. Business Objects are more stable than Industrial Objects because they characterize the significance of the IOs. EBTs are more stable than Business Objects because they characterize the significance of the BOs in the human activities in which they participate.

H. Paul Zeiger
Tucson, AZ

I don’t know that a commercial kitchen could live without the livability theme(s)—cleanliness, convenience, and light. Fayad’s sentence might need revising. For example, if the livability theme is taken out of the model, the model is no longer a useful design for a kitchen in a home, but possibly for a kitchen in the back of a restaurant.

Assuming the kitchen is focused on humans, cleanliness will be enduring for all kitchens. Assuming humans are accomplishing the cooking, light will be necessary. Only convenience seems optional as some kitchens don’t need a preparation area (for example, microwave and serve).

Richard Ho
Oakland, CA

I like the way Fayad describes the inadequacy of typical specifications. Table 1 expertly illustrates the most common error—what I call an "abstraction mismatch."

Industrial objects are usually shoehorned into becoming EBTs, which change far too rapidly to ever create a solid anchor point that withstands the test of time.

I believe this often occurs because of miscommunication between so-called "subject matter experts" or "domain experts" and technical people because they do not use the real EBTs as the common language used to work toward common goals. I’m working on some projects that have problems due to difficulty identifying the EBTs.

It is so difficult to get people to stop talking about the familiar elements of software and get them talking about what they are really trying to do. I think Fayad is onto something a bit beyond that.

David Cymbala
Mt. Kisco, NY

Back to Top

Total Picture

David, Schuff, and St. Louis ("Managing Your IT Total Cost of Ownership," Jan. 2002), presented a view that will likely be near to the hearts of administrators. I have no argument with their acquisition and administration cost categories. However, they have missed one of the most important categories of TCO—one I call the "GOB cost," that is, the Going Out of Business cost. The acronym has the nice connotation of putting one’s foot in one’s own mouth (gob). Surely this is part of the TCO of hardware and software, especially in the UCITA environment where vendor errors are a risk the user must bear.

At the University of Ottawa, like most teaching institutions, there are great pressures to use technology in the classroom. In an effort to keep costs down, our administrators have largely followed the ideas of David et al. However, the choices made by administrators (who do not teach) mean that classroom machines are often unable to run software that is the subject of important lessons. Moreover, even when such software is installed, it may not work properly because of peculiar security, installation, or other settings. There are, of course, solutions to such issues, and arguments available to indicate lower TCO, especially if the costs of professor and student time for an extra class are allowed. More likely, the students and even professors will spread the bad word, and we will lose business—a GOB cost!

I am sure this is but a very minor example. It begs, however, the question of validation of the (possibly amended) TCO costing model of David et al., which is a framework for the measurement of costs. Actual data from carefully designed investigations is required to turn this into workable policies for controlling IT TCO.

IT and its administration can put us out of business or severely damage our ability to carry out our core functions. For most businesses, IT is simply a tool, and its TCO is important and must be managed within the context of surviving and prospering. An evidence-based study of TCO having wide applicability would be most welcome. David et al. are at least getting the discussion started.

John C. Nash
Ottawa, Ontario, Canada

Back to Top

A Readable Plea

One of the real contributions information technology has given to research is that one can now find many articles quickly and simply by Googling the authors and going straight to the text online. This advance is tempered, unfortunately, by the frequent practice of CS researchers to provide such text in Postscript format (.ps) or, worse yet, Gzipped Postscript (.ps.gz), making access difficult or impossible from a browser. No doubt various gizmos exist, commercial or free, to facilitate conversion from these formats, but installing them on various platforms is an unjustifiable tedium. Other than plain text, only two formats—HTML and PDF—are really convenient and universally understood by browsers. For research papers that usually requires precise typesetting, PDF is the proper choice. Converting from Postscript to PDF is a trivial matter, for example with Adobe Distiller.

I take it as a sign of disrespect for authors to expect every single reader to perform the required conversion on his or her own, whereas it should have been taken care of once and for all at the source. (Personally I lose patience quickly and tend to ignore articles in strange formats, such as .ps.gz. This may be unfair and possibly self-harming, but life is short and too much of it is already spent fighting various software tools.) The original need for compressed formats—saving space—became obsolete many years ago. By buying yourself 30GB for $70 or so, you’ll have space for some 100,000 standard-size articles and a few books, which should keep you busy for a while. Hence, my plea to all researchers reading this letter: if you want someone to read your brilliant work on the Web, please produce it in HTML or PDF.

Bertrand Meyer
Zürich, Switzerland

Back to Top

The More Things Change…

Recently, as part of preparation for a software project management course, I decided to reread Edsgar Dijkstra’s 1972 Turing Award lecture, "The Humble Programmer."

I believe it appropriate to offer what, to my mind, is perhaps the ultimate compliment: If Dijkstra were to submit the article for publication today, it would stand virtually unchanged.

It is thrilling to review the power of clear thinking and elegant thoughts. Everyone involved in training young people needs to adopt at least one of the classic seminal articles that has had a lasting effect on our profession and use it. Not for old times sake, but to show that elegance has no time limitation.

Mordechai Ben-Menachem
Ben-Gurion University

Back to Top