🏗️Software Engineering: Programming (Just the Quotes)

"As soon as we started programming, we found out to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs." (Maurice Wilkes, 1949) 

"If one wants to make a machine mimic the behaviour of the human computer in some complex operation one has to ask him how it is done, and then translate the answer into the form of an instruction table. Constructing instruction tables is usually described as 'programming'." (Alan Turing, "Computing Machinery and Intelligence", Mind Vol. 59, 1950) 

"If the system exhibits a structure which can be represented by a mathematical equivalent, called a mathematical model, and if the objective can be also so quantified, then some computational method may be evolved for choosing the best schedule of actions among alternatives. Such use of mathematical models is termed mathematical programming." (George Dantzig, "Linear Programming and Extensions", 1963)

"The process of preparing programs for a digital computer is especially attractive, not only because it can economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." (Donald E Knuth, "The Art of Computer Programming: Fundamental algorithms", 1968)

"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming." (Donald E Knuth, "Computer Programming as an Art", 1968)

"Computer languages of the future will be more concerned with goals and less with procedures specified by the programmer." (Marvin Minsky, "Form and Content in Computer Science", [Turing Award lecture] 1969)

"We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better. Therefore we can be glad that people who lecture at computer conferences speak of the state of the Art." (Donald E Knuth, "The Art of Computer Programming", 1968)

"The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible." (Edsger W Dijkstra, "Notes On Structured Programming", 1970)

"But active programming consists of the design of new programs, rather than contemplation of old programs." (Niklaus Wirth, "Program Development by Stepwise Refinement", 1971)

"Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians." (Edsger W Dijkstra, "How do we tell truths that might hurt?", 1975)

"Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?" (Edsger W Dijkstra, "A Discipline of Programming", 1976) 

"Controlling complexity is the essence of computer programming." (Brian W Kernighan, Software Tools, 1976)

"Programming is the art of writing essays in crystal clear prose and making them executable." (Per B Hansen, "The architecture of concurrent programs", 1977) 

"If the advancement of the general art of programming requires the continuing invention and elaboration of paradigms, advancement of the art of the individual programmer requires that he expand his repertory of paradigms." (Robert Floyd, "The Paradigms of Programming", 1979)

"Programs must be written for people to read, and only incidentally for machines to execute. (Gerald J Sussman & Hal Abelson, "Structure and Interpretation of Computer Programs", 1979)

"When we program a computer to make choices intelligently after determining its options, examining their consequences, and deciding which is most favorable or most moral or whatever, we must program it to take an attitude towards its freedom of choice essentially isomorphic to that which a human must take to his own." (John McCarthy "Ascribing Mental Qualities to Machines", 1979)

"A language that doesn't affect the way you think about programming, is not worth knowing." (Alan Perlis, "Epigrams on Programming", 1982)

"How do we convince people that in programming simplicity and clarity - in short: what mathematicians call 'elegance' - are not a dispensable luxury, but a crucial matter that decides between success and failure?" (Edsger W Dijkstra, "'Why Is Software So Expensive?' An Explanation to the Hardware Designer", [EWD648] 1982) 

"There is one very good reason to learn programming, but it has nothing to do with preparing for high-tech careers or with making sure one is computer literate in order to avoid being cynically manipulated by the computers of the future. The real value of learning to program can only be understood if we look at learning to program as an exercise of the intellect, as a kind of modern-day Latin that we learn to sharpen our minds." (Roger Schank, "The Cognitive Computer: on language, learning, and artificial intelligence", 1984) 

"An organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only." (Bjarne Stroustrup, "The C++ Programming Language", 1985)

"[…] programming demands a significantly higher standard of accuracy. Things don’t simply have to make sense to another human being, they must make sense to a computer. (Donald E Knuth, "Theory and practice", EATCS Bulletin 27, 1985)

"The finest pieces of software are those where one individual has a complete sense of exactly how the program works. To have that, you have to really love the program and concentrate on keeping it simple, to an incredible degree." (Bill Gates , [interview], 1986)

"Programming is like pinball. The reward for doing it well is the opportunity to do it again." (Rick Cook, "The Wizardry Compiled", 1989)

"The main activity of programming is not the origination of new independent programs, but in the integration, modification, and explanation of existing ones." (Terry Winograd, "Beyond Programming Languages", 1991)

"Most programming tools and techniques focus on one aspect or a few related aspects of a system. The details of the aspect they select are shown in utmost clarity, but other details may be obscured or forgotten." (John Zachman, "Extending and Formalizing the Framework for Information Systems Architecture", 1992)

"When one considers how hard it is to write a computer program even approaching the intellectual scope of a good mathematical paper, and how much greater time and effort have to be put into it to make it 'almost' formally correct, it is preposterous to claim that mathematics as we practice it is anywhere near formally correct." (William P Thurston, "On proof and progress in mathematics", Bulletin of the AMS 30 (2), 1994)

"Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity." (David Gelernter, "Machine Beauty: Elegance And The Heart Of Technolog", 1998)

"Computer programs are complex by nature. Even if you could invent a programming language that operated exactly at the level of the problem domain, programming would be complicated because you would still need to precisely define relationships between real-world entities, identify exception cases, anticipate all possible state transitions, and so on. Strip away the accidental work involved in representing these factors in a specific programming language and in a specific computing environment, and you still have the essential difficulty of defining the underlying real-world concepts and debugging your understanding of them." (Steve C McConnell," After the Gold Rush : Creating a True Profession of Software Engineering", 1999)

"When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature." (Martin Fowler, "Refactoring: Improving the Design of Existing Code", 1999)

"Optimism is an occupational hazard of programming: feedback is the treatment." (Kent Beck, "Extreme Programming Explained", 2000) 

