Communications of the ACM

Communications of the ACM

Forum: What Defines a Programming Relic?

By Diane Crawford
Communications of the ACM, October 2000, Vol. 43 No. 10, Pages 11-12
10.1145/352183.352187
Comments

Glass's differentiation of art versus practice is right on the money (July 2000, p. 15). But what I see as the problem for the mature practitioner (besides the smugness of the younger ones) is not necessarily overcoming technical obsolescence but emotional obsolescence. And this is what upper management and the young practitioners sense as well. The elders of the herd don't have the energy to change, perhaps in spite of well-intentioned protestations that we will. I've noticed this time and again with my peers (age-wise). That's why I've always made it a point to be a "change agent" (I hate this term but it works)—to be at least one of the people leading the charge rather than laying back in the crowd and waiting to be one of the mercy kills.

But simply because our technical skills may be diminishing doesn't mean our usefulness to the organization has. Political persuasion and institutional memory can still make a technical professional useful to the IT organization. These are skills usually lacking in the young (except for the truly sophisticated). A smart organization keeps a few old stallions and mares around who know how to bring discipline to a place.

Michael Gardner
Sacramento, CA

I do not fully agree with Glass's view. Many of us no longer write code but that doesn't mean if we had to we couldn't. How many molecular biologists still go to the lab and pipette reagents or set up Western blots. I always believed writing code was a mechanical act that came at the end of an understanding of something we wanted to automate. Getting to this step is what experience is all about, not deciding if one should write "Index Skip" or "Index Jump."

The commercial interests in programming have had too much audience. I agree that formal specification of a problem is more valuable than coding it, because if you can explain it well then you understand it. Anybody can toss around the acronyms, but few really understand what problems they have been invented to solve. How many so-called programmers can tell you exactly how conversion of decimal to binary works mathematically?

I don't think you are a relic Bob.

Andrew Bender
Carlisle, MA

I read Glass's column with interest. I work in a large systems engineering organization where new tools and techniques are constantly being introduced (UML, XML, Java, C#, and others). In our project-oriented environment, those who do not or cannot learn these tools and techniques are less and less in demand. It has been claimed that an engineer's knowledge/skill has a half-life of five years.

My organization has a good intranet, and it is possible to get a lot of information from it, as everyone is strongly encouraged to publish and make available any nonproprietary work products that are developed. However, intranets are not specifically designed to support workers in keeping up with the state of the practice of their particular expertise(s). Glass' self-education methods (and mine) are mostly reading and attending conferences, but those who actually write code for a living need skills, not just information.

Web-based training materials have been available for some time and have proven their value. However, using them may require one to be in an "ignorant trainee" mode; something many adults are reluctant to do. In contrast, most adults are quite willing to learn something new if it helps them conduct their jobs—especially their current tasks—better. In my work environment we are exploring the possibilities of redesigning intranets as "learning environments" (such as intranets with embedded features specifically intended to support the acquisition of new skills). For example, we are piloting a URL recommender system, recommending intranet URLs to individuals based on the URLs their peers have been perusing. But there is much more we could do, such as promoting reflection in action and encouraging other techniques for developing a deeper understanding. I believe intranets hold great promise as a medium for addressing the need that Glass points out: keeping engineers up to date on the state of the practice.

Frank Linton
Burlington, MA

I very much enjoyed Glass's column. I recently answered an electronic questionnaire InformationWeek emailed to every software industry CTO. The submission was rejected because of an erroneous entry; I had reported 45 years experience in the computer industry. When I did a mouseover I was informed that the maximum value allowed in this field was 40 years. I emailed a copy of the filled but unsubmittable form to the magazine's editor in which I facetiously accused him of age bias. He quickly replied, explaining that the questionnaire was written by a group of 20-somethings at InformationWeek's ad agency; he guessed the creators did not even suspect the computer industry was more than 40 years old.

I think Glass is right on with his conclusion, but I would like to add one factor: to a technology heat-seeker like myself, the burnout factor will more likely be decreasing tolerance for organizational ambiguity and general corporate red tape, rather than the accelerating change rate of the technology itself.

Pete Patton
Saint Paul, MN

Communications contained a "Viewpoint" (Feb. 2000, p. 29) explaining the ACM Council's decision not to support the licensing of Software Engineers at this time.

As a member of the panel mentioned in the "Viewpoint," I am outraged by the authors' distortion of the position of those who disagree with the decision.

Contrary to what they write, no advocate of licensing would claim that licensing would "assure the public safety" in the sense of guaranteeing it. Licensing of drivers does not assure there will be no accidents; licensing of doctors does not assure that medical practitioners will not make mistakes. It does not even prevent malpractice. However, most of us would agree we are safer by insisting someone cannot drive a car on a public road or practice medicine without demonstrating the required knowledge and discipline. Licensing does not make us absolutely safe, but it does make us safer.

It is an old debating trick to claim that your opponents expect perfection; you can justify any conclusion by making false assumptions. I had expected an honest discussion, not a debate. I am disappointed.

I was also outraged by the authors' suggestion that the engineering regulatory authorities want to license engineers as a way to "make their money from fees." The various state and provincial authorities are not voluntary associations like the ACM. They were created by legislation with the mandate to regulate the engineering profession. I know of no legislation that exempts software engineering from regulation. In my opinion, they neglected their duty for many years; we need to welcome their belated recognition of this new engineering discipline and help them to do their job properly.

I am glad the authors expressed their opinions, but they had no right to distort the opinions of those who disagree. And they are wrong to accuse other societies of acting only for licensing fees. After all, ACM survives on membership fees.

David Parnas
Ontario, Canada

Authors' Response:
The opening sentence in "Software Engineering: An Examination of the Actions Taken by the Texas Board of Professional Engineers," dated Feb. 4, 1999, states: "The Texas Board of Professional Engineers serves to provide the public with a competent and ethical professional engineering community whose practice will safeguard the health, safety, welfare, and property of the citizens and businesses of Texas."

Is the Texas Board an advocate of licensing? Yes. Could the public interpret this as assuring public safety? Yes. Did anyone say anything about guaranteeing it? No. Parnas has misinterpreted the points we were making.

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.

---

No entries found