Software engineering is engineering
letters to the editor I was saddened by the conclusion of Michael Davis's Viewpoint " Will Software Engineering Ever Be Engineer-ing?" but the following from the ACM's own " Software Engineering Code of Ethics and Professional Practice " states the principle clearly: " Software engineers shall act consistent with the public interest".
Abstract
letters to the editor I wa s c o n f o u n d e d by the conclusion of Michael Davis's Viewpoint " Will Software Engineering Ever Be Engineer-ing? " (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 para-digm—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 un-professional 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 …