31 December 2007

Software Engineering: Problem Solving (Just the Quotes)

"We can scarcely imagine a problem absolutely new, unlike and unrelated to any formerly solved problem; but if such a problem could exist, it would be insoluble. In fact, when solving a problem, we should always profit from previously solved problems, using their result or their method, or the experience acquired in solving them." (George Polya, 1945)

"The problems are solved, not by giving new information, but by arranging what we have known since long." (Ludwig Wittgenstein, "Philosophical Investigations", 1953)

"A great many problems are easier to solve rigorously if you know in advance what the answer is." (Ian Stewart, "From Here to Infinity", 1987)

"An important symptom of an emerging understanding is the capacity to represent a problem in a number of different ways and to approach its solution from varied vantage points; a single, rigid representation is unlikely to suffice." (Howard Gardner, "The Unschooled Mind", 1991)

"[By understanding] I mean simply a sufficient grasp of concepts, principles, or skills so that one can bring them to bear on new problems and situations, deciding in which ways one’s present competencies can suffice and in which ways one may require new skills or knowledge." (Howard Gardner, "The Unschooled Mind", 1991) 

"Solving a problem for which you know there’s an answer is like climbing a mountain with a guide, along a trail someone else has laid. In mathematics, the truth is somewhere out there in a place no one knows, beyond all the beaten paths. And it’s not always at the top of the mountain. It might be in a crack on the smoothest cliff or somewhere deep in the valley." (Yōko Ogawa, "The Housekeeper and the Professor", 2003)

"Framing the right problem is equally or even more important than solving it." (Pearl Zhu, "Change, Creativity and Problem-Solving", 2017)

"A great discovery solves a great problem but there is a grain of discovery in the solution of any problem. Your problem may be modest; but if it challenges your curiosity and brings into play your inventive faculties, and if you solve it by your own means, you may experience the tension and enjoy the triumph of discovery." (George Polya)

"A great many problems are easier to solve rigorously if you know in advance what the answer is." (Ian Stewart, "From Here to Infinity", 1987)"Every problem has a solution; it may sometimes just need another perspective.” (Rebecca Mallery et al, “NLP for Rookies”, 2009)

"Mostly we rely on stories to put our ideas into context and give them meaning. It should be no surprise, then, that the human capacity for storytelling plays an important role in the intrinsically human-centered approach to problem solving, design thinking." (Tim Brown, "Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation", 2009)

"A problem thoroughly understood is always fairly simple." (Charles Kettering)

"A problem well-defined is a problem half solved." (John Dewey)

"An expert problem solver must be endowed with two incompatible qualities, a restless imagination and a patient pertinacity." (Howard W Eves)

"Finding the right answer is important, of course. But more important is developing the ability to see that problems have multiple solutions, that getting from X to Y demands basic skills and mental agility, imagination, persistence, patience." (Mary H Futrell)

"I have not seen any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated." (Paul Anderson)

"I knew nothing, except how to think, how to grapple with a problem and then go on grappling with it until you had solved it." (Sir Barnes Wallis)

"Man is not born to solve the problems of the universe, but to find out where the problems begin, and then to take his stand within the limits of the intelligible." (Johann Wolfgang von Goethe)

"One is always a long way from solving a problem until one actually has the answer." (Stephen Hawking) 

"One measure of our understanding is the number of independent ways we are able to get to the same result." (Richard P Feynman) 

“Solving problems is a practical skill like, let us say, swimming. We acquire any practical skill by imitation and practice.” (George Polya)

"Some problems are just too complicated for rational logical solutions. They admit of insights, not answers." (Jerome B Wiesner)

"The best way to escape from a problem is to solve it." (Brendan Francis)

"The greatest challenge to any thinker is stating the problem in a way that will allow a solution." (Bertrand Russell)

"The measure of our intellectual capacity is the capacity to feel less and less satisfied with our answers to better and better problems." (Charles W Churchman)

