There's no difference between design and architecture, they are part of the same whole
All high and low level details form a complete structure together
Goal: Minimise the human resources required to build and maintain a required system
A design is good if the required effort to meet customer needs is low and remains low throughout the system's lifetime
A design is bad if the required effort to meet customer needs grows with each release
Case study
Figure 1.1 indicates an increase of staff over releases
Figure 1.2 shows despite the staff increase, the production size is barely increasing and eventually plateauing
Figure 1.3 highlights a high cost per line of code as a result of many staff and low production rates
Figure 1.4 indicates productivity is asymptotically approaching 0 over time
Figure 1.5 shows a dramatic increase in monthly payroll for each release. Highlights an underlying problem when so much is invested but barely any work gets done
What went wrong?
The old saying "Slow and steady wins the race" can be applied to software developers
The hare becomes complacent and decides to take a nap, eventually the slow tortoise catches up
Developers become overconfident in their productiveness, that the piling mess of badly written code eventually slows them down
Developers often overlook the importance of clean and well-designed code
A common mindset is to convince yourself to address this issue later, but that time almost never comes
Don't gaslight yourself
A solution is to complete work under test (TDD) which involves refactoring as you go
Figure 1.6 also shows its more efficient
Conclusion
Don't completely prioritise speed over the quality of software architecture (developers should raise the importance of architecture)
A system should work but also be adaptable when requirements change
A good software architecture should minimise effort and maximise productivity, implementing a new feature should not result exponential cost