Communications of the ACM
Communications of the ACM
Forum
Robert Glass's "Practical Programmer" column (Apr. 1999, p. 17), passed over some intangibles in his discussion of software inspectionsspecifically, some of the pros and cons of scheduling group review meetings vs. individual reviews.
Though meetings incur extra overhead, they produce benefits such as inspection visibility, mentoring opportunities, and communication opportunities. Individual reviews mean less visibility, which leads to several undesirable practices, such as the inspection activities turning into a black-magic taboo kind of practice, politics having a more ambiguous area in which to hide, greater time pressure from management due to the lost visibility of inspection overhead, and inspectors glossing over reviews due to time pressures. Meetings help enhance visibility of the inspections, not only among programmers but management too. They can be a good way to encourage communication among programmers and help ensure technology transfer so that knowledge of a particular area does not reside solely in one critical resource. And finally, the most important intangible of inspection meetings: They offer and promote mentoring opportunities.
Does adding the intangibles make for a rule about which philosophy to use? Of course not. As in so many other aspects of software development, this decision depends on the context of the project. My personal experience suggests that most times the additional overhead of calling inspection meetings is well worth the dividends, especially as the size of the group grows.
Jason Steffler
Aurora, OH
I work in a product software development group. One of my tasks is to improve the way the company develops software. Glass's findings about improving code review effectiveness were very interesting; my gut reaction is they were right on target. Just from my own practical experience, the points Glass made about issues around the "current" (Fagan) way of doing code reviews are quite true.
Jane D. Bernstein
Rochester, NY
OO Programming
I enjoyed the "Thinking Objectively" column on the myth of transparent distribution by R. Guerraoui and M. Fayad ("OO Distributed Programming is Not Distributed OO Programming," Apr. 1999, p. 101). I came to the same conclusion after several years working on an OO distributed operating system in the early 1990s. I have an argument of my own to add to the discussion.
In OO programming, behavior is decomposed into independent objects. The global behaviororder of communication among the pieces, total resources used, and so forthis an emergent property of the interconnections. This makes sense in the context of Simula, the origin of OO, defined for simulation in which the global behavior is the unknown being solved by running the program.
Unfortunately, in distributed programming, the global behavior needs to be controlled tightly. Designers of distributed systems start from carefully designed message orderings and information flows, ensuring that the distributed task is completed successfully despite failure, bandwidth limitations, and latency problems. This is a terrible mismatch with OO programming, which is carefully designed global behavior splattered across independent objects, so people who read or maintain the code cannot see or manipulate it directly .
Therefore OO is the wrong programming abstraction for distributed systems, even though it is well matched to the separation of computation across multiple machines. The notion of an individual machine sending an individual message is the assembly language of distributed systems programming. As long as we stay on that level, we will make only marginal productivity and reliability improvements over simple message-passing programming environments. Instead, we need programming abstractions that more directly match the mental structures used by the designers of distributed systems and which are automatically compiled down to the lowest level of machines and messages.
I hope some of the fundamental abstractions extracted and classified for distributed systems in a future column will move in this direction.
John Chapin
Cambridge, MA
Licensing a Unique Field
Kudos to Donald Bagert for an excellent overview of the efforts to license software engineers ("Taking the Lead in Licensing Software Engineers," Apr. 1999, p. 27). Although I've personally procrastinated on professional certification, I wholeheartedly endorse establishing SE certification. I am an electrical engineer who's spent most of the past 11 years in software and system engineering. I've worked with computer scientists who applied exactly the same engineering principles I learned in my curriculum. However, I object to Bagert's assertion that SE developed out of CS alone. SE is a unique field in which two disciplines have merged synergistically. The academic world may still carry the distinction; the working world of software development is based on a melding of both CS and EE knowledge, skill, and ability. SE professionalization must recognize and embrace this unique partnership.
David M. Rockwell
Alexandria, VA
John Ebert ("Forum," Apr. 1999, p. 13) needs to RTFM (that's "Read the Funny Manual") on how to use a search engine.
It's true that if one simply searches for "discipline software engineering" with any of the major search engines, a lot of hits having to do with bondage and domination turn up. Searching "discipline" + "software engineering" would yield far better results, since the phrase "software engineering" is used as part of the search criteria. Using a search tool improperly is not the fault of the tool, but of the person misusing it.
It must be realized that people using a commercially available filter program are buying the publisher's politics. Unless users can controlsite by site and page by pagewhat is blocked, they are completely under the filter program's control as to what is and isn't "appropriate."
I too would like to see the Net used for better things than the faster distribution of smut and hate, but the lack of a clear legal definition of "offensive material" and the worldwide scope of the Internet make any regulation problematic. "Consensual anarchy" may be hard to take, but I prefer it to having the Taliban say what I may and may not see.
Kenneth Bell
Cucamonga, CA
©1999 ACM 0002-0782/99/0600 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 1999 ACM, Inc.
No entries found