Software quotes

From Motley Bytes Wiki
Jump to: navigation, search

Contents

Agile Manifesto Signatories

Manifesto for Agile Software Development

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.”
  • Source: Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). 'Manifesto for Agile Software Development'. Agile Alliance. https://agilemanifesto.org/ Retrieved 14 June 2010.
    • © 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

F_Terry_Baker

Code Library

“The most important of these is a development support library which encourages the visibility and manageability of the product, as well as reduces clerical effort on the part of the programmers. The library is typically maintained and operated by a programming librarian who serves to control the programming assets and to provide the necessary services for both programmers and management. As a result of its use, the entire project is maintained in a centralized, up-to-date, visible form which makes its status immediately apparent to code-competent software managers and makes it possible for programmers to answer their questions directly without relying on others.”
  • Source: Baker, F. T. (1975). Software Management Through Improved Programming Technology. ACM ’75: Proceedings of the 1975 Annual Conference, 286–287. https://doi.org/10.1145/800181.810346

Robert_S_Barton

Software from the Middle

“I think at this point in the field we are almost forced to start in the middle, if we are concerned with the problem of general software construction and the organization of the machines to go with these programs.”

Friedrich_Ludwig_Bauer

Need for Software Engineering

“What we need is Software Engineering.”
  • Source: Friedrich Ludwig Bauer's words at the end of 1967 within the NATO Science Committee charged with assessing the entire field of Computer Science. First generally recorded use of the term software engineering. Bauer also used the term in 1968 in a NATO conference in Garmisch-Partenkirchen, Germany. Reported on page 119 of the book entitled Origins and Foundations of Computing. Written by Friedrich Ludwig Bauer. Published by Springer in 2010. New York, NY. ISBN: 9783642425639.

Tinkering versus Engineering

“The time has arrived to switch from home-made software to manufactured software, from tinkering to engineering.”
  • Source: Quoted in the book entitled Mechanizing Proof: Computing, Risk, and Trust by Donald Mackenzie. Published in 2001 by Massachusetts Institute of Technology. ISBN: 0262133938.

Software Engineering Too Difficult

“Software engineering is the part of computer science which is too difficult for the computer scientist.”
  • Source: [Bauer; 1972]. A paper entitled Software Engineering. Written by Friedrich Ludwig Bauer. Published 1972 in Information Processing 71: Proceedings of Ifip Congress 1971, volume 1. ISBN: 9780720420630.

Software Engineering Definition

“(Software engineering is the) establishment and use of sound engineering principles to obtain economically software that is reliable and works on real machines efficiently.”
  • Source: [Bauer; 1972]. A paper entitled Software Engineering. Written by Friedrich Ludwig Bauer. Published 1972 in Information Processing 71: Proceedings of Ifip Congress 1971, volume 1. ISBN: 9780720420630.

Robert_N_Britcher

Software People Rare

“But the number of people who know how software is written is small. Most of us are not talking, or we are saying 'Trust us'.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 17.

Human Element

“The real scoop on programming and software is the human element. I didn't know Alan Turing or John von Neuman or the other inventors, but I've known plenty of programmers. We are just like everyone, part this, part that. Except we have to deal with enormous complexity, which springs upon us only after we are too far into what started out to be kind of fun - coding an algorithm and watching it run on a machine. Then it's too late and it all becomes work, very stressful work.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 28.

One Database

“I went too far. I specified too much detail. I insisted that one relational database connect every element of the software development environment. The subsystem designers and coders soon learned that this elegant solution could not work. Uniformity and commonality have their limits. ... They developed separate databases that could be queried independently. The team succeeded and I learned when to stop.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 41.

Limits of Testing

“The limits of software are never more obvious than in its testing. Software systems are beyond discrete and statistical analysis. A single incorrect state - out of two to the trillionth states - can down a rocket: To find such a fault in a software system would require a hundred generations of programmers - but after the first failure is found and fixed, all bets are off; they wouldn't be testing the same system anymore. We can design and build fail-safe systems, but can we know we did?”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 56.

Sources of Failures

