1: Design & Architecture
❔ What is design? What is architecture?
There's been a lot of confusion over the years.
There is no difference between them.
"Architecture" is often used in the context of something at a high-level that is divorced from low-level details
"Design" often implies structures and decisions at a lower level.
🏛️ One Whole
Low-level details and the high-level structure are all part of the same whole.
They form a continuous fabric that defines the shape of the system.
Can't have one without the other.
A continuum of decisions from the highest to the lowest point.
🥅 The Goal?
Minimize the human resources required to build and maintain the system.
Measure of design quality is the effort required to meet the needs of the customer.
Effort that stays low throughout the lifetime of the system is good design.
Effort that increases with each new release is bad design.
👎 What goes wrong?
Analogy: The Tortoise vs. the Hare.
Developers work hard, but the part of their brain that knows good, clean, well-design code matters is asleep.
🤥 The Familiar Lie: We can clean it up later
We can clean it up later; we just have to get to market first.
Things never get cleaned up later because market pressures never abate.
The next feature must get done. The mess builds. Productivity declines.
🤥 The Bigger Lie: Clean code slows us down
Writing messy code makes them go fast in the short term and slows them down in the long term.
Fact: Making messes is always slower than staying clean.
Conclusion
The best option for the development organization: Recognize its own overconfidence and take the quality of software architecture seriously.
To take it seriously, you must know what it is.
What attributes of software architecture lead to a system that will minimize effort and maximize productivity?
Last updated