⛩️Rebecca Wirfs-Brock - Collected Quotes

"A subsystem is a set of classes (and possibly other subsystems) collaborating to fulfill a set of responsibilities. Although subsystems do not exist as the software executes, they are useful conceptual entities." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"Encapsulation is the key to increasing the value of such software metrics as reusability, refinability, testability, maintainability, and extensibility. Object-oriented languages provide a number of mechanisms for improving encapsulation, but it is during the design phase that the greatest leverage can be realized." (Rebecca Wirfs-Brock, "Object-oriented design: a responsibility-driven approach", 1989)

"Frameworks are white boxes to those that make use of them. Application developers must be able to quickly understand the structure of a framework, and how to write code that will fit into the framework. Frameworks are reusable designs as well as reusable code." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

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

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

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

"The data-driven approach to object-oriented design focuses on the structure of the data in a system. This results in the incorporation of structural information in the definitions of classes. Doing so violates encapsulation. The responsibility-driven approach emphasizes the encapsulation of both the structure and behavior of objects. By focusing on the contractual responsibilities of a class, the designer is able to postpone implementation considerations until the implementation phase. While responsibility-driven design is not the only technique addressing this problem, most other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits." (Rebecca Wirfs-Brock, "Object-oriented design: a responsibility-driven approach", 1989)

"Responsibility-driven design specifies object behavior before object structure and other implementation considerations are determined. We have found that it minimizes the rework required for major design changes." (Rebecca Wirfs-Brock, "Object-oriented design: a responsibility-driven approach", 1989)

"Users can work with analysts and object designers to formulate and tune system requirements. People from business, analytical and object design disciplines can come together, learn from each other and generate meaningful descriptions of systems that are to be built. Each participant and each project has slightly different concerns and needs. Practical application of use cases can go a long way to improve our ability to deliver just what the customer ordered. (Rebecca Wirfs-Brock, "Designing scenarios: Making the case for a use case framework", 1993)

"An object-oriented application is a set of interacting objects. Each object is an implementation of one or more roles. A role supports a set of related (cohesive) responsibilities. A responsibility is an obligation to perform a task or know certain information. And objects don't work in isolation, they collaborate with others in a community to perform the overall responsibilities of the application. So a conceptual view, at least to start, is a distillation of the key object roles and their responsibilities (stated at a fairly high level). More than likely (unless you form classification hierarchies and use inheritance and composition techniques) many candidates you initially model will map directly to a single class in some inheritance hierarchy. But I like to open up possibilities by think first of roles and responsibilities, and then as a second step towards a specification-level view, mapping these candidates to classes and interfaces." (Rebecca Wirfs-Brock, [interview] 2003)

⛩️Jakob Nielsen - Collected Quotes

"Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action." (Jakob Nielsen, "Usability Engineering", 1993)

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

"A basic reason for the existence of usability engineering is that it is impossible to design an optimal user interface just by giving it your best try. Users have infinite potential for making unexpected misinterpretations of interface elements and for performing their job in a different way than you imagine." (Jakob Nielsen, "Usability Engineering", 1993)

"A problem with this 'waterfall' approach is that there will then be no user interface to test with real users until this last possible moment, since the "intermediate work products" do not explicitly separate out the user interface in a prototype with which users can interact. Experience also shows that it is not possible to involve the users in the design process by showing them abstract specifications documents, since they will not understand them nearly as well as concrete prototypes." (Jakob Nielsen, "Usability Engineering", 1993)

"Guidelines list well-known principles for user interface design which should be followed in the development project. In any given project, several different levels of guidelines should be used: general guidelines applicable to all user interfaces, category-specific guidelines for the kind of system being developed […] and product-specific guidelines for the individual product." (Jakob Nielsen, "Usability Engineering", 1993)

"If users' needs are not known, considerable development efforts may be wasted on such features in the mistaken belief that some users may want them. Users rarely complain that a system can do too much (they just don’t use the superfluous features), so such over-design normally does not become sufficiently visible to make the potential development savings explicitly known. They are there nevertheless." (Jakob Nielsen, "Usability Engineering", 1993)

"It is always better if users can operate the system without having to refer to a help system. Usability is not a quality that can be spread out to cover a poor design like a thick layer of peanut butter, so a user-hostile interface does not get user-friendly even by the addition of a brilliant help system." (Jakob Nielsen, "Usability Engineering", 1993)

"One should not start full-scale implementation efforts based on early user interface designs. Instead, early usability evaluation can be based on prototypes of the final systems that can be developed much faster and much more cheaply, and which can thus be changed many times until a better understanding of the user interface design has been achieved." (Jakob Nielsen, "Usability Engineering", 1993)

