Clean Architecture Quotes

“The only way to go fast, is to go well.”
― Robert C. Martin, Clean Architecture

“Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure”
― Robert C. Martin, Clean Architecture

“I'm a programmer. I like programming. And the best way I've found to have a positive impact on code is to write it.”
― Robert C. Martin, Clean Architecture

“But there are different kinds of duplication. There is true duplication, in which every change to one instance necessitates the same change to every duplicate of that instance. Then there is false or accidental duplication. If two apparently duplicated sections of code evolve along different paths—if they change at different rates, and for different reasons—then they are not true duplicates. Return to them in a few years, and you’ll find that they are very different from each other.”
― Robert C. Martin, Clean Architecture

“Dijkstra once said, “Testing shows the presence, not the absence, of bugs.” In other words, a program can be proven incorrect by a test, but it cannot be proven correct. All that tests can do, after sufficient testing effort, is allow us to deem a program to be correct enough for our purposes.”
― Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

“All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables.”
― Robert C. Martin, Clean Architecture

“What if your company has made a commitment to a certain database, or a certain web server, or a certain framework? A good architect pretends that the decision has not been made, and shapes the system such that those decisions can still be deferred or changed for as long as possible.
A good architect maximizes the number of decisions not made.”
― Robert C. Martin, Clean Architecture

“Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.”
― Robert C. Martin, Clean Architecture

“Science does not work by proving statements true, but rather by proving statements false.”
― Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

“1. “First make it work.” You are out of business if it doesn’t work. 2. “Then make it right.” Refactor the code so that you and others can understand it and evolve it as needs change or are better understood. 3. “Then make it fast.” Refactor the code for “needed” performance.”
― Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

“Which kinds of decisions are premature? Decisions that have nothing to do with the business requirements—the use cases—of the system. These include decisions about frameworks, databases, web servers, utility libraries, dependency injection, and the like. A good system architecture is one in which decisions like these are rendered ancillary and deferrable. A good system architecture does not depend on those decisions. A good system architecture allows those decisions to be made at the latest possible moment, without significant impact.”
― Robert C. Martin, Clean Architecture

“Another problem with service-level decoupling is that it is expensive, both in development time and in system resources. Dealing with service boundaries where none are needed is a waste of effort, memory, and cycles. And, yes, I know that the last two are cheap—but the first is not.”
― Robert C. Martin, Clean Architecture

“The first value of software—behavior—is urgent but not always particularly important. The second value of software—architecture—is important but never particularly urgent.”
― Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

“This is the monstrosity in love, lady, that the will is infinite, and the execution confined; that the desire is boundless, and the act a slave to limit. —William Shakespeare”
― Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

“Just as the Hare was overconfident in its speed, so the developers are overconfident in their ability to remain productive.”
― Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

“The Dependency Inversion Principle (DIP) tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.”
― Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

“If you think good architecture is expensive, try bad architecture. —Brian Foote and Joseph Yoder”
― Robert C. Martin, Clean Architecture: A Craftsman's Guide to Software Structure and Design

“The fact that we did not have a database running for 18 months of development meant that, for 18 months, we did not have schema issues, query issues, database server issues, password issues, connection time issues, and all the other nasty issues that raise their ugly heads when you fire up a database. It also meant that all our tests ran fast, because there was no database to slow them down.”
― Robert C. Martin, Clean Architecture

“A good architecture will allow a system to be born as a monolith, deployed in a single file, but then to grow into a set of independently deployable units, and then all the way to independent services and/or micro-services.”
― Robert C. Martin, Clean Architecture

“As strange as it may seem, this decision is one of the options that a good architect leaves open. A system that is written as a monolith, and that depends on that monolithic structure, cannot easily be upgraded to multiple processes, multiple threads, or micro-services should the need arise. By comparison, an architecture that maintains the proper isolation of its components, and does not assume the means of communication between those components, will be much easier to transition through the spectrum of threads, processes, and services as the operational needs of the system change over time.”
― Robert C. Martin, Clean Architecture

“We wrote our software to know the detailed structure of the disk. It knew that the disk had 200 cylinders and 10 heads, and that each cylinder had several dozen sectors per head. It knew which cylinders held the Agents, Employers, and Members. All this was hard-wired into the code.

...

One day a more experienced programmer joined our ranks. When he saw what we had done, the blood drained from his face, and he stared aghast at us, as if we were aliens of some kind. Then he gently advised us to change our addressing scheme to use relative addresses.”
― Robert C. Martin, Clean Architecture

“What if the decisions have already been made by someone else? What if your company has made a commitment to a certain database, or a certain web server, or a certain framework? A good architect pretends that the decision has not been made, and shapes the system such that those decisions can still be deferred or changed for as long as possible.

A good architect maximizes the number of decisions not made.”
― Robert C. Martin, Clean Architecture

“If you can develop the high-level policy without committing to the details that surround it, you can delay and defer decisions about those details for a long time. And the longer you wait to make those decisions, the more information you have with which to make them properly.”
― Robert C. Martin, Clean Architecture

“The way you keep software soft is to leave as many options open as possible, for as long as possible. What are the options that we need to leave open? They are the details that don’t matter.”
― Robert C. Martin, Clean Architecture

“Software has two types of value: the value of its behavior and the value of its structure. The second of these is the greater of the two because it is this value that makes software soft.”
― Robert C. Martin, Clean Architecture

“The primary cost of maintenance is in spelunking and risk. Spelunking is the cost of digging through the existing software, trying to determine the best place and the best strategy to add a new feature or to repair a defect.”
― Robert C. Martin, Clean Architecture

“On the other hand, a system being developed by five different teams, each of which includes seven developers, cannot make progress unless the system is divided into well-defined components with reliably stable interfaces. If no other factors are considered, the architecture of that system will likely evolve into five components—one for each team.”
― Robert C. Martin, Clean Architecture

“The architecture of a software system is the shape given to that system by those who build it. The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other.

The purpose of that shape is to facilitate the development, deployment, operation, and maintenance of the software system contained within it.

The strategy behind that facilitation is to leave as many options open as possible, for as long as possible”
― Robert C. Martin, Clean Architecture

“Database schemas are notoriously volatile, extremely concrete, and highly depended on. This is one reason why the interface between OO applications and databases is so difficult to manage, and why schema updates are generally painful.”
― Robert C. Martin, Clean Architecture

“We’ve seen several of these oscillations just in the last decade or so since the web became prominent. At first we thought all the computer power would be in server farms, and the browsers would be stupid. Then we started putting applets in the browsers. But we didn’t like that, so we moved dynamic content back to the servers. But then we didn’t like that, so we invented Web 2.0 and moved lots of processing back into the browser with Ajax and JavaScript. We went so far as to create whole huge applications written to execute in the browsers. And now we’re all excited about pulling that JavaScript back into the server with Node.”
― Robert C. Martin, Clean Architecture