Communications of the ACM
Forum
Forum
Bruce Eckfeldt asked an important question in "What Does RFID Do for the Consumer?" (Sept. 2005) but missed an important distinction. The two examples he citedEZ-Pass and SpeedPassof systems that have won consumer acceptance are both voluntary. No one is forced to use them, and users can still pay with cash or credit card. The systems that seem to have attracted the most commercial interest (due perhaps to cost savings or administrative convenience) are typically not voluntary. If Wal-Mart or Land's End embeds RFID tags in garments without my being able to remove them or does not offer the same garments without RFID, I have no choice in the matter. Given the opportunity for abuse, it is precisely this lack of choice that sends me elsewhere when buying clothes.
Kevin Markey
Longmont, CO
What motivates such strong consumer opposition to RFID technology (Sept. 2005)? For one thing, many of us don't like being labeled "consumers," as it tends to distill out most of our existence as human beings. It is precisely our non-consumer aspects that motivate us to oppose the widespread use of RFID. I'm familiar with the technology; the badge I wear at work uses it to open security doors on a daily (sometimes hourly) basis. I accept the tracking of my movements at work as a condition of employment. The jump to facilitating round-the-clock tracking for, say, an easier warranty return process or a product purchase is astronomical.
Any assurance that the tags are used only in stores and could otherwise be disabled is laughable. The chances of my noticing an RFID reader hidden on a street corner is negligible. The confidence I might have in the related security is less than negligible. I'll continue to boycott all products with nonremovable RFID tags, hoping they become a bad memory rather than a continuing threat.
Scott Peer
Glendale, CA
Booms, Busts, and CS Enrollment
David A. Patterson's "President's Letter" ("Restoring the Popularity of Computer Science," Sept. 2005) made interesting reading here in Australia where universities have suffered even greater drops in enrollment over the past four years than the numbers he reported. For example, in the state of Queensland, from the peak year of 2001, the number of applications for IT programs through the state's central application service has dropped more than 70%. While the University of Queensland has been spared some of the more severe effects due to its strong standing, some Australian universities have undergone painful layoffs.
While it is important to relate numbers of students entering a program to industry demand, it is also important to consider the length of the pipeline. If a degree takes four years, students choosing a major based on their perception of job demand on the day they begin might graduate into a very different job market. There is a kind of hysteresis effect, as the employee-demand trend reverses. Word filters back that the field is a dud, sending students elsewhere until the resulting overcorrection leads to a new shortage.
In a system where students switch majors relatively easily, the effect is less pronounced. We have seen the worst of it in Australia because many universities have recast traditional degrees (such as a BSc with a CS major) as an IT degree (such as the BInfTech). This has meant that students once in an IT degree program tend to stay in it, making it difficult to correct for changes in demand before they graduate.
Such cycles are also predictable. A new way of packaging technology appears, resulting in a flurry of original development only to be superseded (or original development is phased out) in favor of packaged solutions, resulting in a short-term decline, until the next wave begins. The 1990s boom combined several factors, including the dot-com boom, the growth of the PC as a business platform, and the Y2K bubble. That there would have been a post-Y2K downturn is obvious; the fact that it coincided with the dot-com bust and the trend to packaged solutions only made it worse. The only really new and worrisome development is the declining interest in IT by femalestudents.
When the smaller classes start to graduate, we won't have to worry that much about attracting students back. There will be a panic in industry over a new skills crisis. The trick will be to avoid boosting student numbers at an unsustainable rate. Otherwise, the next boom will be followed by the next bust.
Philip Machanick
Brisbane, Australia
Who Needs a Certificate?
Certification for software engineers, discussed by Jeannette Nasem Morgan in "Why the Software Industry Needs a Good Ghostbuster" (Aug. 2005), doesn't guarantee the vision or imagination needed to produce a solution. Of failed projects I have known, only one was caused by a "problem" worker. No generally accepted software engineering practices (GASEP) or ISO certificate would have dodged that problem.
Micromanagement can also cause project failure. Meetings involving, say, five engineers working for two hours toward a solution implemented in 20 minutes wastes everyone's time. And management would probably not have reported such a problem to a researcher.
Feature creep represents the greatest risk for management (the classic feedback loop in the product-design cycle). Customers perceive, then demand, new (or the testing and debugging of) features. When they balk at the related costs or delays, the project can fail.
Successful engineers (more than 10 years experience) might feel certification wastes their time or is even an insult. Do they have to be certified every three years? How might someone earn a certificate of tenure as a gun-for-hire contractor? Contracting is sometimes the only way to make a living from writing software when an engineer's skills outgrow a company's needs. Does requiring a certificate suggest you are incompetent because you lack this particular piece of paper?
Certifications like those from Novell and Microsoft accomplish nothing more than produce a herd of cattle while ignoring what happened to 1970s-era IBM training programs (including for typewriter mechanics) that served IBM well but created innovation problems (Wang Laboratories was first with word processor products). Entry-level maybe, senior-level no.
Businesses don't need certified people when tools represent a cheaper alternative (as in home networking). You must know your solution domain and automate when maintenance costs soar.
Then there are delays establishing new certificate programs. Should managers ignore future tool trends and depend entirely on certified engineers? Experience counts for more than a certificate, demonstrating both direct application and problem-solving skills. Certification can't always produce the latter, because problems change with the domain.
Additional barriers to entering a job market make sense when the skill set required for jobs is relatively fixed, as with, say, accountants. The software engineering market is by nature always changing.
Jim Chorn
Portland, OR
Jeanette Nasem Morgan (Aug. 2005) is to be applauded for encouraging the industry to define GASEP. However, to imply it would "rid the world of apparitions" is to fall into a blind spothardening of the categoriescomplicating most certification systems. We don't understand the world well enough to be blindly religious to any one GASEP standard. Indeed, to the extent we understand business processes well enough to define GASEP, we can instead engineer software to solve the problem and save us from having to learn enough to define GASEP in the first place.
C.J. Fearnley
Upper Darby, PA
I understand why Jeanette Nasem Morgan (Aug. 2005) perceives the IEEE Certified Software Development Professional (CSDP) program as a step toward GASEP. CSDP is based not only on an accepted, comprehensive body of knowledge but encourages practitioners to follow the ACM's and IEEE's Code of Ethics for Software Engineering. This point deserves as much attention as the qualification itself in software engineering and should be part of any GASEP.
CSDP has a chance to become a globally accepted credential that, along with process maturity, would raise the bar for software-development organizations. Moreover, professionals in developing countries (few with software engineering education programs) might find in CSDP a professional certification that would give them the credibility they need in the increasingly global job market.
Melvin Perez
Santo Domingo,
Republica Dominicana
Author Responds:
As a past member of software engineering management and now a professor of the practices I proposed, I wrote the article because software engineers need to garner consensus as to many of their best repeatable practices. Robert L. Glass has noted in Communications that software engineering practices are constantly in flux as technology advances. But such a state does not constitute a good reason for shirking the responsibility of documenting best practices and formalizing the related education programs into generally defined and accepted practices that support the training, as well as the hiring, of qualified people in software analysis and engineering.
More than one reader expressed concern about the risk of "freezing" GASEP by defining it. However, just as the Financial Accounting Standards Board reviews and revises practices and principles for accountants, software engineers can do the same for themselves. GASEP neither hinders creativity nor blinds us to bold thinking; nor does it halt development of software engineering practices.
Likewise, certifying individual engineers is not intended to put licensing organizations into legal liability for incomplete or less-than-current testing. CSDP is not intended to make individuals legally liable for failed software projects. Companies already find themselves in court for breach of duty or failure to deliver "good software." It makes sense to certify the people who might help bring companies up to the standards of the Software Engineering Institute Capability Maturity Model Integration or of the Malcolm Baldrige National Quality Award.
Moreover, some readers were skeptical that adoption of even an evolving GASEP would limit the number of project failures due to incompetent software engineers or to poorly defined requirements. GASEP will, at a minimum, provide a set of common techniques (albeit evolving ones as practices and tools evolve) that are understood by both sides of every software engineering/business negotiation. University curricula could also draw on it to develop more practical approaches to software development and IT education.
Just as GAAP for accountants did not prevent fraud, abuse, and incompetence at Enron, MCI WorldCom, and Tyco, GASEP won't prevent incompetent software engineers demonstrating technical excellence on an exam from lacking the business acumen needed to understand requirements. If CSDP and GASEP become globally recognized credentials, and the industry keeps updating the GASEP behind CSDP, the industry will have taken an enormous step toward respectability through repeatability and structure.
Jeanette Nasem Morgan
Pittsburgh, PA
©2005 ACM 0001-0782/05/1200 $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 © 2005 ACM, Inc.
No entries found