🏗️Software Engineering: Software Deployment (Just the Quotes)

"A system that is comprehensively tested and passes all of its tests all of the time is a testable system. That’s an obvious statement, but an important one. Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Releasing software should be easy. It should be easy because you have tested every single part of the release process hundreds of times before. It should be as simple as pressing a button. The repeatability and reliability derive from two principles: automate almost everything, and keep everything you need to build, deploy, test, and release your application in version control." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"So, when should you think about automating a process? The simplest answer is, 'When you have to do it a second time.' The third time you do something, it should be done using an automated process. This fine-grained incremental approach rapidly creates a system for automating the repeated parts of your development, build, test, and deployment process." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"The deployment pipeline has its foundations in the process of continuous integration and is in essence the principle of continuous integration taken to its logical conclusion. The aim of the deployment pipeline is threefold. First, it makes every part of the process of building, deploying, testing, and releasing software visible to everybody involved, aiding collaboration. Second, it improves feedback so that problems are identified, and so resolved, as early in the process as possible. Finally, it enables teams to deploy and release any version of their software to any environment at will through a fully automated process." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"In essence, Continuous Integration is about reducing risk by providing faster feedback. First and foremost, it is designed to help identify and fix integration and regression issues faster, resulting in smoother, quicker delivery, and fewer bugs. By providing better visibility for both technical and non-technical team members on the state of the project, Continuous Integration can open and facilitate communication channels between team members and encourage collaborative problem solving and process improvement. And, by automating the deployment process, Continuous Integration helps you get your software into the hands of the testers and the end users faster, more reliably, and with less effort." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"System engineering is concerned with all aspects of the development and evolution of complex systems where software plays a major role. System engineering is therefore concerned with hardware development, policy and process design and system deployment, as well as software engineering. System engineers are involved in specifying the system, defining its overall architecture, and then integrating the different parts to create the finished system. They are less concerned with the engineering of the system components (hardware, software, etc.)." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"A value stream is a series of activities required to deliver an outcome. The software development value stream may be described as: validate business case, analyze, design, build, test, deploy, learn from usage analytics and other feedback - rinse and repeat." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Continuous deployment is but one of many powerful tools at your disposal for increasing iteration speed. Other options include investing in time-saving tools, improving your debugging loops, mastering your programming workflows, and, more generally, removing any bottlenecks that you identify." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"Why is continuous deployment such a powerful tool? Fundamentally, it allows engineers to make and deploy small, incremental changes rather than the larger, batched changes typical at other companies. That shift in approach eliminates a significant amount of overhead associated with traditional release processes, making it easier to reason about changes and enabling engineers to iterate much more quickly." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

🏗️Software Engineering: Interfaces (Just the Quotes)

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

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

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

"With increasing size and complexity of the implementations of information systems, it is necessary to use some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system." (John Zachman, "A Framework for Information Systems Architecture", 1987)

"Programmers are responsible for software quality - quality in their own work, quality in the products that incorporate their work, and quality at the interfaces between components. Quality has never been and will never be tested in. The responsibility is both moral and professional." (Boris Beizer, "Software Testing Techniques", 1990)

"A problem with this 'waterfall' approach is that there will then be no user interface to test with real users until this last possible moment, since the 'intermediate work products' do not explicitly separate out the user interface in a prototype with which users can interact. Experience also shows that it is not possible to involve the users in the design process by showing them abstract specifications documents, since they will not understand them nearly as well as concrete prototypes." (Jakob Nielsen, "Usability Engineering", 1993)

"One should not start full-scale implementation efforts based on early user interface designs. Instead, early usability evaluation can be based on prototypes of the final systems that can be developed much faster and much more cheaply, and which can thus be changed many times until a better understanding of the user interface design has been achieved." (Jakob Nielsen, "Usability Engineering", 1993)

"Scenarios are an especially cheap kind of prototype. […] Scenarios are the ultimate reduction of both the level of functionality and of the number of features: They can only simulate the user interface as long as a test user follows a previously planned path. […] Scenarios are the ultimate minimalist prototype in that they describe a single interaction session without any flexibility for the user. As such, they combine the limitations of both horizontal prototypes (users cannot interact with real data) and vertical prototypes (users cannot move freely through the system)." (Jakob Nielsen, "Usability Engineering", 1993)

"The difference between standards and guidelines is that a standard specifies how the interface should appear to the user, whereas a set of guidelines provides advice about the usability characteristics of the interface." (Jakob Nielsen, "Usability Engineering", 1993)

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

"As the least conscious layer of the user experience, the conceptual model has the paradoxical quality of also having the most impact on usability. If an appropriate conceptual model is faithfully represented throughout the interface, after users recognize and internalize the model, they will have a fundamental understanding of what the application does and how to operate it." (Bob Baxley, "Making the Web Work: Designing Effective Web Applications", 2002)

"Modularity, an approach that separates a large system into simpler parts that are individually designed and operated, incorrectly assumes that complex system behavior can essentially be reduced to the sum of its parts. A planned decomposition of a system into modules works well for systems that are not too complex. […] However, as systems become more complex, this approach forces engineers to devote increasing attention to designing the interfaces between parts, eventually causing the process to break down."  (Yaneer Bar-Yam, "Making Things Work: Solving Complex Problems in a Complex World", 2004)

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

"Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of a company's operation model. […] The key to effective enterprise architecture is to identify the processes, data, technology, and customer interfaces that take the operating model from vision to reality." (Jeanne W Ross et al, "Enterprise architecture as strategy: creating a foundation for business", 2006)

"An abstraction is not a module, or an interface, class, or method; it is a structure, pure and simple - an idea reduced to its essential form. Since the same idea can be reduced to different forms, abstractions are always, in a sense, inventions, even if the ideas they reduce existed before in the world outside the software. The best abstractions, however, capture their underlying ideas so naturally and convincingly that they seem more like discoveries." (Daniel Jackson, "Software Abstractions", 2006)

"Software is built on abstractions. Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization […] Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make." (Daniel Jackson, "Software Abstractions", 2006)

"We tend to form mental models that are simpler than reality; so if we create represented models that are simpler than the actual implementation model, we help the user achieve a better understanding. […] Understanding how software actually works always helps someone to use it, but this understanding usually comes at a significant cost. One of the most significant ways in which computers can assist human beings is by putting a simple face on complex processes and situations. As a result, user interfaces that are consistent with users’ mental models are vastly superior to those that are merely reflections of the implementation model." (Alan Cooper et al,  "About Face 3: The Essentials of Interaction Design", 2007)

