⛩️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)

⛩️John F Smart - Collected Quotes

"A deployment pipeline is a way of orchestrating your build through a series of quality gates, with automated or manual approval processes at each stage, culminating with deployment into production." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"Coding standards are rules, sometimes relatively arbitrary, that define the coding styles and conventions that are considered acceptable within a team or organization. In many cases, agreeing on a set of standards, and applying them, is more important than the standards themselves." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"Few would deny the importance of writing quality code. High quality code contains less bugs, and is easier to understand and easier to maintain. However, the precise definitions of code quality can be more subjective, varying between organizations, teams, and even individuals within a team." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"In essence, Continuous Integration is about reducing risk by providing faster feedback. First and foremost, it is designed to help identify and fix integration and regression issues faster, resulting in smoother, quicker delivery, and fewer bugs. By providing better visibility for both technical and non-technical team members on the state of the project, Continuous Integration can open and facilitate communication channels between team members and encourage collaborative problem solving and process improvement. And, by automating the deployment process, Continuous Integration helps you get your software into the hands of the testers and the end users faster, more reliably, and with less effort." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"In many applications, integration or functional tests are used by default as the standard way to test almost all aspects of the system. However integration and functional tests are not the best way to detect and identify bugs. Because of the large number of components involved in a typical end-to-end test, it can be very hard to know where something has gone wrong. In addition, with so many moving parts, it is extremely difficult, if not completely unfeasible, to cover all of the possible paths through the application." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"Only an experienced developer can really judge code quality in all its aspects. That is the role of code reviews and, among other things, practices like pair programming. In particular, only a human eye can decide if a piece of code is truly well written, and if it actually does what the requirements ask of it." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"Remember, the most basic function of any Continuous Integration tool is to monitor source code in a version control system and to fetch and build the latest version of your source code whenever any changes are committed." (John F Smart, "Jenkins: The Definitive Guide", 2011)

⛩️Steve C McConnell - Collected Quotes

"An algorithm gives you the instructions directly. A heuristic tells you how to discover the instructions for yourself, or at least where to look for them." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"At the software-architecture level, the complexity of a problem is reduced by dividing the system into subsystems. Humans have an easier time comprehending several simple pieces of information than one complicated piece." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Because successful programming depends on minimizing complexity, a skilled programmer will build in as much flexibility as needed to meet the software's requirements but will not add flexibility - and related complexity - beyond what's required." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"By far the most common project risks in software development are poor requirements and poor project planning, thus preparation tends to focus on improving requirements and project plans."(Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Complexity in all forms - complicated algorithms, large data sets, intricate communications protocols, and so on - is prone to errors. If an error does occur, it will be easier to find if it isn't spread through the code but is localized within a class. Changes arising from fixing the error won't affect other code because only one class will have to be fixed - other code won't be touched. If you find a better, simpler, or more reliable algorithm, it will be easier to replace the old algorithm if it has been isolated into a class. During development, it will be easier to try several designs and keep the one that works best." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Design is sloppy because a good solution is often only subtly different from a poor one." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

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

"From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100–200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as the routine's cohesion, depth of nesting, number of variables, number of decision points, number of comments needed to explain the routine, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"If you're passing a parameter among several routines, that might indicate a need to factor those routines into a class that share the parameter as object data. Streamlining parameter passing isn't a goal, per se, but passing lots of data around suggests that a different class organization might work better." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"In software, consultants sometimes tell you to buy into certain software-development methods to the exclusion of other methods. That’s unfortunate because if you buy into any single methodology 100 percent, you’ll see the whole world in terms of that methodology. In some instances, you’ll miss opportunities to use other methods better suited to your current problem." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

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

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

"Modularity's goal is to make each routine or class like a 'black box': You know what goes in, and you know what comes out, but you don't know what happens inside." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

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

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

"One of the main differences between programs you develop in school and those you develop as a professional is that the design problems solved by school programs are rarely, if ever, wicked." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Programming assignments in school are devised to move you in a beeline from beginning to end. You'd probably want to tar and feather a teacher who gave you a programming assignment, then changed the assignment as soon as you finished the design, and then changed it again just as you were about to turn in the completed program. But that very process is an everyday reality in professional programming." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don't improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction", 1993)

"The more independent the subsystems are, the more you make it safe to focus on one bit of complexity at a time. Carefully defined objects separate concerns so that you can focus on one thing at a time. Packages provide the same benefit at a higher level of aggregation." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The most challenging part of programming is conceptualizing the problem, and many errors in programming are conceptual errors." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The source code is often the only accurate description of the software. On many projects, the only documentation available to programmers is the code itself. Requirements specifications and design documents can go out of date, but the source code is always up to date. Consequently, it's imperative that the code be of the highest possible quality." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The words available in a programming language for expressing your programming thoughts certainly determine how you express your thoughts and might even determine what thoughts you can express." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

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

"A typical software project can present more opportunities to learn from mistakes than some people get in a lifetime." (Steve McConnell, "Rapid Development", 1996)

"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)

"Motivation is undoubtedly the single greatest influence on how well people perform. Most productivity studies have found that motivation has a stronger influence on productivity than any other factor."  (Steve McConnell, "Rapid Development", 1996)

"It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive." (Steve McConnell, "Software Project Survival Guide", 1997)

"Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively." (Steve McConnell, "Software Project Survival Guide", 1997)

"The default movement on a software project should be in the direction of taking elements of the software away to make it simpler rather than adding elements to make it more complex." (Steve McConnell, "Software Project Survival Guide", 1997)

"The job of the average manager requires a shift in focus every few minutes. The job of the average software developer requires that the developer not shift focus more often than every few hours." (Steve McConnell, "Software Project Survival Guide", 1997)

"Trying to apply formal methods to all software projects is just as bad as trying to apply code-and-fix development to all projects." (Steve McConnell, "After the Gold Rush: Creating a True Profession of Software Engineering", 1999)

"A brute force solution that works is better than an elegant solution that doesn't work." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Building software implies various stages of planning, preparation and execution that vary in kind and degree depending on what's being built." (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)

"In software, the chain isn't as strong as its weakest link; it's as weak as all the weak links multiplied together." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

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

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

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

"A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Be sure you understand whether you're presenting uncertainty in an estimate or uncertainty that affects your ability to meet a commitment." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Don't expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can't accurately estimate an out-of-control process." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Don't intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Not all estimation methods are equal. When looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

"The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them." (Steve McConnell, "Software Estimation: Demystifying the Black Art", 2006)

⛩️Matthew Skelton - Collected Quotes

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

"A 'stream' is the continuous flow of work aligned to a business domain or organizational capability. Continuous flow requires clarity of purpose and responsibility so that multiple teams can coexist, each with their own flow of work. A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"An obsession with 'feature delivery' ignores the human-related and team-related dynamics inherent in modern software, leading to a lack of engagement from staff, especially when the cognitive load is exceeded." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"[…] decisions based on org-chart structure tend to optimize for only part of the organization, ignoring upstream and downstream effects. Local optimizations help the teams directly involved, but they don’t necessarily help improve the overall delivery of value to customers. Their impact might be negligent if there are larger bottlenecks in the stream of work." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"However, in a highly collaborative context filled with uncertainty over outcomes, relying on the org chart as a principal mechanism of splitting the work to be done leads to unrealistic expectations." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Organizations that rely too heavily on org charts and matrixes to split and control work often fail to create the necessary conditions to embrace innovation while still delivering at a fast pace. In order to succeed at that, organizations need stable teams and effective team patterns and interactions. They need to invest in empowered, skilled teams as the foundation for agility and adaptability. To stay alive in ever more competitive markets, organizations need teams and people who are able to sense when context changes and evolve accordingly." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Systems thinking focuses on optimizing for the whole, looking at the overall flow of work, identifying what the largest bottleneck is today, and eliminating it." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Teams are always works in progress, but they are also your best shot at delivering value continuously and sustainably by aligning them with the business. Ideally, teams should be long lived and autonomous, with engaged team members. However, teams don’t live in isolation. They need to understand how and when to interact with each other. And these team interactions need to evolve over time to support the distinct phases of discovery and execution that products and technology go through during their lifetimes." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Teams take time to form and be effective. Typically, a team can take from two weeks to three months or more to become a cohesive unit. When (or if) a team reaches that special state, it can be many times more effective than individuals alone. If it takes three months for a team to become highly effective, we need to provide stability around and within the team to allow them to reach that level." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"The org chart does have its uses in the context of building software systems, specifically around regulatory and legal compliance. However, in a highly collaborative context filled with uncertainty over outcomes, relying on the org chart as a principal mechanism of splitting the work to be done leads to unrealistic expectations. We need to rely instead on decoupled, long-lived teams that can collaborate effectively to meet the challenge of balancing speed and safety." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"The problem with taking the org chart at face value is that we end up trying to architect people as if they were software, neatly keeping their communication within the accepted lines." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Trying to determine the cognitive load of software using simple measures such as lines of code, number of modules, classes, or methods is misguided. […] When measuring cognitive load, what we really care about is the domain complexity - how complex is the problem that we’re trying to solve with software? A domain is a more largely applicable concept than software size." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

