Forum

Achieving the kind of "flow" in the software industry Phillip G. Armour discussed in his "The Business of Software" column ("The Learning Edge," June 2006) depends on emphasizing computer science fundamentals during CS education, in addition to basic learning. The formula should be (Solid Basics + Simplicity + Outward Focus + Learning => Flow). CS educators must themselves learn to resist the temptation to teach only the latest programming languages.

Most CS education should focus on such fundamentals as algorithms that are applicable independent of the software being used. This approach will help give students a solid foundation in the field, even as technologies rise and fall.

Educators and companies must stress and constantly preach the advantages of and need for simplicity in engineering work. Too often, engineers, particularly inexperienced ones, mistake clever implementations for the correct implementation. Undocumented code only adds to time wasted. The opportunity costs of unnecessary problems resulting from needless complexity and poor source code documentation is enormous.

Meanwhile, companies must expose their computer professionals to real-world customers and product use. Too often they lack a clear idea of how paying customers actually use the products they build.

Companies must provide an environment where their computer professionals are able to monitor the pulse of the software industry. When engineers are bogged down due to complex software and poor documentation, even as they are learning new "details" of the software, they are not learning new skills. The result is a strange combination of anxiety and boredom.

With a solid CS foundation, along with simplicity as a challenge, engineers are better prepared to build quality software that’s able to meet real-world challenges in terms of other parameters (such as performance and scalability). Such an approach yields more time for learning and software professionals being more outwardly focused—helping them achieve proper flow.

Umesh Panchaksharaiah
Richmond, CA

No Room for Bias When Covering the Copyright System

I was dismayed by the pervasive political and philosophical bias in Kallol Bagchi et al.’s article "Global Software Piracy: Can Economic Factors Alone Explain the Trend?" (June 2006). Even the headline characterized unauthorized copying—a neutral term describing a phenomenon that also defines the issue of how, when, and by whom copying is authorized—as "piracy"—a highly pejorative term promoted by both the Business Software Alliance and the Software Publishers Association. The authors contrasted "individualistic nations"—a positive term in the U.S.—with "collectivist societies"—a pejorative term in the U.S.—rather than using less loaded terms (such as "competition-oriented," "cooperation-oriented," "individual-centered," or "community-centered"). The data quoted in reference [1] is from the the Business Software Alliance and the Software Publishers Association, but these figures are not trustworthy in light of these organizations’ enormous stake in the results. The article’s reference [5] concerning "corruption" is a paper by the right-wing Heritage Foundation.

Meanwhile, Bagchi et al. made no mention of open source software, even though it strongly affects common perceptions of "fair" pricing for software (at least outside the U.S.), which in turn directly affects people’s willingness to pay for authorized (high-priced) copies. Similarly, the assumption that the artificial scarcity and monopoly pricing of software created by the copyright system and its increasingly draconian punitive mechanisms (such as the U.S. Digital Millennium Copyright Act of 1998) is the most beneficial approach for the industry and/or the user was not spelled out. Nor was it challenged. (For a fascinating alternative view of copyright and creative works, see the Copy/South Dossier by the Copy South Research Group, www.copysouth.org.) I hope Communications will be more sensitive to such bias in future articles.

I am an ACM Fellow, a small software business founder and owner, and a strong supporter of and contributor to open source software. However, the views in this comment are mine alone.

L. Peter Deutsch
Menlo Park, CA

Author’s Response:

We would like to point out several inconsistencies in Deutsch’s comments:

Our data set was extracted from several standard databases used in peer-reviewed journal articles;
We used standard terms from the literature that are not necessarily pejorative (except in Deutsch’s view); and
We acknowledge that the open source software movement might play an important role in software piracy.

Kallol Bagchi
Peeter Kirs
El Paso, TX
Robert Cerveny
Boca Raton, FL

Don’t Misuse or Misteach UML

Brian Dobing’s and Jeffrey Parsons’s "How UML Is Used" (May 2006) reported the very interesting results of a well-done scientific study on UML use, given that so much of the information I’ve seen is merely anecdotal. The findings reinforced a notion I’m now fully convinced of: UML is often misused by IT, and worse, mistaught by IT professionals to their business counterparts.

For the roughly 50% of the survey’s respondents who indicated they do not use Use Cases, I wonder in what context they expect their business counterparts to understand such artifacts as Class and Sequence Diagrams. Describing a given system in terms of Use Cases, then describing their realization through Class and Sequence Diagrams written at the conceptual and specification level, is central to keeping business management and IT on the same page throughout a project. Otherwise what’s the point? The fact that so many survey respondents reported that Use Case Diagrams were not useful for programmers shows that the value of using the artifacts to tie business requirements to implementation is still lost on many users of UML.

