More on this book
Community
Kindle Notes & Highlights
Started reading
December 26, 2020
getting something to work—once—just isn’t that hard.
Getting software right is hard.
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
“The race is not to the swift, nor the battle to the strong.”
“We can clean it up later; we just have to get to market first!” Of course, things never do get cleaned up later, because market pressures never abate.
The bigger lie that developers buy into is the notion that writing messy code makes them go fast in the short term, and just slows them down in the long term.
making messes is always slower than staying clean,
The only way to go fast, is to go well.
the best option is for the development organization to recognize and avoid its own overconfidence and to start taking the quality of its software architecture seriously.
Every software system provides two different values to the stakeholders: behavior and structure. Software developers
are responsible for ensuring that both those values remain high.
Software was invented to be “soft.” It was intended to be a way to easily change the behavior of machines. If we’d wanted the behavior of machines to be hard to change, we would have called it hardware.
When the stakeholders change their minds about a feature, that change should be simple and easy to make. The difficulty in making such a change should be proportional only to the scope of the change, and not to the shape of the change.
I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.1
The mistake that business managers and developers often make is to elevate items in position 3 to position 1. In other words, they fail to separate those features that are urgent but not important from those features that truly are urgent
and important. This failure then leads to ignoring the important architecture of the system in favor of the unimportant features of the system.
it is the responsibility of the software development team to assert the importance of architecture over the urgency of features.
The development team has to struggle for what they believe to be best for the company,
Effective software development teams tackle that struggle head on. They unabashedly squabble with all the other stakeholders as equals.
Remember, as a software developer, you are a stakeholder. You have a stake in the software that
you need to safeguard. That’s part of your role, and part of your duty. And it’s a big p...
This highlight has been truncated due to consecutive passage length restrictions.
If architecture comes last, then the system will become ever more costly to develop, and eventually change will become practically impossible for part or all of the system.
In 1951, Grace Hopper invented A0, the first compiler. In fact, she coined the term compiler.
Paradigms are ways of programming, relatively unrelated to languages. A paradigm tells you which programming structures to use, and when to use them.
structured programming, which was discovered by Edsger Wybe Dijkstra in 1968.
Structured programming imposes discipline on direct transfer of control.
Object-oriented programming imposes discipline on indirect transfer of control.
Functional programming imposes discipline upon assignment.
Eventually
petered out.
moved ever rearward,
empirical
nature of scientific theories and laws: They are falsifiable but not provable.
bet
we can say that mathematics is the discipline of proving provable statements true. Science, in contrast, is the discipline of proving provable statements false.
“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.
implications
stunning.
ende...
This highlight has been truncated due to consecutive passage length restrictions.
software is like a science. We show correctness by failing to prove incorrectness, ...
This highlight has been truncated due to consecutive passage length restrictions.
unrestrained
falsifiable
we still consider
functional decomposition
to be one of our best ...
This highlight has been truncated due to consecutive passage length restrictions.
falsifiability.
Software architects strive to define modules, components, and services that are easily falsifiable (testable). To do so, they employ restrictive disciplines similar to structured programming,
a...
This highlight has been truncated due to consecutive passage length restrictions.
admixture