"Computer programming is tremendous fun. Like music, it is a skill that derives from an unknown blend of innate talent and constant practice. Like drawing, it can be shaped to a variety of ends – commercial, artistic, and pure entertainment. Programmers have a well-deserved reputation for working long hours, but are rarely credited with being driven by creative fevers. Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination, but because their imagination reveals worlds that others cannot see." (Larry O'Brien & Bruce Eckel, "Thinking in C#", 2002)

"Computer programs are the most intricate, delicately balanced and finely interwoven of all the products of human industry to date. They are machines with far more moving parts than any engine: the parts don't wear out, but they interact and rub up against one another in ways the programmers themselves cannot predict." (James Gleick, "What Just Happened: A chronicle from the information frontier", 2002)

"A programming language is for thinking of programs, not for expressing programs you've already thought of." (Paul Graham, "Hackers and Painters", 2003)

"Putting a new feature into a program is important, but refactoring so new features can be added in the future is equally important." (Ward Cunningham, "Crucible of Creativity", 2005)

"A commitment to simplicity of design means addressing the essence of design - the abstractions on which software is built - explicitly and up front. Abstractions are articulated, explained, reviewed and examined deeply, in isolation from the details of the implementation. This doesn’t imply a waterfall process, in which all design and specification precedes all coding. But developers who have experienced the benefits of this separation of concerns are reluctant to rush to code, because they know that an hour spent on designing abstractions can save days of refactoring." (Daniel Jackson, "Software Abstractions", 2006)

"[Corporate programming] is often done to the point where the individual is completely submerged in corporate 'culture' with no outlet for unique talents and skills. Corporate practices can be directly hostile to individuals with exceptional skills and initiative in technical matters. I consider such management of technical people cruel and wasteful." ( Bjarne Stroustrup, ["The Problem with Programming", MIT Technology Review, [interview] ] 2006)

"Software is built on abstractions. Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization […] Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make." (Daniel Jackson, "Software Abstractions", 2006)

"Programming is the ability to talk to the computer in a language it can understand and using grammar and syntax that it can follow to get it to perform useful tasks for you." (Adrian Kingsley-Hughes & Kathie Kingsley-Hughes, "Beginning Programming", 2007)

"We are also limited by the fact that verbalization works best when mental model manipulation is an inherent element of the task of interest. Troubleshooting, computer programming, and mathematics are good examples of tasks where mental model manipulation is central and explicit. In contrast, the vast majority of tasks do not involve explicit manipulation of task representations. Thus, our access of mental models - and the access of people doing these tasks - is limited." (William B Rouse, "People and Organizations: Explorations of Human-Centered Design", 2007)

"The cleaner and nicer the program, the faster it's going to run. And if it doesn't, it'll be easy to make it fast." (Joshua Bloch, [interview with (Peter Seibel, "Coders At Work", 2009)])

"Coding is an intellectually challenging and exhausting activity. It requires a level of concentration and focus that few other disciplines require. The reason for this is that coding requires you to juggle many competing factors at once." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Programming is a personal activity and there is no general process that is usually followed. Some programmers start with components that they understand, develop these, and then move on to less-understood components. Others take the opposite approach, leaving familiar components till last because they know how to develop them. Some developers like to define data early in the process then use this to drive the program development; others leave data unspecified for as long as possible." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos. We are confidently commanding, in precise detail, the behaviors of a machine that could otherwise do incalculable damage. And so, programming is an act of supreme arrogance." (Robert C Martin, "The Clean Coder: A code of conduct for professional programmers", 2011)

"Programming in the real world tends to happen on a large scale. The strategy is similar to what one might use to write a book or undertake any other big project: figure out what to do, starting with a broad specification that is broken into smaller and smaller pieces, then work on the pieces separately while making sure that they hang together. In programming, pieces tend to be of a size such that one person can write the precise computational steps in some programming language. Ensuring that the pieces written by different programmers work together is challenging, and failing to get this right is a major source of errors." (Brian W Kernighan, "Understanding the Digital World", 2017)

"Sadly, no substantial program works the first time; life is too complicated and programs reflect that complexity. Programming requires perfect attention to detail, something that few people can achieve. Thus all programs of any size will have errors, that is, they will do the wrong thing or produce the wrong answer under some circumstances. Those flaws are called bugs [...]" (Brian W Kernighan, "Understanding the Digital World", 2017)

"There aren’t enough programmers in the world to do the amount of programming involved in making computers do everything we want or need." (Brian W Kernighan, "Understanding the Digital World", 2017)

"Programming is the process of taking an algorithm and encoding it into a notation that the computer can execute. These notation systems are referred to as programming languages. [...] Programming is an important part of what a computer scientist does. It is through programming that we create a representation of our solution. However, the solutions that we achieve are often affected by the process and language that we choose. [...] Programming languages must then provide a way to represent both the process and the data required by the solution." (Bradley N Miller et al, "Python Programming in Context", 2019)

"Computer programming is like the ability or skill to see what Picasso saw from all the different angles at once. If it is an art, the crucial element of art is to look at things from an angle that produces new insight or at least has that potential." (Erik Naggum)

"Our industry will start to mature when it stops thinking about programming as being like something else, and when it realises that the only thing that programming is like is programming." (Nat Pryce)

"Programming: when the ideas turn into the real things." (Maciej Kaczmarek)

"To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge." (Grace Hopper)

🏗️Software Engineering: Iterative Development (Just the Quotes)

"Systems with unknown behavioral properties require the implementation of iterations which are intrinsic to the design process but which are normally hidden from view. Certainly when a solution to a well-understood problem is synthesized, weak designs are mentally rejected by a competent designer in a matter of moments. On larger or more complicated efforts, alternative designs must be explicitly and iteratively implemented. The designers perhaps out of vanity, often are at pains to hide the many versions which were abandoned and if absolute failure occurs, of course one hears nothing. Thus the topic of design iteration is rarely discussed. Perhaps we should not be surprised to see this phenomenon with software, for it is a rare author indeed who publicizes the amount of editing or the number of drafts he took to produce a manuscript." (Fernando J Corbató, "A Managerial View of the Multics System Development", 1977)

"One of the purposes of planning is we always want to work on the most valuable thing possible at any given time. We can’t pick features at random and expect them to be most valuable. We have to begin development by taking a quick look at everything that might be valuable, putting all our cards on the table. At the beginning of each iteration the business (remember the balance of power) will pick the most valuable features for the next iteration." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"It is a myth that we can get systems 'right the first time'. Instead, we should implement only today’s stories, then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility. Test-driven development, refactoring, and the clean code they produce make this work at the code level." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Agile methods universally rely on an incremental approach to software specification, development, and delivery. They are best suited to application development where the system requirements usually change rapidly during the development process. They are intended to deliver working software quickly to customers, who can then propose new and changed requirements to be included in later iterations of the system. They aim to cut down on process bureaucracy by avoiding work that has dubious long-term value and eliminating documentation that will probably never be used." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"When you write a computer program you've got to not just list things out and sort of take an algorithm and translate it into a set of instructions. But when there's a bug - and all programs have bugs - you've got to debug it. You've got to go in, change it, and then re-execute … and you iterate. And that iteration is really a very, very good approximation of learning." (Nicholas Negroponte, "A 30-year history of the future", [Ted Talk] 2014)

"Feedback is what makes it iterative; otherwise, it is just mini-waterfall. Merely splitting use cases into stories does not make for iterative development if we wait until all stories are developed before we seek feedback. The point of splitting is to get feedback faster so that it can be incorporated into ongoing development. However, seeking stakeholder/user feedback for small batches of functionality (stories) is often not feasible with formal stage-gate processes. They were conceived with linear flows of large batches in mind." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"This is what the Agile Manifesto means when it says responding to change over following a plan. To maximize adaptability, it is essential to have good, fast feedback loops. This is why there is so much emphasis on iterative development." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

🏗️Software Engineering: Inheritance (Just the Quotes)

"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships." (Grady Booch, "Object-oriented design: With Applications", 1991)

"[...] inheritance is a powerful tool for reducing complexity because a programmer can focus on the generic attributes of an object without worrying about the details. If a programmer must be constantly thinking about semantic differences in subclass implementations, then inheritance is increasing complexity rather than reducing it." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Inheritance is the idea that one class is a specialization of another class. The purpose of inheritance is to create simpler code by defining a base class that specifies common elements of two or more derived classes. The common elements can be routine interfaces, implementations, data members, or data types. Inheritance helps avoid the need to repeat code and data in multiple locations by centralizing it within a base class. When you decide to use inheritance, you have to make several decisions: For each member routine, will the routine be visible to derived classes? Will it have a default implementation? Will the default implementation be overridable? For each data member (including variables, named constants, enumerations, and so on), will the data member be visible to derived classes?" (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The underlying message of all these rules is that inheritance tends to work against the primary technical imperative you have as a programmer, which is to manage complexity. For the sake of controlling complexity, you should maintain a heavy bias against inheritance." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Programming languages on the whole are very much more complicated than they used to be: object orientation, inheritance, and other features are still not really being thought through from the point of view of a coherent and scientifically well-based discipline or a theory of correctness. My original postulate, which I have been pursuing as a scientist all my life, is that one uses the criteria of correctness as a means of converging on a decent programming language design - one which doesn’t set traps for its users, and ones in which the different components of the program correspond clearly to different components of its specification, so you can reason compositionally about it. [...] The tools, including the compiler, have to be based on some theory of what it means to write a correct program." (Charles A R Hoare, [interview] 2002)

"Few classical programmers found prototypal inheritance to be acceptable, and classically inspired syntax obscures the language’s true prototypal nature. It is the worst of both worlds." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Structural patterns describe how classes and objects can be combined to form larger structures. Patterns for classes describe how inheritance can be used to provide more useful program interfaces. Patterns for objects describe how objects can be composed into larger structures using object composition." (Junji Nakano et al, "Programming Statistical Data Visualization in the Java Language" [in "Handbook of Data Visualization"], 2008)

"Most designers think of design patterns as a way of supporting object-oriented design. Patterns often rely on object characteristics such as inheritance and polymorphism to provide generality. However, the general principle of encapsulating experience in a pattern is one that is equally applicable to all software design approaches." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

🏗️Software Engineering: Engineering (Just the Quotes)

"In fact 'engineering' now often signifies a new system of thought, a fresh method of attack upon the world’s problems the antithesis of traditionalism, with its precedents and dogmas. (Alfred D Flinn, "Leadership in Economic Progress", Civil Engineering Vol. 2 (4), 1932)

"There may be said to be two kinds of engineering, that which is essentially creative, and that which is practiced in pursuit of known methods." (William L Emmet, "The Autobiography of an Engineer", 1940)

"Science acquires knowledge but has no interest in its practical applications. The applications are the work of engineers." (Edwin P Hubble, "The Nature of Science and Other Lectures", 1954)

"Doing engineering is practicing the art of the organized forcing of technological change." (George Spencer-Brown, Electronics, Vol. 32 (47),  1959)

"Science aims at the discovery, verification, and organization of fact and information [...] engineering is fundamentally committed to the translation of scientific facts and information to concrete machines, structures, materials, processes, and the like that can be used by men." (Eric A Walker, "Engineers and/or Scientists", Journal of Engineering Education Vol. 51, 1961)

"What, then, is science according to common opinion? Science is what scientists do. Science is knowledge, a body of information about the external world. Science is the ability to predict. Science is power, it is engineering. Science explains, or gives causes and reasons." (John Bremer "What Is Science?" [in "Notes on the Nature of Science"], 1962)

"Engineering is the art of skillful approximation; the practice of gamesmanship in the highest form. In the end it is a method broad enough to tame the unknown, a means of combing disciplined judgment with intuition, courage with responsibility, and scientific competence within the practical aspects of time, of cost, and of talent. This is the exciting view of modern-day engineering that a vigorous profession can insist be the theme for education and training of its youth. It is an outlook that generates its strength and its grandeur not in the discovery of facts but in their application; not in receiving, but in giving. It is an outlook that requires many tools of science and the ability to manipulate them intelligently In the end, it is a welding of theory and practice to build an early, strong, and useful result. Except as a valuable discipline of the mind, a formal education in technology is sterile until it is applied." (Ronald B Smith, "Professional Responsibility of Engineering", Mechanical Engineering Vol. 86 (1), 1964)

"Engineering is a method and a philosophy for coping with that which is uncertain at the earliest possible moment and to the ultimate service to mankind. It is not a science struggling for a place in the sun. Engineering is extrapolation from existing knowledge rather than interpolation between known points. Because engineering is science in action - the practice of decision making at the earliest moment - it has been defined as the art of skillful approximation. No situation in engineering is simple enough to be solved precisely, and none worth evaluating is solved exactly. Never are there sufficient facts, sufficient time, or sufficient money for an exact solution, for if by chance there were, the answer would be of academic and not economic interest to society. These are the circumstances that make engineering so vital and so creative." (Ronald B Smith, "Engineering Is…", Mechanical Engineering Vol. 86 (5), 1964)

"Engineering is knowledge work. That is, although the goal of engineering may be to produce useful objects, engineers do not construct such object themselves. Rather they aim to generate knowledge that will allow such objects to be built." Dorothy A Winsor, "Writing Like an Engineer: A Rhetorical Education", 1966)