"Structural patterns describe how classes and objects can be combined to form larger structures. Patterns for classes describe how inheritance can be used to provide more useful program interfaces. Patterns for objects describe how objects can be composed into larger structures using object composition." (Junji Nakano et al, "Programming Statistical Data Visualization in the Java Language" [in "Handbook of Data Visualization"], 2008)

"Making interfaces hard to use incorrectly requires two things. First, you must anticipate errors users might make and find ways to prevent them. Second, you must observe how an interface is misused during early release and modify the interface - yes, modify the interface! - to prevent such errors. The best way to prevent incorrect use is to make such use impossible. If users keep wanting to undo an irrevocable action, try to make the action revocable. If they keep passing the wrong value to an API, do your best to modify the API to take the values that users want to pass." (Scott Meyers, [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"More generally, each unit of code, from a block to a library, should have a narrow interface. Less communication reduces the reasoning required. This means that getters that return internal state are a liability - don’t ask an object for information to work with. Instead, ask the object to do the work with the information it already has. In other words, encapsulation is all - and only - about narrow interfaces." (Yechiel Kimchi [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

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

"When an engineer refactors the internals of a system without modifying its interface, whether for performance, clarity, or any other reason, the system’s tests shouldn’t need to change. The role of tests in this case is to ensure that the refactoring didn’t change the system’s behavior. Tests that need to be changed during a refactoring indicate that either the change is affecting the system’s behavior and isn’t a pure refactoring, or that the tests were not written at an appropriate level of abstraction." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

🏗️Software Engineering: Risks (Just the Quotes)

"The major distinguishing feature of the spiral model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties." (Barry Boehm, "A spiral model of software development and enhancement", IEEE, 1988)

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

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

"Developing fewer features allows you to conserve development resources and spend more time refining those features that users really need. Fewer features mean fewer things to confuse users, less risk of user errors, less description and documentation, and therefore simpler Help content. Removing any one feature automatically increases the usability of the remaining ones." (Jakob Nielsen, "Prioritizing Web Usability", 2006)

"Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Modeling is the creation of abstractions or representations of the system to predict and analyze performance, costs, schedules, and risks and to provide guidelines for systems research, development, design, manufacture, and management. Modeling is the centerpiece of systems architecting - a mechanism of communication to clients and builders, of design management with engineers and designers, of maintaining system integrity with project management, and of learning for the architect, personally."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"In essence, Continuous Integration is about reducing risk by providing faster feedback. First and foremost, it is designed to help identify and fix integration and regression issues faster, resulting in smoother, quicker delivery, and fewer bugs. By providing better visibility for both technical and non-technical team members on the state of the project, Continuous Integration can open and facilitate communication channels between team members and encourage collaborative problem solving and process improvement. And, by automating the deployment process, Continuous Integration helps you get your software into the hands of the testers and the end users faster, more reliably, and with less effort." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"Systems with high risks must be tested more thoroughly than systems that do not generate big losses if they fail. The risk assessment must be done for the individual system parts, or even for single error possibilities. If there is a high risk for failures by a system or subsystem, there must be a greater testing effort than for less critical (sub)systems. International standards for production of safety-critical systems use this approach to require that different test techniques be applied for software of different integrity levels." (Andreas Spillner et al, "Software Testing Foundations: A Study Guide for the Certified Tester Exam" 4th Ed., 2014)

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

🏗️Software Engineering: Abstraction (Just the Quotes)

"The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer." (Edsger W Dijkstra, "The Humble Programmer", 1972)

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

"All of engineering involves some creativity to cover the parts not known, and almost all of science includes some practical engineering to translate the abstractions into practice." (Richard W Hamming, "The Art of Probability for Scientists and Engineers", 1991)

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

"Watch for coupling that's too tight. 'Coupling' refers to how tight the connection is between two classes. In general, the looser the connection, the better. Several general guidelines flow from this concept: Minimize accessibility of classes and members. Avoid friend classes, because they're tightly coupled. Make data private rather than protected in a base class to make derived classes less tightly coupled to the base class. Avoid exposing member data in a class's public interface. Be wary of semantic violations of encapsulation. Observe the 'Law of Demeter' [...]. Coupling goes hand in glove with abstraction and encapsulation. Tight coupling occurs when an abstraction is leaky, or when encapsulation is broken." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

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

"Abstraction is the ability to engage with a concept while safely ignoring some of its details - handling different details at different levels. Any time you work with an aggregate, you're working with an abstraction. […] From a complexity point of view, the principal benefit of abstraction is that it allows you to ignore irrelevant details. Most real-world objects are already abstractions of some kind." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"Encapsulation picks up where abstraction leaves off. Abstraction says, ‘You're allowed to look at an object at a high level of detail’. Encapsulation says, ‘Furthermore, you aren't allowed to look at an object at any other level of detail’." (Steve C McConnell, "Code Complete: A Practical Handbook of Software Construction" 2nd Ed., 2004)

"A commitment to simplicity of design means addressing the essence of design - the abstractions on which software is built - explicitly and up front. Abstractions are articulated, explained, reviewed and examined deeply, in isolation from the details of the implementation. This doesn’t imply a waterfall process, in which all design and specification precedes all coding. But developers who have experienced the benefits of this separation of concerns are reluctant to rush to code, because they know that an hour spent on designing abstractions can save days of refactoring." (Daniel Jackson, "Software Abstractions", 2006)

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

"An abstraction is not a module, or an interface, class, or method; it is a structure, pure and simple - an idea reduced to its essential form. Since the same idea can be reduced to different forms, abstractions are always, in a sense, inventions, even if the ideas they reduce existed before in the world outside the software. The best abstractions, however, capture their underlying ideas so naturally and convincingly that they seem more like discoveries." (Daniel Jackson, "Software Abstractions", 2006)

"Software is built on abstractions. Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization […] Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make." (Daniel Jackson, "Software Abstractions", 2006)

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

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

"Less apparent is that qualitatively different problem-solving techniques are required at high levels of complexity than at low ones. Purely analytical techniques, powerful for the lower levels, can be overwhelmed at the higher ones. At higher levels, architecting methods, experience-based heuristics, abstraction, and integrated modeling must be called into play."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Modeling is the creation of abstractions or representations of the system to predict and analyze performance, costs, schedules, and risks and to provide guidelines for systems research, development, design, manufacture, and management. Modeling is the centerpiece of systems architecting - a mechanism of communication to clients and builders, of design management with engineers and designers, of maintaining system integrity with project management, and of learning for the architect, personally."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Modeling is the fabric of architecting because architecting is at a considerable distance of abstraction from actual construction. The architect does not manipulate the actual elements of construction. The architect builds models that are passed into more detailed design processes. Those processes lead, eventually, to construction drawings or the equivalent and actual system fabrication or coding."  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"The basic idea behind all of these techniques is to simplify problem solving by concentrating on its essentials. Consolidate and simplify the objectives. Focus on the things with the highest impact, things that determine other things. Put to one side minor issues likely to be resolved by the resolution of major ones. Discard the nonessentials. Model (abstract) the system at as high a level as possible, then progressively reduce the level of abstraction. In short: Simplify!"  (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)

"Programmers need to be fluent in the language of the machine, whether real or virtual, and in the abstractions that can be related to that language via development tools. It is important to learn many different abstractions, otherwise some ideas become incredibly hard to express. Good programmers need to be able to stand outside their daily routine, to be aware of other languages that are expressive for other purposes. The time always comes when this pays off." (Klaus Marquardt, [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"A model is an abstraction of the system being studied rather than an alternative representation of that system. Ideally, a representation of a system should maintain all the information about the entity being represented. An abstraction deliberately simplifies and picks out the most salient characteristics." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Design patterns are high-level abstractions that document successful design solutions. They are fundamental to design reuse in object-oriented development." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"A design pattern, and more generally a design, is an abstraction of an implementation. Because the human mind is better at forming abstractions from details, maybe the best way to get a deeper understanding of design patterns is to reverse engineer one from implementation." (Eddie Burris, "Programming in the Large with Design Patterns", 2012)

"Adopting a mindset of instrumentation means ensuring we have a set of dashboards that surface key health metrics and that enable us to drill down to the relevant data. However, many of the questions we want to answer tend to be exploratory, since we often don’t know everything that we want to measure ahead of time. Therefore, we need to build flexible tools and abstractions that make it easy to track additional metrics." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

"But like many other aspects of code quality, building an abstraction for a problem comes with tradeoffs. Building a generalized solution takes more time than building one specific to a given problem. To break even, the time saved by the abstraction for future engineers needs to outweigh the time invested." (Edmond Lau, "The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact", 2015)

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

"When an engineer refactors the internals of a system without modifying its interface, whether for performance, clarity, or any other reason, the system’s tests shouldn’t need to change. The role of tests in this case is to ensure that the refactoring didn’t change the system’s behavior. Tests that need to be changed during a refactoring indicate that either the change is affecting the system’s behavior and isn’t a pure refactoring, or that the tests were not written at an appropriate level of abstraction." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

🖍️Alan Watkins - Collected Quotes

"A major aspect of the alignment problem is values misalignment: AI systems may lack sufficient understanding of human ethics, cultural norms, or social contexts, making it difficult to translate our values directly into algorithms. For instance, if an AI is programmed to prioritise efficiency without balancing safety or ethical considerations, it might make decisions that, while effective, disregard human welfare. This is further complicated by 'specification gaming', where an AI might exploit loopholes in its programming to achieve objectives in unintended or counterproductive ways. An AI instructed to avoid obstacles, for instance, could redefine what counts as an 'obstacle' and take routes that, while technically following the rule, lead to negative outcomes." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"A transformer is a type of deep learning model designed to handle sequential data, such as text, more efficiently than previous RNNs. It uses a self-attention mechanism introduced [...] to process all parts of a sequence simultaneously, rather than one by one. This allows it to capture relationships between words (or data points) more effectively. The development of transformers revolutionised natural language processing and was a key leap forward. Transformers also used an encoder–decoder architecture. The encoder transforms the input into an abstract representation, and the decoder generates the output. So, by tokenising text into subword units and using parallel self-attention, it enables far greater throughput than RNNs. This design eliminates the need for recurrence (in RNNs) and achieves state-of-the-art results in tasks like translation and allows for a 1,000× speed-up using GPUs." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"An alternative future is a more federated open-source AI where commoditised LLM can be run independently by anyone but loosely coordinated between each other if that is mutually advantageous. This requires sophisticated governance of an ecosystem where the rules that maintain the healthy stability of the ecosystem are defined and adhered to. This model allows anyone to put any LLM on a normal computer and plug into the AI. This is the path that already seems most sensible to business leaders and government officials, who recognise that their private data and iterative datasets hold value that can increase productivity and improve the bottom line or assist citizens in their lives." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"Driven by a fear of missing out (FOMO), many companies have launched AI initiatives. But many failed. For example, customer service chatbots have been introduced to handle inquiries, reduce costs and improve efficiency. But chatbots failed to grasp the complexity of customer issues; they created frustration rather than solving problems. Customers were stuck in repetitive loops, being asked the same questions, and unable to reach a human when needed. Instead of enhancing the customer experience, they delivered spikes in customer complaints instead." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"In game theory, the prisoner’s dilemma provides a powerful framework for understanding why companies might hesitate to adopt AI, even if it appears advantageous in the long run. For example, two competitors might invest in AI-driven automation to gain a potential edge, but if they do they also incur increased costs. Or they could both refrain from adopting AI-automation and avoid the associated risks and expenses. The dilemma arises because each company fears that if it chooses a different path to its competitors, it could be at a significant disadvantage, losing market share, efficiency, or innovation capability." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"In RAG methods, the AI model itself doesn’t actually 'remember' or learn the proprietary data directly. Instead, the proprietary data are stored separately in what’s called a vector database. When the model is asked a question, it first performs a quick search of the proprietary database, finds relevant pieces of information, and then uses these to generate its response. The model’s core parameters remain entirely unchanged and are never updated with this private data. In this sense, the model hasn’t learned or 'seen' your proprietary data in its internal parameters, it only temporarily consults it as a reference to formulate an answer." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"One major concern is goal misalignment, where an AI interprets its goals in unintended ways. This demonstrates the challenge of designing objectives that are both specific and safe and consider the wider context. Another issue is instrumental convergence, the idea that an AI might develop certain intermediate goals, like acquiring resources or ensuring its survival, that help it achieve its primary objective but also make it harder to control. These concerns tie into the broader value alignment problem: the difficulty of ensuring that AI systems act in accordance with human ethics and priorities." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"So training is all about learning from data, while inference is about using that learning to make real-world predictions or classifications. Training builds the model’s capability, while inference applies that capability to new data." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"Synthetic data are artificially created data that closely resembles real-world data, generated using algorithms, simulations, or machine learning models. Unlike real data, which are collected from actual events or user interactions, synthetic data are intentionally designed to share the statistical properties and patterns of real data. This makes it valuable for training and testing machine learning models, particularly in fields where real data may be limited, sensitive, or difficult to obtain. [...] One of the key benefits of synthetic data is its ability to overcome challenges related to data scarcity and privacy. In fields like healthcare and finance, privacy regulations often restrict access to sensitive data. By using synthetic data, developers can create and train models while maintaining user privacy. Additionally, synthetic data can be generated to cover rare or unique scenarios, which may not be well-represented in real-world data, making models more robust and better at handling fringe cases." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"The AI adoption challenges that businesses are facing share a common thread: AI is not a magic solution. Many businesses fall into the trap of expecting AI to solve their problems quickly, without fully understanding its limitations or properly integrating it into their operations. Data quality plays a crucial role in the success of AI systems; if the data are biased, incomplete, or outdated, the results will reflect those shortcomings. In addition, the human element is vital. AI should augment, not replace, human intelligence in areas that require empathy, creativity, or complex decision-making, such as dealing with the many experts right across the organisation. Additionally, AI systems need to be adaptable, accounting for external factors such as cultural differences, market changes, and unpredictable human behaviours." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"This AI-driven version of the prisoner’s dilemma captures a fundamental tension in business decision-making: competitive pressures can compel firms to take actions that aren’t necessarily aligned with their best interests. It highlights the risk of acting defensively out of fear and creating an unsustainable cycle of AI investment without strategic benefit, rather than fostering cooperative approaches that could yield mutual gains, such as industry-wide standards, ethical AI practices, or shared innovation efforts."(Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"The crux of the disagreement lies in the perceived balance of risk and reward. Extinctionists stress that the stakes of getting AI wrong are so high, potentially existential, that precaution must take precedence. Expansionists, however, contend that an overly cautious approach could stifle innovation and prevent humanity from achieving its full potential, including partnering with AI to prevent alignment problems. Bridging this divide requires finding strategies to pursue the benefits of AI while addressing the legitimate concerns about its risks, a balance that continues to fuel heated debate in AI ethics and policy circles." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"The third battleground is the race to Artificial General Intelligence (AGI) – machines capable of performing any intellectual task that humans can. Although still in early skirmishes, this battle is intensifying, with leading technology companies and researchers making significant strides. [...] The race towards AGI is characterised by rapid technological advancements, differing expert opinions on timelines, ethical and regulatory considerations, and geopolitical dynamics. As AI systems become more sophisticated, the importance of responsible development and international cooperation becomes increasingly critical." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

"Training is the process of teaching a model to recognise patterns and relationships in data and adjust over time to improve accuracy. During this phase, the model is fed large amounts of labelled data (data where the correct output is already known), and it tries to learn the associations between input data and its corresponding outputs. As the model processes the data, it repeatedly adjusts its internal parameters, like weights and biases, to reduce the difference between its predictions and the actual results (just like the human mind adjusts.) This iterative optimisation continues until the model reaches an acceptable level of accuracy." (Alan Watkins & G C Cooke, "Smarter than You Winning in Business with Superintelligent AI", 2026)

🏗️Software Engineering: Limitations (Just the Quotes)

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." (Edsger W Dijkstra, "The Humble Programmer", 1972) 

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

"Throughout the software life cycle, there are many decision situations involving limited resources in which software engineering economics techniques provide useful assistance.(Barry Boehm, "Software Engineering Economics", 1984)

"Second law: The complexity barrier. Software complexity" (and therefore that of bugs) grows to the limits of our ability to manage that complexity." (Boris Beizer, "Software Testing Techniques", 1990)

"The complexity barrier. Software complexity" (and therefore that of bugs) grows to the limits of our ability to manage that complexity." (Boris Beizer, "Software Testing Techniques", 1990)

"Scenarios are an especially cheap kind of prototype. [...] Scenarios are the ultimate reduction of both the level of functionality and of the number of features: They can only simulate the user interface as long as a test user follows a previously planned path. [...] Scenarios are the ultimate minimalist prototype in that they describe a single interaction session without any flexibility for the user. As such, they combine the limitations of both horizontal prototypes" (users cannot interact with real data) and vertical prototypes" (users cannot move freely through the system)." (Jakob Nielsen, "Usability Engineering", 1993)

"But code as a design document does have its limits. It can overwhelm the reader with detail. Although its behavior is unambiguous, that doesn't mean it is obvious. And the meaning behind a behavior can be hard to convey. [...] A document shouldn't try to do what the code already does well. The code already supplies the detail. It is an exact specification of program behavior. Other documents need to illuminate meaning, to give insight into large-scale structures, and to focus attention on core elements. Documents can clarify design intent when the programming language does not support a straightforward implementation of a concept. Written documents should complement the code and the talking." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

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

"Prototypes should command only as much time, effort, and investment as is necessary to generate useful feedback and drive an idea forward. The greater the complexity and expense, the more 'finished' it is likely to seem and the less likely its creators will be to profit from constructive feedback - or even to listen to it. The goal of prototyping is not to create a working model. It is to give form to an idea to learn about its strengths and weaknesses and to identify new directions for the next generation of more detailed, more refined prototypes. A prototype's scope should be limited. The purpose of early prototypes might be to understand whether an idea has functional value." (Tim Brown, "Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation", 2009)

"Programming is a science dressed up as art, because most of us don   t understand the physics of software and it   s rarely, if ever, taught. The physics of software is not algorithms, data structures, languages, and abstractions. These are just tools we make, use, and throw away. The real physics of software is the physics of people. Specifically, it   s about our limitations when it comes to complexity and our desire to work together to solve large problems in pieces. This is the science of programming: make building blocks that people can understand and use easily, and people will work together to solve the very largest problems." (Pieter Hintjens, "ZeroMQ: Messaging for Many Applications", 2012)

"One of the limitations of data management solutions today is how we have attempted to manage its unwieldy complexity, how we have decomposed an ever-growing monolithic data platform and team to smaller partitions. We have chosen the path of least resistance, a technical partitioning." (Zhamak Dehghani, "Data Mesh: Delivering Data-Driven Value at Scale", 2021)

🏗️Software Engineering: Optimization (Just the Quotes)

"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming." (Donald E Knuth, "Computer Programming as an Art", 1968)

"Heuristic methods may aim at local optimization rather than at global optimization, that is, the algorithm optimizes the solution stepwise, finding the best solution at each small step of the solution process and 'hoping' that the global solution, which comprises the local ones, would be satisfactory." (Nikola K Kasabov, "Foundations of Neural Networks, Fuzzy Systems, and Knowledge Engineering", 1996)

"The whole idea of a system is to optimize - not maximize - the fit of its elements in order to maximize the whole. If we merely maximize the elements of systems, we end up suboptimizing the whole [...]" (Stephen G Haines, "The Managers Pocket Guide to Systems Thinking & Learning", 1998)

 "All feats of engineering, whether stone dwellings or space stations, require a particular sequence of events. First, the engineer must understand the needs and wants of the society or subgroup of society that is to be served. Second, the engineer must formulate concepts of potential designs that might serve the designated needs and wants. Third, the engineer must analyze the concepts to determine their functionality. Fourth, the engineer must optimize selected candidate designs and choose a single preferred design. And fifth, the engineer must design a production system to realize the selected design." (George A Hazelrigg, "Laws and Models: An Introduction", 2000)

"An optimization is said to be unsafe if it may lead to incorrect code in certain programs. It is said to be speculative if it usually improves performance, but may degrade it in certain cases. A compiler is said to be conservative if it applies optimizations only when it can guarantee that they will be both safe and effective. By contrast, an optimistic compiler may make liberal use of speculative optimizations. It may also pursue unsafe optimizations by generating two versions of the code, with a dynamic check that chooses between them based on information not available at compile time. Examples of speculative optimization include nonbinding prefetches, which try to bring data into the cache before they are needed, and trace scheduling, which rearranges code in hopes of improving the performance of the processor pipeline and the instruction cache." (Michael L Scott, "Programming Language Pragmatics" 3rd. Ed., 2009)

"Code improvement is often referred to as optimization, though it seldom makes anything optimal in any absolute sense. It is an optional phase of compilation whose goal is to transform a program into a new version that computes the same result more efficiently - more quickly or using less memory, or both." (Michael L Scott, "Programming Language Pragmatics" 3rd. Ed., 2009)

"An important thing to take away [...] is the approach we took to every optimization: profile the code to get a sense of what is going on, come up with a possible solution to fix slow parts, then profile to make sure the fix actually worked. Although this sounds straightforward, things can get complicated quickly [...]" (Micha Gorelick & Ian Ozsvald, "High Performance Python", 2014)

"Sometimes it’s good to be lazy. By profiling first, you can quickly identify the bottlenecks that need to be solved, and then you can solve just enough of these to achieve the performance you need. If you avoid profiling and jump to optimization, then it is quite likely that you’ll do more work in the long run. Always be driven by the results of profiling." (Micha Gorelick & Ian Ozsvald, "High Performance Python", 2014)

"[…] building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. However, it’s also important to choose the right tool for the job, and different technologies each have their own strengths and weaknesses." (Martin Kleppmann, "Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems", 2015)

"Optimization is more than finding the best simulation results. It is itself a complex and evolving field that, subject to certain information constraints, allows data scientists, statisticians, engineers, and traders alike to perform reality checks on modeling results." (Chris Conlan, "Automated Trading with R: Quantitative Research and Platform Development", 2016)

"Engineering managers have a responsibility to optimize their teams. They improve engineering workflows and reduce dependencies and repetitive tasks. Self-sustaining teams minimize dependencies that hinder them in their efforts to achieve their objectives. Scalable teams minimize software delivery steps and eliminate bottlenecks. The mechanisms to achieve this may include the use of tools, conventions, documentation, processes, or abstract things such as values and principles. Any action that produces a tangible improvement in the speed, reliability, or robustness of your team’s work is worth your consideration." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"The best performance improvement is the transition from the nonworking state to the working state." (John Ousterhout  [attributed]) 

🏗️Software Engineering: Versioning (Just the Quotes)

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

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

"When the main design gets changed (as it will), you now have to think about where this design also exists. If you’re in this mode, you are either guaranteeing extra work to keep things in synch or you have a huge versioning problem where it is unclear which version to trust. The former will add time and costs. The latter can introduce errors and affect quality!" (F Alan Goodman, "Defining and Deploying Software Processes", 2006)

"If your code needs comments, consider refactoring it so it doesn’t. Lengthy comments can clutter screen space and might even be hidden automatically by your IDE. If you need to explain a change, do so in the version control system check-in message and not in the code." (Peter Sommerlad, [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010])

"Releasing software should be easy. It should be easy because you have tested every single part of the release process hundreds of times before. It should be as simple as pressing a button. The repeatability and reliability derive from two principles: automate almost everything, and keep everything you need to build, deploy, test, and release your application in version control." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"The deployment pipeline has its foundations in the process of continuous integration and is in essence the principle of continuous integration taken to its logical conclusion. The aim of the deployment pipeline is threefold. First, it makes every part of the process of building, deploying, testing, and releasing software visible to everybody involved, aiding collaboration. Second, it improves feedback so that problems are identified, and so resolved, as early in the process as possible. Finally, it enables teams to deploy and release any version of their software to any environment at will through a fully automated process." (David Farley & Jez Humble, "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation", 2010)

"Many smaller Scrum projects succeed with informal requirements mechanisms such as direct discussion between the Product Owner and Team, but as project complexity and criticality grows, more depth and richness of requirements expression and requirements versioning will likely be required. For example, documentation of interfaces that affect multiple teams becomes critical. Changes to interfaces or new features that cross team boundaries may have a significant impact on the project. These requirements should be elaborated on a just-in-time basis, meaning at, or just prior to the Sprint that implements the new functionality. To address this problem, teams may want centralized support for richer forms of requirements expression, their compilation for review and automated change notification." (Ken Schwaber & Jeff Sutherland, "Software in 30 days: How Agile managers beat the odds, delight their customers, and leave competitors in the dust", 2012)

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

"When people use different tools for similar activities" (e.g., version control, work tracking, documentation), they tend to form groups" (camps) around tool usage boundaries. [...] The more we are invested in certain tools, the greater the likelihood of deriving a part of our identity from the tool and its ecosystem." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Automated data orchestration is a key DataOps principle. An example of orchestration can take ETL jobs and a Python script to ingest and transform data based on a specific sequence from different source systems. It can handle the versioning of data to avoid breaking existing data consumption pipelines already in place." (Sonia Mezzetta, "Principles of Data Fabric: Become a data-driven organization by implementing Data Fabric solutions efficiently", 2023)

"Data products should remain stable and be decoupled from the operational/transactional applications. This requires a mechanism for detecting schema drift, and avoiding disruptive changes. It also requires versioning and, in some cases, independent pipelines to run in parallel, giving your data consumers time to migrate from one version to another." (Piethein Strengholt, "Data Management at Scale: Modern Data Architecture with Data Mesh and Data Fabric" 2nd Ed., 2023)

"When performing experiments, the first step is to determine what compute infrastructure and environment you need.16 A general best practice is to start fresh, using a clean development environment. Keep track of everything you do in each experiment, versioning and capturing all your inputs and outputs to ensure reproducibility. Pay close attention to all data engineering activities. Some of these may be generic steps and will also apply for other use cases. Finally, you’ll need to determine the implementation integration pattern to use for your project in the production environment." (Piethein Strengholt, "Data Management at Scale: Modern Data Architecture with Data Mesh and Data Fabric" 2nd Ed., 2023)

"Configuration is coding in a poorly designed programming language without tests, version control, or documentation." (Gregor Hohpe)

"God could create the world in six days because he didn't have to make it compatible with the previous version." (programmer folklore [attributed to Donald Knuth, Mark Twain])

"It is not usually until you’ve built and used a version of the program that you understand the issues well enough to get the design right." (Rob Pike)

"The third version is the first version that doesn't suck." (Mike Simpson)

🏗️Software Engineering: Classes (Just the Quotes)

"A subsystem is a set of classes (and possibly other subsystems) collaborating to fulfill a set of responsibilities. Although subsystems do not exist as the software executes, they are useful conceptual entities." (Rebecca Wirfs-Brock, "Object-oriented Design: A. responsibility-driven approach", 1989)

"The data-driven approach to object-oriented design focuses on the structure of the data in a system. This results in the incorporation of structural information in the definitions of classes. Doing so violates encapsulation. The responsibility-driven approach emphasizes the encapsulation of both the structure and behavior of objects. By focusing on the contractual responsibilities of a class, the designer is able to postpone implementation considerations until the implementation phase. While responsibility-driven design is not the only technique addressing this problem, most other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits." (Rebecca Wirfs-Brock, "Object-oriented design: a responsibility-driven approach", 1989)

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

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

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

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

"Object-oriented methods tend to focus on the lowest-level building block: the class and its objects." (Peter Coad, "Object-oriented patterns", 1992)

"If you're passing a parameter among several routines, that might indicate a need to factor those routines into a class that share the parameter as object data. Streamlining parameter passing isn't a goal, per se, but passing lots of data around suggests that a different class organization might work better." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"[...] inheritance is a powerful tool for reducing complexity because a programmer can focus on the generic attributes of an object without worrying about the details. If a programmer must be constantly thinking about semantic differences in subclass implementations, then inheritance is increasing complexity rather than reducing it." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Inheritance is the idea that one class is a specialization of another class. The purpose of inheritance is to create simpler code by defining a base class that specifies common elements of two or more derived classes. The common elements can be routine interfaces, implementations, data members, or data types. Inheritance helps avoid the need to repeat code and data in multiple locations by centralizing it within a base class. When you decide to use inheritance, you have to make several decisions: For each member routine, will the routine be visible to derived classes? Will it have a default implementation? Will the default implementation be overridable? For each data member (including variables, named constants, enumerations, and so on), will the data member be visible to derived classes?" (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Modularity's goal is to make each routine or class like a 'black box': You know what goes in, and you know what comes out, but you don't know what happens inside." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Watch for coupling that's too tight. 'Coupling' refers to how tight the connection is between two classes. In general, the looser the connection, the better. Several general guidelines flow from this concept: Minimize accessibility of classes and members. Avoid friend classes, because they're tightly coupled. Make data private rather than protected in a base class to make derived classes less tightly coupled to the base class. Avoid exposing member data in a class's public interface. Be wary of semantic violations of encapsulation. Observe the 'Law of Demeter' [...]. Coupling goes hand in glove with abstraction and encapsulation. Tight coupling occurs when an abstraction is leaky, or when encapsulation is broken." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

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

"An object-oriented application is a set of interacting objects. Each object is an implementation of one or more roles. A role supports a set of related (cohesive) responsibilities. A responsibility is an obligation to perform a task or know certain information. And objects don't work in isolation, they collaborate with others in a community to perform the overall responsibilities of the application. So a conceptual view, at least to start, is a distillation of the key object roles and their responsibilities (stated at a fairly high level). More than likely (unless you form classification hierarchies and use inheritance and composition techniques) many candidates you initially model will map directly to a single class in some inheritance hierarchy. But I like to open up possibilities by think first of roles and responsibilities, and then as a second step towards a specification-level view, mapping these candidates to classes and interfaces." (Rebecca Wirfs-Brock, [interview] 2003)

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

"An abstraction is not a module, or an interface, class, or method; it is a structure, pure and simple - an idea reduced to its essential form. Since the same idea can be reduced to different forms, abstractions are always, in a sense, inventions, even if the ideas they reduce existed before in the world outside the software. The best abstractions, however, capture their underlying ideas so naturally and convincingly that they seem more like discoveries." (Daniel Jackson, "Software Abstractions", 2006)

"Clean code is focused. Each function, each class, each module exposes a single-minded attitude that remains entirely undistracted, and unpolluted, by the surrounding details."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

🏗️Software Engineering: Modularity (Just the Quotes)

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

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

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

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

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

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

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

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

"Wherever there is modularity there is the potential for misunderstanding: Hiding information implies a need to check communication." (Alan J Perlis, "Epigrams on Programming", 1982)

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

"Extra features were once considered desirable. We now recognize that 'free' features are rarely free. Any increase in generality that does not contribute to reliability, modularity, maintainability, and robustness should be suspected." (Boris Beizer, "Software Testing Techniques", 1990)

"Modularity's goal is to make each routine or class like a 'black box': You know what goes in, and you know what comes out, but you don't know what happens inside." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"The concept of modularity is related to information hiding, encapsulation, and other design heuristics. But sometimes thinking about how to assemble a system from a set of black boxes provides insights that information hiding and encapsulation don't, so the concept is worth having in your back pocket." (Steve C McConnell," Code Complete: A Practical Handbook of Software Construction", 1993)

"Modularity, an approach that separates a large system into simpler parts that are individually designed and operated, incorrectly assumes that complex system behavior can essentially be reduced to the sum of its parts. A planned decomposition of a system into modules works well for systems that are not too complex. […] However, as systems become more complex, this approach forces engineers to devote increasing attention to designing the interfaces between parts, eventually causing the process to break down."  (Yaneer Bar-Yam, "Making Things Work: Solving Complex Problems in a Complex World", 2004)

"Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Design is the bridging activity between gathering and implementation of software requirements that satisfies the required needs. […] The fundamental goal of design is to reduce the number of dependencies between modules, thus reducing the complexity of the system. This is also known as coupling; lesser the coupling the better is the design. On the other hand, higher the binding between elements within a module (known as cohesion) the better is the design." (Vasudeva Varma, "Software Architecture: A Case Based Approach", 2009)

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

🖍️Hayden Van Der Post - Collected Quotes

"A critical aspect of neural networks is their ability to learn from data. This learning occurs during the training phase, where the network is exposed to vast datasets, allowing it to adjust its internal parameters - the weights and biases associated with each neuron. The goal of this adjustment is to minimize the difference between the network's predictions and the actual outcomes, a process known as optimization. Through techniques such as gradient descent and backpropagation, neural networks iteratively refine their parameters, enhancing their ability to make accurate predictions or decisions based on new input."(Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"Beyond the choice of model, the accuracy of neural network predictions in trading significantly depends on the quality and relevance of the data fed into them. This underscores the importance of meticulous data preparation, encompassing cleaning, normalization, and feature engineering. By ensuring that the input data is reflective of the market's complexities, traders can fine-tune their neural networks to produce more accurate and actionable predictions." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"Deep learning algorithms are exceptionally adept at identifying anomalies within large datasets, making them an indispensable tool for detecting fraudulent transactions and financial irregularities. By learning from historical transaction data, these models can pinpoint patterns and behaviors indicative of fraudulent activities with remarkable accuracy. This ability not only aids in safeguarding assets but also ensures compliance with increasingly stringent regulatory standards aimed at preventing financial fraud and misconduct." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"Deep learning is an advanced subset of machine learning, distinguished by its ability to process data through layers of neural networks, each layer abstracting information from the one preceding it. This hierarchical approach enables the model to handle complex, high-dimensional data, learning features and patterns at multiple levels of abstraction. [...] Traditional neural networks, with their shallower architectures, often struggle with the nuances of financial data, limited by their capacity to extrapolate and interpret intricate patterns. Deep learning, however, with its deeper, more sophisticated networks, can navigate these complexities, offering nuanced insights into market dynamics." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"Feature selection is the first critical step in model optimization. It's the art of identifying which features in your dataset contribute most significantly to the outcome you're trying to predict. This not only helps in enhancing the model's accuracy but also in reducing computational complexity, leading to more efficient models. [...] While feature selection is about cherry-picking the most useful features, feature engineering is about creating new features that increase the predictive strength of the model. This is where creativity and domain knowledge come into play, especially in financial data, where market sentiment, economic indicators, and other external factors can influence market movements." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"Genetic programming represents a frontier in feature engineering, allowing for the automated creation of new features through the application of evolutionary algorithms. By combining existing features in non-linear and complex ways, genetic programming can uncover hidden relationships in the data that were not apparent through manual exploration. This technique, while computationally intensive, holds the promise of discovering novel predictors that can enhance the performance of trading algorithms." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"Neural networks are structured into layers, each comprising a collection of neurons. The arrangement begins with an input layer, which receives the raw data. This is followed by one or more hidden layers, where the actual processing happens through a complex web of interconnected neurons. The journey through the layers culminates in an output layer, where the network delivers its final decision or prediction. The hidden layers are the cradle of the network’s learning capability, enabling it to detect patterns, make associations, and refine its predictions through repeated exposure to data." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"Predictive analytics, involves the use of data, statistical algorithms, and machine learning techniques to identify the likelihood of future outcomes based on historical data. Neural networks, with their remarkable ability to learn and model complex patterns, have become the backbone of modern forecasting methods. Their application ranges from predicting consumer behavior in retail to forecasting the stock market trends, from anticipating weather patterns to foreseeing potential healthcare outbreaks." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"The beauty of neural networks lies in their ability to learn and improve. Through a process known as 'training', a neural network is fed large amounts of data along with feedback on its performance. This feedback guides the network in adjusting its internal parameters, known as weights, to minimize errors in its predictions. This iterative process of learning from mistakes closely mirrors the cognitive and learning processes of the human brain, making neural networks particularly adept at tasks that involve pattern recognition, such as image and speech recognition [...]" (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"The essence of backpropagation is captured in the gradient descent algorithm, which seeks to minimize the error by iteratively adjusting the weights in the direction that most steeply decreases the error function. This rigorous process requires a meticulous balance; too large a weight adjustment can lead to erratic learning, while too small an adjustment can trap the network in local minima. In algorithmic trading, the capacity to learn from past predictions and refine strategies accordingly is invaluable, allowing for the continual optimization of trading algorithms in alignment with market dynamics." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"The power of neural networks lies in their flexibility and adaptability. They are not confined to a single type of problem or dataset but can be tailored to a wide range of applications, from voice recognition and image classification to forecasting financial market movements. This versatility stems from the network's ability to capture and model complex, non-linear relationships within the data it is trained on, making it a potent tool in the arsenal of data scientists and algorithmic traders alike." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"Weights and biases are pivotal in shaping the neural network's decision-making process. Weights determine the strength of the connection between two neurons, influencing how much of the input signal is passed forward. Biases, added to the weighted sum before the activation function, allow neurons to adjust their output independently of their input, providing an additional degree of freedom. The process of learning in a neural network involves adjusting these weights and biases based on the error between the network's predictions and the actual data, typically using an algorithm like gradient descent." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

"While forward propagation provides the prediction, backpropagation is the mechanism through which a neural network learns from its errors and enhances its accuracy. Backpropagation, a form of reverse engineering of the forward propagation process, involves calculating the error between the predicted output and the actual output, and then distributing this error back through the network. This distribution occurs layer by layer, in reverse order from output to input, adjusting the weights of the connections based on the magnitude of the error." (Hayden Van Der Post, "Neural Network: Mastering the Art of Algorithmic Trading", 2024)

🏗️Software Engineering: Domains (Just the Quotes)

"[Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light." (Edward Yourdon, "Object-Oriented Design", 1991) 

"To us, analysis is the study of a problem domain, leading to a specification of externally observable behavior; a complete, consistent, and feasible statement of what is needed; a coverage of both functional and quantified operational characteristics (e. g. reliability, availability, performance)." (Edward Yourdon, Object-oriented design, 1991)

"While a small domain (consisting of fifty or fewer objects) can generally be analyzed as a unit, large domains must be partitioned to make the analysis a manageable task. To make such a partitioning, we take advantage of the fact that objects on an information model tend to fall into clusters: groups of objects that are interconnected with one another by many relationships. By contrast, relatively few relationships connect objects in different clusters. When partitioning a domain, we divide the information model so that the clusters remain intact. [...] Each section of the information model then becomes a separate subsystem. Note that when the information model is partitioned into subsystems, each object is assigned to exactly one subsystem." (Stephen J Mellor et al, "Object Lifecycles: Modeling the World in States", 1992)

"As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system - the software architecture - presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms." (David Garlan & Mary Shaw, "An introduction to software architecture", Advances in software engineering and knowledge engineering Vol 1, 1993)

"Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Nor are they complex, domain-specific designs for an entire application or subsystem. The design patterns [...] are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context." (Erich Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

"Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven DESIGN." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect. At the same time, complex mappings between models and design functions are difficult to understand and, in practice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"The technical model that drives the software development process must be strictly pared down to the necessary minimum to fulfill its functions. An explanatory model can include aspects of the domain that provide context that clarifies the more narrowly scoped model. Explanatory models offer the freedom to create much more communicative styles tailored to a particular topic. Visual metaphors used by the domain experts in a field often present clearer explanations, educating developers and harmonizing experts. Explanatory models also present the domain in a way that is simply different, and multiple, diverse explanations help people learn." (Eric Evans, "Domain-Driven Design: Tackling complexity in the heart of software", 2003)

"Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns."  (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Enterprise architecture [is] a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise's organisational structure, business processes, information systems, and infrastructure. […] The most important characteristic of an enterprise architecture is that it provides a holistic view of the enterprise. […] To achieve this quality in enterprise architecture, bringing together information from formerly unrelated domains necessitates an approach that is understood by all those involved from those different domains." (Marc Lankhorst, "Enterprise Architecture at Work: Modelling, Communication and Analysis", 2009)

"Making domain concepts explicit in your code means other programmers can gather the intent of the code much more easily than by trying to retrofit an algorithm into what they understand about a domain. It also means that when the domain model evolves - which it will, as your understanding of the domain grows - you are in a good position to evolve the code. Coupled with good encapsulation, the chances are good that the rule will exist in only one place, and that you can change it without any of the dependent code being any the wiser." (Dan North [in Kevlin Henney’s "97 Things Every Programmer Should Know", 2010]) 

"Trying to determine the cognitive load of software using simple measures such as lines of code, number of modules, classes, or methods is misguided. […] When measuring cognitive load, what we really care about is the domain complexity - how complex is the problem that we’re trying to solve with software? A domain is a more largely applicable concept than software size." (Matthew Skelton, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Knowledge graphs use an organizing principle so that a user (or a computer system) can reason about the underlying data. The organizing principle gives us an additional layer of organizing data (metadata) that adds connected context to support reasoning and knowledge discovery. […] Importantly, some processing can be done without knowledge of the domain, just by leveraging the features of the property graph model (the organizing principle)." (Jesús Barrasa et al, "Knowledge Graphs: Data in Context for Responsive Businesses", 2021)

"Domain-driven design is an approach to design where we aim to capture the core behaviors of our code in essence as simulations of the problem domain. The design of our system aims to accurately model the problem." (David Farley, "Modern Software Engineering: Doing what works to build better software faster", 2022)

🏗️Software Engineering: Success (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)

"The ideas need not be complex. Most ideas that are successful are ludicrously simple. Successful ideas generally have the appearance of simplicity because they seem inevitable." (Sol LeWitt, "Paragraphs on Conceptual Art", 1967)

"How do we convince people that in programming simplicity and clarity - in short: what mathematicians call 'elegance' - are not a dispensable luxury, but a crucial matter that decides between success and failure?" (Edsger W Dijkstra, "'Why is software so expensive?' An explanation to the hardware designer", 1982)

"No matter how vigorously a 'science' of design may be pushed, the successful design of real things in a contingent world will always be based more on art than on science. Unquantifiable judgments and choices are the elements that determine the way a design comes together. Engineering design is simply that kind of process. It always has been; it always will be. (Eugene S Ferguson , "Engineering and the Mind’s Eye", 1992)

"Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent. Put simply, design patterns help a designer get a design 'right' faster." (Erich Gamma et al, "Design Patterns: Elements of Reusable Object-Oriented Software", 1994)

"Our experience with designing and analyzing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and in its ultimate success or failure. Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products). These requirements dictate the system's performance, availability, security, compatibility with other systems, and the ability to accommodate change over its lifetime. The desire to satisfy these goals with software that has the requisite properties influences the design choices made by a software architect." (Len Bass et al, "Software Architecture in Practice", 1998)

"Successful software development is a team effort - not just the development team, but the larger team consisting of customer, management and developers. [...] Every software project needs to deliver business value. To be successful, the team needs to build the right things, in the right order, and to be sure that what they build actually works." (Ron Jeffries, "Extreme Programming Installed", 2001)

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

"Computation at its root consists of a data structure (for input, output, and perhaps something being stored in between) and some process. One cannot talk about the process without describing the data structure. More importantly, different data structures enable certain computations to be done easily, whereas other data structures support other computations. Thus, the choice of data structure (representation) helps explain why a problem-solver does or does not successfully engage in a given process (cognition/behavior) or perhaps why a process takes as long or as short as it does." (Christian D Schunn et al, "Complex Visual Data Analysis, Uncertainty, and Representation", 2007)

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

"Successful reproduction [of bugs] is all about control. If you control all the relevant variables, you will reproduce your problem. The trick, of course, is identifying which variables are relevant to the bug at hand, discovering what you need to set them to, and finding a way to do so." (Paul Butcher, "Debug It! Find, Repair, and Prevent Bugs in Your Code", 2009)

"Design patterns are high-level abstractions that document successful design solutions. They are fundamental to design reuse in object-oriented development." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"Software systems do not exist in isolation. They are used in a social and organizational context and software system requirements may be derived or constrained by that context. Satisfying these social and organizational requirements is often critical for the success of the system. One reason why many software systems are delivered but never used is that their requirements do not take proper account of how the social and organizational context affects the practical operation of the system." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

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