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

⛩️Frederick P Brooks - Collected Quotes

"A basic principle of data processing teaches the folly of trying to maintain independent files in synchronism. It is far better to combine them into one file with each record containing all the information both files held concerning a given key." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"A baseball manager recognizes a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. It is essential for great programming teams, too. Hustle provides the cushion, the reserve capacity, that enables a team to cope with routine mishaps, to anticipate and forfend minor calamities. The calculated response, the measured effort, are the wet blankets that dampen hustle. As we have seen, one must get excited about a one-day slip. Such are the elements of catastrophe." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"A computer program is a message from a man to a machine. The rigidly marshaled syntax and the scrupulous definitions all exist to make intention clear to the dumb engine." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"A good information system both exposes interface errors and stimulates their correction" (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"A good top-down design avoids bugs in several ways. First, the clarity of structure and representation makes the precise statement of requirements and functions of the modules easier. Second, the partitioning and independence of modules avoids system bugs. Third, the suppression of detail makes flaws in the structure more apparent. Fourth, the design can be tested at each of its refinement steps, so testing can start earlier and focus on the proper level of detail at each step." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

[Brook's Law:] "Adding manpower to a late software project makes it later." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"All programmers are optimists. [...] Computer programming, however, creates with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Because ease of use is the purpose, this ratio of function to conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design. [...] Function, and not simplicity, has always been the measure of excellence for its designers." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"By the architecture of a system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a compiler it is the language manual. For a control program it is the manuals for the language or languages used to invoke its functions. For the entire system it is the union of the manuals the user must consult to do his entire job." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Clearly, methods of designing programs so as to eliminate or at least illuminate side effects can have an immense payoff in maintenance costs. So can methods of implementing designs with fewer people, fewer interfaces, and hence fewer bugs." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Conceptual integrity is the most important consideration in system design. [,..] For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. [...] Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Different levels of documentation are required for the casual user of a program, for the user who must depend upon a program, and for the user who must adapt a program for changes in circumstance or purpose." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Far be it from me to suggest that all changes in customer objectives and requirements must, can, or should be incorporated in the design. Clearly a threshold has to be established, and it must get higher and higher as development proceeds, or no product ever appears." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Flow charts show the decision structure of a program, which is only one aspect of its structure. They show decision structure rather elegantly when the flow chart is on one page, but the overview breaks down badly when one has multiple pages, sewed together with numbered exits and connectors." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"How does one control a big project on a tight schedule? The first step is to have a schedule." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"It is very difficult to make a vigorous, plausible, and jobrisking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"More software projects have gone awry for lack of calendar time than for all other causes combined. Why is this cause of disaster so common?
First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well. Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef. Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering. Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Much more often, strategic breakthrough will come from redoing the representation of the data or tables. This is where the heart of a program lies. [...] Representation is the essence of programming." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Nevertheless, some changes in objectives are inevitable, and it is better to be prepared for them than to assume that they won't come. Not only are changes in objective inevitable, changes in development strategy and technique are also inevitable. The throw-one-away concept is itself just an acceptance of the fact that as one learns, he changes the design." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"No amount of space budgeting and control can make a program small. That requires invention and craftsmanship. [...] Beyond craftsmanship lies invention, and it is here that lean, spare, fast programs are born. Almost always these are the result of stategic breakthrough rather than tactical cleverness." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Of course the technological base on which one builds is always advancing. As soon as one freezes a design, it becomes obsolete in terms of its concepts. But implementation of real products demands phasing and quantizing. The obsolescence of an implementation must be measured against other existing implementations, not against unrealized concepts. The challenge and the mission are to find real solutions to real problems on actual schedules with available resources." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"[...] on the larger project each of the roles is necessarily a full-time job, or more." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Program maintenance involves no cleaning, lubrication, or repair of deterioration. It consists chiefly of changes that repair design defects. Much more often than with hardware, these changes include added functions. Usually they are visible to the user." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Structuring an organization for change is much harder than designing a system for change. Each man must be assigned to jobs that broaden him, so that the whole force is technically flexible. [...] Management structures also need to be changed as the system changes." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The added burden of communication is made up of two parts, training and intercommunication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The boss must first distinguish between action information and status information. He must discipline himself not to act on problems his managers can solve, and never to act on problems when he is explicitly reviewing status." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The flow chart is a most thoroughly oversold piece of program documentation. Many programs don't need flow charts at all; few programs need more than a one-page flow chart. [...] In fact, flow charting is more preached than practiced." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

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

"The means by which communication is obviated are division of labor and specialization of function." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

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

"The project workbook is not so much a separate document as it is a structure imposed on the documents that the project will be producing anyway. [...] The early design of the project workbook ensures that the documentation structure itself is crafted, not haphazard. [...] The second reason for the project workbook is control of the distribution of information. The problem is not to restrict information, but to ensure that relevant information gets to all the people who need it." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The purpose of a programming system is to make a computer easy to use. To do this, it furnishes languages and various facilities that are in fact programs invoked and controlled by language features. But these facilities are bought at a price: the external description of a programming system is ten to twenty times as large as the external description of the computer system itself. The user finds it far easier to specify any particular function, but there are far more to choose from, and far more options and formats to remember." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The programmer's primary weapon in the never-ending battle against slow system is to change the intramodular structure. Our first response should be to reorganize the modules' data structures." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The separation of architectural effort from implementation is a very powerful way of getting conceptual integrity on very large projects." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The solution, I think, is to merge the files, to incorporate the documentation in the source program. This is at once a powerful incentive toward proper maintenance, and an insurance that the documentation will always be handy to the program user. Such programs are called self-documenting." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"The task of the manager is to develop a plan and then to realize it. But only the written plan is precise and communicable. Such a plan consists of documents on what, when, how much, where, and who. This small set of critical documents encapsulates much of the manager's work. If their comprehensive and critical nature is recognized in the beginning, the manager can approach them as friendly tools rather than annoying busywork. He will set his direction much more crisply and quickly by doing so." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Thinkers are rare; doers are rarer; and thinker-doers are rarest." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Why is programming fun? What delights may its practitioner expect as his reward?
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. [...] Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. [...] Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. [...] Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. [...] Finally, there is the delight of working in such a tractable medium." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be."

"Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. Much of the complexity he must master is arbitrary complexity [… ] because they were designed by different people, rather than by God." (Fred Brooks, "No Silver Bullet", 1986)

"The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence." (Frederick P Brooks, "No Silver Bullet", 1986)

"The essence of a software entity is a construct of interlocking concepts: […] I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation." (Fred Brooks, "No Silver Bullet", 1986)

⛩️Neal Ford - Collected Quotes

"All too often architects make a decision that is the correct decision at the time but becomes a bad decision over time because of changing conditions like dynamic equilibrium. For example, architects design a system as a desktop application, yet the industry herds them toward a web application as users’ habits change. The original decision wasn’t incorrect, but the ecosystem shifted in unexpected ways." (Neal Ford, "Building Evolutionary Architectures: Support Constant Change", 2017)

"By placing an external tool or framework at the heart of the architecture, developers severely restrict their ability to evolve in two key ways, both technically and from a business process standpoint. Developers are technically constrained by choices the vendor makes in terms of persistence, supported infrastructure, and a host of other constraints." (Neal Ford, "Building Evolutionary Architectures: Support Constant Change", 2017)

"DBAs who rarely genuinely restructure schemas build an increasingly fossilized world, with byzantine grouping and bunching strategies. When DBAs don’t restructure the database, they’re not preserving a precious enterprise resource, they’re instead creating the concretized remains of every version of the schema, all overlaid upon one another via join tables." (Neal Ford, "Building Evolutionary Architectures: Support Constant Change", 2017)

"Even if the ecosystem doesn’t change, what about the gradual erosion of architectural characteristics that occurs? Architects design architectures, but then expose them to the messy real world of implementing things atop the architecture. How can architects protect the important parts they have defined?" (Neal Ford, "Building Evolutionary Architectures: Support Constant Change", 2017)

"For any dimension in our architecture that requires protection from the side effects of evolution, we create fitness functions. A common practice in microservices architectures is the use of consumer-driven contracts, which are atomic integration architecture fitness functions." (Neal Ford, "Building Evolutionary Architectures: Support Constant Change", 2017)

"Metrics are a common adjunct to the deployment pipeline in incremental change environments. If teams use this effort as a proof-of-concept, developers should gather appropriate metrics for both before and after scenarios. Gathering concrete data is the best way to for developers to vet the approach; remember the adage that demonstration defeats discussion." (Neal Ford, "Building Evolutionary Architectures: Support Constant Change", 2017)

"The other new role that evolutionary architecture creates has enterprise architects defining enterprise-wide fitness functions. Enterprise architects are typically responsible for enterprise-wide nonfunctional requirements, such as scalability and security. Many organizations lack the ability to automatically assess how well projects perform individually and in aggregate for these characteristics. Once projects adopt fitness functions to protect parts of their architecture, enterprise architects can utilize the same mechanism to verify that enterprise-wide characteristics remain intact."  (Neal Ford, "Building Evolutionary Architectures: Support Constant Change", 2017)

⛩️Michael Hüttermann - Collected Quotes

"Agile development methods require a disciplined approach to ensure that customer feedback, continuous testing, and iterative development actually lead to frequent deliveries of working, valuable software." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"Agile development teams often view metrics as a onetime pointer instead of a continuous measurement. The pointer makes the current state of the software’s internal quality visible. It is then up to the team to decide when to adjust the code base or whether to do so at all. These pointers provide indicators that there’s something worth investigating, but they don’t provide the context and understanding needed to make critical decisions." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"Agile teams often do not distinguish between bugs, enhancements, or change requests. They use a general unit called change to track progress. Change seems to be a valid unit for both development and operations because operations teams primarily think in terms of changes to the production system. Using changes as a shared term for both development and operations makes it easier to stream production issues back to a work backlog (that is ideally shared by both groups)." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"Automation is an essential backbone of DevOps. Automation is the use of solutions to reduce the need for human work. Automation can ensure that the software is built the same way each time, that the team sees every change made to the software, and that the software is tested and reviewed in the same way every day so that no defects slip through or are introduced through human error." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"Conflicts between development and operations teams often originate from time pressures. Typically, a new software release must be deployed quickly. Another scenario that requires operations team to react quickly is when the system is down, and restoring it quickly becomes the highest priority. Th is situation often leads to a blame game where each side accuses the other of causing the problem." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"DevOps is a mix of patterns intended to improve collaboration between development and operations. DevOps addresses shared goals and incentives as well as shared processes and tools. Because of the natural conflicts among different groups, shared goals and incentives may not always be achievable. However, they should at least be aligned with one another." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"DevOps is about team play and a collaborative problem-solving approach. If a service goes down, everyone must know what procedures to follow to diagnose the problem and get the system up and running again. Additionally, all of the roles and skills necessary to perform these tasks must be available and able to work together well. Training and effective collaboration are critical here." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"DevOps is essentially about gaining fast feedback and decreasing the risk of releases through a holistic approach that is meaningful for both development and operations. One major step for achieving this approach is to improve the fl ow of features from their inception to availability. This process can be refined to the point that it becomes important to reduce batch size (the size of one package of changes or the amount of work that is done before the new version is shipped) without changing capacity or demand." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"Essential to improving collaboration is the alignment of incentives across teams as well as the application of shared processes and tools. The main attributes of aligned incentives include a shared definition of quality for the whole project or company and a commitment to it. Aligned with defined quality attributes, visibility and transparency can help to foster collaboration. Incentives must treat the development and operations groups as one team. That is, they should be rewarded for developing many changes that are stable and shipped."(Michael Hüttermann et al, "DevOps for Developers", 2013)

"Stability is often defined as a resilient system that keeps processing transactions, even if transient impulses (rapid shocks to the system), persistent stresses (force applied to the system over an extended period), or component failures disrupt normal processing." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"The advantages of Agile processes, including Scrum and Kanban (a method for delivering software with an emphasis on just-in-time delivery), are often nullified because of the obstacles to collaboration, processes, and tools that are built up in front of operations." (Michael Hüttermann et al, "DevOps for Developers", 2013)

⛩️Kent Beck - Collected Quotes

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

"Change is not necessarily slow. A team eager or desperate for improvement can progress quickly. It doesn't need to wait long to assimilate one change before moving on to the next practice. If you change too fast, though, you risk slipping back into old practices and values. When this happens, take time to regroup. Remind yourself of the values you want to hold. Review your practices and remind yourself why you chose them. New habits take time to solidify." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"Folk wisdom in software development teaches that interfaces shouldn't be unduly influenced by implementations. Writing a test first is a concrete way to achieve this separation." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"If there are forms of testing, like stress and load testing, that find defects after development is 'complete', bring them into the development cycle. Run load and stress tests continuously and automatically." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"In software development, 'perfect' is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"Inaccurate estimates are a failure of information, not of values or principles. If the numbers are wrong, fix the numbers and communicate the consequences." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"Pair programmers: Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team's practices." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren't." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"Simplicity only makes sense in context." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"The difference between what I think is valuable and what is really valuable creates waste." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"The XP philosophy is to start where you are now and move towards the ideal. From where you are now, could you improve a little bit?" (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"Often you'll see the same three or four data items together in lots of places: fields in a couple of classes, parameters in many method signatures. Bunches of data that hang around together really ought to be made into their own object." (Kent Beck, "Refactoring: Improving the Design of Existing Code", 1999)

"When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous." (Kent Beck, "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."  (Kent Beck, "Refactoring: Improving the Design of Existing Code", 1999)

"Write contracts for software development that fix time, costs, and quality but call for an ongoing negotiation of the precise scope of the system. Reduce risk by signing a sequence of short contracts instead of one long one." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)

"One of the purposes of planning is we always want to work on the most valuable thing possible at any given time. We can’t pick features at random and expect them to be most valuable. We have to begin development by taking a quick look at everything that might be valuable, putting all our cards on the table. At the beginning of each iteration the business (remember the balance of power) will pick the most valuable features for the next iteration." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"Optimism is an occupational hazard of programming: feedback is the treatment." (Kent Beck, "Extreme Programming Explained", 2000)

"Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn’t even be happy if it did, because by the time software gets there, the customers don’t want what was planned, they want something different." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"Projects sometimes fail long before they deliver anything. At some point they may be determined to be too expensive to continue. Or perhaps they took too long to develop and the business need evaporated. Or perhaps the requirements change so often that the developers can never finish one thing without having to stop and start all over on something new. Certainly these are planning failures." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"The business changes. The technology changes. The team changes. The team members change. The problem isn't change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes." (Kent Beck, Extreme Programming Explained, 2000)

"The new concept of Extreme Programming (XP) is gaining more and more acceptance, partially because it is controversial, but primarily because it is particularly well-suited to help the small software development team succeed. [...] XP is controversial, many software development sacred cows don't make the cut in XP; it forces practitioners to take a fresh look at how software is developed." (Kent Beck, "Abstract Extreme Programming Explained", 2000)

"There are two ways to approach prevention of these planning failures. We can plan not to lose, or we can plan to win. The two are not identical. Planning not to lose is defensive; while planning to win is aggressive.[...] the problem that planning is supposed to solve is simply, to build the right system at the right cost. If we take a defensive posture by planning not to lose, we will be able to hold people accountable for any failures; but at an enormous cost. If we take an aggressive posture and plan to win, we will be unafraid to make errors, and will continuously correct them to meet our goals." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"We plan because: We need to ensure that we are always working on the most important thing we need to do. We need to coordinate with other people. When unexpected events occur we need to understand the consequences for the first two." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

"When we plan to win we take direct steps to ensure that we are building the right system at the best possible cost. Every action we take goes towards that end. Instead of trying to plan everything up front, we plan just the next few steps; and then allow customer feedback to correct our trajectory. In this way, we get off the mark quickly, and then continuously correct our direction. Errors are unimportant because they will be corrected quickly." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)

⛩️Brian W Kernighan - Collected Quotes

"A clean design is more easily modified as requirements change or as more is learned about what parts of the code consume significant amounts of execution time. A 'clever' design that fails to work or to run fast enough can often be salvaged only at great cost. Efficiency does not have to be sacrificed in the interest of writing readable code - rather, writing readable code is often the only way to ensure efficient programs that are also easy to maintain and modify." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"A computer program is shaped by its data representation and the statements that determine its flow of control. These define the structure of a program. There is no sharp distinction between expression and organization; it is more a question of scope." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"A powerful tool for reducing apparent complexity is recursion. In a recursive procedure, the method of solution is defined in terms of itself. That is, each part of the routine handles only a small piece of the strategy, then calls the other parts of the routine as needed to handle the rest. The trick is to reduce each hard case to one that is handled simply elsewhere." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Choosing a better data structure is often an art, which we cannot teach. Often you must write a preliminary draft of the code before you can determine what changes in the data structure will help simplify control. [...] Choose a data representation that makes the program simple." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Don’t comment bad code - rewrite it." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Don't compare floating point numbers just for equality." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Don't diddle code to make it faster - find a better algorithm." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Don't just echo the code with comments make every comment count." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Don't patch bad code - rewrite it." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Don't sacrifice clarity for small gains in 'efficiency'." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Don't strain to re-use code; reorganize instead." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Don't use conditional branches as a substitute for a logical expression." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Format a program to help the reader understand it." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"'Good programmers' are those who already have learned a set of rules that ensures good style; many of them will read this book and see no reason to change. If you are still learning to be a 'good programmer', however, then perhaps some of what we consider good style will have rubbed off in the reading." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Good programming cannot be taught by preaching generalities. The way to learn to program well is by seeing, over and over, how real programs can be improved by the application of a few principles of good practice and a little common sense. Practice in critical reading leads to skill in rewriting, which in turn leads to better writing." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Indent to show the logical structure of a program." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Instrument your programs. Measure before making 'efficiency' changes." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"It is a good rule of thumb that a program should read from top to bottom in the order that it will be executed; if this is not true, watch out for the bugs that often accompany poor structure. Make your programs read from top to bottom." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Jumping around unnecessarily in a computer program has proved to be a fruitful source of errors, and usually indicates that the programmer is not entirely in control of the code." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Let the data structure the program." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Let your compiler do the simple optimizations." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Make it right before you make it faster.[...] Keep it right when you make it faster. [...] Make it clear before you make it faster. [...] Keep it simple to make it faster."

"Make sure every module hides something." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Make sure special cases are truly special." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Make the coupling between modules visible." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

 "Make input easy to prepare and output self-explanatory. [...] Use uniform input formats. [...] Make input easy to proofread. [...] Use self-identifying input. Allow defaults. Echo both on output. [...] Localize input and output in subroutines." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Make sure all variables are initialized before use." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Make sure comments and code agree." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Most programs are too big to be comprehended as a single chunk. They must be divided into smaller pieces that can be conquered separately. That is the only way to write them reliably; it is the only way to read and understand them. [...] When a program is not broken up into small enough pieces, the larger modules often fail to deliver on these promises. They try to do too much, or too many different things, and hence are difficult to maintain and are too specialized for general use." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"[...] no program is ever perfect; there is always room for improvement. Of course, it is foolish to polish a program beyond the point of diminishing returns, but most programmers do too little revision; they are satisfied too early. Don't stop with your first draft." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Notice that even the data is commented. One of the most effective ways to document a program is simply to describe the data layout in detail. If you can specify for each important variable what values it can assume and how it gets changed, you have gone a long way to describing the program. [...] Document your data layouts." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Program defensively." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Program organization, deciding what gets done where, is often given insufficient consideration. This can be true even when the format of input or output data strongly suggests the most convenient order of processing. Failure to heed such suggestions leads to code that is hard to relate to the problem being solved, and hence likely to contain mistakes." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Programmers have a strong tendency to underrate the importance of good style. Eternally optimistic, we all like to think that once we throw a piece of code together, however haphazardly, it will work properly the first time and ever after. Why waste time cleaning up something that is almost certain to be correct? Besides, it probably will be used for only a few weeks." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Programs are not used once and discarded, nor are they run forever without change. They evolve. The new version of the integration program has a greater likelihood of surviving changes later without acquiring bugs. It assists instead of intimidating those who must maintain it." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Recursion represents no saving of time or storage. Somewhere in the computer must be maintained a list of all the places a recursive routine is called, so the program can eventually find its way back. But the storage for that list is shared among many different uses. More important, it is managed automatically; many of the burdens of storage management and control flow are placed on the compiler, not on the programmer. And since bookkeeping details are hidden, the program can be much easier to understand. Learning to think recursively takes some effort, but it is repaid with smaller and simpler programs." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Repeated patterns of code catch the eye when scanning listings. Since the computer is a tool for handling repetitious operations, we should be alerted by such patterns to look for oversights - why didn't the programmer let the computer do the repeating?" (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Say what you mean, simply and directly." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"The best documentation for a computer program is a clean structure. It also helps if the code is well formatted, with good mnemonic identifiers and labels (if any are needed), and a smattering of enlightening comments. Flowcharts and program descriptions are of secondary importance; the only reliable documentation of a computer program is the code itself. The reason is simple -whenever there are multiple representations of a program, the chance for discrepancy exists. If the code is in error, artistic flowcharts and detailed comments are to no avail. Only by reading the code can the programmer know for sure what the program does." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Test input for validity and plausibility. [...] Make sure input cannot violate the limits of the program. [...] Identify bad input; recover if possible. [...] Test programs at their boundary values." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"The fewer temporary variables in a program, the less chance there is that one will not be properly initialized, or that one will be altered unexpectedly before it is used. 'Temporary' is a dirty word in programming - it suggests that a variable can be used with less thought than a 'normal' (permanent?) one, and it encourages the use of one variable for several unrelated calculations. Both are dangerous practices." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"The general rule is: after you make a decision, do something. Don't just go somewhere or make another decision. If you follow each decision by the action that goes with it, you can see at a glance what each decision implies. Follow each decision as closely as possible with its associated action." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Use IF-ELSE to emphasize that only one of two actions is to be performed." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Use recursive procedures for recursively-defined data structures." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Use the good features of a language; avoid the bad ones." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Use variable names that mean something." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Watch out for off-by-one errors. A common cause of off-by-one errors is an incorrect test, for example using 'greater than' when 'greater than or equal to' is actually needed. This program is a binary search routine, which looks for a particular element in a table by halving the interval in which the element might lie, until it ultimately either finds it, or deduces that it isn't present." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"When the operation to be done is more complex, write a separate subroutine or function. The ease of later comprehending, debugging, and changing the program will more than compensate for any overhead caused by adding the extra modules." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Write and test a big program in small pieces." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Writing a computer program eventually boils down to writing a sequence of statements in the language at hand. How each of those statements is expressed determines in large measure the intelligibility of the whole; no amount of commenting, formatting, or supplementary documentation can entirely replace well expressed statements. After all, they determine what the program actually does." (Brian W Kernighan & Phillip J Plauger, "The Elements of Programming Style", 1974)

"Controlling complexity is the essence of computer programming." (Brian W Kernighan, "Software Tools", 1976)

"Mechanical rules are never a substitute for clarity of thought." (Brian W Kernighan, "Software Tools", 1976)

"First is the sheer joy of making things. Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful." (Brian W Kernighan, "Hello, World! Opinion columns from the Daily Princetonian", 2011)

"A computer is a general-purpose machine. It takes its instructions from memory, and one can change the computation it performs by putting different instructions in the memory. Instructions and data are indistinguishable except by context; one person’s instructions are another person’s data." (Brian W Kernighan, "Understanding the Digital World", 2017)

"A standard is a precise and detailed description of how some artifact is built or is supposed to work." (Brian W Kernighan, "Understanding the Digital World", 2017)

"[...] algorithms, which are abstract or idealized process descriptions that ignore details and practicalities. An algorithm is a precise and unambiguous recipe. It’s expressed in terms of a fixed set of basic operations whose meanings are completely known and specified. It spells out a sequence of steps using those operations, with all possible situations covered, and it’s guaranteed to stop eventually." (Brian W Kernighan, "Understanding the Digital World", 2017)

"An algorithm is the computer science version of a careful, precise, unambiguous recipe or tax form, a sequence of steps that is guaranteed to compute a result correctly." (Brian W Kernighan, "Understanding the Digital World", 2017)

"By contrast, a program is anything but abstract - it’s a concrete statement of every step that a real computer must perform to accomplish a task. The distinction between an algorithm and a program is like the difference between a blueprint and a building; one is an idealization and the other is the real thing." (Brian W Kernighan, "Understanding the Digital World", 2017)

"Cryptography, the art of 'secret writing', is in many ways our best defense against the attacks noted above and those yet to come. Properly done, cryptography is wonderfully flexible and powerful. Unfortunately good cryptography is also difficult and subtle, and all too often defeated by human error." (Brian W Kernighan, "Understanding the Digital World", 2017)

"Programming in the real world tends to happen on a large scale. The strategy is similar to what one might use to write a book or undertake any other big project: figure out what to do, starting with a broad specification that is broken into smaller and smaller pieces, then work on the pieces separately while making sure that they hang together. In programming, pieces tend to be of a size such that one person can write the precise computational steps in some programming language. Ensuring that the pieces written by different programmers work together is challenging, and failing to get this right is a major source of errors." (Brian W Kernighan, "Understanding the Digital World", 2017)

"Sadly, no substantial program works the first time; life is too complicated and programs reflect that complexity. Programming requires perfect attention to detail, something that few people can achieve. Thus all programs of any size will have errors, that is, they will do the wrong thing or produce the wrong answer under some circumstances. Those flaws are called bugs [...]" (Brian W Kernighan, "Understanding the Digital World", 2017)

"The good news is that a computer is a general-purpose machine, capable of performing any computation. Although it only has a few kinds of instructions to work with, it can do them very fast, and it can largely control its own operation. The bad news is that it doesn’t do anything itself unless someone tells it what to do, in excruciating detail. A computer is the ultimate sorcerer’s apprentice, able to follow instructions tirelessly and without error, but requiring painstaking accuracy in the specification of what to do." (Brian W Kernighan, "Understanding the Digital World", 2017)

"There aren’t enough programmers in the world to do the amount of programming involved in making computers do everything we want or need." (Brian W Kernighan, "Understanding the Digital World", 2017)

"Why should anyone know or care about binary numbers? One reason is that working with numbers in an unfamiliar base is an example of quantitative reasoning that might even improve understanding of how numbers work in good old base ten. Beyond that, it’s also important because the number of bits is usually related in some way to how much space, time or complexity is involved. And fundamentally, computers are worth understanding, and binary is central to their operation." (Brian W Kernighan, "Understanding the Digital World", 2017)

"Do what you think is interesting, do something that you think is fun and worthwhile, because otherwise you won’t do it well anyway." (Brian W Kernighan [interview])

"Another effective technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed 'Never mind, I see what's wrong. Sorry to bother you.' This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor." (Brian W Kernighan)

⛩️Grady Booch - Collected Quotes

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer." (Grady Booch, "Object-Oriented Design with Applications", 1991)

"[...] encapsulation - also known as information hiding - prevents clients from seeing its inside view, were the behavior of the abstraction is implemented." (Grady Booch, "Object-Oriented Design With Applications", 1991)

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

"In object-oriented analysis, we seek to model the world by identifying the classes and objects that form the vocabulary of the problem domain, and in object-oriented design, we invent the abstractions and mechanisms that provide the behavior that this model requires." (Grady Booch, "Object-Oriented Design: With Applications", 1991) 

"Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain."(Grady Booch, "Object-oriented design: With Applications", 1991)

"Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships." (Grady Booch, "Object-oriented design: With Applications", 1991)

"Structured design does not scale up well for extremely complex systems, and this method is largely inappropriate for use with object-based and object-oriented programming languages." (Grady Booch, "Object-oriented design: With Applications", 1991) 

"The object-oriented paradigm is useful when building software systems where there is a hierarchy defined as a ranking or ordering of abstractions. (Grady Booch, "Object-Oriented Design: With Applications", 1991)

"Whereas object-oriented analysis typically focuses upon one specific problem at a time, domain analysis seeks to identify the classes and objects that are common to all applications within a given domain, such as missile avionics systems, compilers, or accounting software." (Grady Booch, "Object-oriented design: With Applications", 1991)

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

⛩️Douglas Crockford - Collected Quotes

"Computer programs are the most complex things that humans make." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. [...] Features have a documentation cost. Every feature adds pages to the manual increasing training costs." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Features that offer value to a minority of users impose a cost on all users." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Few classical programmers found prototypal inheritance to be acceptable, and classically inspired syntax obscures the language’s true prototypal nature. It is the worst of both worlds." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Generally, the craft of programming is the factoring of a set of requirements into a a set of functions and data structures." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"It turns out that strong typing does not eliminate the need for careful testing. And I have found in my work that the sorts of errors that strong type checking finds are no the errors I worry about." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Most programming languages contain good parts and bad parts. I discovered that I could be better programmer by using only the good parts and avoiding the bad parts." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Obsolete comments are worse than no comments." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Software is usually expected to be modified over the course of its productive life. The process of converting one correct program into a different correct program is extremely challenging." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to customers because they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are much harder to produce that designs that assemble long lists of features." (Douglas Crockford, "JavaScript: The Good Parts", 2008)

"Progress comes from finding better ways to do things. Don’t be afraid of innovation. Don’t be afraid of ideas that are not your own." (Douglas Crockford, [response to David Winer])

"The good thing about reinventing the wheel is that you can get a round one." (Douglas Crockford, [response to David Winer])

⛩️Scott Millett - Collected Quotes

"A lack of focus on a shared language and knowledge of the problem domain results in a codebase that works but does not reveal the intent of the business. This makes codebases difficult to read and maintain because translations between the analysis model and the code model can be costly and error prone." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"All models are not created equal; the most appropriate design patterns are used based on the complexity needs of each subdomain rather than applying a blanket design to the whole system. Models for subdomains that are not core to the success of the product or that are not as complex need not be based on rich object‐oriented designs, and can instead utilize more procedural or data‐driven architectures." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"Any team can write a software product to meet the needs of a set of use cases, but teams that put time and effort into the problem domain they are working on can consistently evolve the product to meet new business use cases." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"Areas of low complexity or that are unlikely to be invested in can be built without the need for perfect code quality; working software is good enough. Sometimes feedback and first-to-market are core to the success of a product; in this instance, it can make business sense to get working software up as soon as possible, whatever the architecture." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"By sketching out high‐level logic before you write code, you are in a better position to build the component efficiently and properly because you understand what you are doing. This is where a component diagram provides a lot of benefit. A useful time to start creating component diagrams is during knowledge‐crunching sessions with domain experts. You can produce basic sketches together using just boxes and lines to communicate domain events and processes. When you then sit down to start coding, you already have an idea of what you need to build and terminology from the UL that needs to be modeled in your system." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"Domain-Driven Design (DDD) is a process that aligns your code with the reality of your problem domain." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"Don’t let design patterns and principles get in the way of getting things done and providing value to the business. Patterns and principles are guides for you to produce supple designs. Badges of honor will not be given out the more you use them in an application. DDD is about providing value, not producing elegant code." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"If key areas of the software are not in synergy with the business domain  then, over time, it is likely that the design will rot and turn into a big ball of mud, resulting in hard‐to‐maintain software." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"It’s important to understand that not all parts of a problem are equal. Some parts of the application are more important than others. Some parts need more attention and investment than others to make the application a success. During knowledge crunching with domain experts, it’s important to reduce the noise of what’s unimportant to enable you to focus on what is important. Model‐Driven Design is hard and should only be reserved to the areas of your systems that are vital to its success. This chapter covers how you can reveal the most important areas of a system and how by using distillation you can focus on those areas. With the knowledge of where to focus you can deeply model what is core, and focus on what will make a difference." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"It may seem sensible to model the entire problem domain using a single model. However, this can be problematic because it needs to cater to all the needs of your domain. This renders the model either too complex or overly generic and devoid of any behavior. If you have large systems, it is far better and more manageable to break down the problem space into smaller, more focused models that can be tied to a specific context. Remember DDD is all about reducing complexity; a single monolithic model would increase complexity. Instead you should break the problem domain down so that you are able to create smaller models in the solution space." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"Knowledge crunching is key to bridging any knowledge gaps for the technical team when designing a solution for a problem domain based on a set of requirements. In order for a team to produce a useful model they need to have a deep insight of the problem domain to ensure important concepts are not overlooked or misunderstood. This can only be done through working in collaboration with the people that understand the domain the most; i.e., the business users, stakeholders, and subject matter experts. Without this there is a danger that a technical solution will be produced that is void of any real domain insight and something that cannot be understood by the business or by other developers during software maintenance or subsequent enhancements." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"Model‐Driven Design is the process of binding an analysis model to a code implementation model, ensuring that both stay in sync and are useful during evolution. It is the process of validating and proving the model in practice, because it’s pointless to have an elaborate model if you can’t actually implement it. Model‐Driven Design differs from DDD in that it is focused on implementation and any constraints that may require changes to an initial model, whereas DDD focuses on language, collaboration, and domain knowledge. The two complement each other; a Model‐Driven Design approach enables domain knowledge and the shared language to be incorporated into a software model that mirrors the language and mental models of the business experts. This then supports collaboration because business experts and software developers are able to solve problems together as a result of their respective models being valid. Insights gained in either model are shared and knowledge is increased, leading to better problem solving and clearer communication between the business and development team." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"Not all of a large software product needs be perfectly designed - in fact trying to do so would be a waste of effort." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"The DDD philosophy is not about following a set of rules or applying coding patterns. It is a process of learning. The journey is far more important than the destination, and the journey is all about exploring your problem domain in collaboration with domain experts rather than how many design patterns you can employ in your solution." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"Unfortunately, many developers find it difficult to create effective diagrams. However, when drawing sketches, one basic principle can help you to create highly effective diagrams: keep your diagrams at a consistent level of detail. If you’re talking about high‐level concepts like the way independent software systems communicate to fulfill a business use case, try not to drop down into lower-level concepts like class or module names that will clutter the diagram. Keeping your diagrams at a consistent level of detail will prevent you from showing too much detail or too little detail, meaning everyone can understand what you are trying to convey. It’s often better to create multiple diagrams each at a different level of detail." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"When you have a sound understanding of the problem domain, strategic patterns of DDD can help you implement a technical solution in synergy with the problem space. Patterns enable core parts of your system that are crucial to the success of the product to be protected from the generic areas. Isolating integral components allows them to be modified without having a rippling effect throughout the system." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

"You won’t get a useful model on the first attempt; you might not even get one on the second or third attempts. Don’t be afraid of experimentation. Get used to ripping up designs and starting over. Remember that there is not a correct model, only a model that is useful for the current context and the set of problems you are facing." (Scott Millett, "Patterns Principles and Practices of Domain Driven Design", 2015)

🖌️Norman R Augustine - Collected Quotes

Law of Apocalyptic Costing: "Ninety percent of the time things will turn out worse than you expect. The other ten percent of the time you had no right to expect so much."  (Norman R Augustine, "Augustine's Laws", 1983)

Law of Definitive Imprecision: "The weaker the data available upon which to base one's position, the greater the precision which should be quoted in order to give that data authenticity." (Norman R Augustine, "Augustine's Laws", 1983)

Comprehensive Law of Incomprehensibility: "Profound concepts are often characterized by their difficulty of being understood; therefore persons unfamiliar with Greek or Latin should give intellectual depth to their ideas by utilizing acronyms to a degree more or less proportionate with the lack of sophistication of the ideas being presented." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Insatiable Appetites: "The last 10 percent of the performance sought generates one-third of the cost and two-thirds of the problems." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Conservation of Input: "The features incorporated into any system will continue to increase until the unit cost of the system in dollars approximates the Threshold of Intolerance, which is defined as 10^10/N^1.2, where N is the quantity of the item which is to be purchased." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Undiminished Expectations: "It is very expensive to achieve high degrees of unreliability. It Is not uncommon to increase the cost of an item by a factor of ten for each factor of ten degradation accomplished." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Propagation of Misery: "If a sufficient number of management layers are superimposed on top of each other, it can be assured that disaster is not left to chance." (Norman R Augustine, "Augustine's Laws", 1983)

"Big Bang" Theory of Software Development: "Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics; i.e., it always increases." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Universal Agitation: "There are only three kinds of programs which suffer incessant budget tampering: those which are behind schedule, those which are on schedule, and those which used to be ahead of schedule." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Inconstancy of Time: "In a noncompetitive process, time expands to fit the work prescribed." (Norman R Augustine, "Augustine's Laws", 1983)

Second Law of Averages: "One-tenth of the participants produce at least one-third of the output, and increasing the number of participants merely reduces the average output." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Unmitigated Optimism: "Any task can be completed In only one-third more time than is currently estimated." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Economic Unipolarity: "The only thing more costly than stretching the schedule of an established development program Is accelerating it, which is itself the most costly action known to man." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Coinplicational Simplicity: "Truly simple systems are not feasible because they require infinite testing." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Limited Liability: "The problem with the acquisition process is that by the time the people at the top are ready for the answer the people at the bottom have forgotten the question" (Norman R Augustine, "Augustine's Laws", 1983).

Law of Amplification of Agony: "One should expect that the expected can be prevented but that the unexpected should have been expected." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Hardware Belligerency: "Hardware works best when it matters the least." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Analytical Alchemy: "Hiring advisors to conduct studies can be an excellent means of turning problems into gold: your problems into their gold." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Inverse Contributions: "It is true that complex systems may be expensive, but it must be remembered that they don't contribute much." (Norman R Augustine, "Augustine's Laws", 1983)

Law of Consternation of Energy: "The ubiquitous regulation, created as a management surrogate, takes on a life of its own and exhibits a growth pattern which closely parallels that of selected other living entities observed in nature; most specifically, weeds." (Norman R Augustine, "Augustine's Laws", 1983)

"Whenever parameters can be quantified, it is usually desirable to do so." (Norman R Augustine, "Augustine's Laws", 1983)

🖌️Robert Heller - Collected Quotes

"As in war, strategic success depends on tactical effectiveness, and no degree of planning can lessen management's tactical imperatives. The first responsibility of the executive, anyway, is to the here and now. If he makes a shambles of the present, there may be no future; and the real purpose of planning - the one whose neglect is common, but poisonous - is to safeguard and sustain the company in subsequent short-run periods." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Before the computer, the task of gazing into the chasms of the future and juggling with its endless permutations would have chained every manager to his slide rule for eternity. Thanks to the computer, companies could now do their sums, right or wrong, in comfort." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"But the greater the primary risk, the safer and more careful your secondary assumptions must be. A project is only as sound as its weakest assumption, or its largest uncertainty." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Don't start from statistical objectives and work backward. Begin from the premise that whatever the company is doing could be done better, and start moving forward by making the improvements that are always waiting to be grabbed." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Faced with a decision, always ask one implacable question: If this project fails, if the worst comes to the worst, what will be the result? If the answer is total corporate disaster, drop the project. If the worst possible outcome is tolerable, say, break-even, the executive has the foundation of all sound decision making - a fail-safe position." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"How executives plan or what numbers they choose doesn't count; what does is the standard of performance they are ready to exact. The essence of any objective is that reaching it should be reasonable. The precondition is that you expect it to be met." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"In the objectives system, the corporation's aims, or plans, are broken down into a hierarchy of lesser aims or plans; and the grand total of all those objectives adds up to those of the corporation. Then all the executives have to do is meet their planned and agreed objectives and - hey presto - the corporation does the same. Perfection in management, at last, has arrived, except that it hasn't and won't." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Management theory is obsessed with risks. Top executives bemoan the lack of risk-taking initiative among their young. Politicians and stockholders are advised (by directors) to make directors rich, so that they can afford to take risks. Theorists teach how to construct decision trees, heraldic devices of scientific management; and how to marry the trees with probability theory, so that the degree of risk along each branch (each branch and twig representing alternative results of alternative courses of action) can be metered. But the measuring is spurious, and, anyway, the best management doesn't take risks. It avoids them. It goes for the sure thing." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Planning and management by objectives have their point as devices for compelling thought, so long as executives don't forget that any plan worth making is inaccurate; the longer a plan takes to write, the worse it is - just because of its consumption of time. And the more they change plans to suit events, the better they will manage - if you've made a mistake, you had better admit it." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"The dogma of delegation is simple - the Sixth Truth of Management again: either the delegatee is capable of running the operation successfully by himself or he isn't. This handy formula relieves the top executive of any responsibility except that of finding, supervising, and (at the appropriate time) moving the men who are doing all the work. He Can then truly manage by exception: he does not get worked up over operations that are going well, but concentrates on the plague spots, where everything, including the management, is going badly." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"The Eighth Truth of Management is: if you are doing something wrong, you will do it badly. The reverse of this truth is that, if your decision is blindingly right, you will execute it well - or appear to do so, which is much the same thing. But any executive can massacre his own nonsensical project." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"The future, however, is pure uncertainty, limited only by the constraints of possibility. The manager must understand those constraints, and he can limit that uncertainty by thoughtful anticipation. But, above all, if you want to master the future, you have to find out what is really and truly happening right now - arid to make sure that it is happening right." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"The object of the honest manager is to fit the abstraction to the reality as neatly as he may. Any managers who toy with procedures to invent a higher profit must search their souls long and harshly. Will the change paint a truer likeness, or will it obscure the truth?" (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"The weakness of most mergers is not that ignorant managers enter unfamiliar businesses; it is that the price is wrong, regardless. If the price is right, the synergy and the management can look after themselves. If not, it will take years to close the gap by the workings of industrial logic." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"Yet intelligent men plump for one project rather than another on the strength of a difference of a few decimal points in the rate of return calculated over the next decade. All such mind-stretching calculation comes under the lash of the Seventh Truth of Management: if you need sophisticated calculations to justify an action, it is probably wrong (the sophisticated calculations, anyway, are all too often based on simple false assumptions)." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"You can teach the rudiments of cooking, as of management, but you cannot make a great cook or a great manager. In both activities, you ignore fundamentals at grave risk  - but sometimes succeed. In both, science can be extremely useful but is no substitute for the art itself. In both, inspired amateurs can outdo professionals. In both, perfection is rarely achieved, and failure is more common than the customers realize. In both, practitioners don't need recipes that detail timing down to the last second, ingredients to the last fraction of an ounce, and procedures down to the Just flick of the wrist; they need reliable maxims, instructive anecdotes, and no dogmatism." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"What goes wrong [in long-range planning] is that sensible anticipation gets converted into foolish numbers: and their validity always hinges on large loose assumptions." (Robert Heller, "The Naked Manager: Games Executives Play", 1972)

"A good sign that either the meeting or some of the people are superfluous is when they try to get out of coming." (Robert Heller, "The Supermanagers", 1984)

"Effective management always means asking the right question." (Robert Heller, "The Supermanagers", 1984)

"No talent in management is worth more than the ability to master facts - not just any facts, but the ones that provide the best answers. Mastery thus involves knowing what facts you want; where to dig for them; how to dig; how to process the mined ore; and how to use the precious nuggets of information that are finally in your hand. The process can be laborious - which is why it is so often botched." (Robert Heller, "The Supermanagers", 1984)

"Decisions should be pushed down as far as possible, to the level of competence. This allows senior managers more time for making decisions of a more complex nature."(Robert Heller, "The Pocket Manager", 1987)

"[decision trees are the] most picturesque of all the allegedly scientific aids to making decisions. The analyst charts all the possible outcomes of different options, and charts all the latters' outcomes, too. This produces a series of stems and branches (hence the tree). Each of the chains of events is given a probability and a monetary value." (Robert Heller, "The Pocket Manager", 1987)

"Management: The definition that includes all the other definitions in this book and which, because of that, is the most general and least precise. Its concrete, people meaning - the board of directors and all executives with the power to make decisions - is no problem, except for the not-so-little matter of where to draw the line between managers who are part of 'the management' and managers who are not. (Robert Heller, "The Pocket Manager", 1987)

"No decision in business provides greater potential for the creation of wealth (or its destruction, come to think of it) than the choice of which innovation to back." (Robert Heller, "The Decision Makers", 1989)

🖌️Eben Hewitt - Collected Quotes

"A hypothesis is a starting point for an investigation. When you hypothesize, you make a claim about why something might be the case, based on limited data, to offer an explanation or a path forward. You wouldn’t make a proposition about something you are certain of. You may not have enough evidence yet to even convince you that it’s true. But making such a claim puts a stake in the ground that suggests a path for focused analysis." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"[...] an architect’s work [...] comprises the set of strategic and technical models that create a context for position (capabilities), velocity (directedness, ability to adjust), and potential (relations) to harmonize strategic business and technology goals." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"An insight is when you mix your creative and intellectual labor with a set of data points to create a point of view resulting in a useful assertion. You 'see into' an object of inquiry to reveal important characteristics about its nature." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"As we know, every action produces an equal and opposite reaction. Adding security reduces performance. Sharding and partitioning the database affords greater performance and distribution but creates complexity that is difficult to manage. Adding robust monitoring can generate huge volumes of log data to be stored, rotated, secured, and cleansed. Keeping the design 'simple' often defers the interests of flexibility until later, where it becomes very expensive." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"Every strategy starts with a set of problems to be solved. The strategy itself is the set of solutions to those problems. A Logic Tree is the critical starting point for any strategy. It ensures you have defined the problem correctly and helps you enumerate the best strategic solutions." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"[...] strategy is about determining the problems and opportunities in front of you, defining them properly, and shaping a course of action that will give your business the greatest advantage. Balancing problem solving with creating and exploiting new opportunities through imagination and analysis is the cornerstone of a great strategy." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"Technology systems are difficult to wrangle. Our systems grow in accidental complexity and complication over time. Sometimes we can succumb to thinking that other people really hold the cards, that they have the puppet strings we don’t." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"The culture of your organization comprises your stated principles, and to a far greater extent, the actual lived principles as reflected by the attitudes, communication styles, and behaviors of your teams." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"We know what forecasting is: you start in the present and try to look into the future and imagine what it will be like. Backcasting is the opposite: you state your desired vision of the future as if it’s already happened, and then work backward to imagine the practices, policies, programs, tools, training, and people who worked in concert in a hypothetical past (which takes place in the future) to get you there." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)