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

Phil Simon - Collected Quotes

"Adding more resources can have mixed results. If the right people are involved at the right time to perform tasks within their abilities, the benefits will outweigh the costs. However, adding more people will not always fix an issue and make up for lost time. There is no guarantee that these steps will put a project back on target." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"As a general rule, implementations do not just spontaneously combust. Failures tend to stem from the aggregation of many issues. Although some issues may have been known since the early stages of the project (for example, the sales cycle or system design), implementation teams discover the majority of problems during the middle of the implementation, typically during some form of testing." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Implementation issues are not confined to the data and system realms. On the contrary, many of the problems encountered during a typical implementation stem from people, the roles they are required to play, political issues, and comfort zones." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Implementing new systems is not like baking a cake. Organizations cannot follow a recipe with the following ingredients: three consultants, six weeks of testing, two training classes, and a healthy dose of project management. Nor do projects bake for six months until complete, after which time everyone enjoys a delicious piece of cake. For all sorts of reasons, a well-conceived and well-run project may fail, whereas a horribly managed project may come in under budget, ahead of schedule, and do everything that the vendor promised at the onset." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Implementing new systems provides organizations with unique opportunities not only to improve their technologies, but to redefine and improve key business processes. Ultimately, for organizations to consider these new systems successes, the post-legacy environment must ensure that business processes, client end users, and systems work together." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Organizations cannot expect new systems to concurrently deliver the benefits of integration and decentralization. By definition, more of one means less of another. Decide in advance the acceptable trade-offs, and live by those decisions." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Organizations considering customizations should look carefully at their available options, ideally with the help of experienced business and technical consultants. It is imperative that they carefully consider the short- and long-term implications of these customizations, lest they be stuck with an unsustainable status quo and paint themselves into a corner." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Organizations face challenges of all kinds after activating their new systems. To be sure, these challenges are typically not as significant as those associated with going live. Still, executives and end users should never assume that system activation means that everyone is home free. Systems are hardly self-sufficient, and issues always appear." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Organizations often fail to understand that business processes do not exist in a vacuum; they must be viewed against the backdrop of the technology used to enable those processes. Systems and business processes are related in a symbiotic - but not causal - manner." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Pre-implementation, post-implementation, and ongoing data audits are invaluable tools for organizations. Used judiciously by knowledgeable and impartial resources, audits can detect, avoid, and minimize issues that can derail an implementation or cause a live system to fail. Rather than view them as superfluous expenses, organizations would be wise to conduct them at key points throughout the system’s life cycle." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Some end users are so accustomed to seeing data in a certain way that they insist that new reports present the data in a manner identical to legacy reports. This is a problem: no two systems represent data in the same manner." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"The best managed project may fail, whereas a horribly managed project may come in under budget, ahead of schedule, and do everything that the vendor promised at the onset. In reality, however, organizations are unlikely to find themselves in one of these extreme scenarios. On a fundamental level, successfully activating and utilizing a new system is about minimizing risk from day one until the end of the project and beyond. The organization that can do this stands the best chance of averting failure." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Understanding the causes of system failures may help organizations avoid them, although there are no guarantees." (Phil Simon, "Why New Systems Fail: An Insider’s Guide to Successful IT Projects", 2010)