IT professionals have a tendency to underestimate the ability of their business counterparts to grasp concepts they might deem "too technical." When a technical concept is explained poorly by, say, not using Use Cases and/or presenting Class Diagrams that jump right in at the implementation stage, there’s bound to be a disconnect, and rightly so, but that disconnect isn’t due to business professionals’ lack of comprehension skills.

I attribute some of Dobing’s and Parsons’s results concerning "reasons for not using some UML components" to what I would call "the Rational Rose effect." I’d be willing to bet that many designers learned UML by poking around in Rational Rose, rather than first looking at "UML Distilled" or "Applying UML and Patterns." (I know because I’ve done it myself.) "Learning" UML by exploring in Rational Rose is like "learning" Visual Basic by exploring Microsoft Visual Studio.

As the saying goes, this approach gives one just enough to be dangerous. This is the only conclusion I could reach, as the article said the main reason Activity Diagrams (in their more basic form essentially the same as a flowchart) are not used is that they are not well understood by analysts. More likely, the reason is that it’s a diagram not easily constructed in Rational Rose, so IT doesn’t use it—so the analysts never see it.

I agree that, as Dobing and Parsons wrote, "UML should not be considered exclusively as a language for software professionals." First, however, software professionals must learn to use it properly, especially before trying to introduce it to their business counterparts.

Edward J. Ferrara
Massapequa Park, NY

Cover to Cover

I’ve never written to Communications before, but the June 2006 issue with the special section "Hacking and Innovation" was so outstanding I had to share my feelings. I joined ACM as a student member in 1966 and except for a short hiatus have been a member ever since. June is the first issue I’ve ever read cover to cover. Absolutely first-rate writing by every author.

Frederick G. Volpicelli
Harwich, MA

Future CS Course Already Here

In his "President’s Letter" ("Computer Science Education in the 21st Century," Mar. 2006) David A. Patterson suggested creating a course that would leverage high-quality examples from open source software. I’ve been teaching just such a course for the past three years at the Athens University of Economics and Business. The lectures (see www.dmst.aueb.gr/dds/ismr/) focus on how students comprehend, evaluate, maintain, and enhance large software systems. Students’ grades are derived by assessing their contribution to an open source project they select based on their own interests. The course’s theoretical background is covered in my books Code Reading and Code Quality: The Open Source Perspective (Addison-Wesley, 2003 and 2006, respectively); all the examples I use come exclusively from large existing open source projects. Two of the software systems I use for drawing examples are the very ones Patterson mentioned in his column: BSD Unix and PostgreSQL. I also use the source code of other systems (such as the Java HSQLDB database engine, the Apache Tomcat application server, the ACE networking framework, the X Window System, ArgoUML, and Perl) to cover subjects like object-oriented programming in Java and C++, networking, language processors, and graphics.

Diomidis Spinellis
Athens, Greece

To Attract New Members, Increase ACM Scope and Mandate

I want to thank David A. Patterson for his leadership during the past two years. His dedication to ACM is appreciated by the membership, especially in light of the difficulty we all have finding time for activities other than work and family. I agree that ACM’s greatest challenge today is recruiting new members, as Patterson pointed out in his final "President’s Letter" ("Farewell Address: The Growing and Graying of ACM," June 2006). But ACM is not the only organization experiencing such difficulty. Most others—whether professional, recreational, political, or religious—report the same.

As professionals and as members of the ACM community, we each decide how to allocate the limited time we have left after fulfilling our family- and income-related obligations. Should we participate in ACM activities or in, say, our town halls, our children’s parent-teacher associations, fraternal organizations, ethnic associations, churches, or yet other professional associations? Should we pay for membership in ACM, IEEE, book clubs, or employee associations? What about the hundred or so other worthwhile options we have?

Time and financial resources are limited, and we have no other option but to limit ourselves to what we view as the one or two most important activities. In order to increase ACM membership we must acknowledge the fact that we are competing for our potential members’ time. Perhaps if ACM could meet more than just practitioner needs it would be able to attract more members. Perhaps ACM could find a way to play the role of professional, charitable, recreational, spiritual, educational, health, and social organization all at the same time.

C. Augusto Casas
Sparkill, NY