Software quotes
From Motley Bytes Wiki
Contents
- 1 Agile Manifesto Signatories
- 2 F_Terry_Baker
- 3 Robert_S_Barton
- 4 Friedrich_Ludwig_Bauer
- 5 Robert_N_Britcher
- 5.1 Software People Rare
- 5.2 Human Element
- 5.3 One Database
- 5.4 Limits of Testing
- 5.5 Sources of Failures
- 5.6 Errors in Tests and Simulators
- 5.7 Failures Disappointing
- 5.8 Verification Percent
- 5.9 Size Exponential
- 5.10 Difficult Programming Shortcuts
- 5.11 Important Development Things
- 5.12 Software Testing Completion Criteria
- 5.13 Failure Discovery Rate
- 5.14 Knowing Versus Doing
- 6 Fred_Brooks
- 6.1 Brooks' Law
- 6.2 Throw One Away
- 6.3 Software Complexity
- 6.4 Specification Hard
- 6.5 People Central
- 6.6 Productivity Magnitude
- 6.7 Great Designers
- 6.8 Grow Not Build Software
- 6.9 Programmer Poetry
- 6.10 Child Bearing Task Law
- 6.11 Tables versus Flowcharts
- 6.12 Rapid Prototyping
- 6.13 Rational Model
- 6.14 Waterfall Model
- 7 Alistair_Cockburn
- 8 Edward_Emil_David
- 9 Edward_Emil_David
- 10 Tom_DeMarco and Tim_Lister
- 11 Edsger_Wybe_Dijkstra
- 12 David_Epstein
- 13 Forbes_Tech_Council
- 14 Martin_Fowler
- 15 Tony_Hoare
- 16 Donald_Hoffman
- 17 Hans_Hüttel
- 18 Capers_Jones
- 19 Donald_Knuth
- 20 Kenneth_W_Kolence
- 21 Michael_Sean_Mahoney
- 22 David_E_Nye
- 23 Ascher_Opler
- 24 Ipek_Ozkaya
- 25 Alan_Perlis
- 26 Douglas_T_Ross
- 27 Franz_Selig
- 28 John_Tukey
- 29 Shannon_Vallor
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.
- See Also:
- Keywords: Manifesto_quotes Agile_quotes Software_quotes Development_quotes Uncover_quotes Better_quotes Do_quotes Help_quotes Work_quotes Value_quotes Individual_quotes Interaction_quotes Process_quotes Tool_quotes Comprehensive_quotes Documentation_quotes Customer_quotes Collaboration_quotes Contract_quotes Negotiate_quotes Respond_quotes Change_quotes Follow_quotes Plan_quotes
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
- Keywords: Programming_quotes Productivity_quotes Library_quotes Source_Code_quotes Important_quotes Development_quotes Support_quotes Encourage_quotes Visible_quotes Management_quotes Product_quotes Reduce_quotes Clerical_quotes Effort_quotes Part_quotes Programmer_quotes Typical_quotes Maintain_quotes Operate_quotes Librarian_quotes Serve_quotes Control_quotes Asset_quotes Provide_quotes Service_quotes Necessary_quotes Result_quotes Use_quotes Entire_quotes Project_quotes Centralize_quotes Up_to_date_quotes Form_quotes Make_quotes Status_quotes Immediate_quotes Apparent_quotes Code_quotes Competent_quotes Software_quotes Manager_quotes Possible_quotes Answer_quotes Question_quotes Direct_quotes Rely_quotes
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.”
- Source: Robert S. Barton in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 28.
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.
- Keywords: Software_Engineering_quotes Need_quotes Software_quotes Engineering_quotes
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.
- See Also:
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.
- See Also:
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.
- Keywords: Programming_quotes People_quotes Software_quotes Trust_quotes Rare_quotes Number_quotes Knowledge_quotes Writing_quotes Small_quotes Talk_quotes Say_quotes
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.
- Keywords: Programming_quotes Software_quotes Humanity_quotes Programmer_quotes Complexity_quotes Algorithm_quotes Machine_quotes Work_quotes Stress_quotes Real_quotes Scoop_quotes Element_quotes Human_quotes Turing(topic)_quotes Neuman(topic)_quotes Inventor_quotes Plenty_quotes Part_quotes Deal_quotes Enormous_quotes Spring_quotes Far_quotes Start_quotes Fun_quotes Coding_quotes Watch_quotes Run_quotes Late_quotes
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.
- Keywords: Detail_quotes Database_quotes Relational_quotes Element_quotes Software_quotes Development_quotes Design_quotes Programmer_quotes Elegant_quotes Solution_quotes Uniformity_quotes Commonality_quotes Limitation_quotes Independent_quotes Query_quotes Team_quotes Success_quotes Learning_quotes Far_quotes Specify_quotes Insist_quotes Connect_quotes Environment_quotes Subsystem_quotes Coder_quotes Work_quotes Limit_quotes Separate_quotes Stop_quotes
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.
- Keywords: Limitation_quotes Software_quotes Obvious_quotes Testing_quotes Discrete_quotes Statistics_quotes Analysis_quotes State_quotes Incorrect_quotes Correctness_quotes Error_quotes Rocket_quotes Fault_quotes System_quotes Programmer_quotes Programming_quotes Failure_quotes Correction_quotes Found_quotes Design_quotes Safe_quotes Knowledge_quotes Limit_quotes Beyond_quotes Trillion_quotes Down_quotes Find_quotes Require_quotes Generation_quotes First_quotes Fix_quotes Bet_quotes Off_quotes Fail_Safe_quotes
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.
- Keywords: Testing_quotes Failure_quotes Software_quotes Impurity_quotes Requirements_quotes Specification_quotes Repair_quotes Fix_quotes Fault_quotes Injection_quotes Hard_quotes Debugging_quotes Run_quotes Find_quotes Time_quotes Chance_quotes Anecdotal_quotes Study_quotes Result_quotes Try_quotes Rid_quotes
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.
- Keywords: Discovery_quotes Failure_quotes Pressure_quotes Software_quotes Schedule_quotes Testing_quotes Disappoint_quotes Find_quotes Door_quotes
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.
- Keywords: Software_quotes Size_quotes Linear_quotes Exponential_quotes Increasing_quotes Effect_quotes
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.
- Keywords: Importance_quotes Programmer_quotes Responsibility_quotes Control_quotes Programming_quotes Function_quotes Design_quotes Review_quotes Rigorous_quotes Heavy_quotes Methodology_quotes Monitoring_quotes Progress_quotes Project_quotes Communication_quotes Trust_quotes Development_quotes Failure_quotes Quickness_quotes Thinking_quotes Expression_quotes Overtime_quotes Management_quotes Profit_Sharing_quotes Bonus_quotes Product_quotes Excellence_quotes Office_quotes Dress_Code_quotes Meeting_quotes Software_quotes Writing_quotes Garbage_quotes Best_Seller_quotes Compensation_quotes Eliminate_quotes Occur_quotes Coding_quotes Talk_quotes Code_quotes Developer_quotes Create_quotes Good_quotes Say_quotes Think_quotes Supervisor_quotes Manager_quotes Best_quotes Awesome_quotes Book_quotes
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.
- Keywords: Software_quotes Testing_quotes Criteria_quotes Completion_quotes Failure_quotes Rate_quotes Fit_quotes Continue_quotes Performance_quotes
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.
- Keywords: Critical_quotes Parameter_quotes Development_quotes System_quotes Discovery_quotes Rate_quotes Failure_quotes Testing_quotes Software_quotes
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.
- Keywords: Persistence_quotes Unification_quotes Theory_quotes Software_Engineering_quotes Element_quotes Hard_quotes Simplicity_quotes Protein_quotes Problem_quotes Knowledge_quotes Action_quotes Practice_quotes Doing_quotes Software_quotes Engineering_quotes Easy_quotes Implement_quotes Relative_quotes Compare_quotes Study_quotes Practice_quotes
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.
- Keywords: Complexity_quotes Software_quotes Nature_quotes Deity_quotes Faith_quotes System_quotes Interface_quotes Human_Limitations_quotes Design_quotes Software_Design_quotes Einstein(topic)_quotes Repeat_quotes Argue_quotes Simplify_quotes Explanation_quotes God_quotes Capricious_quotes Arbitrary_quotes Force_quotes Rhyme_quotes Reason_quotes Human_quotes Limit_quotes Institution_quotes Conform_quotes Different_quotes Time_quotes Necessary_quotes People_quotes
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.
- Keywords: Specification_quotes Requirements_quotes Verification_quotes Debugging_quotes Project_quotes Project_Management_quotes Software_quotes Software_Management_quotes Perfect_quotes Program_quotes Establish_quotes Hard_quotes Difficult_quotes Task_quotes Management_quotes Arrive_quotes Complete_quotes Consistent_quotes Essence_quotes Build_quotes Fact_quotes Debug_quotes
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.
- Keywords: Design_quotes People_quotes Software_quotes Productivity_quotes Quality_quotes Software_Quality_quotes Project_Management_quotes Excellence_quotes Study_quotes Designer_quotes Produce_quotes Structure_quotes Fast_quotes Simple_quotes Small_quotes Clean_quotes Effort_quotes Project_quotes Management_quotes Difference_quotes Great_quotes Average_quotes Order_quotes Magnitude_quotes
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.
- Keywords: Design_quotes People_quotes Software_quotes Quality_quotes Software_Quality_quotes Project_Management_quotes Excellence_quotes Software_Management_quotes Retrospection_quotes Fine_quotes Useful_quotes System_quotes Committee_quotes Build_quotes Multipart_quotes Excited_quotes Passionate_quotes Fan_quotes Product_quotes One_quotes Few_quotes Mind_quotes Great_quotes Designer_quotes Management_quotes
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.
- Keywords: Programming_quotes Programmer_quotes Creativity_quotes Software_quotes Thinking_quotes Imagination_quotes Flexibility_quotes Poetry_quotes Poet_quotes Work_quotes Slight_quotes Remove_quotes Pure_quotes Build_quotes Castle_quotes Air_quotes Create_quotes Exertion_quotes Polish_quotes Rework_quotes Capable_quotes Realize_quotes Grand_quotes Concept_quotes Structure_quotes
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.
- Keywords: Child_Bearing_quotes Human_Resources_quotes Programming_quotes Programmer_quotes Productivity_quotes Project_Management_quotes Software_quotes Debugging_quotes Sequential_quotes Law_quotes Bearing_quotes Child_quotes Month_quotes Women_quotes Assign_quotes Management_quotes Task_quotes Characteristic_quotes Nature_quotes
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.
- Keywords: Software_Engineering_quotes Rapid_quotes Prototyping_quotes Tool_quotes Requirements_quotes Iterative_quotes Goal_quotes Design_quotes Today_quotes Software_quotes Engineering_quotes Discipline_quotes Sophisticated_quotes Recognize_quotes Essential_quotes Formulate_quotes Precise_quotes Process_quotes Set_quotes
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
- Keywords: Formality_quotes Methodology_quotes Software_quotes Development_quotes Ambiguity_quotes Design_quotes Specification_quotes Requirements_quotes Training_quotes Education_quotes Specialization_quotes Communication_quotes Motivation_quotes Problem_quotes Statement_quotes Description_quotes People_quotes Work_quotes Mathematics_quotes Learning_quotes Success_quotes Ignore_quotes Deliver_quotes Colleague_quotes Student_quotes School_quotes Frustration_quotes Desire_quotes Advantage_quotes Circumstance_quotes Assignment_quotes Master_quotes
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."
- 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/.
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.”
- Source: Edward E. David in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk
/brian.randell /NATO /index.html; http://homepages.cs.ncl.ac.uk /brian.randell /NATO /nato1968.PDF; https://dl.acm.org /citation.cfm ?id=1102020; https://books.google.com /books /about /Software_engineering.html?id=Uc9QAAAAYAAJ. Page 9.
- Keywords: Reason_quotes Software_quotes Innovation_quotes Calculation_quotes Risk_quotes Task_quotes Novel_quotes Concept_quotes Uncalculable_quotes
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."
- Source: Edward E. David in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk
/brian.randell /NATO /index.html; http://homepages.cs.ncl.ac.uk /brian.randell /NATO /nato1968.PDF; https://dl.acm.org /citation.cfm ?id=1102020; https://books.google.com /books /about /Software_engineering.html?id=Uc9QAAAAYAAJ. Page 41.
- Keywords: Software_Engineering_quotes Computer_quotes Uncertainty_quotes Effort_quotes Research_quotes Development_quotes Production_quotes Telescope_quotes Process_quotes Competition_quotes Unknown_quotes Scope_quotes Requirements_quotes Property_quotes Unique_quotes Aggravate_quotes Software_quotes Engineering_quotes Phase_quotes Technique_quotes Console_quotes Timeshare_quotes Strive_quotes Forward_quotes Leap_quotes Gulf_quotes Width_quotes Depth_quotes
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."
- Source: Edward E. David in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk
/brian.randell /NATO /index.html; http://homepages.cs.ncl.ac.uk /brian.randell /NATO /nato1968.PDF; https://dl.acm.org /citation.cfm ?id=1102020; https://books.google.com /books /about /Software_engineering.html?id=Uc9QAAAAYAAJ. Page 75.
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).
- Keywords: Thinking_quotes Worker_quotes Mistake_quotes Work_quotes Natural_quotes Biblical_quotes Error_quotes Job_quotes Sin_quotes Attitude_quotes Change_quotes Software_quotes Manager_quotes Strategy_quotes Iterative_quotes Design_quotes Defect_quotes Intrinsic_quotes Rejection_quotes Repair_quotes Dead_End_quotes Failure_quotes Fail_Early_quotes Activity_quotes Effort_quotes Cost_quotes Clean_quotes Fresh_quotes Impossibility_quotes Political_quotes Problem_quotes Environment_quotes Atmosphere_quotes Defensive_quotes Try_quotes Systematic_quotes Process_quotes Rigidity_quotes Methodology_quotes Technology_quotes Team_quotes Sociology_quotes Suffering_quotes Encouragement_quotes Congratulate_quotes
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.”
- Source: Dijkstra (2000). Answers to questions from students of Software Engineering (EWD 1305). Retrieved 2022 from http://www.cs.utexas.edu
/users /EWD /transcriptions /EWD13xx /EWD1305.html.
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.”
- Source: Dijkstra, E. W. (1972). The Humble Programmer. Communications of the ACM, 15(10). https://doi.org
/10.1145 /355604.361591
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).
- Keywords: Problem_quotes Research_quotes Freedom_quotes Lead_quotes False_quotes Conclusion_quotes Know_quotes Now_quotes Pervasive_quotes Science_quotes Age_quotes Big_quotes Data_quotes Database_quotes Software_quotes Make_quotes Easy_quotes Mix_quotes Match_quotes Statistics_quotes Pursuit_quotes Positive_quotes Result_quotes Likely_quotes Artifact_quotes Chance_quotes
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.”
- Source: From the magazine article “14 Common Reasons Software Projects Fail (And How To Avoid Them)” published 2020-03-31 by Forbes Magazine. Written by the Forbes Technology Council. Online at https://www.forbes.com
/councils /forbestechcouncil /2020/03/31 /14-common-reasons- software-projects-fail -and-how-to-avoid-them/, retrieved 2024.
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.”
- Source: From the magazine article “14 Common Reasons Software Projects Fail (And How To Avoid Them)” published 2020-03-31 by Forbes Magazine. Written by the Forbes Technology Council. Online at https://www.forbes.com
/councils /forbestechcouncil /2020/03/31 /14-common-reasons- software-projects-fail -and-how-to-avoid-them/, retrieved 2024.
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.
- Keywords: Construction_quotes Software_quotes Design_quotes Simplicity_quotes Defect_quotes Complexity_quotes Difficulty_quotes Obvious_quotes Method_quotes
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.
- Keywords: Purpose_quotes Desktop_quotes Interface_quotes Show_quotes Truth_quotes Computer_quotes Metaphor_quotes Refer_quotes Circuit_quotes Voltage_quotes Layer_quotes Software_quotes Hide_quotes Simple_quotes Graphic_quotes Perform_quotes Task_quotes Craft_quotes Email_quotes Edit_quotes Photo_quotes Toggle_quotes Friends_quotes Hear_quotes Evolution_quotes Endow_quotes Sense_quotes Display_quotes Icon_quotes Need_quotes Survive_quotes Raise_quotes Offspring_quotes Space_quotes Perception_quotes Look_quotes 3D_quotes Apple_quotes Snake_quotes Physical_quotes Object_quotes
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).
- Keywords: Conclusion_quotes Work_quotes Project_quotes Software_quotes Programming_quotes Hard_quotes
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.”
- Source: Kenneth W. Kolence; Jeffrey Yost (2003). An Interview with Kenneth W. Kolence. Charles Babbage Institute Center for the History of Information Technology. Retrieved 2018-03-27 from https://hdl.handle.net/11299/107415 or https://conservancy.umn.edu/bitstream/handle/11299/107415/oh348kk.pdf .
- See Also:
- What Is Software Design? by Jack W. Reeves. Published February 23, 2005)
- https://www.developerdotstar.com/mag/articles/reeves_design.html
- This essay first appeared in the Fall, 1992 issue of C++ Journal.
- Kenneth_W_Kolence_quotes
- Kenneth_W_Kolence_quotes/Software_Not_Physical
- What Is Software Design? by Jack W. Reeves. Published February 23, 2005)
- Keywords: Engineering_quotes Capability_quotes Compare_quotes Physical_quotes Science_quotes Software_Engineering_quotes Software_quotes System_quotes Computer_quotes Activity_quotes Drawing_quotes Paper_quotes Sibling_quotes Family_quotes Discipline_quotes Consider_quotes Maintain_quotes Incorrect_quotes
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.”
- Source: Kenneth W. Kolence; Jeffrey Yost (2003). An Interview with Kenneth W. Kolence. Charles Babbage Institute Center for the History of Information Technology. Retrieved 2018-03-27 from https://conservancy.umn.edu
/bitstream /handle /11299 /107415 /oh348kk.pdf.
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.”
- Source: Kenneth W. Kolence; Jeffrey Yost (2003). An Interview with Kenneth W. Kolence. Charles Babbage Institute Center for the History of Information Technology. Retrieved 2018-03-27 from https://conservancy.umn.edu/bitstream/handle/11299/107415/oh348kk.pdf .
Software Development Management
“Software product development requires (but is not itself sufficient) the design of rational and correctly integrated management and technical processes.”
- Source: Kenneth W. Kolence; Jeffrey Yost (2003). An Interview with Kenneth W. Kolence. Charles Babbage Institute Center for the History of Information Technology. Retrieved 2018-03-27 from https://conservancy.umn.edu/bitstream/handle/11299/107415/oh348kk.pdf .
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.
- See Also:
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.
- Keywords: Definition_quotes Software_quotes Software_Engineering_quotes Engineering_quotes Time_quotes Practice_quotes Coin_quotes Activity_quotes Desire_quotes
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.
- Keywords: Single_quotes Error_quotes Program_quotes Thousand_quotes Line_quotes Long_quotes Prevent_quotes Run_quotes Correct_quotes Computer_quotes Programmer_quotes Fanatic_quotes Exact_quotes Group_quotes Perfectionist_quotes Work_quotes Arcane_quotes Specialty_quotes Sociologist_quotes Study_quotes Man_quotes Machine_quotes Interface_quotes Find_quotes Personality_quotes Change_quotes Prolong_quotes Exposure_quotes Severe_quotes Logical_quotes Software_quotes Engineering_quotes Software_Engineering_quotes
Ascher_Opler
Spot the Lemon Early
“In managing software projects the real problem is ‘spot the lemon and spot the lemon early’.”
- Source: Ascher Opler in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 50.
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.
- Keywords: Teach_quotes Student_quotes Hello_quotes Development_quotes Read_quotes Million_quotes Line_quotes Code_quotes Triage_quotes Fix_quotes Bug_quotes Contribute_quotes Understand_quotes Structure_quotes Behavior_quotes Software_quotes Rather_quotes Single_quotes Class_quotes Story_quotes Card_quotes Responsible_quotes
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.
- Keywords: LLM_quotes Large_quotes Language_quotes Model_quotes Sister_quotes AI_quotes Artificial_quotes Intelligence_quotes App_quotes Application_quotes Assist_quotes Developer_quotes Need_quotes Teach_quotes Next_quotes Generation_quotes Software_quotes Engineer_quotes Trust_quotes Create_quotes Evidence_quotes Assessment_quotes Rapid_quotes Correct_quotes Improve_quotes Assistant_quotes
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.”
- Source: Alan Jay Perlis in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 29.
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.”
- Source: Alan Jay Perlis in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 32.
- Keywords: Software_quotes System_quotes Design_quotes Process_quotes Interlace_quotes Testing_quotes Usage_quotes Simulation_quotes Match_quotes Requirements_quotes Control_quotes Organize_quotes Repetition_quotes Iteration_quotes Model_quotes Key_quotes Approach_quotes Suggestion_quotes Question_quotes After_quotes Fact_quotes Effect_quotes Replace_quotes Module_quotes Deep_quotes Detail_quotes Order_quotes Place_quotes Do_quotes Ultimate_quotes
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”
- Source: Alan Jay Perlis in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 51.
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.”
- Source: Alan Jay Perlis in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 73.
- 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?”
- Keywords: Fact_quotes Software_Engineering_quotes Competence_quotes System_quotes Place_quotes Stable_quotes Provide_quotes Magnificent_quotes Service_quotes Effort_quotes Large_quotesProgram_quotes Programmer_quotes People_quotes Knowledge_quotes Build_quotes Software_quotes Development_quotes Engineering_quotes
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.”
- Source: Alan Jay Perlis in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 78, Keynote address.
- Keywords: Usefulness_quotes Practical_quotes Problem_quotes Difficulty_quotes Importance_quotes Arise_quotes Success_quotes Design_quotes Production_quotes Maintain_quotes Software_quotes System_quotes Obvious_quotes Great_quotes Growth_quotes Demand_quotes Requirements_quotes Consequence_quotes Poor_quotes Performance_quotes Instability_quotes Mismatch_quotes Promise_quotes Go_quotes Limitation_quotes Computing_quotes Fraternity_quotes Near_quotes Neighbor_quotes Affect_quotes Considerable_quotes Section_quotes Society_quotes Ability_quotes Forgiveness_quotes Inverse_quotes Proportion_quotes Ignorance_quotes Face_quotes Source_quotes Distributed_quotes Easy_quotes Identify_quotes Cure_quotes Hard_quotes Pinpoint_quotes Improve_quotes
Neuroscience, Psychology, and Software
“The only constructive theory connecting neuroscience and psychology will arise from the study of software.”
- Source: Perlis, A. J. (1982). Special Feature: Epigrams on programming. ACM SIGPLAN Notices, 17(9), 7–13. http://doi.org/10.1145/947955.1083808
- Keywords: Neuroscience_quotes Psychology_quotes Software_quotes Construction_quotes Connection_quotes Theory_quotes Arise_quotes Study_quotes
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”
- Source: Alan Jay Perlis in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 79, Keynote address.
- Keywords: First_quotes Conference_quotes Software_Engineering_quotes Serious_quotes Tone_quotes Future_quotes Work_quotes Field_quotes Software_quotes Engineering_quotes
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.”
- Source: Alan Jay Perlis in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 79, Keynote address.
- Keywords: Problem_quotes Arise_quotes Demand_quotes Appetite_quotes Exuberant_quotes Magnify_quotes Uneven_quotes Training_quotes Personnel_quotes Work_quotes Deliberation_quotes Belief_quotes Avoidance_quotes Education_quotes Software_Engineering_quotes Optimism_quotes Engineering_quotes Engineer_quotes Software_quotes
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.”
- Source: Douglas T. Ross in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842. See http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html ; http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF ; https://dl.acm.org/citation.cfm?id=1102020 ; https://books.google.com/books/about/Software_engineering.html?id=Uc9QAAAAYAAJ . Page 21.
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.”
- Source: F. Selig in a report entitled Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Chaired by Friedrich Ludwig Bauer. Edited by P. Naur; B. Randell. Conference held 1968-10-07 through 1968-10-11 in Garmisch, Germany. OCLC: 35337842.
- Keywords: Software_Engineering_quotes Specification_quotes Design_quotes Feedback_quotes Implementation_quotes Project_quotes Goal_quotes Objectives_quotes Software_quotes Engineering_quotes Level_quotes Product_quotes Term_quotes Item_quotes Control_quotes Available_quotes Internal_quotes Realize_quotes External_quotes Understand_quotes Essential_quotes Part_quotes Realistic_quotes Effective_quotes Process_quotes Interaction_quotes Stage_quotes Establish_quotes Completion_quotes
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.
- Keywords: Today_quotes Software_quotes Comprise_quotes Careful_quotes Plan_quotes Interpretation_quotes Routine_quotes Compilation_quotes Aspect_quotes Automation_quotes Programming_quotes Importance_quotes Modern_quotes Calculator_quotes Hardware_quotes Tube_quotes Transistor_quotes Wire_quotes Tape_quotes
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.