♟️Strategic Management: The Good (Just the Quotes)

"Present opportunities are neglected, and attainable good is slighted, by minds busied in extensive ranges and intent upon future advantages." (Samuel Johnson, "The Idler", 1801)

"For any manager to utilize graphic methods for visualizing the vital facts of his business, in the first place it must be impressed upon his that the method will produce the results for him and then he must know how to get up a chart correctly, and last, but far from least, he must know what the essential facts of his business are. Charts, in themselves, mean little and like many another force for the accomplishment of good, if misdirected, may result unprofitably." (Allan C Haskell, "How to Make and Use Graphic Charts", 1919)

"The fine art of executive decision consists in not deciding questions that are not now pertinent, in not deciding prematurely, in not making decision that cannot be made effective, and in not making decisions that others should make. Not to decide questions that are not pertinent at the time is uncommon good sense, though to raise them may be uncommon perspicacity. Not to decide questions prematurely is to refuse commitment of attitude or the development of prejudice. Not to make decisions that cannot be made effective is to refrain from destroying authority. Not to make decisions that others should make is to preserve morale, to develop competence, to fix responsibility, and to preserve authority.

From this it may be seen that decisions fall into two major classes, positive decisions - to do something, to direct action, to cease action, to prevent action; and negative decisions, which are decisions not to decide. Both are inescapable; but the negative decisions are often largely unconscious, relatively nonlogical, instinctive, 'good sense'. It is because of the rejections that the selection is good."" (Chester I Barnard, "The Functions of the Executive", 1938)"

"Good management are rarely overcompensated to an extent that makes any significant difference with respect to the stockholder's position. Poor management are always overcompensated, because they are worth less than nothing to the owners." (Benjamin Graham, "The Intelligent Investor", 1949)

"If charts do not reflect actual organization and if the organization is intended to be as charted, it is the job of effective management to see that actual organization conforms with that desired. Organization charts cannot supplant good organizing, nor can a chart take the place of spelling out authority relationships clearly and completely, of outlining duties of managers and their subordinates, and of defining responsibilities." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"While good charting will attempt, as far as possible, to make levels on the chart conform to levels of importance in the business enterprise, it cannot always do so. This problem can be handled by clearly spelling out authority relationships." (Harold Koontz & Cyril O Donnell, "Principles of Management", 1955)

