⛩️Erich Gamma - Collected Quotes

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

"Design patterns help you define interfaces by identifying their key elements and the kinds of data that get sent across an interface. A design pattern might also tell you what not to put in the interface. [...] Design patterns also specify relationships between interfaces. In particular, they often require some classes to have similar interfaces, or they place constraints on the interfaces of some classes." (Erich Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

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

"Design patterns should not be applied indiscriminately. Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and/or cost you some performance. A design pattern should only be applied when the flexibility it affords is actually needed." (Erich Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

"The choice of programming language is important because it influences one's point of view." (Erich Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

⛩️Alistair Cockburn - Collected Quotes

"A methodology is the conventions that your group agrees to. 'The conventions your group agrees to' is a social construction." (Alistair Cockburn, "Agile Software Development", 2001)

"A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology may help or hinder them along the way)." (Alistair Cockburn, "Agile Software Development", 2001)

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

"Software development is a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game. The next game may be to alter or replace the system or to create a neighboring system." (Alistair Cockburn, "Agile Software Development: The Cooperative Game" 2nd Ed., 2006)

"[…] Software development is a cooperative game, in which the participants help each other in reaching the end of the game - the delivery of software […]" (Alistair Cockburn, "Agile Software Development: The Cooperative Game" 2nd Ed., 2006)

"Heart of Agile is a meme. Heart of Agile is four words stripped down to nothing. It contains only four words – collaborate, deliver, reflect, improve." (Alistair Cockburn, [interview] 2017)

⛩️Bill Gates - Collected Quotes

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

"Developments on the Internet over the next several years will set the course of our industry for a long time to come." (Bill Gates, "Internet Tidal Wave", [Microsoft internal memo], 1995)

"Software is a great combination between artistry and engineering." (Bill Gates, "Bill Gates Speaks: Insight from the World's Greatest Entrepreneur", 1998)

"A bad strategy will fail no matter how good your information is and lame execution will stymie a good strategy. If you do enough things poorly, you will go out of business." (Bill Gates, "Business @ the Speed of Thought: Succeeding in the Digital Economy", 2009)

"Bringing together the right information with the right people will dramatically improve a company's ability to develop and act on strategic business opportunities." (Bill Gates,  "Business @ the Speed of Thought: Succeeding in the Digital Economy", 2009) 

"Teams should be able to act with the same unity of purpose and focus as a well-motivated individual." (Bill Gates, "Business @ the Speed of Thought: Succeeding in the Digital Economy", 2009)

"The most meaningful way to differentiate your company from your competitors, the best way to put distance between you and the crowd is to do an outstanding job with information. How you gather, manage and use information will determine whether you win or lose." (Bill Gates, "Business @ the Speed of Thought: Succeeding in the Digital Economy", 2009)

"[...] the rules for running a strong business and creating value haven’t changed. For one thing, there’s an essential human factor in every business endeavor. It doesn’t matter if you have a perfect product, production plan and marketing pitch; you’ll still need the right people to lead and implement those plans. That is a lesson you learn quickly in business [...]" (Bill Gates, "Bill Gates’ Favorite Business Book", Wall Street Journal Online, 2014)

"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." (Bill Gates)

⛩️Morgan Evans - Collected Quotes

"A heuristic is a mental shortcut for easing the cognitive load of making decisions. Heuristics help us to make decisions in our day-to-day lives, but they can also lead us to wrong decisions or illogical conclusions. As engineering managers, an understanding of the most common heuristics can help us to avoid unconscious biases in our decision processes and recognize them in the behaviors and actions of others." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"An effort estimate is not complete without including its assumptions. Estimate assumptions include any and all underlying factors the estimate relies upon. Assumptions are especially important in more rigid estimation environments, but they are a good practice even where expectations are more flexible. Explicitly listing all assumptions helps to remove ambiguity and avoid misunderstandings during project delivery." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Beliefs must be reflected in actions to become a part of your leadership style. Your actions develop and strengthen the abilities that support your leadership style. Practicing your beliefs cements them into skills and resources." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Engineering managers have a responsibility to optimize their teams. They improve engineering workflows and reduce dependencies and repetitive tasks. Self-sustaining teams minimize dependencies that hinder them in their efforts to achieve their objectives. Scalable teams minimize software delivery steps and eliminate bottlenecks. The mechanisms to achieve this may include the use of tools, conventions, documentation, processes, or abstract things such as values and principles. Any action that produces a tangible improvement in the speed, reliability, or robustness of your team’s work is worth your consideration." (Morgan Evans, "Engineering Manager's Handbook", 2023)

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

"Great engineering managers find ways to give work meaning and make that meaning broadly understood. They align the realities of the engineering work they are tasked with to the aspirations and beliefs of their team members. [...] For your engineers, translating the why in a way they can understand and accept is a powerful tool for alignment and guiding decisions in the direction you want. [...] Translating outside of your team and upward to leadership (managing up) is oftentimes the most impactful translation of all." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"[...] high-accountability teams are characterized by having members that are willing and able to resolve issues within the team. They take responsibility for their own actions and hold each other accountable. They take ownership of resolving disputes and feel empowered to do so without intervention from others. They learn quickly by identifying issues and solutions together, adopting better patterns over time. They are able to work without delay because they don’t need anyone else to resolve problems. Their managers are able to work more strategically without being bogged down by day-to-day conflict resolution." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"In a workplace setting, accountability is the willingness to take responsibility for one’s actions and their outcomes. Accountable team members take ownership of their work, admit their mistakes, and are willing to hold each other accountable as peers." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"In addition to knowing what to do, good engineering management entails knowing what not to do. The wrong actions on our part as managers can damage the trust placed in us by our teams. We might learn the hard way through painful failures, but occasionally, we are lucky enough to learn these lessons from the experiences of others. " (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Low-accountability teams can be recognized based on their tendency to shift blame, avoid addressing issues within the team, and escalate most problems to their manager. In low-accountability teams, it is difficult to determine the root of problems, failures are met with apathy, and managers have to spend much of their time settling disputes and addressing performance. Members of low-accountability teams believe it is not their role to resolve disputes and instead shift that responsibility up to the manager, waiting for further direction. These teams fall into conflict and avoidance deadlocks, unable to move quickly because they cannot resolve issues within the team."

"Software architecture is the process and product of creating technical systems designs. Architecture may include a specification of resources, patterns, conventions, and communication protocols, among other details." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Systems architecture is the portion of any project over which the engineering team has the most control. This design is usually less of a collaboration between different functions and more clearly in the domain of engineers. As such, engineering managers have a high responsibility to own this process and its decisions. To produce the best decisions possible, you must have the right decision-building blocks: complete information to work from and a structured methodology to guide you." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Plans allow us to think through objectives beforehand in the hope of being prepared for delivery. Plans are useful when they preempt conflict, direct efforts in harmony, and align expectations. Plans are not useful when they waste valuable build time or provide a false sense of security, for example, by missing unknown unknowns." (Morgan Evans, "Engineering Manager's Handbook", 2023)

⛩️Boris Beizer - Collected Quotes

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

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

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

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

"Programmers are responsible for software quality - quality in their own work, quality in the products that incorporate their work, and quality at the interfaces between components. Quality has never been and will never be tested in. The responsibility is both moral and professional." (Boris Beizer, "Software Testing Techniques", 1990)

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

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

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

"Software never was perfect and won't get perfect. But is that a license to create garbage? The missing ingredient is our reluctance to quantify quality." (Boris Beizer, "Software Testing Techniques", 1990)

"Third law: Code migrates to data. Because of this law there is increasing awareness that bugs in code are only half the battle and that data problems should be given equal attention."  (Boris Beizer, "Software Testing Techniques", 1990)

"The most common kind of coding bug, and often considered the least harmful, are documentation bugs (i.e., erroneous comments). Although many documentation bugs are simple spelling errors or the result of poor writing, many are actual errors - that is, misleading or erroneous comments. We can no longer afford to discount such bugs, because their consequences are as great as 'true' coding errors. Today programming labor is dominated by maintenance. This will increase as software becomes even longer-lived. Documentation bugs lead to incorrect maintenance actions and therefore cause the insertion of other bugs." (Boris Beizer, "Software Testing Techniques", 1990)

⛩️Diego Rasskin-Gutman - Colected Quotes

"A chess hypothesis is basically the equivalent to drawing up a strategic plan. Experimentation in chess is equivalent to the moves that are found to carry out each plan. Throughout the history of chess, both the plans (the hypotheses) as well as the moves (the experiments) have been evolving (thanks to results from the practice of the game and from analyses), and this knowledge is the patrimony of professional players." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

"An algorithm refers to a successive and finite procedure by which it is possible to solve a certain problem. Algorithms are the operational base for most computer programs. They consist of a series of instructions that, thanks to programmers’ prior knowledge about the essential characteristics of a problem that must be solved, allow a step-by-step path to the solution." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

"Any scientific hypothesis springs from knowledge that was previously generated by observations of facts in the real world. In addition, hypotheses produce predictions that need to be tested. For some, scientific definitions are limited to natural phenomena (although this definition would require mathematics to stop being a science since it deals with ideal objects)." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

"The brain and its cognitive mental processes are the biological foundation for creating metaphors about the world and oneself. Artificial intelligence, human beings’ attempt to transcend their biology, tries to enter into these scenarios to learn how they function. But there is another metaphor of the world that has its own particular landscapes, inhabitants, and laws. The brain provides the organic structure that is necessary for generating the mind, which in turn is considered a process that results from brain activity." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

"The problem of identifying the subset of good moves is much more complicated than simply counting the total number of possibilities and falls completely into the domain of strategy and tactics of chess as a game." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

"Generally, these programs fall within the techniques of reinforcement learning and the majority use an algorithm of temporal difference learning. In essence, this computer learning paradigm approximates the future state of the system as a function of the present state. To reach that future state, it uses a neural network that changes the weight of its parameters as it learns." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

"The simplest basic architecture of an artificial neural network is composed of three layers of neurons - input, output, and intermediary (historically called perceptron). When the input layer is stimulated, each node responds in a particular way by sending information to the intermediary level nodes, which in turn distribute it to the output layer nodes and thereby generate a response. The key to artificial neural networks is in the ways that the nodes are connected and how each node reacts to the stimuli coming from the nodes it is connected to. Just as with the architecture of the brain, the nodes allow information to pass only if a specific stimulus threshold is passed. This threshold is governed by a mathematical equation that can take different forms. The response depends on the sum of the stimuli coming from the input node connections and is 'all or nothing'." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

"Vision is a capacity to understand a position and to generate solid strategic plans." (Diego Rasskin-Gutman, "Chess Metaphors: Artificial Intelligence and the Human Mind", 2009)

⛩️Jake Knapp - Collected Quotes

"Because of the short timeline, it’s tempting to jump into prototyping as soon as you’ve selected your winning ideas. But if you start prototyping without a plan, you’ll get bogged down by small, unanswered questions. Pieces won’t fit together, and your prototype could fall apart." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"But perhaps the biggest problem is that the longer you spend working on something - whether it’s a prototype or a real product - the more attached you’ll become, and the less likely you’ll be to take negative test results to heart. After one day, you’re receptive to feedback. After three months, you’re committed." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"No problem is too large for a sprint. Yes, this statement sounds absurd, but there are two big reasons why it’s true. First, the sprint forces your team to focus on the most pressing questions. Second, the sprint allows you to learn from just the surface of a finished product." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"Sometimes, the best way to broaden your search is to look inside your own organization. Great solutions often come along at the wrong time, and the sprint can be a perfect opportunity to rejuvenate them. Also look for ideas that are in progress but unfinished - and even old ideas that have been abandoned." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"Sometimes when people work together in groups, they start to worry about consensus and try to make decisions that everybody will approve - mostly out of good nature and a desire for group cohesion, and perhaps in part because democracy feels good. Well, democracy is a fine system for governing nations, but it has no place in your sprint." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"Sometimes you can’t fit everything in. Remember that the sprint is great for testing risky solutions that might have a huge payoff. So you’ll have to reverse the way you would normally prioritize. If a small fix is so good and low-risk that you’re already planning to build it next week, then seeing it in a prototype won’t teach you much. Skip those easy wins in favor of big, bold bets." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"The prototype is meant to answer questions, so keep it focused. You don’t need a fully functional product - you just need a real-looking façade to which customers can react." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"There are only six working hours in the typical sprint day. Longer hours don’t equal better results. By getting the right people together, structuring the activities, and eliminating distraction, we’ve found that it’s possible to make rapid progress while working a reasonable schedule." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"When a big problem comes along, like the challenge you selected for your sprint, it’s natural to want to solve it right away. The clock is ticking, the team is amped up, and solutions start popping into everyone’s mind. But if you don’t first slow down, share what you know, and prioritize, you could end up wasting time and effort on the wrong part of the problem." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

"You can prototype anything. Prototypes are disposable. Build just enough to learn, but not more. The prototype must appear real." (Jake Knapp et al, "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days", 2016)

⛩️Edsger W Dijkstra - Collected Quotes

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

"Program testing can be used to show the presence of bugs, but never to show their absence!" (Edsger W Dijkstra, "Notes on Structured Programming", 1970)

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

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

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

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

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

"How do we convince people that in programming simplicity and clarity - in short: what mathematicians call 'elegance' - are not a dispensable luxury, but a crucial matter that decides between success and failure?" (Edsger W Dijkstra, "'Why is software so expensive?' An explanation to the hardware designer", 1982)

"Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter 'How to program if you cannot'." (Edsger W Dijkstra, "On the cruelty of really teaching computing science", 1988)

The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. (Edsger W Dijkstra, "Answers to questions from students of Software Engineering”, 2000)

"The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." (Edsger Dijkstra)