skip to main content
10.1145/2910925.2910938acmotherconferencesArticle/Chapter ViewAbstractPublication PageswccceConference Proceedingsconference-collections
research-article

Closing the Barn Door: Re-Prioritizing Safety, Security, and Reliability

Published: 06 May 2016 Publication History

Abstract

Past generations of software developers were well on the way to building a software engineering mindset/gestalt, preferring tools and techniques that concentrated on safety, security, reliability, and code re-usability. Computing education reflected these priorities and was, to a great extent organized around these themes, providing beginning software developers a basis for professional practice. In more recent times, economic and deadline pressures and the de-professionalism of practitioners have combined to drive a development agenda that retains little respect for quality considerations. As a result, we are now deep into a new and severe software crisis.
Scarcely a day passes without news of either a debilitating data or website hack, or the failure of a mega-software project. Vendors, individual developers, and possibly educators can anticipate an equally destructive flood of malpractice litigation, for the argument that they systematically and recklessly ignored known best development practice of long standing is irrefutable. Yet we continue to instruct using methods and to employ development tools we know, or ought to know, are inherently insecure, unreliable, and unsafe, and that produce software of like ilk.
The authors call for a renewed professional and educational focus on software quality, focusing on redesigned tools that enable and encourage known best practice, combined with reformed educational practices that emphasize writing human readable, safe, secure, and reliable software. Practitioners can only deploy sound management techniques, appropriate tool choice, and best practice development methodologies such as thorough planning and specification, scope management, factorization, modularity, safety, appropriate team and testing strategies, if those ideas and techniques are embedded in the curriculum from the beginning.
The authors have instantiated their ideas in the form of their highly disciplined new version of Niklaus Wirth's 1980s Modula-2 programming notation under the working moniker Modula-2 R10. They are now working on an implementation that will be released under a liberal open source license in the hope that it will assist in reforming the CS curriculum around a best practices core so as to empower would-be professionals with the intellectual and practical mindset to begin resolving the software crisis.
They acknowledge there is no single software engineering silver bullet, but assert that professional techniques can be inculcated throughout a student's four-year university tenure, and if implemented in the workplace, these can greatly reduce the likelihood of multiplied IT failures at the hands of our graduates. The authors maintain that professional excellence is a necessary mindset, a habit of self-discipline that must be intentionally embedded in all aspects of one's education, and subsequently drive all aspects of one's practice, including, but by no means limited to, the choice and use of programming tools.

References