"The mere formulation of a problem is often far more essential than its solution. To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advances in science." (Albert Einstein)

"The worst thing you can do to a problem is solve it completely." (Daniel Kleitman)

"There is no such thing as a problem without a gift. We seek problems because we need their gifts." (Richard Bach)

"To ask the right question is harder than to answer it." (Georg Cantor)

"When the answer to a mathematical problem cannot be found, then the reason is frequently that we have not recognized the general idea from which the given problem only appears as a link in a chain of related problems." (David Hilbert) 

"You are never sure whether or not a problem is good unless you actually solve it." (Mikhail Gromov)

Software Engineering: Architecture (Just the Quotes)

"The term architecture is used here to describe the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation." (Gene Amdahl et al, "Architecture of the IBM System", IBM Journal of Research and Development. Vol 8 (2), 1964)

"In computer design three levels can be distinguished: architecture, implementation and realisation; for the first of them, the following working definition is given: The architecture of a system can be defined as the functional appearance of the system to the user, its phenomenology. […] The inner structure of a system is not considered by the architecture: we do not need to know what makes the clock tick, to know what time it is. This inner structure, considered from a logical point of view, will be called the implementation, and its physical embodiment the realisation." (Gerrit A Blaauw, "Computer Architecture", 1972)

"There always is an architecture, whether it is defined in advance - as with modern computers - or found out after the fact - as with many older computers. For architecture is determined by behavior, not by words. Therefore, the term architecture, which rightly implies the notion of the arch, or prime structure, should not be understood as the vague overall idea. Rather, the product of the computer architecture, the principle of operations manual, should contain all detail which the user can know, and sooner or later is bound to know." (Gerrit A Blaauw, "Computer Architecture", 1972)

"The design of a digital system starts with the specification of the architecture of the system and continues with its implementation and its subsequent realisation... the purpose of architecture is to provide a function. Once that function is established, the purpose of implementation is to give a proper cost-performance and the purpose of realisation is to build and maintain the appropriate logical organisation." (Gerrit A Blaauw, "Specification of Digital Systems", Proc. Seminar in Digital Systems Design, 1978)

"With increasing size and complexity of the implementations of information systems, it is necessary to use some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system." (John Zachman, "A Framework for Information Systems Architecture", 1987)

"Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture). [A] step in [the] development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points." (Grady Booch, "Object-Oriented Design: with Applications", 1991)

"As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system - the software architecture - presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms." (David Garlan & Mary Shaw, "An introduction to software architecture", Advances in software engineering and knowledge engineering Vol 1, 1993)

"Software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among those components. Such a system may in turn be used as a (composite) element in a larger system design." (Mary Shaw & David Garlan,"Characteristics of Higher-Level Languages for Software Architecture", 1994)

"If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process." (Barry Boehm, 1995)

"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)

"Generically, an architecture is the description of the set of components and the relationships between them. […] A software architecture describes the layout of the software modules and the connections and relationships among them. A hardware architecture can describe how the hardware components are organized. However, both these definitions can apply to a single computer, a single information system, or a family of information systems. Thus 'architecture' can have a range of meanings, goals, and abstraction levels, depending on who’s speaking." (Frank J Armour et al, "A big-picture look at enterprise architectures", IT professional Vol 1 (1), 1999)

"An architecture framework is a tool which can be used for developing a broad range of different architectures [architecture descriptions]. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks." (TOGAF, 2002)

"The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds." (James McGovern et al, "A Practical Guide to Enterprise Architecture", 2004)

"The traditional view on software architecture suffers from a number of key problems that cannot be solved without changing our perspective on the notion of software architecture. These problems include the lack of first-class representation of design decisions, the fact that these design decisions are cross-cutting and intertwined, that these problems lead to high maintenance cost, because of which design rules and constraints are easily violated and obsolete design decisions are not removed." (Jan Bosch, "Software architecture: The next step", 2004)