⛩️Paul Butcher - Collected Quotes

"A blame culture is corrosive, eroding the team ethos that is vital for success. If they fear that they will be pilloried or punished for their mistakes, your colleagues will start worrying more about how to protect their back than doing what’s best for the team and wider organization. In the worst cases, this can even lead to lying, setting up fall guys, and other dysfunctional behavior." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Anti-patterns are the dark side of patterns - common mistakes we fall into repeatedly. Sometimes they seem to be good solutions that experience has demonstrated don’t work in practice. On other occasions, we know that they’re not a good idea, but we fall into them anyway." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Before you start trying to reproduce the problem or hypothesizing about its cause, you need to know exactly what is happening. And just as important, you need to know what should happen instead." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"But remember that refactoring should never be combined with modifying the functionality of the code, and that very definitely includes fixing bugs." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Diagnosis is the key element of debugging. This is where the rubber meets the road and you arrive at the understanding of the root cause of the behavior you’re seeing." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Every piece of code is built upon a platform of myriad assumptions - things that have to be true for it to behave as expected. More often than not, bugs arise because one or more of these assumptions are violated or turn out to be mistaken." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Everything you do is based upon a foundation of assumptions. You can’t possibly avoid making them, and it’s crazy to try - you can’t work from first principles every time. But assumptions are dangerous, because they create blind spots - things you treat as true without necessarily having direct evidence." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Experiments are a means to an end, not an end in themselves. There is no point performing an experiment unless it proves something." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"If you make a single change and see an effect, you can be pretty certain that the one caused the other. If you make more than one change, however, it can be very difficult to be sure which change resulted in which effect. Or the changes may interact in unpredictable ways. At best, this might mean that you are unable to conclude anything useful. At worst, you may reach misleading conclusions that lead you down completely the wrong path." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Most bugs are caused by simple oversights. Yes, occasionally you will be faced by something very subtle, but don’t overlook the simple things." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"One final point - whether fixing bugs or implementing new functionality, it’s good practice to always examine exactly what it is that you’re about to check in before every check-in. It won’t take long, and every once in a while, you’ll catch a change that you really didn’t intend to make from slipping through."  (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Part of the beauty of software is that it’s deterministic - the computer does exactly what you tell it to do, and, given the same starting point, it will do exactly the same thing every time." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Successful reproduction [of bugs] is all about control. If you control all the relevant variables, you will reproduce your problem. The trick, of course, is identifying which variables are relevant to the bug at hand, discovering what you need to set them to, and finding a way to do so." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"The best defence is to maintain a record of the experiments you’ve tried and what the results were. This doesn’t have to take a long time or include huge amounts of detail - just enough to ensure that you don’t forget what you’ve already done. Periodically review your notes to refresh your memory and help you identify the most promising next steps." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Writing and (particularly) maintaining software is a continual battle against entropy. Keeping on top of quality is tough, requiring high levels of discipline. This discipline is difficult enough to maintain under the best of circumstances, let alone when faced with concrete evidence that the software is uncared for, such as a long-unfixed bug. As soon as discipline slips, quality can go into a self-reinforcing downward spiral, and you’re in real trouble." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"We developers can easily develop blind spots. We necessarily have a different perspective from our users, and that can mean we miss important information that would be obvious to someone who understands things from their point of view. Furthermore, our focus tends to be on working out how to make the software work, not proving that it’s broken." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Refactoring is the process of improving the design of existing code without changing its behavior. [...] Bug fixing often uncovers opportunities for refactoring. The very fact that you’re working with code that contains a bug indicates that there is a chance that it could be clearer or better structured." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

