⛩️Scott Rosenberg - Collected Quotes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⛩️Girish Suryanarayana - Collected Quotes

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

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

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

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

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

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

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

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

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

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

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

⛩️Martin Fowler - Collected Quotes

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

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

"When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature." (Martin Fowler, "Refactoring: Improving the Design of Existing Code", 1999)

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

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

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

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

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

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

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

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

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

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

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

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

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