"As a noun, design is the named (although sometimes unnamable) structure or behavior of a system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. A design may be singular (representing a leaf decision) or it may be collective (representing a set of other decisions). As a verb, design is the activity of making such decisions. Given a large set of forces, a relatively malleable set of materials, and a large landscape upon which to play, the resulting decision space may be large and complex. As such, there is a science associated with design (empirical analysis can point us to optimal regions or exact points in this design space) as well as an art (within the degrees of freedom that range beyond an empirical decision; there are opportunities for elegance, beauty, simplicity, novelty, and cleverness). All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." (Grady Booch, "On design", 2006)

"The goal for our software architecture is to provide the key mechanisms that are required to implement a wide variety of cross-layer adaptations described by our taxonomy. Our strategy for developing such an architecture is actually to create two architectures, a 'conceptual' one, followed by a 'concrete' one." (Soon H Choi, "A Software Architecture for Cross-layer Wireless Networks", 2008)

"A good system design is based on a sound conceptual model (architecture). A system design that has no conceptual structure and little logic to its organization is ultimately going to be unsuccessful. Good architecture will address all the requirements of the system at the right level of abstraction." (Vasudeva Varma, "Software Architecture: A Case Based Approach", 2009)

"A software architecture encompasses the significant decisions about the organization of the software system, the selection of structural elements and interfaces by which the system is composed, and determines their behavior through collaboration among these elements and their composition into progressively larger subsystems. Hence, the software architecture provides the skeleton of a system around which all other aspects of a system revolve." (Muhammad A Babar et al, "Agile Software Architecture Aligning Agile Processes and Software Architectures", 2014)

"Good architecture is all about splitting stuff reliably into self-contained parcels that allow work on them to continue relatively independently in parallel (often these days in different locations)." (Richard Hopkins & Stephen Harcombe, "Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects", 2014)

"Good architecture provides good interfaces that separate the shear layers of its implementation: a necessity for evolution and maintenance. Class-oriented programming puts both data evolution and method evolution in the same shear layer: the class. Data tend to remain fairly stable over time, while methods change regularly to support new services and system operations. The tension in these rates of change stresses the design." (James O Coplien & Trygve Reenskaug, "The DCI Paradigm: Taking Object Orientation into the Architecture World", 2014)

"In more ways than one, architecture is all about avoiding bottlenecks. In architecture, the term bottleneck typically refers to a design problem that is preventing processing from occurring at full speed. [...] A good architecture will avoid bottlenecks in both." (Richard Hopkins & Stephen Harcombe, "Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects", 2014)

"There is a tendency to believe that good architecture leads to systems that perform better and are more secure, but such claims relate less to any given architectural principle than to the timing of big-picture deliberations in the design cycle and to the proper engagement of suitable stakeholders." (James O Coplien & Trygve Reenskaug, "The DCI Paradigm: Taking Object Orientation into the Architecture World", 2014)

"Architecture begins where engineering ends." (Walter Gropius, [speech])

"Architecture is the tension between coupling and cohesion." (Neal Ford)

"Programming without an overall architecture or design in mind is like exploring a cave with only a flashlight: You don't know where you've been, you don't know where you're going, and you don't know quite where you are." (Danny Thorpe)

"The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution." (ANSI/IEEE Std 1471: 2000)

Software Engineering: Programmers (Just the Quotes)

"Programmers should never be satisfied with languages which permit them to program everything, but to program nothing of interest easily." (Alan Perlis, "The Synthesis of Algorithmic Systems", 1966)

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." (Edsger W Dijkstra, "The Humble Programmer", 1972) 

"The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer." (Edsger W Dijkstra, "The Humble Programmer", 1972)

