Fundamentals of Software Architecture Quotes

“Conway’s law: Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“…because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“A control freak architect might restrict the development team from downloading any useful open source or third-party libraries and instead insist that the teams write everything from scratch using the language API. Control freak architects might also place tight restrictions on naming conventions, class design, method length, and so on. Essentially, control freak architects steal the art of programming away from the developers, resulting in frustration and a lack of respect for the architect.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“Pay close attention to developer flow and be sure not to disrupt it by calling a meeting. Flow is a state of mind developers frequently get into where the brain gets 100% engaged in a particular problem, allowing full attention and maximum creativity. For example, a developer might be working on a particularly difficult algorithm or piece of code, and literally hours go by while it seems only minutes have passed. When calling a meeting, an you should always try to schedule meetings either first thing in the morning, right after lunch, or toward the end of the day, but not during the day when most developers experience flow state.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“Meetings that an architect imposes upon others (the architect calls the meeting) are also a necessity at times but should be kept to an absolute minimum. These are the kinds of meetings an architect has control over. An effective software architect will always ask whether the meeting they are calling is more important than the work they are pulling their team members away from. Many times an email is all that is required to communicate some important information, which saves everyone tons of wasted time.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“A control freak architect might restrict the development team from downloading any useful open source or third-party libraries and instead insist that the teams write everything from scratch using the language API. Control freak architects might also place tight restrictions on naming conventions, class design, method length, and so on.
Essentially, control freak architects steal the art of programming away from the developers, resulting in frustration and a lack of respect for the architect.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“All architectures become iterative because of unknown unknowns, Agile just recognizes this and does it sooner.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“This picture shows someone standing next to a broken-down car on the side of a small country road. In this scenario, how many people might stop and ask the motorist if everything is OK? Because it’s a small road in a small community, probably everyone who passes by. However, how many times have motorists been stuck on the side of a busy highway in the middle of a large city and had thousands of cars simply drive by without anyone stopping and asking if everything is OK? All the time. This is a good example of the diffusion of responsibility. As cities get busier and more crowded, people assume the motorist has already called or help is on the way due to the large number of people witnessing the event. However, in most of these cases help is not on the way, and the motorist is stuck with a dead or forgotten cell phone, unable to call for help. An effective architect not only helps guide the development team through the implementation of the architecture, but also ensures that the team is healthy, happy, and working together to achieve a common goal. Looking for these three warning signs and consequently helping to correct them helps to ensure an effective development team.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“Jonny Leroy of ThoughtWorks is the Inverse Conway Maneuver, which suggests evolving team and organizational structure together to promote the desired architecture.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“Domain concern Architecture characteristics Mergers and acquisitions Interoperability, scalability, adaptability, extensibility Time to market Agility, testability, deployability User satisfaction Performance, availability, fault tolerance, testability, deployability, agility, security Competitive advantage Agility, testability, deployability, scalability, availability, fault tolerance Time and budget Simplicity, feasibility”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“A common anti-pattern in architecture entails trying to design a generic architecture, one that supports all the architecture characteristics.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“The computer scientist Gerald Weinberg is famous for saying, “No matter what the problem is, it’s a people problem.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“Each service is meant to represent a domain or subdomain; in many ways, microservices is the physical embodiment of the logical concepts in domain-driven design.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“Orchestration-Driven Service-Oriented Architecture Architecture styles, like art movements, must be understood in the context of the era in which they evolved, and this architecture exemplifies this rule more than any other. The combination of external forces that often influence architecture decisions, combined with a logical but ultimately disastrous organizational philosophy, doomed this architecture to irrelevance. However, it provides a great example of how a particular organizational idea can make logical sense yet hinder most important parts of the development process.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach

“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle.”
― Mark Richards, Fundamentals of Software Architecture: An Engineering Approach