"Data science is an iterative process. It starts with a hypothesis (or several hypotheses) about the system we’re studying, and then we analyze the information. The results allow us to reject our initial hypotheses and refine our understanding of the data. When working with thousands of fields and millions of rows, it’s important to develop intuitive ways to reject bad hypotheses quickly." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"It’s a mistake to think of data and data visualizations as static terms. They are the very antitheses of stasis." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"Just because data is visualized doesn’t necessarily mean that it is accurate, complete, or indicative of the right course of action. Exhibiting a healthy skepticism is almost always a good thing." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"Metadata serves as a strong and increasingly important complement to both structured and unstructured data. Even if you can easily visualize and interpret primary source data, it behooves you to also collect, analyze, and visualize its metadata. Incorporating metadata may very well enhance your understanding of the source data." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"The term linked data describes the practice of exposing, sharing, and connecting pieces of data, information, and knowledge on the semantic Web. Both humans and machines benefit when previously unconnected data is connected." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"There are myriad questions that we can ask from data today. As such, it’s impossible to write enough reports or design a functioning dashboard that takes into account every conceivable contingency and answers every possible question." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"To be sure, data doesn’t always need to be visualized, and many data visualizations just plain suck. Look around you. It’s not hard to find truly awful representations of information. Some work in concept but fail because they are too busy; they confuse people more than they convey information [...]. Visualization for the sake of visualization is unlikely to produce desired results - and this goes double in an era of Big Data. Bad is still bad, even and especially at a larger scale." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"Visual Organizations benefit from routinely visualizing many different types and sources of data. Doing so allows them to garner a better understanding of what’s happening and why. Equipped with this knowledge, employees are able to ask better questions and make better business decisions." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"We acquire more information through our visual system than we do through all our other senses combined. We understand things better and quicker when we see them." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"We are all becoming more comfortable with data. Data visualization is no longer just something we have to do at work. Increasingly, we want to do it as consumers and as citizens. Put simply, visualizing helps us understand what’s going on in our lives - and how to solve problems." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

"While critical, the arrival of Big Data is far from the only data-related trend to take root over the past decade. The arrival of Big Data is one of the key factors explaining the rise of the Visual Organization." (Phil Simon, "The Visual Organization: Data Visualization, Big Data, and the Quest for Better Decisions", 2014)

Robert Heller - Collected Quotes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Eben Hewitt - Collected Quotes

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

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

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

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

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

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

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

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

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

Paul Gibbons - Collected Quotes

"According to the traditional distinction from economics, risk is measurable, whereas uncertainty is indefinite or incalculable. In truth, risk can never be measured precisely except in dice rolls and games of chance, called a priori probability. Risk can only be estimated from observations in the real world, but to do that, we need to take a sample, and estimate the underlying distribution. In a sense, our estimates of real-world volatility are themselves volatile. Failure to realize this fundamental untidiness of the real world is called the ludic fallacy from the Latin for games. […] However, when the term risk measurement is used as opposed to risk estimation, a degree of precision is suggested that is unrealistic, and the choice of language suggests that we know more than we do. Even the language '​​​​​​risk management'​​​​​​ implies we can do more than we can." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"Because the perfect system cannot be designed, there will always be weak spots that human ingenuity and resourcefulness can exploit." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"Change strategy is, by this definition, the way a business (1) manages the portfolio of change to make sure that the parts deliver the whole business strategy, (2) creates the context for change, and (3) monitors change risk and change performance across the entire business." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"Culture is an emergent phenomenon produced by structures, practices, leadership behavior, incentives, symbols, rituals, and processes. All those levers have to be pulled to have any chance of success. However, one driver of culture change is more important than the others. Culture change fails when the most visible symbols of it fail to change. Those key symbols are almost always the top leader’​​​​​​s behavior, which speaks much louder than anything they might say." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"One way of managing complexity is to constrain the freedom of the parts: to hold some of those nonlinear interactions still. Businesses accomplish this with tight rules, processes, hierarchies, policies, and rigid strategies. Gathering people together under a corporate roof reduces complexity by constraining individual autonomy. The upside, of course, is collaboration, alignment of goals, and faster exchange of information." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"Our minds, especially our intuitions, are not equipped to deal with a probabilistic world. Risk and prediction are widely misunderstood, […] All decision making in a probabilistic world involves estimating the likelihood of an event and how much we will value it (affective forecasting). Humans are bad at both - ​​​​​ particularly at the former. […] In business, understanding the psychology of risk is more important than understanding the mathematics of risk." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"Strategic coherence is more important than strategic precision in an uncertain world. It is impossible to get everything right because of market volatility, but we can ensure strategies do not collide. In large, complex organizations where many executives are empowered to launch major change, strategic incoherence can be a big problem." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"Strategy that takes no account of tactical practicalities is doomed, and great tactics without strategy produce incoherence and nonalignment. Despite this, the strategy-tactics dialogue happens too rarely in organizations." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"The more complex the system, the more variable (risky) the outcomes. The profound implications of this essential feature of reality still elude us in all the practical disciplines. Sometimes variance averages out, but more often fat-tail events beget more fat-tail events because of interdependencies. If there are multiple projects running, outlier (fat-tail) events may also be positively correlated - one IT project falling behind will stretch resources and increase the likelihood that others will be compromised." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"The planning fallacy is the systematic tendency for project plans and budgets to undershoot. […] The reasons for the planning fallacy are partly psychological, partly cultural, and partly to do with our limited ability to think probabilistically." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