“I never ran a test that didn't find at least one failure - not only is the software impure, but so are the requirements specifications. And every time we fix the software, there is a 10 percent chance - according to my anecdotal studies - we'll inject another fault. Those are the hardest to find: the faults that result from trying to get rid of them.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 56.

Errors in Tests and Simulators

“The simulator software had to be tested as thoroughly as the software it was built to test. A fault in the simulator would cause the worst kind of problem, what computer analysts call a Byzantine failure. Byzantine failures are like traitors in a family. There is always a risk this will happen.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 61.

Failures Disappointing

“... discovering a failure is disappointing, and then there is pressure from above not to find them. Everyone wants the software out the door.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 61.

Verification Percent

“Over 70 percent of the technical budget was spent on verification activities such as inspections and testing; only 30 percent was spent designing and writing code.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 117.

Size Exponential

“Of course, the effect of increasing software size is not linear, it is exponential.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 117.

Difficult Programming Shortcuts

“So developing software correctly is difficult. Developing vaccines and medications without side effects is difficult. But neither enterprise will benefit from shortcuts.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 128.

Important Development Things

“The single, most important thing is that the individual programmer needs to be given total responsibility and control of the programming, including its function... eliminate project design and review as an exhaustive and rigorous process. Most of the design and review should occur as the program is written. ... Monitor progress on the project by talking to the individual programmers as [code] is being written. ... You must trust developers on the project to create a good product. ... Sometimes there are failures. ... The important thing is to fail quickly so you have time to find another approach. ... Developers must also feel free to say what they think to their supervisor. ... Managers should be the best programmers; ...There should be no overtime pay. ... Use profit-sharing and bonuses to get awesome products. ... Developers should each get their own office. ... Eliminate the dress code. Avoid meetings at all costs. ... Writing software is a lot like writing a book. Almost anyone can write garbage; very few can write a best-seller.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 155-156.

Software Testing Completion Criteria

“Software is never completely fit. ... Testing should simply continue until all of the performance criteria have been met, including the failure rate.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 157.

Failure Discovery Rate

“A critical parameter in the development of any system is the discovery rate of software failures, especially during system testing.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 62.

Knowing Versus Doing

“We should not give up because there is no unified field theory of software engineering. The elements may not be easy to implement, but they are relatively simple, especially when compared with the study of proteins. ... The problem is not that we do not know enough. The problem is that we do not practice what we know.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 209.

Fred_Brooks

Brooks' Law

“Adding manpower to a late software project makes it later.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 2, page 25. Known as Brooks' Law.

Throw One Away

“Plan to throw one away; you will, anyhow.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 11, page 116.

Software Complexity

“Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. Much of the complexity he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform. These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 16, page 184.

Specification Hard

“Even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 16, page 195.

People Central

“The central question of how to improve the software art centers, as it always has, on people.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 16, page 202.

Productivity Magnitude

“Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 16, page 202.

Great Designers

“A little retrospection shows that although many fine, useful software systems have been designed by committees and built by multipart projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 16, page 202.

Grow Not Build Software

“Grow, not build software... The building metaphor has outlived its usefulness.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 16, page 200.

Programmer Poetry

“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 1, page 7.

Child Bearing Task Law

“The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 2, page 17.

Tables versus Flowcharts

“Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 9, page 102.

Rapid Prototyping

“Today the software engineering discipline is much more sophisticated. We recognize that rapid prototyping is an essential tool for formulating precise requirements. Not only is the design process iterative; the design-goal-setting process is itself iterative.”
  • Source: Brooks Jr., F. P. (2010). The Design of Design. Upper Saddle River, NJ: Addison-Wesley. ISBN: 978-0-201-36298-5. Chapter 3, page 23.

Rational Model

“Perhaps the most devastating critique of the Rational Model, although perhaps the hardest to prove, is that most experienced designers just don’t work that way.”
  • Source: Brooks Jr., F. P. (2010). The Design of Design. Upper Saddle River, NJ: Addison-Wesley. ISBN: 978-0-201-36298-5. Chapter 3, page 30.

Waterfall Model

