"Architecture" is often used in the context of something at a high level, whereas "design" more often seems to imply structures and decisions at lower level. But this usage is nonsensical. In software design the low-level details and the high-level stucture are all part of the same whole, there is a continuum of decisions from the highest to the lowest levels.
The goal of software architecture is to minimize the human resouces required to build and maintain the required system.
The bigger lie: writing messy code makes developers go fast in the short term, just slows them down in the long term.
The fact is that making messes is always slower than staying lean, no matter which time scale you are using.
"The only way to go fast, is to go well."
With bad design effort grows with each new release.
Good software architecture minimizes effort and maximizes productivity.
Stakeholder's requirements change. It's a fact.
soft-ware: a way to easily change the behavior of machines.
So software must be easy to change. Architecture should facilitate changes.
Function or architecture?
-
If you give me a program that works perfectly but is impossible to change, then it won't work when the requirements change, and I won't be able to make it work. Therefore the program will become useless.
-
If you give me a program that dows not work but is easy to change, then I can make il work, and keep it working as requirements change. Therefore the program will remain continually useful.
Importance versus urgency.
"I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent."
Sofware:
- behavior -> urgent
- architecture -> important
Priority:
- Urgent and important
- Not urgent and important
- Urgent and not important
- Not urgent and not important
Important stuff is in the top two positions!
Common mistake: elevate items in position 3 to position 1.
Is the responsibility of the software development team to assert the importance of architecture over the urgency of features.
If the architecture comes last, then the system will become even more costly to develop, and eventually cheange will become practically impossible for part or alla of the system.
Paradigms are ways of programming, relatively unrelated to languages. A paradigm tells you which programming strucure to use, and when to user them.
- Structured programming: from 'goto' to 'if/then/else' and 'dowhile/until'. Structured programming imposes discipline on direct transfer of control.
- Object oriented programming: from function call stack (LIFO) to heap (dynamic allocation) - allow local variables declared by a function to exist after the function returned. Function becama acontructor for a class, the local variables became instance variables, and the nested functions became methods. Discovery of polymorphism through de disciplined use of funcion pointers. Object-oriented programming imposes discipline on indirect transfer of control.
- Functional programming: immutability - no assignment statement. "Functional programming imposses discipline upon assignment."
All of the paradigms removes capabilities from the programmer. Each take something away from us; 'goto' statements, function pointers and assignment.