"What is commonly called change strategy is not very strategic because strategy properly focuses on goals and not on how to deliver those goals." (Paul Gibbons, "The Science of Successful Organizational Change",  2015)

Carl von Clausewitz - Collected Quotes

"But when one comes to the effect of the engagement, where material successes turn into motives for further action, the intellect alone is decisive. In brief, tactics will present far fewer difficulties to the theorist than will strategy." (Carl von Clausewitz, "On War", 1832)

"In a tactical situation one is able to see at least half the problem with the naked eye, whereas in strategy everything has to be guessed at and presumed." (Carl von Clausewitz, "On War", 1832)

"Everything in strategy is very simple, but that does not mean everything is very easy." (Carl von Clausewitz, "On War", 1832)

"Such cases also occur in strategy, since strategy is directly linked to tactical action. In strategy too decisions must often be based on direct observation, on uncertain reports arriving hour by hour and day by day, and finally on the actual outcome of battles. It is thus an essential condition of strategic leadership that forces should be held in reserve according to the degree of strategic uncertainty." (Carl von Clausewitz, "On War", 1832)

"The function of theory is to put all this in systematic order, clearly and comprehensively, and to trace each action to an adequate, compelling cause. […] Theory should cast a steady light on all phenomena so that we can more easily recognize and eliminate the weeds that always spring from ignorance; it should show how one thing is related to another, and keep the important and the unimportant separate. If concepts combine of their own accord to form that nucleus of truth we call a principle, if they spontaneously compose a pattern that becomes a rule, it is the task of the theorist to make this clear." (Carl von Clausewitz, "On War", 1832)

"The insights gained and garnered by the mind in its wanderings among basic concepts are benefits that theory can provide. Theory cannot equip the mind with formulas for solving problems, nor can it mark the narrow path on which the sole solution is supposed to lie by planting a hedge of principles on either side. But it can give the mind insight into the great mass of phenomena and of their relationships, then leave it free to rise into the higher realms of action." (Carl von Clausewitz, "On War", 1832)

Tom DeMarco - Collected Quotes