“The Waterfall Model is wrong and harmful, we must outgrow it.”
  • Source: Brooks Jr., F. P. (2010). The Design of Design. Upper Saddle River, NJ: Addison-Wesley. ISBN: 978-0-201-36298-5. Chapter 3, page 34.

Alistair_Cockburn

Formal Development

"In the formal development of communications software, in 1987, I was given the motivation, 'The problem with software development is that there is too much ambiguity in the problem statement and in the design description. Things will go better if we get people to work with mathematical formalisms.” After some work in this area, I discovered:
Problem 1. The people on the projects were not interested in learning our system.
Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.
I shifted out of formal development, hearing my formal development colleagues saying, 'The problem lies in the training. Things will go better if we start training students in the necessary mathematics earlier, i.e., secondary school.' Based on what I have learned about people, I expect this will be a frustrated desire. It is not that I doubt certain advantages of formal development, but I do doubt our ability to coax 10**6 people to master it. The question should become, 'Under what circumstances, and with what assignment, should a formal specialist be called in?'"

Source: Cockburn, A. A. R. (1999). Characterizing people as non-linear 1st order components in software development. HaT Technical Report 1999.03, Humans and Technology, Inc.. Retrieved 2019-06-29 from https://ameyakarve.wordpress.com/2012/07/22/characterizing-people-as-non-linear-1st-order-components-in-software-development-cockburn-us/.


People First-Order Effect

"I finally concluded that there is something there, in front of us all the time, which we are not seeing: people. People’s characteristics are a first-order success driver, not a second-order one. In fact, I have reversed the order, and now consider process factors to be second-order issues."

Keywords: People_quotes Methodology_quotes Process_quotes Success_quotes Failure_quotes Conclude_quotes Front_quotes Time_quotes See_quotes Characteristic_quotes First-order_quotes Second-order_quotes Reverse_quotes Order_quotes Factor_quotes Software_quotes Development_quotes

Edward_Emil_David

Software Risks

“There are good reasons why software tasks that include novel concepts involve not only uncalculated but also uncalculable risks.”

Competitive Rush

"Computing has one property, unique I think, that seriously aggravates the uncertainties associated with software efforts. In computing, the research, development, and production phases are often telescoped into one process. In the competitive rush to make available the latest techniques, such as on-line consoles served by time-shared computers, we strive to take great forward leaps across gulfs of unknown width and depth."

Edward_Emil_David

Software Engineer Training

"The problem of how the software engineers will get their practice is precisely the same as in other fields of engineering, and is insoluble. This is recognized in industry, where one makes sure that the young engineers coming in will get the proper kind of experience in time."

Tom_DeMarco and Tim_Lister

Error Quota

"For most thinking workers, making an occasional mistake is a natural and healthy part of their work. But there can be an almost Biblical association between error on the job and sin. This is an attitude we need to take specific pains to change. Speaking to a group of software managers, we introduced a strategy for what we think of as iterative design. The idea is that some designs are intrinsically defect-prone; they ought to be rejected, not repaired. Such dead ends should be expected in the design activity. The lost effort of the dead end is a small price to pay for a clean, fresh start. To our surprise, many managers felt this would pose an impossible political problem for their own bosses: 'How can we throw away a product that our company has paid to produce?' They seemed to believe that they’d be better off salvaging the defective version even though it might cost more in the long run. Fostering an atmosphere that doesn’t allow for error simply makes people defensive. They don’t try things that may turn out badly. You encourage this defensiveness when you try to systematize the process, when you impose rigid methodologies so that staff members are not allowed to make any of the key strategic decisions lest they make them incorrectly. The average level of technology may be modestly improved by any steps you take to inhibit error. The team sociology, however, can suffer grievously. The opposite approach would be to encourage people to make some errors. You do this by asking your folks on occasion what dead-end roads they’ve been down, and by making sure they understand that 'none' is not the best answer. When people blow it, they should be congratulated — that’s part of what they’re being paid for."
  • Source: Book: Entitled: Peopleware: Productive Projects and Teams. Edition: 3rd. Written by: Tom DeMarco; Tim Lister. Date published: 1987; 1999; 2013. Publisher: Addison-Wesley. Country: USA; GBR; CAN; DEU; FRA; ESP; ZAF; AUS; JPN; SGP; MEX. Language: en. ISBN: ISBN-13: 978-0-321-93411-6 (alk paper); 0-321-93411-3 (alk paper). Chapter: 2 (Make a Cheeseburger, Sell a Cheeseburger).