[1]
Kowarsch, B. and Sutcliffe, R. J. 2016. Modula-2 R10 Repository. https://bitbucket.org/trijezdci/m2r10/.
[2]
Kowarsch, B. and Sutcliffe, R. J. 2016. Modula-2 R10 Information Site. http://www.modula-2.info.
[3]
Chua, A. Y. K. 2009. Exhuming IT projects from their graves: an analysis of eight failure cases and their risk factors. The Journal of Computer Information Systems. 49, 3, 31--39.
[4]
Charette, R. N. 2005. Why software fails. IEEE spectrum. http://www.rose-hulman.edu/Users/faculty/young/OldFiles/CS-Classes/csse372/201310/Readings/WhySWFails-Charette.pdf.
[5]
Purao, S. and Desouza, K. 2011. Looking for clues to failures in large-scale, public sector projects: A case study. 44th Hawaii International Conference on System Sciences (HICSS).
[6]
Goldstein, H. 2005. Who killed the virtual case file? {case management software}. Spectrum.
[7]
Ewusi-Mensah, K. 2003 Software development failures. MIT Press.
[8]
Linberg, K. R. 1999. Software developer perceptions about software project failure: a case study. Journal of Systems and Software. 49, 177--192.
[9]
Shaw, R. and Culbert, L. 2015 12 14. Major B.C. government IT projects go over budget or end up missing key features. Vancouver Sun.
[10]
Shaw, R. and Culbert, L. 2014 05 29. The B.C. government's $182-million computer system just won't work. Vancouver Sun.
[11]
Sherlock, T. 2015 09 21. Another year, another computer foulup affecting B.C. teachers. Vancouver Sun.
[12]
Sherlock, T. and Crawford, T. 2015 08 03. B.C.'s auditor general says technology used by public health system inefficient. Vancouver Sun.
[13]
Shaw, R. and Culbert, L. 2015 12 15. The province and computers: Finding out what works and why. Vancouver Sun.
[14]
Shaw, R. 2014 07 11. B.C. alone in using troubled software system to manage child welfare. Vancouver Sun.
[15]
Shaw, R. and Culbert, L. 2015 12 15. B.C. not alone in bungling computer projects. Vancouver Sun.
[16]
Verner, J., Sampson, J., and Cerpa, N. 2008. What factors lead to software project failure. Research Challenges in Information Science. RCIS 2008. Second international Conference on. 71--80.
[17]
Williams, T. C. 2011 Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure. American Management Association.
[18]
Singpurwalla, N. D. and Wilson, S. P. 1994. Software reliability modeling. International Statistical Review. 62, 3, 289--317.
[19]
Phipps, G. 1999. Comparing observed bug and productivity rates for Java and C Software. Software - Practice and Wxperience. 29, 4, 345--358.
[20]
Tiwari, V. and Pandey, R. K. 2012. Some Observations on Bug Fixing Process and Defect Density of Open Source Software. International Journal of Advanced Research in Computer Science. 3, 1.
[21]
Khomh, F., Dhaliwal, T., and Zou, Y. 2012. Do faster releases improve software quality? an empirical case study of mozilla firefox. Mining Software.
[22]
Chomal, V. S. and Saini, J. R. 2014. Significance of Software Documentation in Software Development Process. International Journal of Engineering Innovations and Research. 3.4, 410--416.
[23]
Zhi, J., Garousi-Yusifoğlu, V., Sun, B., and Garousi, G. 2015. Cost, benefits and quality of software development documentation: A systematic mapping. Journal of Systems and Software. 99, 175--198.
[24]
van Loggem, B. 2014. Software documentation: a standard for the 21 st century. ISDOC '14 International Conference on Information Systems and Design of Communication. 149--154.
[25]
Arraki, K. S. 2016. Source code management with version control software. American Astronomical Society Meeting Abstracts. http://adsabs.harvard.edu/abs/2016AAS.22712701A.
[26]
Gajda, W. 2013 Working with Well-Known Repositories. In Git Recipes, Springer.
[27]
Miriam Quick, Ella Hollowood, Christian Miles and Hampson, D. World's Biggest Data Breaches. http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/.
[28]
Gollmann, D. 2010. Computer Security. Wiley Interdisciplinary Reviews: Computational Statistics. 2, 5, 544--554. DOI=10.1002/wics.106.
[29]
Tian-yang, G., Yin-sheng, S., and You-yuan, F. 2010. Research on software security testing. World Academy of Science, Engineering and Technology. 70.
[30]
Chess, B. and Arkin, B. 2011. Software security in practice. IEEE Security & Privacy. March/April.
[31]
Nunes, F. J. B. and Belchior..., A. D. 2010. Security engineering approach to support software security. Services (SERVICES-1) 2010 6th World Congress on. 48--55.
[32]
Myers, G. J., Sandler, C., and Badgett, T. 2015 The art of software testing. Wiley.
[33]
Al-Ahmad, W., Al-Fagih, K., Khanfar, K., Abuliel, S., and Abu-Salem, H. 2009. A taxonomy of an IT project failure: Root Causes. International Management Review. 5, http://search.proquest.com/openview/367d4e172fb56040e736cd2d5b6ae55b/1?pq-origsite=gscholar.
[34]
Galorath, D. 2008. Software Project Failure Costs Billions... Better Estimation & Planning Can Help. Project Management.
[35]
France, R. and Rumpe, B. 2007. Model-driven development of complex software: A research roadmap. Future of Software Engineering.
[36]
Evans, E. 2004. Domain-driven design: tackling complexity in the heart of software. books.google.com. http://www-public.tem-tsp.eu/~gibson/Teaching/CSC7322/ReadingMaterial/Evans03.pdf.
[37]
Jennings, N. R. 2001. An agent-based approach for building complex software systems. Communications of the ACM. 44.4).
[38]
Kerzner, H. R. 2013 Project management: a systems approach to planning, scheduling, and controlling. Wiley.
[39]
Royce, W. 1998. Software project management. Pearson Education India.
[40]
Burke, R. 2013. Project management: planning and control techniques.cupa.ir.
[41]
Curtis, B. and Walz, D. 2014 The Psychology of Programming in the Large: Team and Organizational. Academic Press.
[42]
Dooley, J. 2011 Software development and professional practice. Springer.
[43]
Wirth, N. 1996. Recollections about the development of Pascal. History of programming languages---II.
[44]
Morris, R. 2009. Niklaus Wirth: Geek of the Week. http://fruttenboel.verhoeven272.nl/modula-2/data/NikGeek.pdf.
[45]
Lindsey, C. H. 1996. A history of Algol 68. History of programming languages---II.
[46]
Böszörményi, L., Gutknecht, J., and Pomberger, G. 2000. The school of Niklaus Wirth: the art of simplicity. books.google.com.
[47]
Wirth, N. 1982 Programming in Modula-2. Springer-Verlag.
[48]
Wirth, N. 1983 Programming in Modula-2. Springer-Verlag.
[49]
Wirth, N. 1985 Programming in Modula-2. Springer-Verlag.
[50]
Wirth, N. 1988 Programming in Modula-2. Springer-Verlag.
[51]
Andrews, D. J., Cornelius, B.J., Henry, R.B., Sutcliffe, R.J., Ward, D.P., Woodman, M. 1994 Information technology -- Programming Languages -- Modula-2 International Standard (ISO/IEC 10514-1). ISO.
[52]
Sutcliffe, R. J. 1997 Information technology -- Programming Languages -- Generic Modula-2 (ISO/IEC 10514-2). ISO/IEC.
[53]
Henne, E., Wiedemann, A., Woodman, M., Lancaster, J. 1996 Information technology -- Programming Languages -- Standard Object Oriented Modula-2 (ISO/IEC 10514-3). ISO/IEC.
[54]
Sutcliffe, R. J. 1987 Introduction to programming using Modula-2. Merrill.
[55]
Eisenbach, S. and Sadler, C. 1989 Program design with Modula-2. Addison-Wesley.
[56]
Gabrini, P. J. and Kurtz, B. L. 1997 Data structures and algorithms with Modula-2. Jones and Bartlett Publishers.
[57]
Helman, P. and Veroff, R. 1988 Walls and Mirrors: Intermediate Problem Solving and Data Structures. Benjamin/Cummings Pub. Co.
[58]
Sincovec, R. and Wiener, R. 1986 Data structures using Modula--2. Wiley.
[59]
Sutcliffe, R. J. 2005. Modula-2: Abstractions for Data and Programming Structures (Using ISO-Standard Modula-2). http://www.arjay.bc.ca/Modula-2/Text/index.html.
[60]
Pronk, C. and Sutcliffe, R. J. 1997. Scalable Modules in Modula-2. Modular Programming Languages.
[61]
Pronk, C. S., R. March 19-21, 1997. Scalable Modules in Generic Modula-2. Joint Modular Languages Conference at Johannes Kepler University, Linz, Austria. Lecture Notes Series in Computer Science #1204.
[62]
Pronk, C. and Schönhacker, M. S., Richard J. & Wiedemann, Albert Nov 1997. Standardized Extensions to Modula-2. SIGPLAN Notices.
[63]
Pronk, C., Schönhacker, M., and Sutcliffe, R. J. W., Albert Oct 2000. Extensions to the language Modula-2. Journal of Object Oriented Programming.
[64]
Brooks, F. P. 1978. The Mythical Man-Month: Essays on Software. 1st ed. Addison-Wesley Longman.
[65]
Tanenbaum, A. 2009 Modern operating systems. Pearson Education International.