"Anything you need to quantify can be measured in some way that is superior to not measuring it at all." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"As a general rule of them, when benefits are not quantified at all, assume there aren’t any." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Managers jeopardize product quality by setting unreachable deadlines. They don’​​​​​​t think about their action in such terms; they think rather that what they’​​​​​​re doing is throwing down an interesting challenge to their workers, something to help them strive for excellence." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Most of us managers are prone to one failing: A tendency to manage people as though they were modular components." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"People who feel untrusted have little inclination to bond together into a cooperative team." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"People under time pressure don’​​​​​​t work better - ​​​​​​they just work faster. In order to work faster, they may have to sacrifice the quality of the product and of their own work experience." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Programmers seem to be a bit more productive after they’​​​​​​ve done the estimate themselves, compared to cases in which the manager did it without even consulting them." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"[The common definition of estimate is] 'the most optimistic prediction that has a non-zero probability of coming true' [...] Accepting this definition leads irrevocably toward a method called what's-the-earliest-date-by-which-you-can't-prove-you-won't-be-finished estimating" (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The major problems of our work are not so much technological as sociological in nature. Most managers are willing to concede the idea that they’​​​​​​ve got more people worries than technical worries. But they seldom manage that way. They manage as though technology were their principal concern. They spend their time puzzling over the most convoluted and most interesting puzzles that their people will have to solve, almost as though they themselves were going to do the work rather than manage it. […] The main reason we tend to focus on the technical rather than the human side of the work is not because it’​​​​​​s more crucial, but because it’​​​​​​s easier to do." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The most obvious defensive management ploys are prescriptive Methodologies ('My people are too dumb to build systems without them') and technical interference by the manager. Both are doomed to fail in the long run." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The need for uniformity is a sign of insecurity on the part of management. Strong managers don’t care when team members cut their hair or whether they wear ties. Their pride is tied only to their staff’s accomplishments." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The obsession with methodologies in the workplace is another instance of the high-tech illusion. It stems from the belief that what really matters is the technology. [...] Whatever the technological advantage may be, it may come only at the price of a significant worsening of the team's sociology." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The purpose of a team is not goal attainment but goal alignment." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The [software] builders’​​​​​​ view of quality, on the other hand, is very different. Since their self-esteem is strongly tied to the quality of the product, they tend to impose quality standards of their own. The minimum that will satisfy them is more or less the best quality they have achieved in the past. This is invariably a higher standard than what the market requires and is willing to pay for." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"When you automate a previously all-human system, it becomes entirely deterministic."(Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Whether you call it a 'team' or an 'ensemble' or a 'harmonious work group' is not what matters; what matters is helping all parties understand that the success of the individual is tied irrevocably to the success of the whole." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Ability to change has to be an organic part of the organization. Change has to be going on all the time, everywhere. It needs to be everybody’s business."  (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"And the management team is not really a team. A team is a group of people who have joint responsibility for - and joint ownership of - one or more work products. People who own nothing in common may be called a team, but they aren’t. This is not to say that companies never form real management teams, only that they do so rarely. Most of what are called management teams are a mockery of the team concept." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Authoritarian management is obsessed with time. It is destructive of slack and inclined to goad people into outperforming their peers. And it makes learning impossible." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Change always implies abandonment. What you're abandoning is an old way of doing things. You're abandoning it because it's old, because time has made it no longer the best way. But it is also (again because it's old) a familiar way. And more important, it is an approach that people have mastered. So the change you are urging upon your people requires them to abandon their mastery of the familiar, and to become novices once again, to become rank beginners at something with self-definitional importance." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Each time you add automation, you choose some particularly mechanical component of the work (that’s what makes it a good candidate for automation). When the new automation is in place, there is less total work to be done by the human worker, but what work is left is harder. That is the paradox of automation: It makes the work harder, not easier. After all, it was the easy stuff that got absorbed into the machine, so what’s left is, almost by definition, fuzzier, less mechanical, and more complex. Whatever standard is now introduced to govern the work will dictate (often in elaborate detail) how the few remaining mechanical aspects are to be performed."  (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Growth is the rising tide that floats all boats. The period of growth is one in which people are naturally less change-resistant. It is therefore the optimal time to introduce any change. Specifically, changes that are not growth-related should be timed to occur during growth periods. This is not because they are strictly necessary then, but because they are more likely to be possible then. You need that advantage going up against Goliath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"How people feel can be more a factor in the success of a change than what they think. Anxiety of any kind can only complicate the task of change introduction. That’s why the period of sudden decline of corporate fortunes is exactly the worst moment to introduce a change. People are uneasy about their jobs, worried about lasting corporate health, perhaps shocked by the vitality of the competition. In retrospect, a far better time to introduce the change would have been back in the period of healthy growth. Growth always carries with it a certain necessity for change. You may have to hire more people, expand to larger quarters, diversify or centralize, all to accommodate your own burgeoning success. But growth feels good; it feels like winning. It even feels good enough to reduce the amount of change resistance." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"In order to enable change, companies have to learn that keeping managers busy is a blunder. If you have busy managers working under you, they are an indictment of your vision and your capacity to transform that vision into reality. Cut them some slack." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"In the most highly stressed projects, people at all levels talk about the schedule being 'aggressive', or even 'highly aggressive'. In my experience, projects in which the schedule is commonly termed aggressive or highly aggressive invariably turn out to be fiascoes. 'Aggressive schedule', I’ve come to suspect, is a kind of code phrase - understood implicitly by all involved - for a schedule that is absurd, that has no chance at all of being met." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Lack of power is a great excuse for failure, but sufficient power is never a necessary condition of leadership. There is never sufficient power. In fact, it is success in the absence of sufficient power that defines leadership." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Leadership is the ability to enroll other people in your agenda. Meaningful acts of leadership usually cause people to accept some short-term pain (extra cost or effort, delayed gratification) in order to increase the long-term benefit. We need leadership for this, because we all tend to be short-term thinkers." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Management is hard, and not because there is so much work to do (an overworked manager is almost certainly doing work he/she shouldn’t be doing). Management is hard because the skills are inherently difficult to master. Your mastery of them will affect your organization more than anything going on under you." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Meaningful acts of leadership usually cause people to accept some short-term pain (extra cost or effort, delayed gratification) in order to increase the long-term benefit. We need leadership for this, because we all tend to be short-term thinkers." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Ownership of the standard should be in the hands of those who do the work." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Process standardization from on high is disempowerment. It is a direct result of fearful management, allergic to failure. It tries to avoid all chance of failure by having key decisions made by a guru class (those who set the standards) and carried out mechanically by the regular folk. As defense against failure, standard process is a kind of armor. The more worried you are about failure, the heavier the armor you put on. But armor always has a side effect of reduced mobility. The overarmored organization has lost the ability to move and move quickly. When this happens, standard process is the cause of lost mobility. It is, however, not the root cause. The root cause is fear." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Quality takes time and reduces quantity, so it makes you, in a sense, less efficient. The efficiency-optimized organization recognizes quality as its enemy. That's why many corporate Quality Programs are really Quality Reduction Programs in disguise." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Risk management is the explicit quantitative declaration of uncertainty. But in some corporate cultures, people aren’t allowed to be uncertain. They’re allowed to be wrong, but they can’t be uncertain. They are obliged to look their bosses and clients in the face and lie rather than show uncertainty about outcomes. Uncertainty is for wimps." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Risk mitigation is the set of actions you will take to reduce the impact of a risk should it materialize. There are two not-immediately-obvious aspects to risk mitigation: The plan has to precede materialization. Some of the mitigation activities must also precede materialization." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Significant organizational learning can’t happen in isolation. It always involves the joint participation of a set of middle managers. This requires that they actually talk to each other and listen to each other, rather than just taking turns talking to and listening to a common boss." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Slackless organizations tend to be authoritarian. When efficiency is the principal goal, decision making can't be distributed. It has to be in the hands of one person (or a few), with everyone else taking direction without question and acting quickly to carry out orders. This is a fine formula for getting a lot done, but a dismal way to encourage reinvention and learning." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"The premise here is that the hierarchy lines on the chart are also the only communication conduit. Information can flow only along the lines. [...] The hierarchy lines are paths of authority. When communication happens only over the hierarchy lines, that's a priori evidence that the managers are trying to hold on to all control. This is not only inefficient but an insult to the people underneath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"The right way to think about domain knowledge is as a corporate capital asset, as dollars of investment in the head of each knowledge worker, put there by organizational investment in that employee. When that person leaves, the asset is gone. If you did a rigorous accounting of this human capital, you would be obliged to declare an extraordinary loss each time one of your people quit." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"The rule is (as with children) that trust be given slightly in advance of demonstrated trustworthiness. But not too much in advance. You have to have an unerring sense of how much the person is ready for. Setting people up for failure doesn’t make them loyal to you; you have to set them up for success. Each time you give trust in advance of demonstrated performance, you flirt with danger. If you’re risk-averse, you won’t do it. And that’s a shame, because the most effective way to gain the trust and loyalty of those beneath you is to give the same in equal measure." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"There is no such thing as 'healthy' competition within a knowledge organization; all internal competition is destructive. The nature of our work is that it cannot be done by any single person in isolation. Knowledge work is by definition collaborative. The necessary collaboration is not limited to the insides of lowest-level teams; there has to be collaboration as well between teams and between and among the organizations the teams belong to." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"When a schedule is not met, those inclined to pass out blame are quick to point at the lowest-level workers; they reason that performance is the domain entirely of those who perform the work. They ask plaintively, 'Why can’t these guys ever meet their schedules?' The answer that the schedule might have been wrong in the first place only befuddles them. It’s as though they believe there is no such thing as a bad schedule, only bad performances that resulted in missing the scheduled date. There is such a thing as a bad schedule. A bad schedule is one that sets a date that is subsequently missed. That’s it. That’s the beginning and the end of how a schedule should be judged. If the date is missed, the schedule was wrong. It doesn’t matter why the date was missed. The purpose of the schedule was planning, not goal-setting. Work that is not performed according to a plan invalidates the plan. The missed schedule indicts the planners, not the workers." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"When communication happens only over the hierarchy lines, that’s a priori evidence that the managers are trying to hold on to all control. This is not only inefficient but an insult to the people underneath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"When managers are overworked, they’re doing something other than management; the more they allow themselves to be overworked, the less real management gets done." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Whether this person is a designer, product manager, programmer, writer, consultant, or whatever, he/she comes with (1) a set of skills and (2) some explicit knowledge of the area in which skills are to be deployed. The skills alone aren’t enough. Domain knowledge is also required. The more important that domain knowledge is, the less fungible the people are. That means you can’t divide them up into pieces, but it also means that you can’t easily replace them with other people when they leave." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"If you've been in the software business for any time at all, you know that there are certain common problems that plague one project after another. Missed schedules and creeping requirements are not things that just happen to you once and then go away, never to appear again. Rather, they are part of the territory. We all know that. What's odd is that we don't plan our projects as if we knew it. Instead, we plan as if our past problems are locked in the past and will never rear their ugly heads again. Of course, you know that isn't a reasonable expectation." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"Risks and benefits always go hand in hand. The reason that a project is full of risk is that it leads you into uncharted waters. It stretches your capability, which means that if you pull it off successfully, it's going to drive your competition batty. The ultimate coup is to stretch your own capability to a point beyond the competition's ability to respond. This is what gives you competitive advantage and helps you build a distinct brand in the market." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"The business of believing only what you have a right to believe is called risk management." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"The pathology of setting a deadline to the earliest articulable date essentially guarantees that the schedule will be missed." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"There is probably no job on earth for which an ability to believe six impossible things before breakfast is more of a requirement than software project management."  (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

Richard Rumelt - Collected Quotes

"A leader’s most important job is creating and constantly adjusting this strategic bridge between goals and objectives." (Richard Rumelt, "Good Strategy/Bad Strategy", 2011)

"A strategy coordinates action to address a specific challenge. It is not defined by the pay grade of the person authorizing the action." (Richard Rumelt, "Good Strategy/Bad Strategy", 2011)

"Despite the roar of voices wanting to equate strategy with ambition, leadership, 'vision', planning, or the economic logic of competition, strategy is none of these. The core of strategy work is always the same: discovering the critical factors in a situation and designing a way of coordinating and focusing actions to deal with those factors." (Richard Rumelt, "Good Strategy Bad Strategy", 2011)

"Good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests. Strategy is at least as much about what an organization does not do as it is about what it does." (Richard Rumelt, "Good Strategy/Bad Strategy", 2011)

"Having conflicting goals, dedicating resources to unconnected targets, and accommodating incompatible interests are the luxuries of the rich and powerful, but they make for bad strategy. Despite this, most organizations will not create focused strategies. Instead, they will generate laundry lists of desirable outcomes and, at the same time, ignore the need for genuine competence in coordinating and focusing their resources. Good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests. Strategy is at least as much about what an organization does not do as it is about what it does." (Richard Rumelt, "Good Strategy/Bad Strategy", 2011)

"The kernel of a strategy contains three elements: a diagnosis, a guiding policy, and coherent action." (Richard Rumelt, "Good Strategy/Bad Strategy", 2011)

"When organizations are unable to make new strategies - when people evade the work of choosing among different paths in the future - then you get vague mom-and-apple-pie goals everyone can agree on. Such goals are direct evidence of leadership's insufficient will or political power to make or enforce hard choices." (Richard Rumelt, "Good Strategy/Bad Strategy", 2011)

Margaret J Wheatley - Collected Quotes

"Openness to the environment over time spawns a stronger system, one that is less susceptible to externally induced change. [...] Because it partners with its environment, the system develops increasing autonomy from the environment and also develops new capacities that make it increasingly resourceful." (Margaret J Wheatley, "Leadership and the New Science: Discovering Order in a Chaotic World", 1992)

"The things we fear most in organizations - fluctuations, disturbances, imbalances - need not be signs ofan impending disorder that will destroy us. Instead, fluctuations are the primary source of creativity." (Margaret J Wheatley, "Leadership and the New Science: Discovering Order in a Chaotic World", 1992)

"Leadership is always dependent upon the context, but the context is established by the relationships." (Margaret J Wheatley, "Leadership and the New Science: Discovering Order in a Chaotic World", 1992)

"We have created trouble for ourselves in organizations by confusing control with order. This is no surprise, given that for most of its written history, leadership has been defined in terms of its control functions." (Margaret J Wheatley, "Leadership and the New Science: Discovering Order in a Chaotic World", 1992)

"In a complex system, there is no such thing as simple cause and effect." (Margaret J Wheatley, "It's An Interconnected World", 2002)

Frederick W Taylor - Collected Quotes

"The art of management has been defined, 'As knowing exactly what you want men to do, and then seeing that they do it in the best and cheapest way.' No concise definition can fully describe an art, but the relations between employers and men form without question the most important part of this art. In considering the subject, therefore, until this part of the problem has been fully discussed, the remainder of the art may be left in the background." (Frederick W Taylor, "Shop Management", 1903)

"The writer feels that management is also destined to become more of an art, and that many of the, elements which are now believed to be outside the field of exact knowledge will soon be standardized tabulated, accepted, and used, as are now many of the elements of engineering." (Frederick W Taylor, "Shop Management", 1903)

"It is only through enforced standardization of methods, enforced adoption of the best implements and working conditions, and enforced cooperation that this faster work can be assured. And the duty of enforcing the adoption of standards and enforcing this cooperation rests with management alone." (Frederick W Taylor, "Principles of Scientific Management", 1911)

"The principal object of management should be to secure the maximum prosperity for the employer coupled with the maximum prosperity for each employee." (Frederick W Taylor, "Principles of Scientific Management", 1911)

Richard L Daft - Collected Quotes

"A mental model can be thought of as an internal picture that affects a leader's actions and relationships with others. Mental models are theories people hold about specific systems in the world and their expected behavior." (Richard Daft, "The Leadership Experience" , 2002)

"Organizations are (1) social entities that (2) are goal-directed, (3) are designed as deliberately structured and coordinated activity systems, and (4) are linked to the external environment." (Richard Daft, "The Leadership Experience" , 2002)

"The key element of an organization is not a building or a set of policies and procedures; organizations are made up of people and their relationships with one another. An organization exists when people interact with one another to perform essential functions that help attain goals." (Richard Daft, "The Leadership Experience" , 2002)

"Systems thinking means the ability to see the synergy of the whole rather than just the separate elements of a system and to learn to reinforce or change whole system patterns. Many people have been trained to solve problems by breaking a complex system, such as an organization, into discrete parts and working to make each part perform as well as possible. However, the success of each piece does not add up to the success of the whole. to the success of the whole. In fact, sometimes changing one part to make it better actually makes the whole system function less effectively." (Richard L Daft, "The Leadership Experience", 2002)

"Systems thinking is a mental discipline and framework for seeing patterns and interrelationships. It is important to see organizational systems as a whole because of their complexity. Complexity can overwhelm managers, undermining confidence. When leaders can see the structures that underlie complex situations, they can facilitate improvement. But doing that requires a focus on the big picture." (Richard L Daft, "The Leadership Experience", 2002)

"Data are raw facts and figures that by themselves may be useless. To be useful, data must be processed into finished information, that is, data converted into a meaningful and useful context for specific users. An increasing challenge for managers is being able to identify and access useful information." (Richard L Daft & Dorothy Marcic, "Understanding Management" 5th Ed., 2006)

"Decision making is the process of identifying problems and opportunities and then resolving them. Decision making involves effort before and after the actual choice." (Richard L Daft & Dorothy Marcic, "Understanding Management" 5th Ed., 2006)

"A paradigm is a shared mindset that represents a fundamental way of thinking about, perceiving, and understanding the world." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)