Edsger_Wybe_Dijkstra

Effective Reasoning

“The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.”

Software Crisis

“The turning point was the Conference on Software Engineering in Garmisch, October 1968, a conference that created a sensation as there occurred the first open admission of the software crisis.”

David_Epstein

Researcher Freedom

“The problem of researcher freedom leading to false conclusions is now known to be pervasive in science. The age of big data and big-database software makes it easier than ever to mix and match statistics in pursuit of positive results that are likely just artifacts of chance.”
  • Source: David Epstein in the book “Inside the Box: How Constraints Make Us Better”. Published 2026 by Riverhead Books. Page 38. ISBN 978-0593715734 (Ebook).

Forbes_Tech_Council

Business Requirements

“One of the reasons software projects fail is the lack of understanding of the business’ needs... Assigning a seasoned business leader to the project team is essential for success.”

Customer Needs

“Sometimes software projects begin with a great idea... only for developers to discover that the problem they solved wasn’t actually the problem their customer needed to be solved.”

Martin_Fowler

Software Limitations

“Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. ‘We have met the enemy, and he is us.’”
  • Source: Article/Author: Martin Fowler; Publication/Date: 2003; Article/Title: “Who Needs an Architect?”; Publication: IEEE Software; Volume: 20; Number: 5; Pages: 11-13; Online: http://doi.org/10.1109/MS.2003.1231144. Retrieval/Date: 2020.

Tony_Hoare

Software Design

“…there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
  • Source: Hoare, C. A. R. (1981). The 1980 ACM Turing Award Lecture: The Emperor’s Old Clothes. Communications of the ACM, 24(2), 75–83.

Donald_Hoffman

The Interface

“The purpose of a desktop interface is not to show you the ‘truth’ of the computer — where ‘truth,’ in this metaphor, refers to circuits, voltages, and layers of software. Rather, the purpose of an interface is to hide the ‘truth’ and to show simple graphics that help you perform useful tasks such as crafting emails and editing photos. If you had to toggle voltages to craft an email, your friends would never hear from you. That is what evolution has done. It has endowed us with senses that hide the truth and display the simple icons we need to survive long enough to raise offspring. Space, as you perceive it when you look around, is just your desktop — a 3D desktop. Apples, snakes, and other physical objects are simply icons in your 3D desktop.”
  • Source: Donald Hoffman, writing in his book “The Case Against Reality: Why Evolution Hid the Truth from Our Eyes”. Published by W. W. Norton, New York, NY, in 2019. ISBN 978-0393254693. Preface, page 7.

Hans_Hüttel

English Ambiguous

“English has the disadvantage of being semantically ambiguous so one has to be extremely careful, as many software developers will know.”
  • Source: Written by Hans Hüttel in the journal article entitled “On Program Synthesis and Large Language Models”, in Communications of the ACM, volume 68, number 1, 2025-01. DOI:10.1145/3680410.

Capers_Jones

Quality Software

“High-quality software is not expensive. High-quality software is faster and cheaper to build and maintain than low-quality software, from initial development all the way through total cost of ownership.”
  • Source: The Economics of Software Quality by Capers Jones and Oliver Bonsignour, 2011, chapter 7.

Donald_Knuth

Software is Hard

“My main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do.”
  • Source: Donald E. Knuth in the paper entitled All Questions Answered. Published in Notices of the AMS, volume 49, number 3 (March 2002).

Kenneth_W_Kolence

Software Not Physical

“We clearly do not now have an engineering capability comparable to those based on the physical sciences. Such a capability is what is implied by the term software engineering. But software is not a physical system, it is a description of what one describes how a given physical system (a computer of some sort) should act. Thus software is more akin to engineering drawings, either maintained on paper or within a computer. ... So probably it is incorrect to assume software engineering should be considered as a sibling in the family of the physical science based engineering disciplines.”