"Engineering is a profession, an art of action and synthesis and not simply a body of knowledge. Its highest calling is to invent and innovate." (Daniel V DeSimone & Hardy Cross, "Education for Innovation", 1968)

"Technological invention and innovation are the business of engineering. They are embodied in engineering change." (Daniel V DeSimone & Hardy Cross, "Education for Innovation", 1968)

"[...] it is rather more difficult to recapture directness and simplicity than to advance in the direction of ever more sophistication and complexity. Any third-rate engineer or researcher can increase complexity; but it takes a certain flair of real insight to make things simple again." (Ernst F Schumacher, "Small Is Beautiful", 1973)

"Engineering is superficial only to those who view it superficially. At the heart of engineering lies existential joy." (Samuel C Florman, "The Existential Pleasures of Engineering", 1976)

"From the point of view of modern science, design is nothing, but from the point of view of engineering, design is everything. It represents the purposive adaptation of means to reach a preconceived end, the very essence of engineering." (Edwin T Layton Jr., "American Ideologies of Science and Engineering", Technology and Culture No. 4, 1976)

"Engineering or Technology is the making of things that did not previously exist, whereas science is the discovering of things that have long existed." (David Billington, "The Tower and the Bridge: The New Art of Structural Engineering", 1983)

"As engineering becomes increasingly central to the shaping of society, it is ever more important that engineers become introspective. Rather than merely revel in our technical successes, we should intensify our efforts to explore, define, and improve the philosophical foundations of our professions." (Samuel C Florman, "The Civilized Engineer", 1985)

"[...] without imagination, heightened awareness, moral sense, and some reference to the general culture, the engineering experience becomes less meaningful, less fulfilling than it should be." (Samuel C Florman, "The Civilized Engineer", 1985)

"Science can amuse and fascinate us all, but it is engineering that changes the world." (Isaac Asimov, Isaac Asimov’s Book of Science and Nature Quotations, 1988)

"Engineering knowledge reflects the fact that design does not take place for its own sake and in isolation." (Walter G Vincenti, "What Engineers Know and How They Know It", 1990)

"All of engineering involves some creativity to cover the parts not known, and almost all of science includes some practical engineering to translate the abstractions into practice." (Richard W Hamming, "The Art of Probability for Scientists and Engineers", 1991)

"In science if you know what you are doing you should not be doing it. In engineering if you do not know what you are doing you should not be doing it. Of course, you seldom, if ever, see either pure state." (Richard W Hamming, "The Art of Probability for Scientists and Engineers", 1991)

"No matter how vigorously a 'science' of design may be pushed, the successful design of real things in a contingent world will always be based more on art than on science. Unquantifiable judgments and choices are the elements that determine the way a design comes together. Engineering design is simply that kind of process. It always has been; it always will be." (Eugene S Ferguson , "Engineering and the Mind’s Eye", 1992)

"Visual thinking is necessary in engineering. A major portion of engineering information is recorded and transmitted in a visual language that is in effect the lingua franca of engineers in the modern world. It is the language that permits ‘readers’ of technologically explicit and detailed drawings to visualise the forms, the proportions, and the interrelationships of the elements that make up the object depicted. It is the language in which designers explain to makers what they want them to construct." (Eugene S Ferguson, "Engineering and the Mind’s Eye", 1992)

"Good engineering is not a matter of creativity or centering or grounding or inspiration or lateral thinking, as useful as those might be, but of decoding the clever, even witty, messages the solution space carves on the corpses of the ideas in which you believed with all your heart, and then building the road to the next message." (Fred Hapgood, "Up the infinite Corridor: MIT and the Technical Imagination", 1993)

"Engineering is, of course, all about bridging the gulf between art and science. Engineering is often defined as the application of scientific principles to serve human needs. But it also brings creativity to bear on those scientific principles, dragging them out of pristine abstraction into the compromised universe of our frustrations and wants." (Scott Rosenberg, "Dreaming in Code", 2007)