Recommendations

Reviews

Haim I. Kilov

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. Online Computing Reviews Service

Access critical reviews of Computing literature here

Become a reviewer for Computing Reviews.

Comments

Information & Contributors

Information

Published In

cover image ACM Other conferences
WCCCE '16: Proceedings of the 21st Western Canadian Conference on Computing Education
May 2016
137 pages
ISBN:9781450343558
DOI:10.1145/2910925
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. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected].

In-Cooperation

Publisher

Association for Computing Machinery

New York, NY, United States

Publication History

Published: 06 May 2016

Permissions

Request permissions for this article.

Check for updates

Author Tags

  1. Education
  2. Modula-2
  3. Reliability
  4. Safety
  5. Security
  6. Software Engineering

Qualifiers

  • Research-article
  • Research
  • Refereed limited

Conference

WCCCE '16

Acceptance Rates

WCCCE '16 Paper Acceptance Rate 26 of 35 submissions, 74%;
Overall Acceptance Rate 78 of 117 submissions, 67%

Contributors

Other Metrics

Bibliometrics & Citations

Bibliometrics

Article Metrics

  • 0
    Total Citations
  • 115
    Total Downloads
  • Downloads (Last 12 months)6
  • Downloads (Last 6 weeks)0
Reflects downloads up to 13 Feb 2025

Other Metrics

Citations

View Options

Login options

View options

PDF

View or Download as a PDF file.

PDF

eReader

View online with eReader.

eReader

Figures

Tables

Media

Share

Share

Share this Publication link

Share on social media