Software Engineer

“There are people who call themselves software engineers, and who build software systems that other people trust their lives to that software. So a great deal of progress has really been made since 1962 (when I first began considering myself as a software engineer) and in that respect toward what may be considered as a valid engineering capability. ... Using the term [Software Engineering] ... actually did, for the first time, provide programmers with a more professional description of what they were trying to do. In my opinion, that was a very good thing.”

Software Engineering Body of Knowledge

‘While software engineering may be based on good principles of design activities, it is not a physical science based engineering body of knowledge. So we have to build an engineering capability based on some other body of knowledge.”

Software Development Management

“Software product development requires (but is not itself sufficient) the design of rational and correctly integrated management and technical processes.”

Michael_Sean_Mahoney

Software Crisis and Software Engineering

“Let me say a bit more about the ‘software crisis’. It emerged in the late 1960s as an increasing number of large projects experienced large cost overruns, missed deadlines and failures to meet specifications. Some had to be canceled altogether. One response was calls for a discipline of ‘software engineering’”
  • Source: Michael S. Mahoney in a paper entitled The Histories of Computing(s). Published 2005 in Interdisciplinary Science Reviews, volume 30, number 2, pages 119–135. DOI: 10.1179/030801805X25927.

Undefined Software Engineering

“If one could not define 'software engineering' at the time, neither could one point to its practice. It was not coined to characterize an ongoing activity but rather to express a desire for one.”
  • Source: Michael S. Mahoney in a paper entitled The Roots of Software Engineering. Published 1990 in CWI Quarterly, volume 3, number 4.

David_E_Nye

Programmers Perfectionists

“A single error in a program thousands of lines long prevented it from running correctly, and computer programmers became known as a fanatically exact group of perfectionists, working in an arcane specialty. Sociologists studying the ‘man-machine' interface found that a programmer's personality often changed after prolonged exposure to the computer, becoming severely logical and machine-like.”
  • Source: A book. Written by David E. Nye. Entitled 'Narratives and Spaces'. Published in 1997 by Univerity of Exeter Press, Exeter, UK. Hardback ISBN 0-85989-555-6. Paperback ISBN 0-85989-556-4. Chapter 10, page 164.

Ascher_Opler

Spot the Lemon Early

“In managing software projects the real problem is ‘spot the lemon and spot the lemon early’.”

Ipek_Ozkaya

Hello World Development

“We teach students hello world development, while we should be teaching them how to read millions of lines of code, triage and fix bugs that they have not contributed to and understand the structure and behavior of the software rather than the single class or story card they are responsible for.”
  • Source: Ipek Ozkaya, “Application of Large Language Models to Software Engineering Tasks: Opportunities, Risks, and Implications,” in IEEE Software, volume 40, number 3, pages 4-8, May-June 2023, DOI: 10.1109/MS.2023.3248401.

Next Generation Software Engineers

“With LLMs and their sister AI-driven apps assisting developers, we need to be teaching next-generation software engineers when to trust, how to create evidence to trust, how to do trust assessment rapidly and correctly, and how to improve such assistants.”
  • Source: Ipek Ozkaya, “Application of Large Language Models to Software Engineering Tasks: Opportunities, Risks, and Implications,” in IEEE Software, volume 40, number 3, pages 4-8, May-June 2023, DOI: 10.1109/MS.2023.3248401.

Data as Code

“We need to teach them [software engineers] how to evolve systems to incorporate such [AI] components, and we need to teach them to treat data as code.”
  • Source: Ipek Ozkaya, “Application of Large Language Models to Software Engineering Tasks: Opportunities, Risks, and Implications,” in IEEE Software, volume 40, number 3, pages 4-8, May-June 2023, DOI: 10.1109/MS.2023.3248401.

Alan_Perlis

Fit and Try

“Fundamentally, the procedure you mention, which is ‘fit-and-try’, will work very well with three or four people. If you have a hundred people the ‘fit-and-try’ process diverges because of lack of control.”

