Solving the Hard Problems
summary
Argues that engineering means iterative, scientific problem solving and that complex systems evolve through many small experiments, not big up-front designs; uses tests as fitness functions and continuous delivery pipelines to get fast feedback, reduce risk, and let teams take tiny steps; cites Amazon evolving from a PHP app and aviation’s iteration to near-zero fatalities as analogies; prescribes modular design, managed coupling, platforms as abstractions and architecture as a snapshot to keep systems changeable.
AI-written summary · about
chapters (17)
- 0:00Intro
- 3:17What is engineering really for?
- 8:53How to design & architect for ease of change?
- 12:29Iteration
- 15:48How to use the power-tools
- 18:03Small steps
- 21:08Prioritize testability
- 25:00Architecture as a snapshot
- 27:16Maintain the tourist map
- 28:13Prioritize ease of change
- 29:31Separate concerns
- 30:18Adapt to the current context
- 32:34Don't design ahead
- 33:56Platform as abstraction
- 35:45Manage coupling
- 37:25Conclusion
- 37:48Outro
related talks
01h 01mEngineering for Software - How to Amplify Creativity
45mTaking Back "Software Engineering"
35mEngineering for Software - How to Amplify Creativity
55mEngineering for Software
44mHow Not to Die Trying to Evolve Your Architecture
47m‘Engineering' for Software - How to Amplify Creativity
28mThe lean architect: Experimenting your way to better decisions
57mEngineering for Software