"The beginning of wisdom for a programmer is to recognize the difference between getting his program to work and getting it right. A program which does not work is undoubtedly wrong; but a program which does work is not necessarily right. It may still be wrong because it is hard to understand; or because it is hard to maintain as the problem requirements change; or because its structure is different from the structure of the problem; or because we cannot be sure that it does indeed work." (Michael A Jackson, "Principles of Program Design", 1975)

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. […] Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. […] The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be." (Fred Brooks, The Mythical Man-Month: Essays, 1975) 

"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 Not. 10(10), 1975)


"The computer programmer is a creator of universes for which he alone is the lawgiver. No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or field of battle and to command such unswervingly dutiful actors or troops." (Joseph Weizenbaum, "Computer Power and Human Reason", 1976)

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring: Improving the Design of Existing Code", 1999)

"Good programmers know what to write. Great ones know what to rewrite." (Eric S Raymond, "The Cathedral and the Bazaar", 1999)

"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#", 2003)

"The environment that nutures creative programmers kills management and marketing types - and vice versa." (Orson S Card, "How Software Companies Die")

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", 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)

"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 Knuth, "Computer Programming as an Art", 1974) 

"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)

"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)

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

"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)

"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)

"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)])

"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 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) 

"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) 

"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)

30 December 2007

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)

"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)

"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 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

28 December 2007

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)

26 December 2007

Software Engineering: Design Pattern (Definition)

"A design pattern is a reusable solution for a software design problem. Patterns are platform independent, the same pattern can be used in different environments." (Jens Dietrich, "From Business Rules to Application Code: Code Generation Patterns for Rule Defined Associations", 2009)

"A way of representing a contextualized solution to a design problem with sufficient precision and explanation that it is an effective guide to action, but allowing scope for creative adaptation to specific needs." (Peter Goodyear & Dai F Yang, "Patterns and Pattern Languages in Educational Design", 2009)

"Common solutions to common problems, particularly in software design." (Tony C Shan & Winnie W Hua, "Data Caching Patterns" [in "Encyclopedia of Information Communication Technology"] 2009)

"Defines and explains systematically a general design to a recurrent problem of design in object oriented system." (Fuensanta Medina-Domínguez et al, "Patterns in the Field of Software Engineering" [in "Encyclopedia of Information Science and Technology" 2nd Ed.], 2009)

"Describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that one can use this solution a million times over without ever doing it the same way twice." (Franca Garzotto & Symeon Retalis, "A Critical Perspective on Design Patterns for E-Learning", 2009)

"Design patterns are standard solutions to common problems in software design." (Ghita K Mostéfaoui, "Software Engineering for Mobile Multimedia: A Roadmap", 2009)

"Design patterns represent solutions to problems that arise when developing software within a particular context. Design patterns capture the static and dynamic structure and collaboration among key participants in software designs. Design patterns are generic design pieces that need to be instantiated before uses." (Jing Dong et al, "Design Patterns from Theory to Practice" [in "Encyclopedia of Information Science and Technology" 2nd Ed.], 2009)

"Expressing the gist of a solution so that it can be reused many times. Defining a pattern, or a pattern system, is a way to capture the design knowledge of a community, to share it and to leverage it for future developments." (Eddy Boot et al, "Supporting Decision Making in Using Design Languages for Learning Designs and Learning Objects", 2009)

"In software engineering, it is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. [...] Design patterns deal specifically with problems at the level of software design." (Salvatore Scifo, "Accessing Grid Metadata through a Web Interface", 2009)

"A design pattern is a general, proven, and beneficial solution to a common, reoccurring problem in software design. Built upon similar experiences, design patterns represent 'best-practices' about how to structure or build a software architecture." (Jörg Rech et al, "Knowledge Patterns" [in "Encyclopedia of Knowledge Management" 2nd Ed.], 2011)

"A semi-formal way of documenting a solution to a design problem in a particular field of expertise." (Manuel Ecker et al, "Game-Based Learning Design Patterns: An Approach to Support the Development of 'Better' Educational Games", 2011)

