In "Academics, and the Scarlet Letter ‘A’," ("Practical Programmer," April 2001, p. 17), Robert Glass offers an interesting suggestion that does not go far enough.
His complaint about academic authors and reviewers and their bias toward advocacy arose from a reviewer’s comment that the author of a paper being reviewed "needs to do a better job of selling his or her work." Glass objected to any need for "selling." I agree.
My point is that some means are still needed to improve the quality of reviews (possibly by awarding a "B" for bias?). I realize it is difficult enough to get reviewers who complete their reviews on time, without grading them.
I participated for years in soliciting reviews of conference papers submitted by both academics and practitioners. All too often, it seemed, the reviewers sought only to show how much smarter they were than the authors, without really contributing any ideas of value. If we received one good, objective review for a paper, we were delighted.
ACM’s Computing Reviews seems to acknowledge this point by printing two or more reviews of the same book or paper the editors consider to be particularly important. Several reviews tend to cancel out individual bias. Paraphrasing a postulate of psychology, "Bill’s opinion of X tells you more about Bill than it does about X."
Richard G. Canning
Vista, CA
Robert Glass illustrates his own hidden biases as much as the bias he described against "advocate" academics. He and I may both agree that "truth-seeking" is good and excessive advocacy is bad, but we differ on how to laud praise and deliver blame.
The column contends that industry folks are allowed to advocate as much as they want, while academics alone must accept the role of guarding the ivory tower of "truth," forbidden from encouraging others to leverage their works.
Glass’s assessment that academia accept only this more limited role (that is, to show that X may be better than Y, but to never tell others that they should do X) is archaic and actually belittles people in industry. It says that our discipline as a whole need not be less "advocative" and more truth-seeking. Leave that to the academics.
Are industry people not truth-seekers? I certainly hope they are, as important standards are being written and implemented by them. With so many Ph.D.’s in industry, chastising academics presents a dichotomy that doesn’t exist. Unlike white papers or advertisements, publishing conference and journal papers or setting standards are processes comprised of advocation, science, and lots of peer review, no matter the station of the author/reviewer. It is not a subset of academics that are "sinning advocates," but a subset of both academics and industry people.
The truth in Glass’s column is that excessive advocacy is indeed a problem. But his supposition that the problem lies only within the academic community is fundamentally incorrect. Expecting that a company with all eyes on the bottom line will not advocate may be unrealistic, but so is the expectation that academics do not compete in contentious spaces (for example, academic advocacy has been critical to media coding and transmission protocol standards). Thus, Glass’s rejoinder to academics is misplaced; at best, we can encourage "truth-seeking" by all members of the computing profession, not just a specific subset.
Finally, there is a lesson here that may be taken in a broader sense. Glass (and the rest of us) may wish to reconsider attempts to classify all things as "industry versus academia." The simple reality is that the line between the camps can be vanishingly thin in the discipline of computing.
Todd Hodes
Berkeley, CA
Millennium Reflections
I found it ironic to read the reflections on the next millennium by practitioners of a science that is at most a century old (Mar. 2001). As one might expect, the essays were relentlessly humanistic (there are no gods, only us, according to Leon Kappelman) and materialistic (Doug Riecken’s agenda to make computers think just like we do). The courageous sharing by the writers on spiritual life and information technology no doubt provided a moment of wry amusement to those readers who have had spiritual experiences.
However, the greatest omission among the authors lies in the absence of any reflections on the effect of IT on the future of the family. This is understandable; while some computer scientists may have been raised in actual families, their preoccupation with their studies has for many reduced this to a distant memory. Nevertheless, it is at least arguable that stable families form a critical part of the foundation of societies capable of supporting the technologies covered in the essays. Will these technologies strengthen the family or will they weaken it? Will they lead to greater family cohesiveness or to greater individualism and isolation? It would have been good to have included at least one essay by someone with a clear understanding of the importance of family—someone who could show how technology in general and IT in particular have, so far, affected the family and what that might mean for the future.
Bill Leal
Athens, OH
What a delightful parody of the notion that cyberspace eliminates the need to order arguments and marshall facts ("Digital Village," Mar. 2001, p. 17). I enjoyed Hal Berghel’s subtle digs at the fallacy that thought, like time, can be anything but a sequential process, and his plea for the return of disciplined intellectual intercourse.
Berghel rightly blames Gutenberg for beginning the cheapening of the dissemination of words. It led (inevitably?) to the current proliferation of searchable nonsense on the Web and in our 96,000 scientific journals that threatens to overwhelm us all.
What we need is a stiff server-side tax.
George Nagy
Troy, NY
Unfashionable Smalltalk
As a Smalltalk fan, I’m always happy to see people using or writing about my favorite language. The excellent article by Kappel et al. ("Bottom-up Design of Active Object-Oriented Databases," Apr. 2001, p. 99) caught my eye. Oddly, although there’s enough information in the article to make it clear the system is implemented in Smalltalk, the language is never mentioned. Is Smalltalk so unfashionable these days that authors need to conceal its use to get an article published?
Alan Knight
Ottawa, Canada
Authors’ response:
Knight makes a good point. We might well have mentioned the use of Smalltalk, especially because its reflective and dynamic features were helpful for our prototype implementation of active rules and rule patterns. There were three main reasons why we didn’t: (1) The focus was not on GemStone, not even on TriGS (our own prototype implementation of active rules), but on the principles, which we consider applicable to any AOODBMS; (2) The use of Smalltalk seemed too natural—rather than unfashionable—to us to require special highlighting; and (3) We had to squeeze the length of the article and the number of references to the prescribed limits.
Don’t Forget Existing Customers
I believe Fayad et al. "Thinking Objectively," Apr. 2001, p. 105) missed the single greatest development process challenges that new product development teams must face if they are successful: maintenance of existing customers.
The techniques described in the column all center around the various excellent processes for handling new development. Things like XP, SCRUM, and TSP are great for organizing small groups of developers creating new products or "next versions" of an existing product. These techniques fall down when the organization must deal with the realities of supporting real customers with real bugs and/or issues with the delivered system.
Many teams believe they can address these issues by simply altering their new development processes. This approach usually fails for both process and people reasons. It is virtually impossible to create reliable and accurate schedules for the next release when developers can be randomly interrupted to address "critical" customer issues. Finding and making the necessary fixes or changes to address critical bugs can take an unknown amount of time. Just a few of them thrown at the new development team can thoroughly invalidate the carefully planned schedule of the next release. These issues are compounded by the fact that many small development teams do not have adequate support and/or testing resources to accurately simulate the customer environment.
Another common approach for addressing maintenance issues is to take a select number of developers from the original team and assign them to a maintenance team. This approach often suffers because the psychological profile of developers who gravitate toward new development projects is quite different than developers who gravitate toward maintenance or sustaining engineering projects (one way to create such a profile is the Kirton Adaptor-Innovator scale). Unless the differences are accounted for and managed by senior management, both the newly formed maintenance team and the original development team will suffer.
The best approach is to make the new development team responsible for maintenance for the first release of the product. This allows the team to learn how real customers use its system. While this is happening, management needs to carefully monitor support incidents to determine when the drag on the "new development" team is sufficiently large to justify a properly staffed maintenance organization. Included in the definition of "properly" is not just the right number of developers, but the right equipment. Next, hire experienced maintenance managers and give them the authority to staff the team they need to do the job as well as work through the needed process issues with product management, technical support, Q&A, and technical publications.
Luke Hohmann
Sunnyvale, CA
The "Character" of Software
I read with great interest Dan Burk’s article, "Copyrightable Functions and Patentable Speech" (Feb. 2001, p. 69).
As a software engineer, I am surprised about the difficulty of identifying the character of software with respect to the question of its copyrightable and patentable entities.
My impression is that this stems from the use of terminology that does not capture the hybrid character of software precisely enough.
We have to separate the two entities software consists of. The first is design, being manifested in the conceptual, abstract idea of what a set of algorithms should do and how it should do it. This entity might be subject to patent law, as it can describe a nontrivial approach to a computational problem. The question is: Should patent law adapt to the unique character of software development and research in computer science?
The second entity is the implementation chosen for a particular design. It is expressed through programming language, applied programming paradigm, and so forth. This second entity should be copyrightable in order to protect vendors from other vendors that specialize in producing clones without adding original value.
Clearly, the medium on which software is stored is beyond the scope of this discussion, as it does not affect functionality of the two entities.
Nils Jensen
Kingston upon Hull, England
Join the Discussion (0)
Become a Member or Sign In to Post a Comment