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

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