"A well-tried solution to a common problem that captures experience and good practice in a form that can be reused. It is an abstract representation than can be instantiated in a number of ways." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"General solution for a common problem that occurs when designing software. A design pattern is reusable, so that it might be applied in many systems that suffer of a common problem." (Márcio Ribeiro et al, "Recommending Mechanisms for Modularizing Mobile Software Variabilities", 2012)

"[...] a design pattern [...] describes a solution to a 'typical' software design problem. A pattern provides a general template for a solution that can be applied in many different situations. It describes the main elements of a solution in an abstract way that can be specialized for a specific problem at hand." (Michael T Goodrichet al, "Data Structures and Algorithms in Python", 2013)

"A design pattern is an abstract description of best practice that has worked successfully in different systems and environments, and it acts as a reusable solution that may be used in many situations. It is more a description or template on how to solve the problem within a particular context, rather than a finished solution." (Gerard O’Regan, "Concise Guide to Software Engineering: From Fundamentals to Application Methods", 2017)

"Design patterns consists of shared guidelines helping design problems. Design patterns commonly used in software engineering and is also used in ontological engineering to solve common problems." (Galip Kaya & Arif Altun, "Educational Ontology Development" [in "Encyclopedia of Information Science and Technology" 4th Ed.], 2018)

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)

"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) 

25 December 2007

Software Engineering: Documentation (Just the Quotes)

"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)

"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)

"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) 

Software Engineering: Patterns (Definitions)

"A named description of a problem, solution, when to apply the solution, and how to apply the solution in new contexts." (Craig Larman, "Applying UML and Patterns", 2004)

"A named strategy for solving a recurring problem." (Bruce MacIsaac & Per Kroll, "Agility and Discipline Made Easy: Practices from OpenUP and RUP", 2006)

"A reusable entity representing knowledge and experience aggregated by an expert in solving a recurring problem in a domain." (Pankaj Kamthan, "A Perspective on Software Engineering Education with Open Source Software", 2007)

"Patterns (in the computer science sense) describe best practice solutions and different realization variants of a special group of systems. Patterns are abstractions from concrete forms. Examples are architecture patterns, design patterns, and process patterns." (Alke Martens & Andreas Harrer, "Software Engineering in e-Learning Systems", Encyclopedia of Information Technology Curriculum Integration, 2008)

"Patterns provide a proven solution to a repeating problem in a given context. In other words, patterns should be considered as a way to put artifacts into context and to describe a reusable solution to a recurring problem. These artifacts can be best practices, guidelines, services, blueprints, source code skeletons, and frameworks." (Martin Oberhofer et al, "Enterprise Master Data Management", 2008)

"A common combination of logic, interactions, and behaviors that form a consistent or characteristic arrangement. An important use of patterns is the idea of design templates that are general solutions to integration problems. They will not solve a specific problem, but they provide a sort of architectural outline that may be reused in order to speed up the development process." (David Lyle & John G Schmidt, "Lean Integration: An Integration Factory Approach to Business Agility", 2010)

"A recurring combination of data and task management, separate from any specific algorithm. Patterns are universal in that they apply to and can be used in any programming system. Patterns have also been called dwarfs, motifs, and algorithmic skeletons. Patterns are not necessarily tied to any particular hardware architecture or programming language or system." (Michael McCool et al, "Structured Parallel Programming", 2012)

"A general reusable solution to a commonly occurring problem within a given context." Sergey V Zykov, "Crisis Response and Management", 2018) 

24 December 2007

Software Engineering: Design (Just the Quotes)

"The engineer must be able not only to design, but to execute. A draftsman may be able to design, but unless he is able to execute his designs to successful operation he cannot be classed as an engineer. The production engineer must be able to execute his work as he has planned it. This requires two qualifications in addition to technical engineering ability: He must know men, and he must have creative ability in applying good statistical, accounting, and 'system' methods to any particular production work he may undertake." (Hugo Diemer, "Industrial Engineering", 1905)