"Over-engineering is a real disease of many engineers as they delight in design purity and ignore tradeoffs." (Alex Xu, "System Design Interview: An insider's guide", 2017)

"A boat without a captain is nothing more than a floating waiting room: unless someone grabs the rudder and starts the engine, it’s just going to drift along aimlessly with the current. A piece of software is just like that boat: if no one pilots it, you’re left with a group of engineers burning up valuable time, just sitting around waiting for something to happen (or worse, still writing code that you don’t need)." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Engineers love to solve problems and build systems. Most engineers would gladly build a system to solve just about any problem. It is the engineering manager’s job to make sure that the team is using its time wisely and building the right system." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Engineering is an art of simplification, and the rules - when and how to simplify - are a matter of experience and intuition." (Olle I Elgerd)

"Engineering is the art or science of utilizing, directing or instructing others in the utilization of the principles, forces, properties and substances of nature in the production, manufacture, construction, operation and use of things [...] or of means, methods, machines, devices and structures [...]"  (Alfred W Kiddle)

"Engineering is the conscious application of science to the problems of economic production." (Halbert P Gillette)

"Engineering is the professional and systematic application of science to the efficient utilization of natural resources to produce wealth." (T. J. Hoover & J. C. L. Fish)

"Indeed, the most important part of engineering work - and also of other scientific work - is the determination of the method of attacking the problem, whatever it may be." (Charles P Steinmetz)

"The essence of engineering consists not so much in the mere construction of the spectacular layouts or developments, but in the invention required - the analysis of the problem, the design, the solution by the mind which directs it all." (William Hood)

More quotes on" Engineering" at the-web-of-knowledge.blogspot.com. 

🏗️Software Engineering: Encapsulation (Just the Quotes)

"Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process. […] design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming. Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock," Object-Oriented Design: A responsibility-driven approach", 1989)

"Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock, "Object-oriented Design: A responsibility-driven approach", 1989)

"[...] encapsulation - also known as information hiding - prevents clients from seeing its inside view, were the behavior of the abstraction is implemented." (Grady Booch, "Object-Oriented Design With Applications", 1991)

"Encapsulation says that, not only are you allowed to take a simpler view of a complex concept, you are not allowed to look at any of the details of the complex concept. What you see is what you get - it's all you get!" (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The concept of modularity is related to information hiding, encapsulation, and other design heuristics. But sometimes thinking about how to assemble a system from a set of black boxes provides insights that information hiding and encapsulation don't, so the concept is worth having in your back pocket." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Watch for coupling that's too tight. 'Coupling' refers to how tight the connection is between two classes. In general, the looser the connection, the better. Several general guidelines flow from this concept: Minimize accessibility of classes and members. Avoid friend classes, because they're tightly coupled. Make data private rather than protected in a base class to make derived classes less tightly coupled to the base class. Avoid exposing member data in a class's public interface. Be wary of semantic violations of encapsulation. Observe the 'Law of Demeter' [...]. Coupling goes hand in glove with abstraction and encapsulation. Tight coupling occurs when an abstraction is leaky, or when encapsulation is broken." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Encapsulation picks up where abstraction leaves off. Abstraction says, ‘You're allowed to look at an object at a high level of detail’. Encapsulation says, ‘Furthermore, you aren't allowed to look at an object at any other level of detail’." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"The primary intent behind the principle of encapsulation is to separate the interface and the implementation, which enables the two to change nearly independently. This separation of concerns allows the implementation details to be hidden from the clients who must depend only on the interface of the abstraction. If an abstraction exposes implementation details to the clients, it leads to undesirable coupling between the abstraction and its clients, which will impact the clients whenever the abstraction needs to change its implementation details. Providing more access than required can expose implementation details to the clients, thereby, violating the 'principle of hiding'." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

"The principle of encapsulation advocates separation of concerns and information hiding through techniques such as hiding implementation details of abstractions and hiding variations." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

🏗️Software Engineering: Failure (Just the Quotes)

"A complex system can fail in an infinite number of ways." (John Gall, "General Systemantics: How systems work, and especially how they fail", 1975)

"Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The fundamental problem with software maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back. Why aren't defects fixed more cleanly? First, even a subtle defect shows itself as a local failure of some kind. In fact it often has system-wide ramifications, usually nonobvious. Any attempt to fix it with minimum effort will repair the local and obvious, but unless the structure is pure or the documentation very fine, the far-reaching effects of the repair will be overlooked. Second, the repairer is usually not the man who wrote the code, and often he is a junior programmer or trainee. (Frederick P. Brooks, "The Mythical Man-Month" , 1975)

"Systems with unknown behavioral properties require the implementation of iterations which are intrinsic to the design process but which are normally hidden from view. Certainly when a solution to a well-understood problem is synthesized, weak designs are mentally rejected by a competent designer in a matter of moments. On larger or more complicated efforts, alternative designs must be explicitly and iteratively implemented. The designers perhaps out of vanity, often are at pains to hide the many versions which were abandoned and if absolute failure occurs, of course one hears nothing. Thus the topic of design iteration is rarely discussed. Perhaps we should not be surprised to see this phenomenon with software, for it is a rare author indeed who publicizes the amount of editing or the number of drafts he took to produce a manuscript." (Fernando J Corbató, "A Managerial View of the Multics System Development", 1977)

"[...] when a variety of tasks have all to be performed in cooperation, synchronization, and communication, a business needs managers and a management. Otherwise, things go out of control; plans fail to turn into action; or, worse, different parts of the plans get going at different speeds, different times, and with different objectives and goals, and the favor of the 'boss' becomes more important than performance." (Peter F Drucker, "People and Performance", 1977)

"How do we convince people that in programming simplicity and clarity - in short: what mathematicians call 'elegance' - are not a dispensable luxury, but a crucial matter that decides between success and failure?" (Edsger W Dijkstra, "'Why Is Software So Expensive?' An Explanation to the Hardware Designer", [EWD648] 1982) 

"Leaders value learning and mastery, and so do people who work for leaders. Leaders make it clear that there is no failure, only mistakes that give us feedback and tell us what to do next." (Warren G Bennis, Training and Development Journal, 1984)

"Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process. […] design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"Our experience with designing and analyzing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and in its ultimate success or failure. Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products). These requirements dictate the system's performance, availability, security, compatibility with other systems, and the ability to accommodate change over its lifetime. The desire to satisfy these goals with software that has the requisite properties influences the design choices made by a software architect." (Len Bass et al, "Software Architecture in Practice", 1998)

"A test that reveals a bug has succeeded, not failed." (Boris Beizer, "Software Testing Techniques", 1990)

"Failure to initialize a shared object can lead to data-dependent bugs caused by residues from a previous use of that object by another transaction. Note that the culprit transaction is long gone when the bug's symptoms are discovered. Because the effect of corruption of dynamic data can be arbitrarily far removed from the cause, such bugs are among the most difficult to catch." (Boris Beizer, "Software Testing Techniques", 1990)

"Testing proves a programmer’s failure. Debugging is the programmer’s vindication." (Boris Beizer, "Software Testing Techniques", 1990)

"The picture of digital progress that so many ardent boosters paint ignores the painful record of actual programmers’ epic struggles to bend brittle code into functional shape. That record is of one disaster after another, marking the field’s historical time line like craters. Anyone contemplating the start of a big software development project today has to contend with this unfathomably discouraging burden of experience. It mocks any newcomer with ambitious plans, as if to say, What makes you think you’re any different?" (Scott Rosenberg, "Dreaming in Code", 2007)