Iterative Simulation Design

“1. A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.
2. A simulation which matches the requirements contains the control which organizes the design of the system.
3. Through successive repetitions of this process of interlaced testing and design the model ultimately becomes the software system itself.
I think that it is the key of the approach that has been suggested, that there is no such question as testing things after the fact with simulation models, but that in effect the testing and the replacement of simulations with modules that are deeper and more detailed goes on with the simulation model controlling, as it were, the place and order in which these things are done.”

Human Communication Limits

“A man can communicate with about five colleagues on a software project without too much difficulty. Likewise he can supervise about five people and know pretty well what they are doing. One would structure 120 people in three levels, in which no man is talking to more than about eight people, both across his level and up and down”

Software Engineering Competence

“It is a fact that there are software engineers around today who are quite competent. There are systems in many places which are quite stable and which provide magnificent service. It is also the case that there are large numbers of efforts, containing large numbers of programs and programmers, which have no software engineers on them, that is that people function as though they did not know how to build software.”
  • Note: Un-indexed continuation of quote: “I have a number of questions: 1. Is it possible to have software engineers in the numbers in which we need them, without formal software engineering education? 2. Is software engineering the same as Computer Science? 3. Is software engineering best provided by baccalaureate programs in universities? Or by adult education courses? Or by two year courses following the standard grade school education? 4. Do the people educated in these programs have a growing and future role in our society? 5. Will they be useful enough in a firm or government or university, and is their value such that they can distribute their talents in other activities, or must they always remain programmers? 6. What curriculum do we have in mind for software engineers, regardless of what level we choose to educate them? 7. Is software engineering really different from what we now call systems engineering?”

Useful Software Systems

“We recognize that a practical problem of considerable difficulty and importance has arisen: The successful design, production and maintenance of useful software systems. The importance is obvious and the more so since we see only greater growth in demands and requirements in the future. The consequences of poor performance, poor design, instability and mismatching of promise and performance are not going to be limited to the computing fraternity, or even their nearest neighbors, but will affect considerable sections of our society whose ability to forgive is inversely proportional to their ignorance of the difficulties we face. The source of difficulty is distributed through the whole problem, easy to identify, and yet its cure is hard to pinpoint so that systematic improvement can be gotten.”

Neuroscience, Psychology, and Software

“The only constructive theory connecting neuroscience and psychology will arise from the study of software.”

First Software Engineering Conference

“This is the first conference ever held on software engineering and it behooves us to take this conference quite seriously since it will likely set the tone of future work in this field”

Training

“Our problems arise from demands, appetites, and our exuberant optimism. They are magnified by the unevenly trained personnel with which we work. In our deliberations we will not, I believe, be able to avoid the education problem — software engineering does not exist without software engineers.”

Douglas_T_Ross

Requirements Prespecification

“The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job.”

Franz_Selig

Specification Feedback

“External specifications at any level describe the software product in terms of the items controlled by and available to the user. The internal design describes the software product in terms of the program structures which realize the external specifications. It has to be understood that feedback between the design of the external and internal specifications is an essential part of a realistic and effective implementation process. Furthermore, this interaction must begin at the earliest stage of establishing the objectives, and continue until completion of the product.”

John_Tukey

First Use of the Term Software

“Today the ‘software’ comprising the carefully planned interpretive routines, compilers, and other aspects of automative programming are at least as important to the modern electronic calculator as its ‘hardware’ of tubes, transistors, wires, tapes and the like.”
  • Source: John Wilder Tukey. A paper entitled "The Teaching of Concrete Mathematics". The American Mathematical Monthly, volume 65, 1958. DOI: 10.2307/2310294.

Shannon_Vallor

Computer Does

“The computer did precisely what we told it to do, just not what we thought we had told it to do. Much of software engineering is simply figuring out how to close the gap between those two things.”
  • Source: From the book “The AI Mirror” by Shannon Vallor. Published 2024 by Oxford University Press. ISBN 978-0197759066. Chapter 2, page 45.