"Leaders should be aware of how their mental models affect their thinking and may cause 'blind spots' that limit understanding. Becoming aware of assumptions is a first step toward shifting one’s mental model and being able to see the world in new and different ways. Four key issues important to expanding and developing a leader’s mind are independent thinking, open-mindedness, systems thinking, and personal mastery." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)

"Management can be defined as the attainment of organizational goals in an effective and efficient manner through planning, organizing, staffing, directing, and controlling organizational resources." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)

"Strategy is the serious work of figuring out how to translate vision and mission into action. Strategy is a general plan of action that describes resource allocation and other activities for dealing with the environment and helping the organization reach its goals. Like vision, strategy changes, but successful companies develop strategies that focus on core competence, develop synergy, and create value for customers. Strategy is implemented through the systems and structures that are the basic architecture for how things get done in the organization." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)

"Synergy is the combined action that occurs when people work together to create new alternatives and solutions. In addition, the greatest opportunity for synergy occurs when people have different viewpoints, because the differences present new opportunities. The essence of synergy is to value and respect differences and take advantage of them to build on strengths and compensate for weaknesses." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)

"Synergy occurs when organizational parts interact to produce a joint effect that is greater than the sum of the parts acting alone. As a result the organization may attain a special advantage with respect to cost, market power, technology, or employee." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)