"As a general rule, implementations do not just spontaneously combust. Failures tend to stem from the aggregation of many issues. Although some issues may have been known since the early stages of the project (for example, the sales cycle or system design), implementation teams discover the majority of problems during the middle of the implementation, typically during some form of testing." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Understanding the causes of system failures may help organizations avoid them, although there are no guarantees." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"But the history of large systems demonstrates that, once the hurdle of stability has been cleared, a more subtle challenge appears. It is the challenge of remaining stable when the rules change. Machines, like organizations or organisms, that fail to meet this challenge find that their previous stability is no longer of any use. The responses that once were life-saving now just make things worse. What is needed now is the capacity to re-write the procedure manual on short notice, or even (most radical change of all) to change goals." (John Gall, "The Systems Bible: The Beginner's Guide to Systems Large and Small"[Systematics 3rd Ed.], 2011)

"Experts in the 'Problem' area proceed to elaborate its complexity. They design complex Systems to attack it. This approach guarantees failure, at least for all but the most pedestrian tasks. The problem is a Problem precisely because it is incorrectly conceptualized in the first place, and a large System for studying and attacking the Problem merely locks in the erroneous conceptualization into the minds of everyone concerned. What is required is not a large System, but a different approach. Trying to design a System in the hope that the System will somehow solve the Problem, rather than simply solving the Problem in the first place, is to present oneself with two problems in place of one." (John Gall, "The Systems Bible: The Beginner's Guide to Systems Large and Small"[Systematics 3rd Ed.], 2011)

"Pragmatically, it is generally easier to aim at changing one or a few things at a time and then work out the unexpected effects, than to go to the opposite extreme. Attempting to correct everything in one grand design is appropriately designated as Grandiosity. […] A little Grandiosity goes a long way. […] The diagnosis of Grandiosity is quite elegantly and strictly made on a purely quantitative basis: How many features of the present System, and at what level, are to be corrected at once? If more than three, the plan is grandiose and will fail." (John Gall, "The Systems Bible: The Beginner's Guide to Systems Large and Small"[Systematics 3rd Ed.], 2011)

"Systems with high risks must be tested more thoroughly than systems that do not generate big losses if they fail. The risk assessment must be done for the individual system parts, or even for single error possibilities. If there is a high risk for failures by a system or subsystem, there must be a greater testing effort than for less critical (sub)systems. International standards for production of safety-critical systems use this approach to require that different test techniques be applied for software of different integrity levels." (Andreas Spillner et al, "Software Testing Foundations: A Study Guide for the Certified Tester Exam" 4th Ed., 2014)

"The real bug here is that the design of the system even permits this class of bug. It is unconscionable that someone designing a critical piece of security infrastructure would design the system in such a way that it does not fail safe." (Jamie Zawinski, 2014)

"A fault is usually defined as one component of the system deviating from its spec, where - as a failure is when the system as a whole stops providing the required service to the user. It is impossible to reduce the probability of a fault to zero; therefore it is usually best to design fault-tolerance mechanisms that prevent faults from causing failures." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"A key contribution of DevOps was to raise awareness of the problems lingering in how teams interacted (or not) across the delivery chain, causing delays, rework, failures, and a lack of understanding and empathy toward other teams. It also became clear that such issues were not only happening between application development and operations teams but in interactions with many other teams involved in software delivery, like QA, InfoSec, networking, and more." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

🏗️Software Engineering: Extreme Programming (Just the Quotes)

"Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"The XP philosophy is to start where you are now and move towards the ideal. From where you are now, could you improve a little bit?" (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"The new concept of Extreme Programming (XP) is gaining more and more acceptance, partially because it is controversial, but primarily because it is particularly well-suited to help the small software development team succeed. [...] XP is controversial, many software development sacred cows don't make the cut in XP; it forces practitioners to take a fresh look at how software is developed." (Kent Beck, "Abstract Extreme Programming Explained", 2000)

"Don't produce voluminous design documents at the beginning. Don't even produce them in the middle: produce them at the end. Extreme Programming teaches you how to keep the design flexible, for highest flexibility and fastest implementation. The design documents you produce at the beginning will go out of date very quickly (they always do, even on non-Extreme projects), and you 'Il either waste time updating the docs or let them get out of date. Either is bad." (Ron Jeffries, "Extreme Programming Installed", 2001)

"Don't try to freeze requirements before you start implementing. Requirements changes show that the customer is learning! Sure, it would be nice if they knew just what they wanted before you started building things, but the fact is that when they see what you're building, they'll learn what they meant. XP lets you use a development and planning approach that allows for change, without big up-front investment in frameworks or flexibility." (Ron Jeffries, "Extreme Programming Installed", 2001)

"Extreme Programming is a discipline of software development with values of simplicity, communication, feedback and courage. We focus on the roles of customer, manager, and programmer and accord key rights and responsibilities to those in those roles." (Ron Jeffries, "Extreme Programming Installed", 2001)

"The values of XP are simplicity, communication, feedback, and courage. [...] Use simple design and programming practices, and simple methods of planning, tracking, and reporting. Test your program and your practices, using feedback to decide how to steer the project. Working together in this way gives the team courage."  (Ron Jeffries, "Extreme Programming Installed", 2001)

"We all strive for simple and clear design, don't we? Of course we do. But in XP, we take it to extremes. At every moment in time, we want  the system to be as simple as possible. That means that we want no  additional functions that aren't used, no structures or algorithms that  are more complex than the current need would dictate." (Ron Jeffries, "Extreme Programming Installed", 2001)