"Scenarios are an especially cheap kind of prototype. […] Scenarios are the ultimate reduction of both the level of functionality and of the number of features: They can only simulate the user interface as long as a test user follows a previously planned path. […] Scenarios are the ultimate minimalist prototype in that they describe a single interaction session without any flexibility for the user. As such, they combine the limitations of both horizontal prototypes (users cannot interact with real data) and vertical prototypes (users cannot move freely through the system)." (Jakob Nielsen, "Usability Engineering", 1993)

"The concept of 'user' should be defined to include everybody whose work is affected by the product in some way, including the users of the system's end product or output even if they never see a single screen." (Jakob Nielsen, "Usability Engineering", 1993)

"The difference between standards and guidelines is that a standard specifies how the interface should appear to the user, whereas a set of guidelines provides advice about the usability characteristics of the interface." (Jakob Nielsen, "Usability Engineering", 1993)

"The entire idea behind prototyping is to cut down on the complexity of implementation by eliminating parts of the full system. Horizontal prototypes reduce the level of functionality and result in a user interface surface layer, while vertical prototypes reduce the number of features and implement the full functionality of those chosen (i.e., we get a part of the system to play with)." (Jakob Nielsen, "Usability Engineering", 1993)

"The entire idea behind prototyping is to save on the time and cost to develop something that can be tested with real users. These savings can only be achieved by somehow reducing the prototype compared with the full system: either cutting down on the number of features in the prototype or reducing the level of functionality of the features such that they seem to work but do not actually do anything." (Jakob Nielsen, "Usability Engineering", 1993)

"The most basic advice with respect to interface evaluation is simply to do it , and especially to conduct some user testing. The benefits of employing some reasonable usability engineering methods to evaluate a user interface rather than releasing it without evaluation are much larger than the incremental benefits of using exactly the right methods for a given project." (Jakob Nielsen, "Usability Engineering", 1993)

"The system should always keep users informed about what is going on, through appropriate feedback within reasonable time." (Jakob Nielsen, "Usability Engineering", 1993)

"Usability engineering is not a one-shot affair where the user interface is fixed up before the release of a product. Rather, usability engineering is a set of activities that ideally take place throughout the lifecycle of the product, with significant activities happening at the early stages before the user interface has even been designed." (Jakob Nielsen, "Usability Engineering", 1993)

"User interfaces should be simplified as much as possible, since every additional feature or item of information on a screen is one more thing to learn, one more thing to possibly misunderstand, and one more thing to search through when looking for the thing you want. Furthermore, interfaces should match the users' task in as natural a way as possible, such that the mapping between computer concepts and user concepts becomes as simple as possible and the users' navigation through the interface is minimized." (Jakob Nielsen, "Usability Engineering", 1993)

"Users often do not know what is good for them. […] Users have a very hard time predicting how they will interact with potential future systems with which they have no experience. […] Furthermore, users will often have divergent opinions when asked about details of user interface design." (Jakob Nielsen, "Usability Engineering", 1993)

"Users often raise questions that the development team has not even dreamed of asking. This is especially true with respect to potential mismatches between the users' actual task and the developers' model of the task. Therefore, users should be involved in the design process through regular meetings between designers and users. Users participating in a system design process are sometimes referred to as subject matter experts, or SMEs." (Jakob Nielsen, "Usability Engineering", 1993)

"Users are not designers, so it is not reasonable to expect them to come up with design ideas from scratch. However, they are very good at reacting to concrete designs they do not like or that will not work in practice. To get full benefits from user involvement, it is necessary to present these suggested system designs in a form the users can understand." (Jakob Nielsen, "Usability Engineering", 1993)

"A general principle for all user interface design is to go through all of your design elements and remove them one at a time." (Jakob Nielsen, "Designing Web Usability", 1999)

"The web is the ultimate customer-empowering environment. He or she who clicks the mouse gets to decide everything. It is so easy to go elsewhere; all the competitors in the world are but a mouseclick away." (Jakob Nielsen, "Designing Web Usability", 1999)

"Ultimately, users visit your website for its content. Everything else is just the backdrop." (Jakob Nielsen, "Designing Web Usability", 1999)

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

⛩️Alex Xu - Collected Quotes

"A design without bottlenecks isn’t challenging and interesting." (Alex Xu, "System Design Interview: An insider's guide", 2017)

"Nonsensical design is usually a result of not thinking through step by step thoroughly. Take a moment to make sure your diagram provides the right level of details for clarity." (Alex Xu, "System Design Interview: An insider's guide", 2017)

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