"The other element of systems thinking is learning to infl uence the system with reinforcing feedback as an engine for growth or decline. [...] Without this kind of understanding, managers will hit blockages in the form of seeming limits to growth and resistance to change because the large complex system will appear impossible to manage. Systems thinking is a significant solution." (Richard L Daft, "The Leadership Experience" 4th Ed., 2008)

"An organization’s culture is the underlying set of key values, beliefs, understandings, and norms shared by employees. These underlying values and norms may pertain to ethical behavior, commitment to employees, efficiency, or customer service, and they provide the glue to hold organization members together. An organization’s culture is unwritten but can be observed in its stories, slogans, ceremonies, dress, and office layout." (Richard L Daft, "Organization Theory and Design", 3rd Ed., 2010)

"Efficiency refers to the amount of resources used to achieve the organization’s goals. It is based on the quantity of raw materials, money, and employees necessary to produce a given level of output. Effectiveness is a broader term, meaning the degree to which an organization achieves its goals." (Richard L Daft, "Organization Theory and Design", 3rd Ed., 2010)

"Organization theory focuses on the organizational level of analysis but with concern for groups and the environment. To explain the organization, one should look not only at its characteristics but also at the characteristics of the environment and of the departments and groups that make up the organization." (Richard L Daft, "Organization Theory and Design", 3rd Ed., 2010)

"The organization’s goals and strategy define the purpose and competitive techniques that set it apart from other organizations. Goals are often written down as an enduring statement of company intent. A strategy is the plan of action that describes resource allocation and activities for dealing with the environment and for reaching the organization’s goals. Goals and strategies define the scope of operations and the relationship with employees, customers, and competitors." (Richard L Daft, "Organization Theory and Design", 3rd Ed., 2010)