Kevlin Henney: Sustainable Software Architecture

Started off with defining the concepts in the title of the talk.
Sustainable - from the Bruntland Report -
Software is applied thought - Alan O'Callaghan
Architecture - Grady Booch - Design vs architecture is related to significance, measured by the cost of change

All systems have an architecture - intentional or accidental
Architect is a role rather than a job

Good architecture reduces the general significance of decisions
An architecture needs to be stable but this is not the same as static

Reflection on the word Agile.
It is something you are, not something you do (Adjective)

Agile architecture -
The question is not if your system has an architecture, but why and how.
Architecture influences your speed. Code will not magically fall into a good structure.

What properties are we looking for in our architecture:
- Solidity, robustness
- Usefulness
- Aesthetic quality - this is the (virtual) work environment for people (developers). It should be pleasant and intentional..

External integrity of the system (that it works according to expectations) is doing the right job
Conceptual integrity - this is a part of doing the job right

Complexities. Two types
- Essential (inherent in the problem domain)
- Accidental complexity involves the complexity found in the solution. Sometimes necessary but often it is noise and introduced by people. (Hello world in EJB..)

The concept of Technical Debt (by Martin Fowler) was discussed
Ok to take shortcuts for tactical reasons, but we always need to undo the shortcut at a later point in time (sooner rather than later). A clear NOTE should be made. If you have to many, you loose grip of them and the significance decreases.. you are on your way into trouble (unmanaged emails in inbox analogy). Use notes on a visual board.

Refactoring is a form of reactive design

We need Feedback to learn. Feedback in all levels (programmer testing, system testing, continuous integrations, architecture retrospectives, demos, code reviews +++)

Focus on collaboration rather than command
- Architects need to be actively involved in development
- Refactoring, testing, collaborative modeling and incremental work needs to be normal activities
- Immersive workshops with a technical focus (not replaced by stand-ups - this is a required addition forgotten by many teams)

Draws a parallel to building architects, they now often make it possible to start using a building long before it is finished (stages) this is certainly also possible with software.

Programming should focus on the continuous present tense (not the future)
Be careful to taking YAGNI too literally, it's a prediction