"An engineering science aims to organize the design principles used in engineering practice into a discipline and thus to exhibit the similarities between different areas of engineering practice and to emphasize the power of fundamental concepts. In short, an engineering science is predominated by theoretical analysis and very often uses the tool of advanced mathematics." (Qian Xuesen, "Engineering Cybernetics", 1954)

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

"Clearly, programming courses should teach methods of design and construction, and the selected examples should be such that a gradual development can be nicely demonstrated." (Niklaus Wirth, "Program Development by Stepwise Refinement", 1971) 

"Conceptual integrity is the most important consideration in system design." (Frederick P Brooks, "The Mythical Man-Month" , 1975) 

"The hardest single part of building a software system is deciding precisely what to build." (Frederick P. Brooks, "The Mythical Man-Month", 1975) 

"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)

"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)

"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process." (Glenford Myers, "Composite/structured design", 1978)

"A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering." (Freeman Dyson, "Disturbing the Universe", 1979)

"Overemphasis of efficiency leads to an unfortunate circularity in design: for reasons of efficiency early programming languages reflected the characteristics of the early computers, and each generation of computers reflects the needs of the programming languages of the preceding generation." (Kenneth E Iverson, "Notation as a Tool of Thought", 1979) 

"Meta-design is much more difficult than design; it's easier to draw something than to explain how to draw it." (Donald E Knuth, "The METAFONTbook", 1986)

"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)

"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies." (Charles A R Hoare, [lecture] 1987)

"A design remedy that prevents bugs is always preferable to a test method that discovers them." (Boris Beizer, "Software Testing Techniques", 1990)

"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)

"First law: The pesticide paradox. Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffective."  (Boris Beizer, "Software Testing Techniques", 1990)

"Extra features were once considered desirable. We now recognize that 'free' features are rarely free. Any increase in generality that does not contribute to reliability, modularity, maintainability, and robustness should be suspected." (Boris Beizer, "Software Testing Techniques", 1990)

"More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded - indeed, test-design thinking can discover and eliminate bugs at every stage in the creation of software, from conception to specification, to design, coding and the rest."  (Boris Beizer, "Software Testing Techniques", 1990)

"Second law: The complexity barrier. Software complexity (and therefore that of bugs) grows to the limits of our ability to manage that complexity." (Boris Beizer, "Software Testing Techniques", 1990)

"If solutions could be offered within the existing system, there would be no need to design. Thus designers have to transcend the existing system. Their task is to create a different system or devise a new one. That is why designers say they can truly define the problem only in light of the solution. The solution informs them as to what the real problem is." (Béla H Bánáthy, "Systems Design of Education", 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)

"Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Nor are they complex, domain-specific designs for an entire application or subsystem. The design patterns [...] are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context." (Erich Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

"Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent. Put simply, design patterns help a designer get a design 'right' faster." (Erich Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

"If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process." (Barry Boehm, 1995)

"The methods of science include controlled experiments, classification, pattern recognition, analysis, and deduction. In the humanities we apply analogy, metaphor, criticism, and (e)valuation. In design we devise alternatives, form patterns, synthesize, use conjecture, and model solutions." (Béla H Bánáthy, "Designing Social Systems in a Changing World", 1996)

"The woes of software engineering are not due to lack of tools or proper management, but largely due to lack of sufficient technical competence. A good designer must rely on experience; on precise, logical thinking; and on pedantic exactness. No magic will do. In light of all this, it is particularly sad that, in many informatics curricula, programming in the large is badly neglected. Design has become a non-topic." (Niklaus Wirth, [interview in Software Development] 1997)

"Good design is also an act of communication between the designer and the user, except that all the communication has to come about by the appearance of the device itself. The device must explain itself." (Donald Norman, "The Design of Everyday Things", 2002)

"Design is heuristic. Dogmatic adherence to any single methodology hurts creativity and hurts your programs." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Design patterns provide the cores of ready-made solutions that can be used to solve many of software’s most common problems. Some software problems require solutions that are derived from first principles. But most problems are similar to past problems, and those can be solved using similar solutions, or patterns." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"In addition to their complexity-management benefit, design patterns can accelerate design discussions by allowing designers to think and discuss at a larger level of granularity." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"On small, informal projects, a lot of design is done while the programmer sits at the keyboard. 'Design' might be just writing a class interface in pseudocode before writing the details. It might be drawing diagrams of a few class relationships before coding them. It might be asking another programmer which design pattern seems like a better choice. Regardless of how it’s done, small projects benefit from careful design just as larger projects do, and recognizing design as an explicit activity maximizes the benefit you will receive from it." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"The flip side of the coin was that even good programmers and language designers tended to do terrible extensions when they were in the heat of programming, because design is something that is best done slowly and carefully." (Alan Kay, [ACM Queue A Conversation with Alan Kay Vol. 2 (9)] 2004-2005)

"Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Good software designs accommodate change without huge investments and rework. When we use code that is out of our control, special care must be taken to protect our investment and make sure future change is not too costly."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Design has the power to enrich our lives by engaging our emotions through image, form, texture, color, sound, and smell. The intrinsically human-centered nature of design thinking points to the next step: we can use our empathy and understanding of people to design experiences that create opportunities for active engagement and participation." (Tim Brown, "Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation", 2009)

"Design is the bridging activity between gathering and implementation of software requirements that satisfies the required needs. […] The fundamental goal of design is to reduce the number of dependencies between modules, thus reducing the complexity of the system. This is also known as coupling; lesser the coupling the better is the design. On the other hand, higher the binding between elements within a module (known as cohesion) the better is the design." (Vasudeva Varma, "Software Architecture: A Case Based Approach", 2009)

"Design thinking taps into capacities we all have but that are overlooked by more conventional problem-solving practices. It is not only human-centered; it is deeply human in and of itself. Design thinking relies on our ability to be intuitive, to recognize patterns, to construct ideas that have emotional meaning as well as functionality, to express ourselves in media other than words or symbols." (Tim Brown, "Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation", 2009)

"Mostly we rely on stories to put our ideas into context and give them meaning. It should be no surprise, then, that the human capacity for storytelling plays an important role in the intrinsically human-centered approach to problem solving, design thinking." (Tim Brown, "Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation", 2009)

"A good system design is based on a sound conceptual model (architecture). A system design that has no conceptual structure and little logic to its organization is ultimately going to be unsuccessful. Good architecture will address all the requirements of the system at the right level of abstraction." (Vasudeva Varma, "Software Architecture: A Case Based Approach", 2009)

"Design is the process of taking something that appears in the mind’s eye, modeling it in one or more of a number of ways, predicting how that thing will behave if it is made, and then making it, sometimes modifying the design as we make it. Design is what engineering is about. Furthermore, modeling is how engineering design is done. This includes mental models, mathematical models, computer models, plans and drawings, written language, and (sometimes) physical models." (William M Bulleit, "The Engineering Way of Thinking: The Idea", Structure [magazine], 2015) 

"Designers need to be part engineer. Good design only exists in concert with engineering. That is because form has to follow function, so you focus on function and then give the object a shape to make it appealing." (Ferdinand A Porsche)

"One of the great enemies of design is when systems or objects become more complex than a person - or even a team of people - can keep in their heads. This is why software is generally beneath contempt." (Bran Ferren)

"Programming without an overall architecture or design in mind is like exploring a cave with only a flashlight: You don't know where you've been, you don't know where you're going, and you don't know quite where you are." (Danny Thorpe) 

"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)
 
"The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." (Edsger Dijkstra)

"The thing that makes software design difficult is that we must express thoughts about a problem and a solution we typically do not understand fully, using a language that does not contain many of our accustomed features of expression, to a system that is unforgiving of mistakes." (Alistair Cockburn)
Related Posts Plugin for WordPress, Blogger...