⛩️Scott Rosenberg - Collected Quotes

"Because it so often takes ages before a new piece of software is ready for anyone to use, programmers often test their assumptions against 'use cases' hypothetical scenarios about how imaginary people might need or want to use a program." (Scott Rosenberg, "Dreaming in Code", 2007)

"Communicating abstractions unambiguously - from programmer to machine, from programmer to programmer, and from program to user - is the single most challenging demand of software development." (Scott Rosenberg, "Dreaming in Code", 2007)

"Despite the odds - despite complexity and delay and unpredictable change - a lot of software somehow does get written and delivered and, finally, used. Occasionally, it’s even good. Rarely, it actually does something new and valuable. And in a handful of cases, it achieves all of that on schedule." (Scott Rosenberg, "Dreaming in Code", 2007)

"Ending up somewhere entirely different from where you expected to go is the norm in this world. Software projects are prime illustrations of the law of unintended consequences, and their innovations and breakthroughs are more often side effects than planned outcomes." (Scott Rosenberg, "Dreaming in Code", 2007)

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

"Every software project in history has had its loose wires. Every effort to improve the making of software is an effort to keep them tight." (Scott Rosenberg, "Dreaming in Code", 2007)

"For programmers, just as for writers and artists and everyone whose work involves starting with a blank slate, the 'funnest' time of a project often falls at the very beginning, when worlds of giddy possibility lie open, and before painful compromises have shut any doors." (Scott Rosenberg, "Dreaming in Code", 2007)

"[…] in software development, as in all things, plans get dodgier the farther into the future one looks. Any developer who has been around the block will admit that the cavalcade of methodologies over three decades of software history has left the field richer and given programmers useful new tools and ways of thinking about their work. But finding a developer or team that actually subscribes to a particular methodology isn’t easy." (Scott Rosenberg, "Dreaming in Code", 2007)

"In software management, coordination is not an afterthought or an ancillary matter; it is the heart of the work, and deciding what tools and methods to use can make or break a project. But getting sidetracked in managing those tools is a potent temptation." (Scott Rosenberg, "Dreaming in Code", 2007)

"In the binary digital world of computers, all information is reduced to sequences of zeros and ones. But there’s a space between zero and one, between the way the machine counts and thinks and the way we count and think." (Scott Rosenberg, "Dreaming in Code", 2007)

"In the world of software, integration means taking a body of code that works fine by itself and connecting it to the other existing parts of a program that have in turn been working fine. The integration point is typically where a software project hits big trouble. Chunks of code that worked well enough separately often balk when asked to work together; they fail to hook together correctly, send messages that can’t be interpreted, or stubbornly refuse to start or stop." (Scott Rosenberg, "Dreaming in Code", 2007)

"It’s difficult not to have a love/hate relationship with computer programming if you have any relationship with it at all." (Scott Rosenberg, "Dreaming in Code", 2007)

"It’s tempting to view the multitude of monster projects gone bad as anomalies, excrescences of corporate and government bureaucracies run amok. But you will find similar tales of woe emerging from software projects big and small, public and private, old and new. Though details differ, the pattern is depressingly repetitive: Moving targets. Fluctuating goals. Unrealistic schedules. Missed deadlines. Ballooning costs. Despair. Chaos." (Scott Rosenberg, "Dreaming in Code", 2007)

"Late binding is a term in computer science that refers to programming languages’ capacity to provide programmers with more flexibility. Late-bound programs can be changed on the fly, while they’re running; you can even build them so that they change themselves while they’re running." (Scott Rosenberg, "Dreaming in Code", 2007)

"Life is harder without a 'source of truth'. For programmers as for other human beings, a canonical authority can be convenient. It rescues you from having to figure out how to adjudicate dilemmas on your own." (Scott Rosenberg, "Dreaming in Code", 2007)

"Like a black hole or any similar rent in the warp and woof of space-time, a singularity is a disruption of continuity, a break with the past. It is a point at which everything changes, and a point beyond which we can’t see." (Scott Rosenberg, "Dreaming in Code", 2007)

"Mathematically speaking, 'recursion' describes a function that calls itself; in computer science, recursion refers to defining a function in terms of itself. The logic of recursion allows simple, compact statements to generate complex and elaborate output." (Scott Rosenberg, "Dreaming in Code", 2007)

