Communications of the ACM
Forum
Forum
Computer science students certainly need math, and the math they need should include what Peter Henderson recommended in his article "Mathematical Reasoning in Software Engineering Education" (Sept. 2003), namely, discrete math and logic. But computer scientists also need other kinds of math.
A typical set of math courses toward a CS undergraduate degree might include: discrete math, probability and statistics, linear algebra, calculus, data structures and analysis of algorithms, and theory of computation. This selection would permit students to study such subjects as computer graphics, natural language processing, robotics, machine learning, performance modeling and analysis, network analysis, circuit design, and computer vision.
Continuous math is also needed in the CS curriculum. It is healthy for our discipline that computer scientists are needed to solve problems in many application areas. To work in them one must know continuous math to be able to talk to practitioners and understand their problems. Such areas include finance, economics, environmental science, physics, and many types of engineering. Working on such important problems as modeling global climate change and weather prediction, as well as many of these other subjects, depends on continuous math.
Joseph F. Traub
New York
Peter Henderson (Sept. 2003) made many valid points, but his definition of software engineering (SE) is too limited and close to that of computer science (CS). To learn what is important to a software professional, we should look at the 2000 study by Timothy C. Lethbridge cited by Henderson. It found that the 25 most SE-relevant topics were basic CS topics. It also found many "soft" (programming-in-the-large) but no "hard" topics (science, mathematics, logic). The 25 least SE-relevant topics have an inverse distribution.
Discrete mathematics and logic, emphasized by Henderson, appear to be of medium relevance to SE professionals. I recommend the two topics be taught by CS/SE departments themselves and include semi-formal languages like UML2 and OCL. However, logic faces severe theoretical and practical obstacles and should therefore not serve as the main foundation of SE, as Henderson seems to argue.
Reidar Conradi
Trondheim, Norway
As a longtime computer scientist with a Ph.D. in "very abstract" mathematics (category theory), I hold the opposite view of the one in the Sept. 2003 special section "Why CS Students Need Math" justifying strict requirements for mathematics and abstract thinking for CS professionals. Here's why:
How it's taught. Mathematics as it's taught in primary and secondary schools has little to do with abstraction. Mathematics teachers typically give rote homework nightly for 12 years, causing many creative young minds to be turned away from mathematics early. Like my friend's daughter's teacher, unable or unwilling to admit that a square is a special case of a rectangle, many teachers of mathematics do not themselves understand or teach abstraction. And many students who relish abstraction are turned off by rote mathematics. Moreover, abstract thinking can be fostered by, for example, reading science fiction, philosophy, and linguistics, as well as by mathematics itself.
Many ways to learn. I have met and worked with many people lacking a traditional CS background yet are exceptional practitioners. Among current and past colleagues are those who majored in music, poetry, and even Russian economic history. Any deficiencies they might have had in their knowledge of mathematics or abstract thinking were more than compensated by their strengths in other areas. We greatly impoverish our field by excluding or discouraging such people from the study of CS.
Interpersonal skills. CS is a service profession. Except for a thin layer of research icing, most CS practitioners help themselves or others do jobs with little or nothing to do with computers per se. My experience in both large companies and start-ups suggests that interpersonal skills are equally (or more) important to the practicing computer professional than the ability to abstract. Listening to customers, communicating both technical and nontechnical information, and being able to work closely with others and have fun doing it are vital skills rarely mentioned in college classes.
Brilliantly solving the wrong problem is worth little; the failed projects I have worked on were almost always brought down by an inability or unwillingness to communicate, rather than a failure to be sufficiently abstract.
Like librarians, computer professionals need to embrace their role as service profession and attract and train people with a desire to serve. Valuing communication skills and a service mentality will serve our profession better than a focus on abstraction or mathematics.
Steve Johnson
Natick, MA
I am 55 and still involved in software development. Most of what I learned as an undergraduate and graduate student 30 years ago has become obsolete many times over. What has stayed with me on the technical side has been mathematics, including probability and statistics, linear algebra, set theory and logic, analysis and topology, and computational complexity theory. If one is in for the long haul, even perhaps as a manager, then one must develop long-term skills. Today's CS students should realize they will compete against Chinese, Indians, and Russians for jobs. This is no time to cut corners.
Clinton Mah
Fairfax, VA
The Sept. 2003 special section was welcome and most interesting. However, is the lack of reference to the book series The Art of Computer Programming by Donald E. Knuth a sign of "not invented now"? These books should be to IT what apple pie and motherhood are to people in the U.S.
Frédéric Guéron
Sèvres, France
Web Development Not So Different After All
Though Web development indeed breaks software engineering rules (explored in Robert L. Glass's "Practical Programmer" column, Aug. 2003) traditional software development also breaks these rules. So how are these two development environments different from one another?
While I'm something of a fence-sitter on the issue of the objectives of Web development, Web projects do share a major characteristicmutual problem and solution domainsoften differentiating them from traditional software projects.
A key characteristic of most Web systems is that they have a fundamental effect on the nature of the business processes and business models they support. This is often because the Web system changes the nature of the interaction with external stakeholders; indeed Web systems often supplant this interface. The business environment and processes not only drive the definition of system needs but are in turn fundamentally changed by the system. In effect, the business "problem" defines the nature of the technical system "solution," while the solution itself changes the characteristics of the problem.
Though the concept of mutual problem and solution domainsand their expression as a technical solution leading to significant changes in the problem spaceis typical of almost all systems development, it is significant in most Web projects. Web systems can more directly affect the nature of the interaction between an organization and its external stakeholders, particularly in Internet and extranet development.
While most conventional IT development involves mutual dependence of problem and solution domains, the effects are either sufficiently obvious to be readily taken into account, or their scale is sufficiently constrained that they can be ignored initially and addressed when the system is implemented (often resulting in attempts at business process reengineering). As the scale of the effects increasesas in Web projectsdevelopers need to be more predictive of the effects and take them into account during initial development.
David Lowe
Sydney, Australia
For Responsible Spam, Pay As You Go
Lauren Weinstein's "Spam Wars" (Inside Risks, Aug. 2003) leaned in the direction of solving the spam issue primarily with better technology. However, there is no financial incentive today for spammers to act responsibly. Most of us pay as we go for water, electricity, heating oil, the postal system, gasoline, phone service, pay-per-view TV, and lots more. Most of us shut off the lights, use water-saving showerheads, turn down the heat a few degrees, and don a sweater to lower our monthly bills.
It is practically guaranteed that those flooding the Internet with email would be more careful selecting to whom and how often they send it if the monthly bills they receive from their SMTP utility providers were based on the past month's usage. Incorporating spammer pocketbooks into any anti-spam solution would give it significantly sharper teeth.
Bill Willcox
Groton, MA
In his "Inside Risks" column (Aug. 2003) Lauren Weinstein ignored a simple and effective deterrent to spam: the digital postage stamp. If email messages would be processed only when the sender pays a small amount (say 10 cents) 99% of spam would vanish immediately. On the other hand, the cost would be low enough for serious correspondence, including by marketing organizations armed with mailing lists. The stamp could be implemented through a 200b code. The only problem is that because implementation requires agreement among thousands of providers, it might be thwarted by antitrust actions.
Rommert J. Casimir
Tilburg, The Netherlands
No Innovation Means No Customers
The recording industry needs to focus on the kind of positive analysis of online music distribution as was offered by G. Prem Premkumar in "Alternate Distribution Strategies for Digital Music" (Sept. 2003). Management philosopher Peter Drucker said a business has two basic functions: marketing and innovation. A company not focused on gaining and retaining customers will fail, as will a company that cannot adapt to change. The management of the recording industry has shown a breathtaking lack of imagination in using the Internet to create new markets and improve efficiency. Far from innovating, it actively resists change. Far from creating a loyal customer base, it alienates its potential customers. The Internet is an amazing tool for distributing music, yet the recording industry focuses its energy on suing ordinary working people instead of exploiting this historic opportunity. The industry needs to embrace change, not fear it; its future depends on it.
Kevin Mackie
Rio de Janeiro, Brazil
Computer Allure Moves East
Andries van Dam missed the point (quoted in "News Track," Aug. 2003). The reason computing has lost its allure among U.S. college students is not that they believe the computer revolution is over. Rather, they've watched it move to Asia.
Mark Wallace
Los Angeles, CA
Author Responds:
I doubt students have considered or indeed are very aware of the movement of U.S. IT work to Asia; most professionals aren't even aware of how much software (even hardware) work has shifted to Asia, and how countries like China and India, not to mention Singapore, are investing in building up their "machinery." Occam's razor suggests the simple, albeit simplistic, explanation of the dot.bomb and its aftermath.
Andries van Dam
Providence, RI
©2003 ACM 0002-0782/03/1100 $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 © 2003 ACM, Inc.
No entries found