Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Closing the barn door: re-prioritizing safety, security, and reliability
Sutcliffe R., Kowarsch B.  WCCCE 2016 (Proceedings of the 21st Western Canadian Conference on Computing Education, Kamloops, BC, Canada,  May 6-7, 2016) Article No. 1. 2016. Type: Proceedings
Date Reviewed: Dec 13 2016

The problems discussed in this important and timely paper have been with us for decades: the terms “software engineering” and “software crisis” were coined in 1968, when for the first time “programmers’ difficulties were openly discussed in a public forum--and with unusual frankness” [1] at the NATO Software Engineering Conference. The authors demonstrate that “we are now deep into a new and severe software crisis” characterized by failed projects, software crashes resulting in lost customer confidence, thousands of bugs in products endured by the marketplace with “few or no consequences for behavior and performance that in almost any other context would be viewed as unacceptable, unethical and actionable,” poor or inadequate documentation, easily compromised systems, and so on. Further, the authors stress the need for a disciplined approach starting with clearly defined specifications and observe that quick and dirty programming, perhaps adequate “to hack together a program that occupies a screen of code,” does not scale, as well as that both professionalism in software management and appropriate choice of tools are essential for success. They emphasize that university students must, from the beginning, be taught using the best languages and best practices.

The need for simple and elegant high-level languages has been known for decades, but “fashionable” languages that do not support abstraction (and safety) are still with us. A program first and foremost has to be readable and understandable by humans, and the authors properly put readability at the head of the list of proposed solutions. They stress the requirement for language-supported safety and discuss it at length, and then present the requirements for demonstrable correctness, security, reliability, and modifiability. As the language to be used, the authors propose their modernized dialect of Wirth’s Modula-2 (with quite a few examples showing its properties), and in my opinion, their promotion of this language is justified.

The authors properly criticize some popular but clearly inadequate approaches to software development including languages “inherently lending [themselves] to writing cryptic [and unsafe] code”; specifications created “on-the-fly under the assumption that the final project can be created in chunks” without knowing how, and whether, they will work together; code that is never reviewed “for code quality and specification compliance”; and so on. Their proposals to clearly state these problems and teach how to solve them, using their dialect of Modula-2, are more than welcome. At the same time, as many of us (ought to) know, such ideas have been around for decades. The paper’s reference list of 65 items regretfully does not include [1] or other software engineering classics such as Dijkstra. I would also disagree with some of the authors’ statements regarding traditional languages: first, Algol (both 60 and 68) was not “designed by a large committee,” and second, while PL/I indeed is of rather monstrous size and complexity, it was not too difficult to extract from it a small, disciplined subset used both in teaching and in industry. Note also that such an unfashionable and arguably unpleasant language as COBOL was recently praised (of all places) in the Financial Times for “being strictly structured, modular, and, not least, having clearly readable self-documenting syntax and format,” thus avoiding the “challenging problem of code fragility where change in one part of a program has unforeseen consequences on another” [2].

To deal with the current software crisis, as Wirth observed, “programmers must become engaged crusaders against homemade complexity” [1]. This has to start early, in the classroom, and the authors propose to “teach classic professional engineering principles and tradecraft, and instill the self-discipline to apply them habitually.” Thus, I would certainly recommend the paper as an excellent step in the right direction.

Reviewer:  H. I. Kilov Review #: CR144965 (1702-0135)
1) Wirth, N. A brief history of software engineering. IEEE Annals of the History of Computing. July-Sept., (2008), 32–39.
2) Castell, S. That COBOL has lasted is no surprise. Financial Times. October 4, 2016, p. 10.
Bookmark and Share
  Reviewer Selected
Featured Reviewer
 
 
Software Engineering (D.2 )
 
 
Programming Techniques (D.1 )
 
 
The Computing Profession (K.7 )
 
Would you recommend this review?
yes
no
Other reviews under "Software Engineering": Date
Becoming agile: a grounded theory of agile transitions in practice
Hoda R., Noble J.  ICSE 2017 (Proceedings of the 39th International Conference on Software Engineering, Buenos Aires, Argentina,  May 20-28, 2017) 141-151, 2017. Type: Proceedings
Sep 7 2017
Multi-criteria code refactoring using search-based software engineering: an industrial case study
Ouni A., Kessentini M., Sahraoui H., Inoue K., Deb K.  ACM Transactions on Software Engineering and Methodology 25(3): Article No. 23, 2016. Type: Article
May 11 2017
Efficient large-scale trace checking using MapReduce
Bersani M., Bianculli D., Ghezzi C., Krstić S., San Pietro P.  ICSE 2016 (Proceedings of the 38th International Conference on Software Engineering, Austin, TX,  May 14-22, 2016) 888-898, 2016. Type: Proceedings
Feb 13 2017
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright © 2000-2017 ThinkLoud, Inc.
Terms of Use
| Privacy Policy