"No programmer will want to build something from scratch if he can grab something that is already written and adapt it to new ends." (Scott Rosenberg, "Dreaming in Code", 2007)

"Object-oriented techniques organize programs not around sequential lines of commands but instead around chunks of code called objects that spring to life and action when other objects call on them. Objects relate to other objects via strictly defined inputs and outputs, so that programmers writing code that must interact with them need not concern themselves with what’s happening inside them." (Scott Rosenberg, "Dreaming in Code", 2007)

"Old code rarely offers trendy graphics or flavor-of-the-month features, but it has one considerable ad - vantage: It tends to work. A program that has been well used is like an old garden that has been well tended or a vintage guitar that has been well played: Its rough edges have been filed away, its bugs have been found and fixed, and its performance is a known and valuable quantity." (Scott Rosenberg, "Dreaming in Code", 2007)

"One great irony inherent in the management of software projects is that despite the digital precision of the materials programmers work with, the enterprise of writing software is uniquely resistant to measurement." (Scott Rosenberg, "Dreaming in Code", 2007)

"Our civilization runs on software. Yet the art of creating software continues to be a dark mystery, even to the experts. Never in history have we depended so completely on a product that so few know how to make well. There is a big and sometimes frightening gap between our accelerating dependence on software systems and the steady but slow progress in our knowledge of how to make them soundly. The dependence has increased exponentially, while the skill - and the will to apply it -advances only along a plodding line." (Scott Rosenberg, "Dreaming in Code", 2007)

"People write programs. That statement is worth pausing over. People write programs. Despite the field’s infatuation with metaphors like architecture and bridge-building and its dabbling in alternative models from biology or physics, the act of programming today remains an act of writing - of typing character after character, word after word, line after line." (Scott Rosenberg, "Dreaming in Code", 2007)

"Programmers are motivated and led toward their best work by a desire to accomplish something that pleases them or fulfills a personal need." (Scott Rosenberg, "Dreaming in Code", 2007)

"Silos are everywhere. […] Silos are common because they are simple, reliable, and unambiguous." (Scott Rosenberg, "Dreaming in Code", 2007)

"So if programmers are optimists by nature, they also have a keen eye for the downside. A hyper-active imagination for disaster scenarios is a professional asset; they have to think through everything that can go wrong in order to practice their craft." (Scott Rosenberg, "Dreaming in Code", 2007)

"Software is abstract and therefore seems as if it should be infinitely malleable. And yet, for all its ethereal flexibility, it can be stubbornly, maddeningly intractable, and it is constantly surprising us with its rigidity." (Scott Rosenberg, "Dreaming in Code", 2007)

"Software is different; it has no core. It is onionlike, a thing of layers, each built painstakingly and precariously on the previous one, each counting on the one below not to move or change too much. Software builders like to talk about laying bricks; skeptics see a house of cards. Either way, there’s a steady accumulation going on. New layers pile on old. Programmers call these accretions 'layers of abstraction', because each time a new one is added, something complex and specific is being translated into something simpler and more general." (Scott Rosenberg, "Dreaming in Code", 2007)

"Software is easy to make, except when you want it to do something new. And then, of course, there is a corollary: The only software that's worth making is software that does something new." (Scott Rosenberg, "Dreaming in Code", 2007)

"The names programmers adopt for their abstractions are, as geeks like to say, 'nontrivial'. In software, labels and names matter; they are the handles by which you grab things." (Scott Rosenberg, "Dreaming in Code", 2007)

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

"The spec is the programmer’s bible, and, typically, the programmer is a fundamentalist: The spec’s word is law. Programmers are also, by nature and occupational demand, literal-minded. So the creation of specs calls for care and caution: You need to be careful what you wish for, as in a fairy tale." (Scott Rosenberg, "Dreaming in Code", 2007)

"There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won’t handle are the very parts that make your new project different, unique, innovative - and they’re why you’re building it in the first place." (Scott Rosenberg, "Dreaming in Code", 2007)

"There is no reliable relationship between the volume of code produced and the state of completion of a program, its quality, or its ultimate value to a user." (Scott Rosenberg, "Dreaming in Code", 2007)

"To programmers, refactoring means rewriting a chunk of code to make it briefer, clearer, and easier to read without changing what it actually does. Refactoring is often compared to gardening; it is never finished." (Scott Rosenberg, "Dreaming in Code", 2007)

