Gems of Software Engineering Wisdom 34 Years of IEEE Software History in 1000 Quotes
Total Page:16
File Type:pdf, Size:1020Kb
Gems of Software Engineering Wisdom 34 years of IEEE Software history in 1000 quotes Željko Obrenović This book is for sale at http://leanpub.com/se-wisdom This version was published on 2018-03-09 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. © 2018 Željko Obrenović Contents Foreword .................................. 1 1984 .................................... 2 1985 .................................... 16 1986 .................................... 32 1987 .................................... 52 1988 .................................... 78 1989 .................................... 98 1990 .................................... 117 1991 .................................... 140 1992 .................................... 160 1993 .................................... 189 1994 .................................... 214 1995 .................................... 242 1996 .................................... 275 CONTENTS 1997 .................................... 306 1998 .................................... 337 1999 .................................... 378 2000 .................................... 412 2001 .................................... 444 2002 .................................... 477 2003 .................................... 517 2004 .................................... 560 2005 .................................... 608 2006 .................................... 655 2007 .................................... 707 2008 .................................... 762 2009 .................................... 819 2010 .................................... 871 2011 .................................... 925 2012 .................................... 971 2013 ....................................1011 2014 ....................................1072 2015 ....................................1123 2016 ....................................1166 CONTENTS 2017 .................................... 1238 2018 .................................... 1253 Foreword This book contains a selection of 1000 quotes from IEEE Software1. IEEE Software is a leading software engineering magazine with a very rich his- tory. Since 1984, many of the leading software engineering professionals have contributed to IEEE Software. The content is based on the material from the IEEE Software history website2. Visit this site to find more details about IEEE Software and its history. Selected quotes are not intended to serve as a comprehensive overview of the history of software engineering. Rather, the book is designed as a “coffee table book”. It is intended for casual reading, offering interesting, educative, thought-provoking, and sometimes controversial quotes. Zeljko Obrenovic 1https://publications.computer.org/software-magazine/ 2https://obren.info/ieeesw 1984 1984 3 1984 4 “Many of the challenges facing the software industry today are a direct result of our insatiable appetite for new computer-based systems applications. Others confront us simply because we have not managed to successfully solve a large number of problems that we ourselves created many years ago.” Bruce D. Shriver, From the Editor-in-Chief, IEEE Software, January 1984.3 3DOI: 10.1109/MS.1984.233385 1984 5 “There probably isn’t a best way to build the system or even a major part of it. Much more important is to avoid choosing a terrible way and to have a clear division of responsibilities among the parts.” Butler W. Lampson, Hints for Computer System Design, IEEE Software, January 1984.4 4DOI: 10.1109/MS.1984.233391 1984 6 “Designing a computer system is very different from designing an algorithm: … the requirement - is less precisely defined more complex, and more subject to change; the system has much more internal structure - hence, many internal interfaces; and the measure of success is much less clear. The designer usually finds himself flondering in a sea of possibilities, unclear about how one choice will limit his freedom to take other choices or affect the size and performance of the entire-system.” Butler W. Lampson, Hints for Computer System Design, IEEE Software, January 1984.5 5DOI: 10.1109/MS.1984.233391 1984 7 “Booch offers a software design methodology, which he calls ‘object-oriented design’ in contrast to earlier popular methods he designates as either functional or data-oriented. In contrast to suggestions that we either identify a program’s principal function and describe it in the top box in a hierarchy chart or carefully identify the patterns of data and their flows, Booch suggests, ‘Define the problem, develop an informal strategy; formalize the strategy.’” Peter G. Anderson, Review of Grady Booch’s book ‘Software Engineering with Ada’, IEEE Software, January 1984.6 6DOI: 10.1109/MS.1984.233391 1984 8 1984 9 “One does not use structural engineering analysis to build a sandcastle. But neither does one choose the prize-winning builder of sandcastles as architect for a tower block of offices in a city.” Sir Charles Antony Richard Hoare, Programming: Sorcery or Science?, IEEE Software, April 1984.7 7DOI: 10.1109/MS.1984.234042 1984 10 “I believe that in our branch of engineering, above all others, the academic ideals of rigor and elegance will pay the highest dividends in practical terms of reducing costs, increasing performance, and in directing the great sources of computational power on the surface of a silicon chip to the use and convenience of man.” Sir Charles Antony Richard Hoare, Programming: Sorcery or Science?, IEEE Software, April 1984.8 8DOI: 10.1109/MS.1984.234042 1984 11 1984 12 “The greater speed of technical change means that capital investment must be recovered more quickly and that enhancement and evolution consume proportionately more resources than in a slowly changing technology. This contributes to the fact that maintenance and enhancement are the dominant costs in the software life cycle today.” Peter Wegner, Capital-Intensive Software Technology, IEEE Software, July 1984.9 9DOI: 10.1109/MS.1984.234384 1984 13 “Periods of rapid technological change require more innovation and greater risks than periods of stability.” Peter Wegner, Capital-Intensive Software Technology Conclusion, IEEE Software, July 1984.10 10DOI: 10.1109/MS.1984.234706 1984 14 1984 15 “An abstraction is a simplified description, or specification, of a system that emphasizes some of the system’s details or properties while suppressing others. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details that are, at least for the moment immaterial or diversionary.” Mary Shaw, Abstraction Techniques in Modern Programming Languages, IEEE Software, October 1984.11 11DOI: 10.1109/MS.1984.234384 1985 1985 17 1985 18 “The use of formal notation does not, however, preclude that of natural language. In fact, mathematical specification of a problem usually leads to a better natural-language description. This is because formal notations naturally lead the specifier to raise some questions that might have remained unasked, and thus unanswered, in an informal approach.” Bertrand Meyer, On Formalism in Specifications, IEEE Software, January 1985.12 12DOI: 10.1109/MS.1985.229776 1985 19 1985 20 “In essence, programming-in-the large involves the two complementary activities of modularization and interface control. Modularization is the identification of the major system modules and the entities those modules contain, where entities are language elements that are given names, such as subprograms, data objects, and types. Interface control is the specification and control of the interactions among entities in different modules.” Alexander L. Wolf, Lori A. Clarke, Jack C. Wileden, Ada-Based support for programming-in-the-Large, IEEE Software, March 1985.13 13DOI: 10.1109/MS.1985.230352 1985 21 “Engineers may be able to design a better interface if they take into account the control structures underlying the interface syntax.The syntactic, semantic, and protocol aspects of the interface each have their own ‘complexity.’.” T.E. Lindquist, Assessing the Usability of Human-Computer Interfaces, IEEE Software, March 1985.14 14DOI: 10.1109/MS.1985.230052 1985 22 1985 23 “The lack of a complete theoretical basis for distributed computing systems need not inhibit the development of useful systems. Even without such a basis, many technical advances have been made by individuals, who then share them with others, who in turn accept useful concepts and add further innovations.” Stephen F. Lundstrom, Duncan H. Lawrie, Experiences with Distributed Systems, IEEE Software, May 1985.15 15DOI: 10.1109/MS.1985.230692 1985 24 1985 25 “System designers should provide for such practical issues as deadlock avoidance, scheduling, necessary and sufficient primitives to allow for synchronization, and the combination of multiprogramming (a single system dividing its time and resources among many jobs) and multiprocessing (multiple processing units operating on a single job).” Joanne L. Martin, Operating Systems and Environments for Large-Scale Parallel Processors, IEEE Software, July 1985.16 16DOI: 10.1109/MS.1985.231051 1985 26 1985 27 “Program testing consists of scattered collection of rules of thumb, coverage measures, and testing philosophies.” William E. Howden, The Theory and Practice of Foundation Testing, IEEE Software, September 1985.17 17DOI: