Software Engineering Is Engineering

I was confounded by the conclusion of Michael Davis’s Viewpoint "Will Software Engineering Ever Be Engineering?" (Nov. 2011), mainly because anything I can do in code I can also do in digital hardware, analog hardware, fluidics, even gears and motors. One could say "Maintenance is a nightmare," but there is ample proof that software maintenance can also be a nightmare with even modest code. By drawing attention to "[m]oderate the interests of the software engineer, the employer, the client, and the users for the public good," Davis exposed an unfortunate turn of phrase that is easily misconstrued. However, the following from the ACM’s own "Software Engineering Code of Ethics and Professional Practice" (version 5.2 http://www.acm.org/about/se-code) states the principle clearly: "Software engineers shall act consistent with the public interest," which also maps well to the National Society of Professional Engineers’ "Code of Ethics for Engineers" (http://www.nspe.org/Ethics/CodeofEthics/index.html): "Hold paramount the safety, health, and welfare of the public."

Software engineering is not computer programming. Programming is a constructive activity, like soldering, riveting, and pouring concrete, where excellence requires special knowledge, skill, and ability. The fact that many engineers strive to be competent technicians should not confuse the issue; engineering work and technical work are simply different types of work, often done by the same person.

The overarching engineering paradigm—systems engineering—recruits specialty engineering disciplines, including hardware (such as electrical and mechanical), software (such as applications and embedded), and human factors (such as micro-ergonomics and macro-ergonomics). All are used, knowingly or unknowingly, in the formulation and translation of engineering requirements (design inputs) into engineering specifications (design outputs), enabling construction of systems with utilitarian and/or aesthetic value. Ideally, systems engineering occurs in a structured, systematic manner with incremental verifications and the physical realization validated against the original requirements. Haphazard design and construction may be "engineering" but is indeed unprofessional and provides no rational means for ensuring the protection of the public’s safety, health, and welfare.

It may be reasonable to say developing banking and retail software systems do not require training in advanced mathematics, physics, chemistry, biology, or even social science; the same cannot be said of software systems for nuclear weapons, transportation systems, or medical devices. Designing and programming banking and retail software is, perhaps, more like bookkeeping and accounting practices and thus justifies being taught in business school. Software may be designed by engineers or by accountants, but only the former should be deemed software engineering.

The software development I have been involved in for 50 years has always required my engineering training and experience. My basic training was electrical engineering, not computer science, so, perhaps, my projects are somewhat skewed in this direction.

GM Samaras, Pueblo, CO

Back to Top

Author’s Response:

Samaras responded to my quotation of Rule 1.2 of the "Software Engineering Code of Ethics" ("moderate") with a quotation from Principle 1 from the same code ("consistent with the public interest"). He then claimed Principle 1 "maps well" to the paramount clause now common in engineering codes of ethics. Not so. "Hold paramount" means put above other considerations, a somewhat higher standard than "consistent with." He also ignored most of my argument, especially on differences in curriculum between engineering proper and software engineering. His focus is solely on function.

Michael Davis, Chicago, IL

Back to Top

LINQ Limits vs. Computational Reality

As a developer of information systems for more than 15 years, I can say the Language-integrated Query, or LINQ, framework component championed by Erik Meijer in "The World According to LINQ" (Oct. 2011) produces impressive abstractions but also that these abstractions hide many real problems and that projects that rely heavily on LINQ risk hitting a performance wall. The mathematical theory of monads, or computational structures in functional programming, is well established and useful, but today’s information systems are not mathematical constructs but real physical systems with real physical and fiscal constraints.

While processor speed and memory capacity are improving, the speed of light will always mean at least 60ms for a signal roundtrip between Tokyo and New York. No matter the location of the data source, it will not be inside a processor and will require significant time to perform selections, projections, and cross-applies. The danger is programmers working with abstractions make it easy to create huge computational loads with simple statements, with systems ultimately paying in terms of performance and operational costs. Needing a more general abstraction or language for extracting and evaluating large, diverse data sources is not the real problem in application programming.

I don’t deny that the variety of data processing concepts is indeed a problem but criticize LINQ’s (and Meijer’s) focus on language. Many languages and formalisms have the power to express how to get the information an application requires. I wish there were fewer of them so they could be used more easily in many different domains, without programmers having to learn and maintain so many.

LINQ is not the solution system architects have been waiting for; it just hides the most challenging problems, moving them out of sight but not out of existence. A system must still answer a request, and the fewer instructions programmers must provide to the system about what an application needs (and where to find it, along with quantities to accept and cost in terms of response time and resource consumption the application tolerates), the less the system will provide what the sender of the request has asked for.

In real systems, a response to a request is rarely only a collection of information but much more likely a set of desired behavior in time, cost, size, and quality.

Markus Kropf, Thun, Switzerland

Back to Top

Author’s Response

Abstraction means hiding unnecessary details, and most class libraries and frameworks aim to hide specific details to simplify programmers’ lives. However, if these details are in fact relevant to an application, then programmers should not use the abstraction or hope the abstraction is leaky (actually a good thing) such that they can dive under the hood in case they need to deal with lower-level concerns.

Erik Meijer, Redmond, WA

Back to Top

Reinstate Jahromi

This letter updates the Letter to the Editor "Justice for Jahromi" (Nov. 2011) where I reported Masaud Jahromi had been imprisoned in Bahrain for months, beginning last April, and not permitted access to a lawyer or formally charged as to his crime and subsequent imprisonment.

The Jahromi family, which is aware of the letter, says it greatly appreciates ACM’s support and concern.

The new information I have received is both encouraging and of grave concern. For one thing, Jahromi’s exact title has been clarified. He is a professor of telecommunication engineering and chairman of the Telecommunication Engineering Department of Ahlia University in the Kingdom of Bahrain. The encouraging news is he was released on bail September 12, 2011, though it came five months after his arrest. On August 24, he was finally informed of the single charge against him: "participation in an unauthorized rally." The concern is that, following the arrest, false rumors were circulated that destroyed his social and academic prestige at Ahlia University and led to his suspension from his positions there. His lawyer says there is no official order to suspend Jahromi, and he has the right to be back on duty until the day the court issues its verdict. However, the university has apparently rejected Jahromi’s request.

The family is apprehensive about Jahromi’s status and understands it depends on the final verdict and that in the interim it is likely to have no income. That status is likewise likely to remain precarious. Since his release, three court sessions have been held, with all subsequently adjourned to later dates. He is now banned from leaving Bahrain, with the next trial session scheduled for December 22. He has been notified that court appearance will be the final pleading session and the judge will appoint a later date to announce the verdict.

Jahromi’s arrest for exercising his right of free speech and subsequent lack of due process, including denial of access to a lawyer, is in violation of the International Covenant on Civil and Political Rights, to which Bahrain has acceded.

Jahromi appears to have committed no crime and should be presumed innocent until proven otherwise. We all have a stake in maintaining academic freedoms, including of expression, at institutions of higher learning worldwide. I urge us all to write to the president of Ahlia University to reconsider the decision to suspend Jahromi from his positions and reinstate him at once, pending the court’s final decision:

Professor Abdullah Y. Al-Hawaj
President Ahlia University
P.O. Box 10878
First Floor, Gosi Complex,
Exhibitions Road
Manama, Kingdom of Bahrain
email: aalhawaj@ahliauniversity.edu.bh
fax: +973 17 290083

Jack Minker, College Park, MD

Back to Top

Correction: Bouyer Figures Found

Two in-text figures on pages 80 and 81 were inadvertently dropped from the print version of Patricia Bouyer et al.’s Review Article "Quantitative Analysis of Real-Time Systems Using Priced Timed Automata" (Sept. 2011). The complete version is now available through the ACM Digital Library (http://dl.acm.org/citation.cfm?id=1995396&CFID=67421339&CFTOKEN=67074515) and Communications Web site (http://www.cacm.acm.org).

        —Ed.

Back to Top