"Users may be annoyed by bugs, and software developers may be disappointed by their inability to perfect their work, and managers may be frustrated by the unreliability of their plans. But in the end, none of that matters as much as the simple fact that software does not work the way we think, and until it does, it is not worth trying to perfect." (Scott Rosenberg, "Dreaming in Code", 2007)

"Well-commented code is one hallmark of good programming practice; it shows that you care about what you’re doing, and it is considerate to those who will come after you to fix your bugs. But comments also serve as a kind of back channel for programmer-to-programmer communication and even occasionally as a competitive arena or an outlet for silliness." (Scott Rosenberg, "Dreaming in Code", 2007)

"When people dream of streamlining the work of making software, most often they dream of standardized plug-in parts." (Scott Rosenberg, "Dreaming in Code", 2007)

"When we move some aspect of our lives into software code, it’s easy to be seduced by novel possibilities while we overlook how much we may be giving up. A well-designed program will make the most of those new capabilities without attempting to go against the grain of the physical world orientation that evolution has bequeathed us." (Scott Rosenberg, "Dreaming in Code", 2007)

"Writing the spec, a document that lays out copiously detailed instructions for the programmer, is a necessary step in any software building enterprise where the ultimate user of the product is not the same person as the programmer. The spec translates requirements - the set of goals or desires the software developer’s customers lay out - into detailed marching orders for the programmer to follow." (Scott Rosenberg, "Dreaming in Code", 2007)

⛩️Girish Suryanarayana - Collected Quotes

"A software design can be described as a collection of design decisions. These design decisions include decisions about what classes should be included, how classes should behave, and how they should interact with each other. Each and every design decision is influenced by previously made design decisions, constraints on the design, and the requirements. In turn, every design decision also impacts the design; it can narrow down the set of future design decisions considerably or widen the scope of possible design decisions. In other words, each and every design decision impacts and even changes the context of the design." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

"An important enabling technique to effectively apply the principle of abstraction is to assign single and meaningful responsibility for each abstraction. In particular, the Single Responsibility Principle says that an abstraction should have a single well-defined responsibility and that responsibility should be entirely encapsulated within that abstraction. An abstraction that is suffering from Multifaced Abstraction has more than one responsibility assigned to it, and hence violates the principle of abstraction." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

"Given the significance of technical debt, it is important to be able to measure it. A prerequisite for measuring something is to be able to quantify it. In this context, technical debt is very difficult to quantify accurately. There are two main reasons for this. First, there is no clear consensus on the factors that contribute to technical debt. Second, there is no standard way to measure these factors." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

"How does a smell manifest in design? A smell occurs as a result of a combination of one or more design decisions. In other words, the design ecosystem itself is responsible for the creation of the smell. The presence of the smell in turn impacts the ecosystem in several ways. First, it is likely that the presence of the smell triggers new design decisions that are needed to address the smell! Second, the smell can potentially influence or constrain future design decisions as a result of which one or more new smells may manifest in the ecosystem. Third, smells also tend to have an effect on other smells. For instance, some smells amplify the effects of other smells, or co-occur with or act as precursors to other smells. Clearly, smells share a rich relationship with the ecosystem in which they occur." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

"Technical debt is the debt that accrues when you knowingly or unknowingly make wrong or non-optimal design decisions. [...] when a software developer opts for a quick fix rather than a proper well-designed solution, he introduces technical debt. It is okay if the developer pays back the debt on time. However, if the developer chooses not to pay or forgets about the debt created, the accrued interest on the technical debt piles up, just like financial debt, increasing the overall technical debt. The debt keeps increasing over time with each change to the software; thus, the later the developer pays off the debt, the more expensive it is to pay off. If the debt is not paid at all, then eventually the pile-up becomes so huge that it becomes immensely difficult to change the software. In extreme cases, the accumulated technical debt is so huge that it cannot be paid off anymore and the product has to be abandoned. Such a situation is called technical bankruptcy." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

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

"The principle of abstraction advocates the simplification of entities through reduction and generalization: reduction is by elimination of unnecessary details and generalization is by identification and specification of common and important characteristics." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

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

"The principle of hierarchy advocates the creation of a hierarchical organization of abstractions using techniques such as classification, generalization, substitutability, and ordering." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

"The principle of modularization advocates the creation of cohesive and loosely coupled abstractions through techniques such as localization and decomposition." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

"Why is the interest compounding in nature for technical debt? One major reason is that often new changes introduced in the software become interwoven with the debt-ridden design structure, further increasing the debt. Further, when the original debt remains unpaid, it encourages or even forces developers to use 'hacks' while making changes, which further compounds the debt." (Girish Suryanarayana et al, "Refactoring for Software Design Smells: Managing Technical Debt", 2015)

⛩️Martin Fowler - Collected Quotes

"It is commonly said that a pattern, however it is written, has four essential parts: a statement of the context where the pattern is useful, the problem that the pattern addresses, the forces that play in forming a solution, and the solution that resolves those forces. [...] it supports the definition of a pattern as 'a solution to a problem in a context', a definition that [unfortunately] fixes the bounds of the pattern to a single problem-solution pair. (Martin Fowler, "Analysis Patterns: Reusable Object Models", 1997)

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

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

"Before you start refactoring, check that you have a solid suite of tests. These tests must be self-checking." (Martin Fowler et al, "Refactoring: Improving the Design of Existing Code", 2002)

"One problem area for refactoring is databases. Most business applications are tightly coupled to the database schema that supports them. That's one reason that the database is difficult to change. Another reason is data migration. Even if you have carefully layered your system to minimize the dependencies between the database schema and the object model, changing the database schema forces you to migrate the data, which can be a long and fraught task." (Martin Fowler et al, "Refactoring: Improving the Design of Existing Code", 2002)

"People also underestimate the time they spend debugging. They underestimate how much time they can spend chasing a long bug. With testing, I know straight away when I added a bug. That lets me fix the bug immediately, before it can crawl off and hide. There are few things more frustrating or time wasting than debugging. Wouldn't it be a hell of a lot quicker if we just didn't create the bugs in the first place?" (Martin Fowler, 2002)

"Refactoring is risky. It requires changes to working code that can introduce subtle bugs. Refactoring, if not done properly, can set you back days, even weeks. And refactoring becomes riskier when practiced informally or ad hoc." (Erich Gamma, 2002)

"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written." (Martin Fowler et al, "Refactoring: Improving the Design of Existing Code", 2002)

"Refactoring changes the programs in small steps. If you make a mistake, it is easy to find the bug." (Martin Fowler et al, "Refactoring: Improving the Design of Existing Code", 2002)

"Without refactoring, the design of the program will decay. As people change code - changes to realize short-term goals or changes made without a full comprehension of the design of the code - the code loses its structure. It becomes harder to see the design by reading the code. Refactoring is rather like tidying up the code. Work is done to remove bits that aren't really in the right place. Loss of the structure of code has a cumulative effect. The harder it is to see the design in the code, the harder it is to preserve it, and the more rapidly it decays. Regular refactoring helps code retain its shape." (Martin Fowler et al, "Refactoring: Improving the Design of Existing Code", 2002)

"There are many things that make software development complex. But the heart of this complexity is the essential intricacy of the problem domain itself. If you’re trying to add automation to complicated human enterprise, then your software cannot dodge this complexity - all it can do is control it." (Martin Fowler, [forward] 2003)

"The key to controlling complexity is a good domain model, a model that goes beyond a surface vision of a domain by introducing an underlying structure, which gives the software developers the leverage they need. A good domain model can be incredibly valuable, but it’s not something that’s easy to make. Few people can do it well, and it’s very hard to teach." (Martin Fowler, [forward] 2003)

"Graphical design notations have been with us for a while [...] their primary value is in communication and understanding. A good diagram can often help communicate ideas about a design, particularly when you want to avoid a lot of details. Diagrams can also help you understand either a software system or a business process. As part of a team trying to figure out something, diagrams both help understanding and communicate that understanding throughout a team. Although they aren't, at least yet, a replacement for textual programming languages, they are a helpful assistant." (Martin Fowler, "UML Distilled: A Brief Guide to the Standard Object Modeling", 2004)

"Often designers do complicated things that improve the capacity on a particular hardware platform when it might actually be cheaper to buy more hardware." (Martin Fowler, "Patterns of Enterprise Application Architecture", 2012)

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring." (Martin Fowler)