"To say a system is 'self-organizing' leaves open two quite different meanings. There is a first meaning that is simple and unobjectionable. This refers to the system that starts with its parts separate" (so that the behavior of each is independent of the others' states) and whose parts then act so that they change towards forming connections of some type. Such a system is 'self-organizing' in the sense that it changes from 'parts separated' to 'parts joined'. […] In general such systems can be more simply characterized as 'self-connecting', for the change from independence between the parts to conditionality can always be seen as some form of 'connection', even if it is as purely functional […]  'Organizing' […] may also mean 'changing from a bad organization to a good one' […] The system would be 'self-organizing' if a change were automatically made to the feedback, changing it from positive to negative; then the whole would have changed from a bad organization to a good." (W Ross Ashby, "Principles of the self-organizing system", 1962)

"The successful manager must be a good diagnostician and must value a spirit of inquiry." (Edgar H Schein, "Organizational Psychology", 1965)

"Good mission statements focus on a limited number of goals, stress the company's major policies and values, and define the company's major competitive scopes." (Philip Kotler, "Marketing Management", 1967)

"In most management problems there are too many possibilities to expect experience, judgement, or intuition to provide good guesses, even with perfect information." (Russell L Ackoff, "Management Science", 1967)

"Good results without good planning come from good luck, not good management." (David Jaquith, "The Time Trap", 1972

"To be productive the individual has to have control, to a substantial extent, over the speed, rhythm, and attention spans with which he is working […] While work is, therefore, best laid out as uniform, working is best organized with a considerable degree of diversity. Working requires latitude to change speed, rhythm, and attention span fairly often. It requires fairly frequent changes in operating routines as well. What is good industrial engineering for work is exceedingly poor human engineering for the worker." (Peter F Drucker, "Management: Tasks, Responsibilities, Practices", 1973)

"Any approach to strategy quickly encounters a conflict between corporate objectives and corporate capabilities. Attempting the impossible is not good strategy; it is just a waste of resources." (Bruce Henderson, Henderson on Corporate Strategy, 1979)

"Executive stress is difficult to overstate when there is a conflict among policy restrictions, near-term performance, long-term good of the company, and personal survival." (Bruce Henderson, "Henderson on Corporate Strategy", 1979)

"[Organizational] change is intervention, and intervention even with good intentions can lead to negative results in both the short and long run. For example, a change in structure in going from application of one theory to another might cause the unwanted resignation of a key executive, or the loss of an important customer. [...] the factor of change, acts as an overriding check against continual organizational alterations. It means that regardless of how well meant a change is, or how much logic dictates this change, its possible negative effects must be carefully weighed against the hoped-for benefits." (William A Cohen, "Principles of Technical Management", 1980)

"A leader is one who, out of madness or goodness, volunteers to take upon himself the woe of the people. There are few men so foolish, hence the erratic quality of leadership in the world." (John Updike, "They Thought They Were Better", TIME magazine, 1980)

"Because the importance of training is so commonly underestimated, the manager who wants to make a dramatic improvement in organizational effectiveness without challenging the status quo will find a training program a good way to start." (Theodore Caplow, "Managing an Organization", 1983)

"It seems to me that we too often focus on the inside aspects of the job of management, failing to give proper attention to the requirement for a good manager to maintain those relationships between his organization and the environment in which it must operate which permits it to move ahead and get the job done." (Breene Kerr, Giants in Management, 1985) 

"Managers who are skilled communicators may also be good at covering up real problems." (Chris Argyris, Harvard Business Review, 1986)

"Operating managers should in no way ignore short-term performance imperatives [when implementing productivity improvement programs.] The pressures arise from many sources and must be dealt with. Moreover, unless managers know that the day-to-day job is under control and improvements are being made, they will not have the time, the perspective, the self-confidence, or the good working relationships that are essential for creative, realistic strategic thinking and decision making." (Robert H Schaefer, Harvard Business Review, 1986)

"Some management groups are not good at problem solving and decision making precisely because the participants have weak egos and are uncomfortable with competition." (Chris Argyris, Harvard Business Review, 1986)

"The chain of command is an inefficient communication system. Although my staff and I had our goals, tasks, and priorities well defined, large parts of the organization didn't know what was going on. Frequent, thorough, open communication to every employee is essential to get the word out and keep walls from building within the company. And while face-to-face communication is more effective than impersonal messages, it's a good idea to vary the medium and the message so that no one (including top management) relies too much on ''traditional channels of communication." (William H Peace, Harvard Business Review, 1986)

"The source of good management is found in the imagination of leaders, persons who form new visions and manifest them with a high degree of craft. The blending of vision and craft communicates the purpose. In the arts, people who do that well are masters. In business, they are leaders." (Henry M. Boettinger, Harvard Business Review on Human Relations, 1986)

"Employees are most apt to deal with their problems when they believe that they will be helped in good faith." (Paul V Lyons, "Management", 1987)

"Good people can fix a lot of flaws in poor planning, but it's never the other way around." (Roland Shmitt, "Government Executive", 1987)

"Some people are excited about learning a new piece of software. Other people get very depressed. Good managers anticipate both situations they involve the persons to be affected in the process of selecting a particular program, and they provide time and resources for training. Training is the key in both cases." (Jonathan P Siegel, "Communications", 1988)

"Pressure can also make managers act out of character. Degrees of panic will cause a normally good manager to lose self-confidence and focus. Under stress, even a good plan can be abandoned." (Wheeler L Baker, "Crisis Management: A Model for Managers", 1993)

"Managers must clearly distinguish operational effectiveness from strategy. Both are essential, but the two agendas are different. The operational agenda involves continual improvement everywhere there are no trade-offs. Failure to do this creates vulnerability even for companies with a good strategy. The operational agenda is the proper place for constant change, flexibility, and relentless efforts to achieve best practice. In contrast, the strategic agenda is the right place for defining a unique position, making clear trade-offs, and tightening fit. It involves the continual search for ways to reinforce and extend the company’s position. The strategic agenda demands discipline and continuity; its enemies are distraction and compromise." (Michael E Porter, "What is Strategy?", Harvard Business Review, 1996)

"There's a fundamental distinction between strategy and operational effectiveness. Strategy is about making choices, trade-offs; it's about deliberately choosing to be different. Operational effectiveness is about things that you really shouldn't have to make choices on; it's about what's good for everybody and about what every business should be doing. " (Michael E Porter, "What is Strategy?", Harvard Business Review, 1996)

"An effective leader leaves a legacy; they leave their footprints on the road for others to follow. A good leader develops themselves and they develop others. They bring people together rather than divide them." (Joseph O’Connor, "Leading With NLP: Essential Leadership Skills for Influencing and Managing People", 1998)

"Good leaders are ethical, responsible and effective. Ethical because leadership connects you to others through shared values. Responsible because leadership means self-development and not simply giving orders, however charismatically, to get others to do what you want. Effective because shared values and goals give the strongest motivation for getting tasks done. There are no guarantees, but this sort of leadership will bring you closer to people and give you the greatest chance of success." (Joseph O’Connor, "Leading With NLP: Essential Leadership Skills for Influencing and Managing People", 1998)

"Managing [...] used to be about planning and control. Top management decided what was to be done, middle management worked out how to do it and everyone else did as they were told. This model assumed, of course, that top management knew what needed to be done, that the orders had time to percolate their way down and that, like a good army, the lower ranks would obey." (Joseph O’Connor, "Leading With NLP: Essential Leadership Skills for Influencing and Managing People", 1998)

"Good leaders make people feel that they're at the very heart of things, not at the periphery. Everyone feels that he or she makes a difference to the success of the organization. When that happens, people feel centered and that gives their work meaning." (Warren Bennis, "Managing People Is Like Herding Cats", 1999)

"Making good judgments when one has complete data, facts, and knowledge is not leadership - it's bookkeeping." (Dee Hock, "Birth of the Chaordic Age", 1999)

"Data have to be filtered in some manner to make them intelligible. This filtration may be based upon a person's experience plus his presuppositions and assumptions, or it may be more formalized and less subjective, but there will always be some method of analysis. If experience is the basis for interpreting the data, then the interpretation is only as good as the manager's past experience. If the current situation is outside the manager’s experience, then his interpretation of the data may well be incorrect. Likewise, flawed assumptions or flawed presuppositions can also result in flawed interpretations. However, in the absence of formal and standardized data, most managers use the scat-of-the-pants approach. and in the end, about all they can say that some days appear to be better than others." (Donald J Wheeler," Understanding Variation: The Key to Managing Chaos" 2nd Ed., 2000)

"I've learned that mistakes can often be as good a teacher as success." (Jack Welch, "Jack: Straight from the Gut", 2001)

"Project failures are not always the result of poor methodology; the problem may be poor implementation. Unrealistic objectives or poorly defined executive expectations are two common causes of poor implementation. Good methodologies do not guarantee success, but they do imply that the project will be managed correctly." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"The key to good decision making is not knowledge. It is understanding. We are swimming in the former. We are desperately lacking in the latter." (Malcolm Gladwell, "Blink: The Power of Thinking Without Thinking", 2005)

"Wisdom and good governance require more than the consistent application of abstract principles." (Anthony Daniels, "Romancing Opiates: Pharmacological Lies and the Addiction Bureaucracy", 2006)

"Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers." (Peter Weill, "Innovating with Information Systems Presentation", 2007)

"Whereas strategy is abstract and based on long-term goals, tactics are concrete and based on finding the best move right now. Tactics are conditional and opportunistic, all about threat and defense. No matter what pursuit you’re engaged in - chess, business, the military, managing a sports team - it takes both good tactics and wise strategy to be successful." (Garry Kasparov, "How Life Imitates Chess", 2007)

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

"A good strategy is one that takes into account not only the requirements of the position, but also the opponent's strategy and tactics. Strategy lies between science and art. It supports the ability to evaluate positions, recognize patterns and imagine adequate plans." (Mihai Suba, "Dynamic Chess Strategy", 2010)

"And even if we make good plans based on the best information available at the time and people do exactly what we plan, the effects of our actions may not be the ones we wanted because the environment is nonlinear and hence is fundamentally unpredictable. As time passes the situation will change, chance events will occur, other agents such as customers or competitors will take actions of their own, and we will find that what we do is only one factor among several which create a new situation." (Stephen Bungay, "The Art of Action: How Leaders Close the Gaps between Plans, Actions, and Results", 2010)

"Almost by definition, one is rarely privileged to 'control' a disaster. Yet the activity somewhat loosely referred to by this term is a substantial portion of Management, perhaps the most important part. […] It is the business of a good Manager to ensure, by taking timely action in the real world, that scenarios of disaster remain securely in the realm of Fantasy." (John Gall, "The Systems Bible: The Beginner's Guide to Systems Large and Small"[Systematics 3rd Ed.], 2011)

"Clearly, total feedback is Not a Good Thing. Too much feedback can overwhelm the response channels, leading to paralysis and inaction. Even in a system designed to accept massive feedback" (such as the human brain), if the system is required to accommodate to all incoming data, equilibrium will never be reached. The point of decision will be delayed indefinitely, and no action will be taken." (John Gall, "The Systems Bible: The Beginner's Guide to Systems Large and Small"[Systematics 3rd Ed.], 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)

"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)

"It is hard to avoid the conclusion that while strategy is undoubtedly a good thing to have, it is a hard thing to get right. […] So what turns something that is not quite strategy into strategy is a sense of actual or imminent instability, a changing context that induces a sense of conflict. Strategy therefore starts with an existing state of affairs and only gains meaning by an awareness of how, for better or worse, it could be different." (Lawrence Freedman, “Strategy: A history”, 2013)

"You can only look so far, and so you better just keep looking frequently. That’s the most important element of strategy: You understand the direction you’re going, but you also know what you’re going to do in the next six months. Most companies will do a pretty good job many times about the direction, but then they never break it down to shorter metrics. Intel did a super job on that. When you ask why [we] succeeded, this is one of the reasons." (Les Vadasz, 2013)

"Good decision-making is like playing chess and you must avoid making hasty decisions without thinking of how that particular decision will impact on different aspects of your work and organization. The worst kind of decision-making is to decide to delay a difficult decision until later or to pass it to someone else to have to make. You will never excel and be valued by your colleagues if you get into these habits of procrastination and passing responsibility to others." (Nigel Cumberland, "Secrets of Success at Work: 50 techniques to excel", 2014)

"Good governance is less about structure and rules than being focused, effective and accountable." (Pearl Zhu,  "Digitizing Boardroom: The Multifaceted Aspects of Digital Ready Boards", 2016)

"Good mission statements have five major characteristics. (1) They focus on a limited number of goals. (2) They stress the company’s major policies and values. (3) They define the major competitive spheres within which the company will operate. (4) They take a long-term view." (5) They are as short, memorable, and meaningful as possible." (Philip Kotler & Kevin L Keller, "Marketing Management" 15th Ed., 2016)

"No methodology can guarantee success. But a good methodology can provide a feedback loop for continual improvement and learning." (Ash Maurya, "Scaling Lean: Mastering the Key Metrics for Startup Growth", 2016)

"Decision trees are considered a good predictive model to start with, and have many advantages. Interpretability, variable selection, variable interaction, and the flexibility to choose the level of complexity for a decision tree all come into play." (Ralph Winters, "Practical Predictive Analytics", 2017)

"Random forests are essentially an ensemble of trees. They use many short trees, fitted to multiple samples of the data, and the predictions are averaged for each observation. This helps to get around a problem that trees, and many other machine learning techniques, are not guaranteed to find optimal models, in the way that linear regression is. They do a very challenging job of fitting non-linear predictions over many variables, even sometimes when there are more variables than there are observations. To do that, they have to employ 'greedy algorithms', which find a reasonably good model but not necessarily the very best model possible." (Robert Grant, "Data Visualization: Charts, Maps and Interactive Graphics", 2019)

"If you do not conduct sufficient analysis and if you do not have firm technical knowledge, you cannot carry out improvement or standardization, nor can you perform good control or prepare control charts useful for effective control." (Kaoru Ishikawa)

"The traditional approach to leadership values decision-making conviction and consistency; good leaders 'stick to their guns'. By contrast, the emerging approach recognizes that in fast-changing environments, decisions often need to be reversed or adapted, and that changing course in response to new information is a strength, not a weakness. If this tension is not managed wisely, leaders run the risk of seeming too rigid, on the one hand, or too wishy-washy on the other." (Jennifer Jordan et al, "Every Leader Needs to Navigate These 7 Tensions", Harvard Business Review, 2020)

🏗️Software Engineering: The Good (Just the Quotes)

"The engineer must be able not only to design, but to execute. A draftsman may be able to design, but unless he is able to execute his designs to successful operation he cannot be classed as an engineer. The production engineer must be able to execute his work as he has planned it. This requires two qualifications in addition to technical engineering ability: He must know men, and he must have creative ability in applying good statistical, accounting, and 'system' methods to any particular production work he may undertake." (Hugo Diemer, "Industrial Engineering", 1905)

"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)

"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)

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

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

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

"In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included." (Edsger W Dijkstra, "How do we tell truths that might hurt?", 1975)

"A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering." (Freeman Dyson, "Disturbing the Universe", 1979)

"Today's scientific investigations are so complicated that even experts in related fields may not understand them well. But there is a logic in the planning of experiments and in the analysis of their results that all intelligent people can grasp, and this logic is a great help in determining when to believe what we hear and read and when to be skeptical. This logic has a great deal to do with statistics, which is why statisticians have a unique interest in the scientific method, and why some knowledge of statistics can so often be brought to bear in distinguishing good arguments from bad ones." (Robert Hooke, "How to Tell the Liars from the Statisticians", 1983)

"Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming. Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock," Object-Oriented Design: A responsibility-driven approach", 1989)

"Programming in an object-oriented language, however, does not ensure that the complexity of an application will be well encapsulated. Applying good programming techniques can improve encapsulation, but the full benefit of object-oriented programming can be realized only if encapsulation is a recognized goal of the design process." (Rebecca Wirfs-Brock, "Object-oriented Design: A responsibility-driven approach", 1989)

"Good engineering is not a matter of creativity or centering or grounding or inspiration or lateral thinking, as useful as those might be, but of decoding the clever, even witty, messages the solution space carves on the corpses of the ideas in which you believed with all your heart, and then building the road to the next message." (Fred Hapgood, "Up the infinite Corridor: MIT and the Technical Imagination", 1993)

"Users are not designers, so it is not reasonable to expect them to come up with design ideas from scratch. However, they are very good at reacting to concrete designs they do not like or that will not work in practice. To get full benefits from user involvement, it is necessary to present these suggested system designs in a form the users can understand." (Jakob Nielsen, "Usability Engineering", 1993)

"Users often do not know what is good for them. [...] Users have a very hard time predicting how they will interact with potential future systems with which they have no experience. [...] Furthermore, users will often have divergent opinions when asked about details of user interface design." (Jakob Nielsen, "Usability Engineering", 1993)

"When one considers how hard it is to write a computer program even approaching the intellectual scope of a good mathematical paper, and how much greater time and effort have to be put into it to make it 'almost' formally correct, it is preposterous to claim that mathematics as we practice it is anywhere near formally correct." (William P Thurston, "On proof and progress in mathematics", Bulletin of the AMS 30" (2), 1994)

"Good design protects you from the need for too many highly accurate components in the system. But such design principles are still, to this date, ill-understood and need to be researched extensively. Not that good designers do not understand this intuitively, merely it is not easily incorporated into the design methods you were taught in school. Good minds are still needed in spite of all the computing tools we have developed." (Richard Hamming, "The Art of Doing Science and Engineering: Learning to Learn", 1997)

"The woes of software engineering are not due to lack of tools or proper management, but largely due to lack of sufficient technical competence. A good designer must rely on experience; on precise, logical thinking; and on pedantic exactness. No magic will do. In light of all this, it is particularly sad that, in many informatics curricula, programming in the large is badly neglected. Design has become a non-topic." (Niklaus Wirth, [interview in Software Development] 1997)

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

"Good programmers know what to write. Great ones know what to rewrite." (Eric S Raymond, "The Cathedral and the Bazaar", 1999)

"The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better." (Eric S Raymond, "The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary", 1999)

"Project failures are not always the result of poor methodology; the problem may be poor implementation. Unrealistic objectives or poorly defined executive expectations are two common causes of poor implementation. Good methodologies do not guarantee success, but they do imply that the project will be managed correctly." (Harold Kerzner, "Strategic Planning for Project Management using a Project Management Maturity Model", 2001)

"The physical design process is a key phase in the overall design process. It is too often ignored until the last minute in the vain hope that performance will be satisfactory. Without a good physical design, performance is rarely satisfactory and throwing hardware at the problem is rarely completely effective. There is no substitute for a good physical design, and the time and effort spent in the physical design process will be rewarded with an efficient and well-tuned database, not to mention happy users!" (Ken England, "Microsoft SQL Server 2000 Performance Optimization and Tuning Handbook", 2001)

"Good design is also an act of communication between the designer and the user, except that all the communication has to come about by the appearance of the device itself. The device must explain itself." (Donald Norman, "The Design of Everyday Things", 2002)

"All OO languages show some tendency to suck programmers into the trap of excessive layering. Object frameworks and object browsers are not a substitute for good design or documentation, but they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing. The Rules of Simplicity, Clarity, and Transparency get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems." (Eric S Raymond, "The Art of Unix Programming", 2003)

"Many things can put a project off course: bureaucracy, unclear objectives, and lack of resources, to name a few. But it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, developers can no longer understand the software well enough to change or extend it easily and safely. On the other hand, a good design can create opportunities to exploit those complex features." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"The effectiveness of an overall design is very sensitive to the quality and consistency of fine-grained design and implementation decisions. With a MODEL-DRIVEN DESIGN, a portion of the code is an expression of the model; changing that code changes the model. Programmers are modelers, whether anyone likes it or not. So it is better to set up the project so that the programmers do good modeling work." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Coupling describes how tightly a class or routine is related to other classes or routines. The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines, which is known as loose coupling." The concept of coupling applies equally to classes and routines [...] Good coupling between modules is loose enough that one module can easily be used by other modules."" (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Good code is its own best documentation." (Steve McConnell, "Code Complete", 2004)

"On a related topic, let me say that I'm not much of a fan of object-oriented design. I've seen some beautiful stuff done with OO, and I've even done some OO stuff myself, but it's just one way to approach a problem. For some problems, it's an ideal way; for others, it's not such a good fit. [...] OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism" (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem. It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd." (Rob Pike, [interview] 2004) 

"The flip side of the coin was that even good programmers and language designers tended to do terrible extensions when they were in the heat of programming, because design is something that is best done slowly and carefully." (Alan Kay, [ACM Queue A Conversation with Alan Kay Vol. 2" (9)] 2004-2005)

"Abstractions matter to users too. Novice users want programs whose abstractions are simple and easy to understand; experts want abstractions that are robust and general enough to be combined in new ways. When good abstractions are missing from the design, or erode as the system evolves, the resulting program grows barnacles of complexity. The user is then forced to master a mass of spurious details, to develop workarounds, and to accept frequent, inexplicable failures." (Daniel Jackson, "Software Abstractions", 2006)

"In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful. [... I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships." (Linus Torvalds, [email] 2006)

"Much data in databases has a long history. It might have come from old 'legacy' systems or have been changed several times in the past. The usage of data fields and value codes changes over time. The same value in the same field will mean totally different thing in different records. Knowledge or these facts allows experts to use the data properly. Without this knowledge, the data may bc used literally and with sad consequences. The same is about data quality. Data users in the trenches usually know good data from bad and can still use it efficiently. They know where to look and what to check. Without these experts, incorrect data quality assumptions are often made and poor data quality becomes exposed." (Arkady Maydanchik, "Data Quality Assessment", 2007)

"One of the essential parts of a formal training in programming is a long and demanding study of the large collection of algorithms that have already been discovered and analyzed, together with the Data Structures" (carefully tailored, seemingly unnatural ways of organizing data for effective access) that go with them. As with any other engineering profession, it is impossible to do a good job without a thorough knowledge of what has been tried before. If a programmer starts the job fully armed with what is already known, they will have some chance of finding something new. Inventiveness is important: not all problems have been seen before. A programmer who does not already know the standard algorithms and data structures is doomed to nothing more than rediscovering the basics." (Robert Plant & Stephen Murrell, "An Executive's Guide to Information Technology: Principles, Business Models, and Terminology", 2007)

"We are also limited by the fact that verbalization works best when mental model manipulation is an inherent element of the task of interest. Troubleshooting, computer programming, and mathematics are good examples of tasks where mental model manipulation is central and explicit. In contrast, the vast majority of tasks do not involve explicit manipulation of task representations. Thus, our access of mental models - and the access of people doing these tasks - is limited." (William B Rouse, "People and Organizations: Explorations of Human-Centered Design", 2007)

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

"Good software designs accommodate change without huge investments and rework. When we use code that is out of our control, special care must be taken to protect our investment and make sure future change is not too costly." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 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) 

"Standards make it easier to reuse ideas and components, recruit people with relevant experience, encapsulate good ideas, and wire components together. However, the process of creating standards can sometimes take too long for industry to wait, and some standards lose touch with the real needs of the adopters they are intended to serve." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"A good system design is based on a sound conceptual model" (architecture). A system design that has no conceptual structure and little logic to its organization is ultimately going to be unsuccessful. Good architecture will address all the requirements of the system at the right level of abstraction." (Vasudeva Varma, "Software Architecture: A Case Based Approach", 2009)

"Anti-patterns are the dark side of patterns - common mistakes we fall into repeatedly. Sometimes they seem to be good solutions that experience has demonstrated don���t work in practice. On other occasions, we know that they're not a good idea, but we fall into them anyway." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"One final point - whether fixing bugs or implementing new functionality, it's good practice to always examine exactly what it is that you're about to check in before every check-in. It won't take long, and every once in a while, you'll catch a change that you really didn't intend to make from slipping through."" (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"For some reason software developers don't think of debugging time as coding time. They think of debugging time as a call of nature, something that just has to be done. But debugging time is just as expensive to the business as coding time is, and therefore anything we can do to avoid or diminish it is good." (Robert C Martin, "The Clean Coder: A code of conduct for professional programmers", 2011)

"A complete data analysis will involve the following steps: (i) Finding a good model to fit the signal based on the data. (ii) Finding a good model to fit the noise, based on the residuals from the model." (iii) Adjusting variances, test statistics, confidence intervals, and predictions, based on the model for the noise." (DeWayne R Derryberry, "Basic data analysis for time series with R", 2014)

"A good heuristic decision is made by 1) knowing what to look for, 2) knowing when enough information is enough" (the 'threshold of decision' ), and 3) knowing what decision to make." (Patrick Van Horne, "Left of Bang", 2014)

"Good architecture is all about splitting stuff reliably into self-contained parcels that allow work on them to continue relatively independently in parallel" (often these days in different locations)." (Richard Hopkins & Stephen Harcombe, "Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects", 2014)

"Good architecture provides good interfaces that separate the shear layers of its implementation: a necessity for evolution and maintenance. Class-oriented programming puts both data evolution and method evolution in the same shear layer: the class. Data tend to remain fairly stable over time, while methods change regularly to support new services and system operations. The tension in these rates of change stresses the design." (James O Coplien & Trygve Reenskaug, "The DCI Paradigm: Taking Object Orientation into the Architecture World", 2014)

"In more ways than one, architecture is all about avoiding bottlenecks. In architecture, the term bottleneck typically refers to a design problem that is preventing processing from occurring at full speed. [...] A good architecture will avoid bottlenecks in both." (Richard Hopkins & Stephen Harcombe, "Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects", 2014)

"There is a tendency to believe that good architecture leads to systems that perform better and are more secure, but such claims relate less to any given architectural principle than to the timing of big-picture deliberations in the design cycle and to the proper engagement of suitable stakeholders." (James O Coplien & Trygve Reenskaug, "The DCI Paradigm: Taking Object Orientation into the Architecture World", 2014)

"When designers intentionally trick users into inviting friends or blasting a message to their social networks, they may see some initial growth, but it comes at the expense of users' goodwill and trust. When people discover they've been duped, they vent their frustration and stop using the product." (Nir Eyal, "Hooked: How to Build Habit-Forming Products", 2014)

"When you write a computer program you've got to not just list things out and sort of take an algorithm and translate it into a set of instructions. But when there's a bug - and all programs have bugs - you've got to debug it. You've got to go in, change it, and then re-execute [...] and you iterate. And that iteration is really a very, very good approximation of learning." (Nicholas Negroponte, "A 30-year history of the future", [Ted Talk] 2014)

"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)

"But 'average cost to fix one defect' is a stupid metric [...] It makes bad projects look good, and good projects look bad. How? By failing to divide the costs of fixing into two categories: fixed costs of detecting and fixing defects - costs which are the same no matter how buggy or how good the product is - and variable costs, those which you pay for each defect." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Good user stories are expected to be independent, negotiable, valuable, estimable, small, and testable" (mnemonic INVEST). Good tasks are expected to be specific, measurable, achievable, relevant, and time-boxed" (mnemonic SMART). The key difference is that tasks need not be independent or valuable by themselves." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"This is what the Agile Manifesto means when it says responding to change over following a plan. To maximize adaptability, it is essential to have good, fast feedback loops. This is why there is so much emphasis on iterative development." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"No methodology can guarantee success. But a good methodology can provide a feedback loop for continual improvement and learning." (Ash Maurya, "Scaling Lean: Mastering the Key Metrics for Startup Growth", 2016)

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

"Feature extraction is also the most creative part of data science and the one most closely tied to domain expertise. Typically, a really good feature will correspond to some real-world phenomenon. Data scientists should work closely with domain experts and understand what these phenomena mean and how to distill them into numbers." (Field Cady, "The Data Science Handbook", 2017)

"Making good engineering decisions is all about weighing all of the available inputs and making informed decisions about the trade-offs. Sometimes, those decisions are based on instinct or accepted best practice, but only after we have exhausted approaches that try to measure or estimate the true underlying costs." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

🕸Systems Engineering: The Bad (Just the Quotes)

"The concept of teleological mechanisms however it be expressed in many terms, may be viewed as an attempt to escape from these older mechanistic formulations that now appear inadequate, and to provide new and more fruitful conceptions and more effective methodologies for studying self-regulating processes, self-orienting systems and organisms, and self-directing personalities. Thus, the terms feedback, servomechanisms, circular systems, and circular processes may be viewed as different but equivalent expressions of much the same basic conception." (Lawrence K Frank, 1948)

"[...] the concept of 'feedback', so simple and natural in certain elementary cases, becomes artificial and of little use when the interconnexions between the parts become more complex. When there are only two parts joined so that each affects the other, the properties of the feedback give important and useful information about the properties of the whole. But when the parts rise to even as few as four, if every one affects the other three, then twenty circuits can be traced through them; and knowing the properties of all the twenty circuits does not give complete information about the system. Such complex systems cannot be treated as an interlaced set of more or less independent feedback circuits, but only as a whole. For understanding the general principles of dynamic systems, therefore, the concept of feedback is inadequate in itself. What is important is that complex systems, richly cross-connected internally, have complex behaviours, and that these behaviours can be goal-seeking in complex patterns." (W Ross Ashby, "An Introduction to Cybernetics", 1956)

"To say a system is 'self-organizing' leaves open two quite different meanings. There is a first meaning that is simple and unobjectionable. This refers to the system that starts with its parts separate" (so that the behavior of each is independent of the others' states) and whose parts then act so that they change towards forming connections of some type. Such a system is 'self-organizing' in the sense that it changes from 'parts separated' to 'parts joined'. […] In general such systems can be more simply characterized as 'self-connecting', for the change from independence between the parts to conditionality can always be seen as some form of 'connection', even if it is as purely functional […]  'Organizing' […] may also mean 'changing from a bad organization to a good one' […] The system would be 'self-organizing' if a change were automatically made to the feedback, changing it from positive to negative; then the whole would have changed from a bad organization to a good." (W Ross Ashby, "Principles of the self-organizing system", 1962)

"The purpose and real value of systems engineering is [...] to keep going around the loop; find inadequacies and make improvements." (Robert E Machol, "Mathematicians are useful", 1971)

"Systems with unknown behavioral properties require the implementation of iterations which are intrinsic to the design process but which are normally hidden from view. Certainly when a solution to a well-understood problem is synthesized, weak designs are mentally rejected by a competent designer in a matter of moments. On larger or more complicated efforts, alternative designs must be explicitly and iteratively implemented. The designers perhaps out of vanity, often are at pains to hide the many versions which were abandoned and if absolute failure occurs, of course one hears nothing. Thus the topic of design iteration is rarely discussed. Perhaps we should not be surprised to see this phenomenon with software, for it is a rare author indeed who publicizes the amount of editing or the number of drafts he took to produce a manuscript." (Fernando J Corbató, "A Managerial View of the Multics System Development", 1977)

"How can a cognitive system process environmental input and stored knowledge so as to benefit from experience? More specific versions of this question include the following: How can a system organize its experience so that it has some basis for action even in unfamiliar situations? How can a system determine that rules in its knowledge base are inadequate? How can it generate plausible new rules to replace the inadequate ones? How can it refine rules that are useful but non-optimal? How can it use metaphor and analogy to transfer information and procedures from one domain to another?" (John H Holland et al, "Induction: Processes Of Inference, Learning, And Discovery", 1986)

"[…] the complexity of a given system is always determined relative to another system with which the given system interacts. Only in extremely special cases, where one of these reciprocal interactions is so much weaker than the other that it can be ignored, can we justify the traditional attitude regarding complexity as an intrinsic property of the system itself." (John L Casti, "Reality Rules: Picturing the world in mathematics", 1992)

"Complex adaptive systems have the property that if you run them - by just letting the mathematical variable of 'time' go forward - they'll naturally progress from chaotic, disorganized, undifferentiated, independent states to organized, highly differentiated, and highly interdependent states. Organized structures emerge spontaneously. [...]A weak system gives rise only to simpler forms of self-organization; a strong one gives rise to more complex forms, like life." (J Doyne Farmer, The Third Culture: Beyond the Scientific Revolution", 1995)

"No plea about inadequacy of our understanding of the decision-making processes can excuse us from estimating decision making criteria. To omit a decision point is to deny its presence - a mistake of far greater magnitude than any errors in our best estimate of the process." (Jay W Forrester, "Perspectives on the modelling process", 2000)

"Remember a networked learning machine’s most basic rule: strengthen the connections to those who succeed, weaken them to those who fail." (Howard Bloom, "Global Brain: The Evolution of Mass Mind from the Big Bang to the 21st Century", 2000)

"A fundamental reason for the difficulties with modern engineering projects is their inherent complexity. The systems that these projects are working with or building have many interdependent parts, so that changes in one part often have effects on other parts of the system. These indirect effects are frequently unanticipated, as are collective behaviors that arise from the mutual interactions of multiple components. Both indirect and collective effects readily cause intolerable failures of the system. Moreover, when the task of the system is intrinsically complex, anticipating the many possible demands that can be placed upon the system, and designing a system that can respond in all of the necessary ways, is not feasible. This problem appears in the form of inadequate specifications, but the fundamental issue is whether it is even possible to generate adequate specifications for a complex system." (Yaneer Bar-Yam, "Making Things Work: Solving Complex Problems in a Complex World", 2004)

"It is no longer sufficient for engineers merely to design boxes such as computers with the expectation that they would become components of larger, more complex systems. That is wasteful because frequently the box component is a bad fit in the system and has to be redesigned or worse, can lead to system failure. We must learn how to design large-scale, complex systems from the top down so that the specification for each component is derivable from the requirements for the overall system. We must also take a much larger view of systems. We must design the man-machine interfaces and even the system-society interfaces. Systems engineers must be trained for the design of large-scale, complex, man-machine-social systems." (A Wayne Wymore, "Systems Movement: Autobiographical Retrospectives", 2004)

"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)

"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)

See also: Failure, Good, Bad, Ugly, Perfection

🏗️Software Engineering: The Bad (Just the Quotes)

"At the present time, choosing a programming language is equivalent to choosing a data structure, and if that data structure does not fit the data you want to manipulate then it is too bad. It would, in a sense, be more logical first to choose a data structure appropriate to the problem and then look around for, or construct with a kit of tools provided, a language suitable for manipulating that data structure." (Maurice V Wilkes, "Computers Then and Now", 1968)

"Don't comment bad code - rewrite it." (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)

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

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

"There is no programming language, no matter how structured, that will prevent programmers from making bad programs." (Larry Flon, "On research in structured programming", SIGPLAN 10(10), 1975)

"Today's scientific investigations are so complicated that even experts in related fields may not understand them well. But there is a logic in the planning of experiments and in the analysis of their results that all intelligent people can grasp, and this logic is a great help in determining when to believe what we hear and read and when to be skeptical. This logic has a great deal to do with statistics, which is why statisticians have a unique interest in the scientific method, and why some knowledge of statistics can so often be brought to bear in distinguishing good arguments from bad ones." (Robert Hooke, "How to Tell the Liars from the Statisticians", 1983)

"The woes of software engineering are not due to lack of tools or proper management, but largely due to lack of sufficient technical competence. A good designer must rely on experience; on precise, logical thinking; and on pedantic exactness. No magic will do. In light of all this, it is particularly sad that, in many informatics curricula, programming in the large is badly neglected. Design has become a non-topic." (Niklaus Wirth, [interview in Software Development] 1997)

"Don't produce voluminous design documents at the beginning. Don't even produce them in the middle: produce them at the end. Extreme Programming teaches you how to keep the design flexible, for highest flexibility and fastest implementation. The design documents you produce at the beginning will go out of date very quickly" (they always do, even on non-Extreme projects), and you 'Il either waste time updating the docs or let them get out of date. Either is bad." (Ron Jeffries, "Extreme Programming Installed", 2001)

"In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful. [...] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships." (Linus Torvalds, [email] 2006)

"Much data in databases has a long history. It might have come from old 'legacy' systems or have been changed several times in the past. The usage of data fields and value codes changes over time. The same value in the same field will mean totally different thing in different records. Knowledge or these facts allows experts to use the data properly. Without this knowledge, the data may bc used literally and with sad consequences. The same is about data quality. Data users in the trenches usually know good data from bad and can still use it efficiently. They know where to look and what to check. Without these experts, incorrect data quality assumptions are often made and poor data quality becomes exposed." (Arkady Maydanchik, "Data Quality Assessment", 2007)

"It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don't have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 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) 

"Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"If a pattern represents a best practice, then an antipattern represents lessons learned from a bad design. [...] Antipatterns are valuable because they help us to recognise why a particular design alternative might seem at first like an attractive solution, but later on lead to complicacies and finally turn out to be a poor solution." (Rajib Mall, "Fundamentals of Software Engineering" 4th Ed., 2014)

"But 'average cost to fix one defect' is a stupid metric [...] It makes bad projects look good, and good projects look bad. How? By failing to divide the costs of fixing into two categories: fixed costs of detecting and fixing defects - costs which are the same no matter how buggy or how good the product is - and variable costs, those which you pay for each defect." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"Creating mockups to communicate is not intrinsically a bad idea. But, as we are subject to confirmation bias, there.s always a risk that we will stop at our first design attempt and become reluctant to ask if there are better ways to achieve the same goals. Making these first ideas very detailed; putting them into a document; and especially blessing that document with the label 'requirements' are all moves which make further revision less likely, and put us more at risk from confirmation bias." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"We, newbies and young programmers, don't like chaos because it makes us dependent on experts. We have to beg for information and feel bad." (Yegor Bugayenko, "Code Ahead", 2018)

"In addition to developing the proper culture, invest in your testing infrastructure by developing linters, documentation, or other assistance that makes it more difficult to write bad tests." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

🤖〽️Prompt Engineering: Copilot Unabridged (Part 122: Human–Machine Ecologies - Evolution over Next Decade)

 

Prompt Engineering Series

Prompt: "write a blog post of 600 words on the human-machine ecologies and their evolution over next decade focusing on the Foundations of Ambient Intelligence"

Introduction

Over the coming decade, human–machine ecologies will undergo a profound shift. We’re moving from a world where technology is something we use to one where it becomes something we live within. This transition - often described as the rise of ambient intelligence - marks the beginning of environments that sense, respond, and adapt to human presence with increasing subtlety. The next ten years will lay the groundwork for this transformation, shaping how we work, move, communicate, and care for one another.

The Quiet Embedding of Intelligence

Ambient intelligence doesn’t arrive with fanfare. It emerges quietly, through the gradual embedding of sensors, micro‑processors, and adaptive software into the spaces we inhabit. Over the next decade, this embedding will accelerate. Homes will learn daily rhythms and adjust lighting, temperature, and energy use without explicit commands. Offices will become responsive ecosystems that optimize collaboration, comfort, and focus. Public spaces will adapt to crowd flow, environmental conditions, and accessibility needs in real time.

What makes this shift ecological is the interplay between humans and machines. These systems won’t simply automate tasks; they’ll form feedback loops. Human behavior shapes machine responses, and machine responses shape human behavior. The ecology becomes a living system - dynamic, adaptive, and co‑evolving.

From Devices to Distributed Intelligence

One of the biggest changes ahead is the move away from device‑centric thinking. Today, we still treat phones, laptops, and smart speakers as discrete tools. Over the next decade, intelligence will diffuse across environments. Instead of asking a specific device to perform a task, people will interact with a distributed network that understands context. 

Imagine walking into your kitchen and having the room know whether you’re preparing a meal, grabbing a quick snack, or hosting friends. The intelligence isn’t in a single gadget; it’s in the relationships between sensors, data, and human intention. This shift will redefine how we design spaces, workflows, and even social interactions.

The Rise of Predictive and Adaptive Systems

Ambient intelligence thrives on prediction. As machine learning models become more sophisticated, environments will anticipate needs rather than simply respond to them. Over the next decade, predictive systems will become more accurate, more personalized, and more seamlessly integrated.

Transportation networks will anticipate congestion before it forms. Healthcare environments will detect subtle changes in behavior or physiology and prompt early interventions. Workspaces will adjust to cognitive load, offering focus‑enhancing conditions during deep work and collaborative cues during team sessions.

The challenge - and opportunity - lies in ensuring that these predictions enhance human autonomy rather than constrain it. The most successful systems will be those that support human choice, not replace it.

Ethical Foundations for a Machine‑Rich Ecology

As machines become more present and more perceptive, ethical questions will move to the forefront. The next decade will force societies to confront issues of privacy, consent, transparency, and agency in environments where machines are always listening, watching, and learning.

Who owns the data generated by ambient systems? How do we ensure that adaptive environments don’t reinforce bias or exclusion? What does autonomy mean when environments are constantly nudging behavior?

These questions won’t be solved by technology alone. They will require new governance models, new cultural norms, and new forms of digital literacy. The foundations of ambient intelligence must be ethical as well as technical.

Human Flourishing in Machine‑Enhanced Spaces

Despite the complexity, the promise of ambient intelligence is compelling. Done well, it can create environments that are more humane, more sustainable, and more responsive to individual and collective needs. It can reduce cognitive load, enhance creativity, support well‑being, and help societies use resources more wisely.

The next decade is not about machines taking over; it’s about machines becoming better partners. Human–machine ecologies will evolve toward balance - where technology amplifies human potential rather than overshadowing it.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🏗️Software Engineering: The Ugly (Just the Quotes)

"[...] when a variety of tasks have all to be performed in cooperation, synchronization, and communication, a business needs managers and a management. Otherwise, things go out of control; plans fail to turn into action; or, worse, different parts of the plans get going at different speeds, different times, and with different objectives and goals, and the favor of the 'boss' becomes more important than performance." (Peter F Drucker, "People and Performance", 1977)

"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", 1987)

"The longer we wait between integrations and acceptance tests, the worse things get. Wait twice as long and we'll have four or more times the hassle. The reason is that one bug written just yesterday is pretty easy to find, while ten or a hundred written weeks ago can become almost impossible." (Ron Jeffries, "Extreme Programming Installed", 2001)

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

"Prototyping is always inspirational - not in the sense of a perfected artwork but just the opposite: because it inspires new ideas. Prototyping should start early in the life of a project, and we expect them to be numerous, quickly executed, and pretty ugly." (Tim Brown, "Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation", 2009)

"But the history of large systems demonstrates that, once the hurdle of stability has been cleared, a more subtle challenge appears. It is the challenge of remaining stable when the rules change. Machines, like organizations or organisms, that fail to meet this challenge find that their previous stability is no longer of any use. The responses that once were life-saving now just make things worse. What is needed now is the capacity to re-write the procedure manual on short notice, or even" (most radical change of all) to change goals." (John Gall, "The Systems Bible: The Beginner's Guide to Systems Large and Small"[Systematics 3rd Ed.], 2011)

"A boat without a captain is nothing more than a floating waiting room: unless someone grabs the rudder and starts the engine, it's just going to drift along aimlessly with the current. A piece of software is just like that boat: if no one pilots it, you're left with a group of engineers burning up valuable time, just sitting around waiting for something to happen (or worse, still writing code that you don't need)." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

🏗️Software Engineering: Relationships (Just the Quotes)

"Since software construction is inherently a systems effort - an exercise in complex interrelationships - communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning [increasing the workers]. Adding more people then lengthens, not shortens, the schedule." (Frederick Brook, "The Mythical Man-Month", 1975)

"By pulling together all of the decisions affecting the choice of modules and interrelationships in a system, we necessarily affect the way in which other decisions are organized and resolved. Thus, some issues which have traditionally been approached in a certain way during the earliest phase of a project may have to be dealt with in an entirely different manner at a much later stage once the designer graduates to a structured design approach." (Edward Yourdon & Larry L Constantine, "Structured Design: Fundamentals of a discipline of computer program and systems design", 1978)

"Elements" (lines of code) in a coincidentally-cohesive module have no relationship. Typically occurs as the result of modularizing existing code, to separate out redundant code." (Edward Yourdon & Larry L Constantine, "Structured Design: Fundamentals of a discipline of computer program and systems design", 1978)

"Module cohesion may be conceptualized as the cement that holds the processing elements of a module together. It is a most crucial factor in structured design, and it is a major constituent of effective modularity. The concept represents the principal technical handle" that a designer has on the relationship of his system to the original problem structure. In a sense, a high degree of module cohesion is an indication of close approximation of inherent problem structure." (Edward Yourdon & Larry L Constantine, "Structured Design: Fundamentals of a discipline of computer program and systems design", 1978)

"Architecture is defined as a clear representation of a conceptual framework of components and their relationships at a point in time [���] a discussion of architecture must take into account different levels of architecture. These levels can be illustrated by a pyramid, with the business unit at the top and the delivery system at the base. An enterprise is composed of one or more Business Units that are responsible for a specific business area. The five levels of architecture are Business Unit, Information, Information System, Data and Delivery System. The levels are separate yet interrelated. [...] The idea if an enterprise architecture reflects an awareness that the levels are logically connected and that a depiction at one level assumes or dictates that architectures at the higher level." (W Bradford Rigdon, "Architectures and Standards", 1989)

"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)

"Visual thinking is necessary in engineering. A major portion of engineering information is recorded and transmitted in a visual language that is in effect the lingua franca of engineers in the modern world. It is the language that permits 'readers' of technologically explicit and detailed drawings to visualise the forms, the proportions, and the interrelationships of the elements that make up the object depicted. It is the language in which designers explain to makers what they want them to construct." (Eugene S Ferguson, "Engineering and the Mind's Eye", 1992)

"Although the concept of an enterprise architecture (EA) has not been well defined and agreed upon, EAs are being developed to support information system development and enterprise reengineering. Most EAs differ in content and nature, and most are incomplete because they represent only data and process aspects of the enterprise. [...] An EA is a conceptual framework that describes how an enterprise is constructed by defining its primary components and the relationships among these components." (M A Roos, "Enterprise architecture: definition, content, and utility", Enabling Technologies: Infrastructure for Collaborative Enterprises, 1994)

"Meaning is conferred not by a one-to-one correspondence of a symbol with some external concept or object, but by the relationships between the structural components of the system itself." (Paul Cilliers, "Complexity and Postmodernism: Understanding Complex Systems", 1998)

"Complexity is that property of a model which makes it difficult to formulate its overall behaviour in a given language, even when given reasonably complete information about its atomic components and their inter-relations." (Bruce Edmonds, "Syntactic Measures of Complexity", 1999)

"Computer programs are complex by nature. Even if you could invent a programming language that operated exactly at the level of the problem domain, programming would be complicated because you would still need to precisely define relationships between real-world entities, identify exception cases, anticipate all possible state transitions, and so on. Strip away the accidental work involved in representing these factors in a specific programming language and in a specific computing environment, and you still have the essential difficulty of defining the underlying real-world concepts and debugging your understanding of them." (Steve C McConnell," After the Gold Rush : Creating a True Profession of Software Engineering", 1999)

"Enterprise architecture is a family of related architecture components. This include information architecture, organization and business process architecture, and information technology architecture. Each consists of architectural representations, definitions of architecture entities, their relationships, and specification of function and purpose. Enterprise architecture guides the construction and development of business organizations and business processes, and the construction and development of supporting information systems." (Gordon B Davis, "The Blackwell encyclopedic dictionary of management information systems", 1999)

"Generically, an architecture is the description of the set of components and the relationships between them. [...] A software architecture describes the layout of the software modules and the connections and relationships among them. A hardware architecture can describe how the hardware components are organized. However, both these definitions can apply to a single computer, a single information system, or a family of information systems. Thus 'architecture' can have a range of meanings, goals, and abstraction levels, depending on who's speaking." (Frank J Armour et al, "A big-picture look at enterprise architectures", IT professional Vol 1 (1), 1999)

"The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution." (ANSI/IEEE Std 1471: 2000)

"On small, informal projects, a lot of design is done while the programmer sits at the keyboard. 'Design' might be just writing a class interface in pseudocode before writing the details. It might be drawing diagrams of a few class relationships before coding them. It might be asking another programmer which design pattern seems like a better choice. Regardless of how it's done, small projects benefit from careful design just as larger projects do, and recognizing design as an explicit activity maximizes the benefit you will receive from it." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful. [...] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships." (Linus Torvalds, [email] 2006)

"A conceptual model of an interactive application is, in summary: the structure of the application - the objects and their operations, attributes, and relation-ships; an idealized view of the how the application works - the model designers hope users will internalize; the mechanism by which users accomplish the tasks the application is intended to support." (Jeff Johnson & Austin Henderson, "Conceptual Models", 2011)

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

"Once we understand our user's mental model, we can capture it in a conceptual model. The conceptual model is a representation of the mental model using elements, relationships, and conditions. Our design and final system will be the tangible result of this conceptual model." (Pau Giner & Pablo Perea, "UX Design for Mobile, 2017)

"The calculus of causation consists of two languages: causal diagrams, to express what we know, and a symbolic language, resembling algebra, to express what we want to know. The causal diagrams are simply dot-and-arrow pictures that summarize our existing scientific knowledge. The dots represent quantities of interest, called 'variables', and the arrows represent known or suspected causal relationships between those variables - namely, which variable 'listens' to which others." (Judea Pearl & Dana Mackenzie, "The Book of Why: The new science of cause and effect", 2018)

🤖〽️Prompt Engineering: Copilot Unabridged (Part 116: When Can AI Achieve Logical Consistency?)

Prompt Engineering Series

Prompt: "write a post of 600 words on whether AI-based machine can become logically consistent"

Introduction

Logical consistency means that a system’s reasoning does not contradict itself and that conclusions follow validly from premises. For Artificial Intelligence (AI), this is not just a philosophical aspiration but a practical necessity: inconsistent reasoning undermines trust in applications ranging from healthcare to engineering.

Current AI systems are not logically consistent. Deep learning models, with trillions of parameters, excel at pattern recognition but lack explicit logical relationships between parameters and the objects they model. This disconnect produces outputs that may be correct in some contexts but contradictory in others.

Researchers argue that AI can become logically consistent only when uniform logical frameworks are established across all levels of the system:

• Datasets must be structured to reflect multilevel complexity rather than isolated correlations.
• Models must integrate symbolic logic with probabilistic reasoning.
• Software and hardware must support coherent logical structures, ensuring that consistency is preserved across platforms.

Pathways Toward Consistency

Neuro-symbolic Integration

• Combining neural networks with symbolic logic allows AI to validate reasoning steps.
• This hybrid approach can detect contradictions and enforce logical rules, moving AI closer to consistency.

Complexity Science Principles

• Guo and Li propose aligning AI with multilevel complexity and the 'compromise-in-competition' principle from mesoscience.
• This ensures that AI models reflect the layered, dynamic nature of real-world systems rather than oversimplified correlations.

Consistency Across Components

• Logical consistency requires coherence between datasets, models, and hardware.
• Without this alignment, inconsistencies propagate, undermining scalability and reliability.

Validation and Safety Frameworks

• Logical consistency is also tied to AI safety. Systems must be able to reconcile disagreements between agents and avoid contradictions that could lead to unsafe outcomes.

Limits and Challenges

Even with these pathways, absolute logical consistency may remain unattainable:

• Probabilistic foundations: AI thrives on probability distributions, which inherently allow variation.
• Human-like fallibility: AI trained on human data inherits inconsistencies from human reasoning.
• Scaling issues: Ensuring consistency across billions of parameters is exponentially complex.

Thus, AI can become more consistent, but perfect logical coherence may be impossible. The goal is not perfection but functional consistency - a level sufficient to ensure usability, trust, and safety.

Practical Milestones

• AI-based machines can be considered logically consistent enough for real-world use when they achieve:
• Predictable reasoning: Similar inputs yield similar, non-contradictory outputs.
• Transparent validation: Systems can explain and justify their reasoning steps.
• Error detection: Contradictions are flagged and corrected rather than hidden.
• Cross-domain coherence: Consistency is maintained across datasets, models, and hardware.

These milestones mark the point at which AI transitions from probabilistic black boxes to trustworthy reasoning systems.

Conclusion

AI-based machines can become logically consistent when uniform logical frameworks, neuro-symbolic integration, and complexity science principles are embedded into their design. While perfect consistency may remain out of reach, achieving functional consistency - predictable, transparent, and coherent reasoning - will make AI usable and trustworthy in high-stakes domains.

In short, AI will become logically consistent not through incremental tweaks but through a paradigm shift in architecture, aligning data, models, and hardware under coherent logical principles.

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

🤖〽️Prompt Engineering: Copilot Unabridged (Part 113: Fitting the Frame - Schema Congruency and the Intuition of AI)

Prompt Engineering Series

Prompt: "write a post of 600 words on schema congruency in AI"

Introduction

As Artificial Intelligence (AI) becomes more embedded in our daily lives, the way we interact with it is shaped not just by technical performance but by cognitive psychology. One powerful concept influencing this interaction is schema congruency. In simple terms, schema congruency refers to how well new information fits into our existing mental frameworks - or schemas. When AI outputs align with what users expect or understand, they’re perceived as more trustworthy, intuitive, and memorable.

What Is Schema Congruency?

Schemas are mental structures that help us organize and interpret information. They’re built from past experiences and cultural knowledge, allowing us to quickly make sense of new situations. For example, when you walk into a restaurant, you expect to be seated, handed a menu, and served food - this is your restaurant schema.

Schema congruency occurs when new information fits smoothly into these frameworks. In AI, this means that the system’s behavior, language, and interface match what users anticipate. When congruent, users experience less cognitive friction and are more likely to trust and remember the interaction [1].

Schema Congruency in AI Design

AI developers often leverage schema congruency to improve user experience. For instance, a virtual assistant that mimics human conversational norms - like greeting users, using polite phrasing, and responding in context - feels more natural. This congruence with social schemas makes the AI seem more intelligent and relatable.

Similarly, AI interfaces that resemble familiar layouts (like email inboxes or search engines) reduce the learning curve. Users don’t need to build new mental models from scratch; they can rely on existing schemas to navigate the system. This is especially important in enterprise software, where schema-congruent design can boost adoption and reduce training costs.

Congruency and Memory Encoding

Schema congruency also affects how well users retain information from AI interactions. Research shows that when new data aligns with existing schemas, it’s encoded more efficiently in memory. A 2022 study published in Nature Communications found that schema-congruent information led to stronger memory traces and better integration in the brain’s neocortex.

In practical terms, this means that users are more likely to remember AI-generated recommendations, instructions, or insights if they’re presented in a familiar format. For example, a health app that explains symptoms using everyday language and analogies will be more memorable than one that uses clinical jargon.

The Risks of Incongruency

While schema congruency enhances usability, incongruency can create confusion or mistrust. If an AI system behaves unpredictably or uses unfamiliar terminology, users may disengage or misinterpret its outputs. This is particularly risky in high-stakes domains like healthcare, finance, or legal tech, where misunderstanding can have serious consequences.

Moreover, excessive reliance on schema congruency can reinforce biases. If AI systems always conform to dominant cultural schemas, they may marginalize alternative perspectives or perpetuate stereotypes. Developers must strike a balance between familiarity and inclusivity.

Designing for Schema Awareness

To optimize schema congruency in AI, designers and developers should:

• Understand user expectations through research and testing.
• Align language and behavior with familiar norms and contexts.
• Use consistent visual and interaction patterns across platforms.
• Introduce novelty gradually, allowing users to adapt their schemas.
• Audit for bias, ensuring that schema alignment doesn’t exclude diverse users.

Conclusion

Schema congruency is a subtle yet powerful force in shaping how users perceive and interact with AI. By aligning outputs with familiar mental models, AI systems can become more intuitive, memorable, and trustworthy. But with this power comes responsibility: to design systems that are not only congruent - but also inclusive, transparent, and adaptable.

Just try the prompt on Copilot or your favorite AI-powered assistant! Have you got a different/similar result? How big or important is the difference? Any other thoughts?
Just share the link to the post with me and I'll add it to this post as a resource!

Disclaimer: The whole text was generated by Copilot (under Windows 11) at the first attempt. This is just an experiment to evaluate feature's ability to answer standard general questions, independently on whether they are correctly or incorrectly posed. Moreover, the answers may reflect hallucinations and other types of inconsistent or incorrect reasoning.

Previous Post <<||>> Next Post

References
[1] Sam Audrain & Mary Pat McAndrews  (2022) Schemas provide a scaffold for neocortical integration of new memories over time, Nature Communications vol. 13, Art.#: 5795
[2] Julia A Meßmer et al (2021) The more you know: Schema-congruency supports associative encoding of novel compound words. Evidence from event-related potentials, Brain and Cognition
[3] Dimitrios P. Panagoulias et al (2024)Memory and Schema in Human-Generative Artificial Intelligence Interactions, IEEE 36th International Conference on Tools with Artificial Intelligence (ICTAI)