"System design is about understanding the problem you’re trying to solve before coming up with a solution. It is not about coming up with a solution and finding a problem to fit into that solution." (Alex Xu, "System Design Interview: An insider's guide", 2017)

"Systems and users don’t al- ways behave the way you expect, and unexpected behaviors may lead to system failures, resulting in poor user experience." (Alex Xu, "System Design Interview: An insider's guide", 2017)

"Technical knowledge is only impressive if you’re able to apply it to justify a chosen design." (Alex Xu, "System Design Interview: An insider's guide", 2017)

"The high-level diagram design aims to set up the foundations for the design and give clarity […] on which parts are important to have to achieve the requirements. […] The objective of the high-level diagram design is to get a flow diagram […] as the baseline for further discussions." (Alex Xu, "System Design Interview: An insider's guide", 2017)

"The purpose of requirement gathering is to test your ability to clarify an open-ended and ambiguous problem statement." (Alex Xu, "System Design Interview: An insider's guide", 2017)

"When faced with a problem, our suggestion is to brainstorm a couple of options and think through the pros and cons with respect to the design requirements. Don’t generically discuss the pros and cons, but focus on what the end-users would experience based on your suggested solution." (Alex Xu, "System Design Interview: An insider's guide", 2017)

⛩️Donald E Knuth - Collected Quotes

"It’s the idea that counts true; but we need a name for the idea, so we can apply it more easily next time." (Donald E Knuth, "Surreal Numbers", 1968)

"[…] random numbers should not be generated with a method chosen at random. Some theory should be used." (Donald E Knuth, "The Art of Computer Programming" Vol. II, 1968)

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

"These machines have no common sense; they have not yet learned to 'think', and they do exactly as they are told, no more and no less. This fact is the hardest concept to grasp when one first tries to use a computer." (Donald E Knuth, "The Art of Computer Programming", 1968)

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

"Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald E Knuth, "Literate Programming", 1984)

"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 ultimate goal of mathematics is to eliminate all need for intelligent thought." (Donald E Knuth, "Concrete Mathematics: A Foundation for Computer Science", 1990)

"Science is what we understand well enough to explain to a computer. Art is everything else we do." (Donald E Knuth, [foreword to the book "A=B" by Marko Petkovsek et al] 1996)

"The whole thing that makes a mathematician's life worthwhile is that he gets the grudging admiration of three or four colleagues." (Donald E Knuth, [interview] 1996)

"The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct." (Donald E Knuth,"Selected Papers on Computer Science") 

"The difference between art and science is that science is what people understand well enough to explain to a computer. All else is art." (Donald E Knuth)

⛩️Eric S Raymond - Collected Quotes

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

"If you have the right attitude, interesting problems will find you." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)

"Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)

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

"Software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)

"The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)

"To solve an interesting problem, start by finding a problem that is interesting to you." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)

"Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)

"When writing gateway software of any kind, take pains to disturb the data stream as little as possible - and never throw away information unless the recipient forces you to!" (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)

"Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code." (Eric S. Raymond, "Why Python?", Linux Journal, 2000)

"A software system is transparent when you can look at it and immediately see what is going on. It is simple when what is going on is uncomplicated enough for a human brain to reason about all the potential cases without strain." (Eric S Raymond, "The Art of UNIX Programming", 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)

"Programmer time is expensive; conserve it in preference to machine time." (Eric S Raymond, "The Art of UNIX Programming", 2003)

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

"The only way to write complex software that won't fall on its face is to hold its global complexity down - to build it out of simple pieces connected by well-defined interfaces, so that most problems are local and you can have some hope of fixing or optimizing a part without breaking the whole." (Eric S Raymond, "The Art of UNIX Programming", 2003)

⛩️Marvin Minsky - Collected Quotes

"A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren’t flexible. Neither is a violin, or a typewriter, until you learn how to use it." (Marvin Minsky, "Why Programming Is a Good", 1967)

"When a program grows in power by an evolution of partially understood patches and fixes, the programmer begins to lose track of internal details, loses his ability to predict what will happen, begins to hope instead of know, and watches the results as though the program were an individual whose range of behavior is uncertain. [...] This is already true in some big programs [...] developed and modified by several programmers, each testing them on different examples from different [remotely located computer] consoles and inserting advice independently. The program will grow in effectiveness, but no one of the programmers will understand it all. [...] Now we see the real trouble with statements like 'It only does what its programmer told it to do.' There isn't any one programmer." (Marvin M Minsky, "Design and Planning" II, 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)