"XP isn't slash and burn programming, not code and fix, not at all. Extreme Programming is about careful and continuous design, rapid  feedback from extensive testing, and the maintenance of relentlessly clear and high-quality code." (Ron Jeffries, "Extreme Programming Installed, 2001)

"Extreme Programming is the most prominent new, light-weight (or agile) methods, defined to contrast the current heavy-weight and partially overloaded object-oriented methods. It focuses on the core issues of software technology. One of its principles is not to rely on diagrams to document a system." (Bernhard Rumpe, "Executable Modeling with UML. A vision or a Nightmare", Issues & Trends of Information Technology Management in Contemporary Associations, 2002)

"Extreme Programming recognizes the importance of design decisions, but it strongly resists upfront design. Instead, it puts an admirable effort into communication and improving the project’s ability to change course rapidly. With that ability to react, developers can use the “simplest thing that could work” at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer’s true needs." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"In fact, XP works best for developers with a sharp design sense. The XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But past design choices make refactoring itself either easier or harder. The XP process attempts to increase team communication, but model and design choices clarify or confuse communication." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Extreme Programming is the first popular methodology to view software development as an exercise in coding rather than an exercise in management." (Ben Aveling, "XP lite considered harmful?", 2004)

"One of the central axioms of extreme programming is the disciplined use of regression testing during stepwise software development." (Thomas A Henzinger et al, "Extreme model checking", 2004)

🏗️Software Engineering: Simplicity vs Complexity (Just the Quotes)

"Simplicity of structure means organic unity, whether the organism be simple or complex; and hence in all times the emphasis which critics have laid upon Simplicity, though they have not unfrequently confounded it with narrowness of range." (George H Lewes, "The Principles of Success in Literature", 1865)

"The first obligation of Simplicity is that of using the simplest means to secure the fullest effect. But although the mind instinctlvely rejects all needless complexity, we shall greatly err if we fail to recognise the fact, that what the mind recoils from is not the complexity, but the needlessness." (George H Lewes, "The Principles of Success in Literature", 1865)

"Simplicity is the soul of efficiency." (Austin Freeman, "The Eye of Osiris", 1911)

"The complexity of a system is no guarantee of its accuracy." (John P Jordan, "Cost accounting; principles and practice", 1920)

"[Disorganized complexity] is a problem in which the number of variables is very large, and one in which each of the many variables has a behavior which is individually erratic, or perhaps totally unknown. However, in spite of this helter-skelter, or unknown, behavior of all the individual variables, the system as a whole possesses certain orderly and analyzable average properties. [...] [Organized complexity is] not problems of disorganized complexity, to which statistical methods hold the key. They are all problems which involve dealing simultaneously with a sizable number of factors which are interrelated into an organic whole. They are all, in the language here proposed, problems of organized complexity." (Warren Weaver, "Science and Complexity", American Scientist Vol. 36, 1948)

"A theory is the more impressive the greater the simplicity of its premises is, the more different kinds of things it relates, and the more extended its area of applicability." (Albert Einstein, "Autobiographical Notes", 1949)

"In products of the human mind, simplicity marks the end of a process of refining, while complexity marks a primitive stage." (Eric Hoffer, 1954)

"Nor does complexity deny the valid simplification which is part of the process of analysis, and even a method of achieving complex architecture itself." (Robert Venturi, "Complexity and Contradiction in Architecture Complexity and Contradiction in Architecture", 1966)

"The ideas need not be complex. Most ideas that are successful are ludicrously simple. Successful ideas generally have the appearance of simplicity because they seem inevitable." (Sol LeWitt, "Paragraphs on Conceptual Art", 1967) 

"Simplicity does not precede complexity, but follows it." (Alan Perlis, "Epigrams on Programming", 1982)

"The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence." (Frederick P Brooks, "No Silver Bullet" , 1987)

"Organized simplicity occurs where a small number of significant factors and a large number of insignificant factors appear initially to be complex, but on investigation display hidden simplicity." (Robert L Flood & Ewart R Carson, "Dealing with Complexity: An introduction to the theory and application of systems", 1988)

"It is important to emphasize the value of simplicity and elegance, for complexity has a way of compounding difficulties and as we have seen, creating mistakes. My definition of elegance is the achievement of a given functionality with a minimum of mechanism and a maximum of clarity."  (Fernando J Corbató, "On Building Systems That Will Fail", 1991)

"Crude complexity is ‘the length of the shortest message that will describe a system, at a given level of coarse graining, to someone at a distance, employing language, knowledge, and understanding that both parties share (and know they share) beforehand." (Murray Gell-Mann, "What is Complexity?" Complexity Vol. 1 (1), 1995)

"A dictionary definition of the word ‘complex’ is: ‘consisting of interconnected or interwoven parts’ […] Loosely speaking, the complexity of a system is the amount of information needed in order to describe it. The complexity depends on the level of detail required in the description. A more formal definition can be understood in a simple way. If we have a system that could have many possible states, but we would like to specify which state it is actually in, then the number of binary digits (bits) we need to specify this particular state is related to the number of states that are possible." (Yaneer Bar-Yamm, "Dynamics of Complexity", 1997)

"When the behavior of the system depends on the behavior of the parts, the complexity of the whole must involve a description of the parts, thus it is large. The smaller the parts that must be described to describe the behavior of the whole, the larger the complexity of the entire system. […] A complex system is a system formed out of many components whose behavior is emergent, that is, the behavior of the system cannot be simply inferred from the behavior of its components." (Yaneer Bar-Yamm, "Dynamics of Complexity", 1997)

"Complexity is that property of a model which makes it difficult to formulate its overall behaviour in a given language, even when given reasonably complete information about its atomic components and their inter-relations." (Bruce Edmonds, "Syntactic Measures of Complexity", 1999)

"People who pride themselves on their 'complexity' and deride others for being 'simplistic' should realize that the truth is often not very complicated. What gets complex is evading the truth." (Thomas Sowell, "Barbarians inside the Gates and Other Controversial Essays", 1999)

"Complexity is the characteristic property of complicated systems we don’t understand immediately. It is the amount of difficulties we face while trying to understand it. In this sense, complexity resides largely in the eye of the beholder - someone who is familiar with s.th. often sees less complexity than someone who is less familiar with it. [...] A complex system is created by evolutionary processes. There are multiple pathways by which a system can evolve. Many complex systems are similar, but each instance of a system is unique." (Jochen Fromm, "The Emergence of Complexity", 2004)

"Simplicity is achieved in two general ways: minimizing the amount of essential complexity that anyone's brain has to deal with at any one time, and keeping accidental complexity from proliferating needlessly." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Complexity carries with it a lack of predictability different to that of chaotic systems, i.e. sensitivity to initial conditions. In the case of complexity, the lack of predictability is due to relevant interactions and novel information created by them." (Carlos Gershenson, "Understanding Complex Systems", 2011)

"Complexity has shown that reductionism is limited, in the sense that emergent properties cannot be reduced. In other words, the properties at a given scale cannot be always described completely in terms of properties at a lower scale. This has led people to debate on the reality of phenomena at different scales." (Carlos Gershenson, "Complexity", 2011)

"I think there is a profound and enduring beauty in simplicity; in clarity, in efficiency. True simplicity is derived from so much more than just the absence of clutter and ornamentation. It's about bringing order to complexity." (Jonathan Ive, 2013)

"Simplicity in a system tends to increase that system’s efficiency. Because less can go wrong with fewer parts, less will. Complexity in a system tends to increase that system’s inefficiency; the greater the number of variables, the greater the probability of those variables clashing, and in turn, the greater the potential for conflict and disarray. Because more can go wrong, more will. That is why centralized systems are inclined to break down quickly and become enmeshed in greater unintended consequences." (Lawrence K Samuels,"Defense of Chaos: The Chaology of Politics, Economics and Human Action", 2013)

🏗️Software Engineering: Data Structures (Just the Quotes)

"At the present time, choosing a programming language is equivalent to choosing a data structure, and if that data structure does not fit the data you want to manipulate then it is too bad. It would, in a sense, be more logical first to choose a data structure appropriate to the problem and then look around for, or construct with a kit of tools provided, a language suitable for manipulating that data structure." (Maurice V Wilkes, "Computers Then and Now", 1968)

"Choosing a better data structure is often an art, which we cannot teach. Often you must write a preliminary draft of the code before you can determine what changes in the data structure will help simplify control. [...] Choose a data representation that makes the program simple." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Let the data structure the program." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Use recursive procedures for recursively-defined data structures." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"The programmer's primary weapon in the never-ending battle against slow system is to change the intramodular structure. Our first response should be to reorganize the modules' data structures." (Fred Brooks, "The Mythical Man-Month: Essays on Software Engineering", 1975)

"The representation of knowledge in symbolic form is a matter that has pre-occupied the world of documentation since its origin. The problem is now relevant in many situations other than documents and indexes. The structure of records and files in databases: data structures in computer programming; the syntactic and semantic structure of natural language; knowledge representation in artificial intelligence; models of human memory: in all these fields it is necessary to decide how knowledge may be represented so that the representations may be manipulated." (Brian C Vickery, "Concepts of documentation", 1978)

"Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures." (Rob Pike, "Notes on Programming in C" , 1989)

"Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." (Rob Pike, "Notes on Programming in C", 1989)

"If a programmer designs a program, only half the job is done if they have only designed the data structures. They also have to design the procedures for operating on the structures. (Specifically, a programmer designs abstract data types.) Without the appropriate procedures for operating on data structures, a computer would literally get lost in the structures, even supposing it could start executing anything sensible." (Yin L Theng et al," 'Lost in hhyperspace': Psychological problem or bad design?", 1996)

"Often you'll see the same three or four data items together in lots of places: fields in a couple of classes, parameters in many method signatures. Bunches of data that hang around together really ought to be made into their own object." (Kent Beck, "Refactoring: Improving the Design of Existing Code", 1999)

"Smart data structures and dumb code works a lot better than the other way around." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 2001)