"What is the difference between merely knowing (or remembering, or memorizing) and understanding? […] A thing or idea seems meaningful only when we have several different ways to represent it - different perspectives and different associations […]. Then we can turn it around in our minds, so to speak: however it seems at the moment, we can see it another way and we never come to a full stop. In other words, we can 'think' about it. If there were only one way to represent this thing or idea, we would not call this representation thinking." (Marvin Minsky, "Music, Mind, and Meaning", 1981)

"The hardest problems we have to face do not come from philosophical questions about whether brains are machines or not. There is not the slightest reason to doubt that brains are anything other than machines with enormous numbers of parts that work in perfect accord with physical laws. As far as anyone can tell, our minds are merely complex processes. The serious problems come from our having had so little experience with machines of such complexity that we are not yet prepared to think effectively about them." (Marvin Minsky, 1986)

"For generations, scientists and philosophers have tried to explain ordinary reasoning in terms of logical principles - with virtually no success. I suspect this enterprise failed because it was looking in the wrong direction: common sense works so well not because it is an approximation of logic; logic is only a small part of our great accumulation of different, useful ways to chain things together." (Marvin Minsky, "The Society of Mind", 1987)

"Every system that we build will surprise us with new kinds of flaws until those machines become clever enough to conceal their faults from us." (Marvin Minsky, "The Emotion Machine: Commonsense Thinking, Artificial Intelligence, and the Future of the Human Mind", 2006)

"It makes no sense to seek a single best way to represent knowledge - because each particular form of expression also brings its particular limitations. For example, logic-based systems are very precise, but they make it hard to do reasoning with analogies. Similarly, statistical systems are useful for making predictions, but do not serve well to represent the reasons why those predictions are sometimes correct." (Marvin Minsky, "The Emotion Machine: Commonsense Thinking, Artificial Intelligence, and the Future of the Human Mind", 2006)

⛩️Kenneth E Iverson - Collected Quotes

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

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

"The practice of first developing a clear and precise definition of a process without regard for efficiency, and then using it as a guide and a test in exploring equivalent processes possessing other characteristics, such as greater efficiency, is very common in mathematics. It is a very fruitful practice which should not be blighted by premature emphasis on efficiency in computer execution." (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)

"The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind. Economy of notation is therefore important." (Kenneth E Iverson, "Notation as a Tool of Thought", 1979)

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

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

⛩️Ron Jeffries - Collected Quotes

"Bugs are things that creep into your software against your will. Every defect in your code was put there by one of the programmers. Two of the programmers, with pair programming. With the customers we visit, when something goes wrong, they think it's a defect." (Ron Jeffries, "Extreme Programming Installed", 2001)

"Do build perfectly for today. Do the simple thing that solves today's problem, but do it well. Keep the code of high quality, just perfect for today's needs." (Ron Jeffries, "Extreme Programming Installed", 2001)

"Do design all the time. Begin simply, and as you learn what the design should be, refactor to make it so. Never stop designing, never stop making the code agree with what the design should be." (Ron Jeffries, "Extreme Programming Installed", 2001)

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

"Don't try to design the whole system before you start implementing. Usually, requirements changes alone will make this impossible. In any case, no existing design methodology is effective enough to avoid problems during implementation, and a process of design a little, build a little will allow you to learn faster and get a quality system done sooner." (Ron Jeffries, "Extreme Programming Installed", 2001)

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

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

"No one can tell you exactly, far in advance, just how long it will take to  build software. [...] Much of the pain of software development revolves around a simple error: mistaking an estimate for a promise." (Ron Jeffries, "Extreme Programming Installed", 2001)

"Successful software development is a team effort - not just the development team, but the larger team consisting of customer, management and developers. [...] Every software project needs to deliver business value. To be successful, the team needs to build the right things, in the right order, and to be sure that what they build actually works." (Ron Jeffries, "Extreme Programming Installed", 2001)

"The longer we wait between integrations and acceptance tests, the worse things get. Wait twice as long and we'll have four or more times the hassle. The reason is that one bug written just yesterday is pretty easy to find, while ten or a hundred written weeks ago can become almost impossible." (Ron Jeffries, "Extreme Programming Installed", 2001)

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

"Through refactoring and focus on simple design, we can build a system incrementally, focused on business value, without getting cornered by an early decision that turns out to be wrong. We expect our early decisions to need updating, and through refactoring, we know just how to do it." (Ron Jeffries, "Extreme Programming Installed", 2001)

"Unit tests can be tedious to write, but they save you time in the future (by catching bugs after changes). Less obviously, but just as important, is that they can save you time now: tests focus your design and implementation on simplicity, they support refactoring, and they validate features as you develop." (Ron Jeffries, "Extreme Programming Installed, 2001)

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

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