"In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful. […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships." (Linus Torvalds, [email] 2006)

"Computation at its root consists of a data structure (for input, output, and perhaps something being stored in between) and some process. One cannot talk about the process without describing the data structure. More importantly, different data structures enable certain computations to be done easily, whereas other data structures support other computations. Thus, the choice of data structure (representation) helps explain why a problem-solver does or does not successfully engage in a given process (cognition/behavior) or perhaps why a process takes as long or as short as it does." (Christian D Schunn et al, "Complex Visual Data Analysis, Uncertainty, and Representation", 2007)

"One of the essential parts of a formal training in programming is a long and demanding study of the large collection of algorithms that have already been discovered and analyzed, together with the Data Structures (carefully tailored, seemingly unnatural ways of organizing data for effective access) that go with them. As with any other engineering profession, it is impossible to do a good job without a thorough knowledge of what has been tried before. If a programmer starts the job fully armed with what is already known, they will have some chance of finding something new. Inventiveness is important: not all problems have been seen before. A programmer who does not already know the standard algorithms and data structures is doomed to nothing more than rediscovering the basics." (Robert Plant & Stephen Murrell, "An Executive’s Guide to Information Technology: Principles, Business Models, and Terminology", 2007)

"A modeling language is usually based on some kind of computational model, such as a state machine, data flow, or data structure. The choice of this model, or a combination of many, depends on the modeling target. Most of us make this choice implicitly without further thinking: some systems call for capturing dynamics and thus we apply for example state machines, whereas other systems may be better specified by focusing on their static structures using feature diagrams or component diagrams. For these reasons a variety of modeling languages are available." (Steven Kelly & Juha-Pekka Tolvanen, "Domain-specific Modeling", 2008)

"Clearly, the search for a dividing line between code and data is fruitless—and not particularly flattering to our egos. Let’s abandon any attempt to find a higher truth here, and settle for a pragmatic definition. If a piece of generated text simply instantiates and provides values for a data structure, it’s data; otherwise, it’s code." (Steven Kelly & Juha-Pekka Tolvanen, "Domain-specific Modeling", 2008)

"Generally, the craft of programming is the factoring of a set of requirements into a a set of functions and data structures." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"If the data structure can’t be explained on a beer coaster, it’s too complex." (Felix von Leitner, "Source Code Optimization", 2009)

🏗️Software Engineering: Programing Languages (Just the Quotes)

"The establishment of formal standards for proofs about programs [...] and the proposal that the semantics of a programming language may be defined independently of all processors for that language, by establishing standards of rigor for proofs about programs in the language, appears to be novel." (Robert Floyd, "Assigning Meanings to Programs", 1967)

"Computer languages of the future will be more concerned with goals and less with procedures specified by the programmer." (Marvin Minsky, "Form and Content in Computer Science", [Turing Award lecture] 1969)

"There is no programming language, no matter how structured, that will prevent programmers from making bad programs." (Larry Flon, "On research in structured programming", SIGPLAN 10(10), 1975)

"Most programming languages are decidedly inferior to mathematical notation and are little used as tools of thought in ways that would be considered significant by, say, an applied mathematician." (Kenneth E Iverson, "Notation as a Tool of Thought", 1979)

"The properties of executability and universality associated with programming languages can be combined, in a single language, with the well-known properties of mathematical notation which make it such an effective tool of thought." (Kenneth E Iverson, "Notation as a Tool of Thought", 1979)

"A language that doesn't affect the way you think about programming, is not worth knowing." (Alan Perlis, "Epigrams on Programming", 1982)

"A programming language is low level when its programs require attention to the irrelevant." (Alan J Perlis, "Epigrams on Programming", 1982)

"Some programming languages manage to absorb change, but withstand progress." (Alan J Perlis, "Epigrams on Programming", 1982)

"The only way to learn a new programming language is by writing programs in it." (Dennis Ritchie, "C Programming Language", 1988)

"A programming language is like a natural, human language in that it favors certain methaphors, images, and ways of thinking." (Seymour Papert, "Mindstorms: Children, Computers, And Powerful Ideas", 1993) 

"Although mathematical notation undoubtedly possesses parsing rules, they are rather loose, sometimes contradictory, and seldom clearly stated. [...] The proliferation of programming languages shows no more uniformity than mathematics. Nevertheless, programming languages do bring a different perspective. [...] Because of their application to a broad range of topics, their strict grammar, and their strict interpretation, programming languages can provide new insights into mathematical notation." (Kenneth E Iverson, "Math for the Layman", 1999) 

"Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock, "Object-oriented Design: A responsibility-driven approach", 1989)

"Computer programs are complex by nature. Even if you could invent a programming language that operated exactly at the level of the problem domain, programming would be complicated because you would still need to precisely define relationships between real-world entities, identify exception cases, anticipate all possible state transitions, and so on. Strip away the accidental work involved in representing these factors in a specific programming language and in a specific computing environment, and you still have the essential difficulty of defining the underlying real-world concepts and debugging your understanding of them." (Steve C McConnell," After the Gold Rush : Creating a True Profession of Software Engineering", 1999)

“The precision provided (or enforced) by programming languages and their execution can identify lacunas, ambiguities, and other areas of potential confusion in conventional [mathematical] notation." (Kenneth E Iverson, "Math for the Layman", 1999)

"Programming languages on the whole are very much more complicated than they used to be: object orientation, inheritance, and other features are still not really being thought through from the point of view of a coherent and scientifically well-based discipline or a theory of correctness. My original postulate, which I have been pursuing as a scientist all my life, is that one uses the criteria of correctness as a means of converging on a decent programming language design - one which doesn’t set traps for its users, and ones in which the different components of the program correspond clearly to different components of its specification, so you can reason compositionally about it. [...] The tools, including the compiler, have to be based on some theory of what it means to write a correct program." (Charles A R Hoare, [interview] 2002)

"A programming language is for thinking of programs, not for expressing programs you've already thought of." (Paul Graham, "Hackers and Painters", 2003)

"All OO languages show some tendency to suck programmers into the trap of excessive layering. Object frameworks and object browsers are not a substitute for good design or documentation, but they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing. The Rules of Simplicity, Clarity, and Transparency get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems." (Eric S Raymond, "The Art of Unix Programming", 2003)

"Few classical programmers found prototypal inheritance to be acceptable, and classically inspired syntax obscures the language’s true prototypal nature. It is the worst of both worlds." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Most programming languages contain good parts and bad parts. I discovered that I could be better programmer by using only the good parts and avoiding the bad parts." (Douglas Crockford, "JavaScript: The Good Parts", 2008) 

🏗️Software Engineering: Documentation (Just the Quotes)

"Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves. These are the manager's chief personal tools." (William Bengough, "Scene in the old Congressional Library", 1897)

"Notice that even the data is commented. One of the most effective ways to document a program is simply to describe the data layout in detail. If you can specify for each important variable what values it can assume and how it gets changed, you have gone a long way to describing the program. [...] Document your data layouts." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"The best documentation for a computer program is a clean structure. It also helps if the code is well formatted, with good mnemonic identifiers and labels (if any are needed), and a smattering of enlightening comments. Flowcharts and program descriptions are of secondary importance; the only reliable documentation of a computer program is the code itself. The reason is simple -whenever there are multiple representations of a program, the chance for discrepancy exists. If the code is in error, artistic flowcharts and detailed comments are to no avail. Only by reading the code can the programmer know for sure what the program does." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Writing a computer program eventually boils down to writing a sequence of statements in the language at hand. How each of those statements is expressed determines in large measure the intelligibility of the whole; no amount of commenting, formatting, or supplementary documentation can entirely replace well expressed statements. After all, they determine what the program actually does." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"There is nothing in the programming field more despicable than an undocumented program." (Edward Yourdon, "Techniques of program structure and design", 1975)

"The representation of knowledge in symbolic form is a matter that has pre-occupied the world of documentation since its origin. The problem is now relevant in many situations other than documents and indexes. The structure of records and files in databases: data structures in computer programming; the syntactic and semantic structure of natural language; knowledge representation in artificial intelligence; models of human memory: in all these fields it is necessary to decide how knowledge may be represented so that the representations may be manipulated." (Brian C Vickery, "Concepts of Documentation", 1978)

"Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large." (Jakob Nielsen, "Usability Engineering", 1994)

"The following two statements are usually both true: 

There's not enough documentation. 

There's too much documentation." (Larry Wall, [Usenet article], 1997)

"But code as a design document does have its limits. It can overwhelm the reader with detail. Although its behavior is unambiguous, that doesn’t mean it is obvious. And the meaning behind a behavior can be hard to convey. […] A document shouldn’t try to do what the code already does well. The code already supplies the detail. It is an exact specification of program behavior. Other documents need to illuminate meaning, to give insight into large-scale structures, and to focus attention on core elements. Documents can clarify design intent when the programming language does not support a straightforward implementation of a concept. Written documents should complement the code and the talking." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Good code is its own best documentation." (Steve McConnell, "Code Complete", 2004)

"Documentation is a love letter that you write to your future self." (Damian Conway, "Perl Best Practices", 2005)

"Developing fewer features allows you to conserve development resources and spend more time refining those features that users really need. Fewer features mean fewer things to confuse users, less risk of user errors, less description and documentation, and therefore simpler Help content. Removing any one feature automatically increases the usability of the remaining ones." (Jakob Nielsen, "Prioritizing Web Usability", 2006)

"Any comment that forces you to look in another module for the meaning of that comment has failed to communicate to you and is not worth the bits it consumes." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008) 

"Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. […] Features have a documentation cost. Every feature adds pages to the manual increasing training costs." (Douglas Crockford, "JavaScript: The Good Parts: The Good Parts", 2008)

Software is usually accompanied by documentation in the form of big fat scary manuals that nobody ever reads. (Dave Barry, "Dave Barry in Cyberspace", 2010)

"In addition to developing the proper culture, invest in your testing infrastructure by developing linters, documentation, or other assistance that makes it more difficult to write bad tests." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Documentation is a practice concerned with all the processes involved in transferring documents from sources to users." (Brian C Vickery)

"Documentation is not understanding, process is not discipline, formality is not skill." (Jim Highsmith)

"The guy who knows about computers is the last person you want to have creating documentation for people who don't understand computers." (Adam Osborne)

"This is generally true: any sizeable piece of program, or even a complete program package, is only a useful tool that can be used in a reliable fashion, provided that the documentation pertinent for the user is much shorter than the program text. If any machine or system requires a very thick manual, its usefulness becomes for that very circumstance subject to doubt!" (Edsger W. Dijkstra, "On the reliability of programs")

🏗️Software Engineering: Object-Oriented Programming (Just the Quotes)

"Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process. […] design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world." (Grady Booch, "Software Engineering with Ada", 1986)

"Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming. Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock," Object-Oriented Design: A responsibility-driven approach", 1989)

"Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock, "Object-oriented Design: A responsibility-driven approach", 1989)

"In object-oriented analysis, we seek to model the world by identifying the classes and objects that form the vocabulary of the problem domain, and in object-oriented design, we invent the abstractions and mechanisms that provide the behavior that this model requires." (Grady Booch, "Object-Oriented Design: With Applications", 1991) 

"Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain."(Grady Booch, "Object-oriented design: With Applications", 1991)

"[Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light." (Edward Yourdon, "Object-Oriented Design", 1991) 

"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships." (Grady Booch, "Object-oriented design: With Applications", 1991)

"Structured design does not scale up well for extremely complex systems, and this method is largely inappropriate for use with object-based and object-oriented programming languages." (Grady Booch, "Object-oriented design: With Applications", 1991) 

"The object-oriented paradigm is useful when building software systems where there is a hierarchy defined as a ranking or ordering of abstractions. (Grady Booch, "Object-Oriented Design: With Applications", 1991)

"Whereas object-oriented analysis typically focuses upon one specific problem at a time, domain analysis seeks to identify the classes and objects that are common to all applications within a given domain, such as missile avionics systems, compilers, or accounting software." (Grady Booch, "Object-oriented design: With Applications", 1991)

"Object-oriented methods tend to focus on the lowest-level building block: the class and its objects." (Peter Coad, "Object-oriented patterns", 1992)

"Object-oriented domain analysis seeks to identify reusable items localized around objects e. g., classes, instances, systems of interacting objects, and kits." (Edward V Berard, "Essays on object-oriented software engineering", 1993)

"All OO languages show some tendency to suck programmers into the trap of excessive layering. Object frameworks and object browsers are not a substitute for good design or documentation, but they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing. The Rules of Simplicity, Clarity, and Transparency get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems." (Eric S. Raymond, "The Art of Unix Programming", 2003)

"Objects are the real and conceptual things we find in the world around us. An object may be hardware, software, a concept (e. g., velocity), or even 'flesh and blood'. Objects are complete entities, i. e., they are not 'simply information' or 'simply information and actions'. Software objects strive to capture as completely as possible the characteristics of the 'real world' objects which they represent. Finally, objects are 'black boxes', i. e., their internal implementations are hidden from the outside world, and all interactions with an object take place via a well-defined interface." (Edward V Berard, "Essays onObject-Oriented Software Engineering", 1993) 

"The combination of threads, remote-procedure-call interfaces, and heavyweight object-oriented design is especially dangerous [...] if you are ever invited onto a project that is supposed to feature all three, fleeing in terror might well be an appropriate reaction." (Eric S Raymond, "The Art of UNIX Programming", 2003)

"Abstraction is the ability to engage with a concept while safely ignoring some of its details - handling different details at different levels. Any time you work with an aggregate, you're working with an abstraction. […] From a complexity point of view, the principal benefit of abstraction is that it allows you to ignore irrelevant details. Most real-world objects are already abstractions of some kind." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Coupling describes how tightly a class or routine is related to other classes or routines. The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines, which is known as "loose coupling." The concept of coupling applies equally to classes and routines […] Good coupling between modules is loose enough that one module can easily be used by other modules." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Encapsulation picks up where abstraction leaves off. Abstraction says, ‘You're allowed to look at an object at a high level of detail’. Encapsulation says, ‘Furthermore, you aren't allowed to look at an object at any other level of detail’." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Object-oriented design is the roman numerals of computing." (Rob Pike, 2004)

"On a related topic, let me say that I'm not much of a fan of object-oriented design. I've seen some beautiful stuff done with OO, and I've even done some OO stuff myself, but it's just one way to approach a problem. For some problems, it's an ideal way; for others, it's not such a good fit. […] OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem. It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd." (Rob Pike, [interview] 2004) 

"The steps in designing with objects are

- Identify the objects and their attributes (methods and data).

- Determine what can be done to each object.

- Determine what each object is allowed to do to other objects.

- Determine the parts of each object that will be visible to other objects—which parts will be public and which will be private.

- Define each object's public interface. 

These steps aren't necessarily performed in order, and they're often repeated. Iteration is important." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work." (Alexander Stepanov, [Interview with A. Stepanov] 2008)

"We do not want to expose the details of our data. Rather we want to express our data in abstract terms. This is not merely accomplished by using interfaces and/or getters and setters. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"[Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light." (Ed Yourdon)

"Strive for class interfaces that are complete and minimal." (Scott Meyers)