Change is inevitable in software, but most systems are not designed to absorb it safely. New requirements, new teams, and new constraints are often introduced into architectures that become increasingly brittle over time.
This talk explores what it really means to design systems that can be changed safely. Going beyond tests and CI/CD, we’ll focus on architectural decisions that reduce blast radius, make behavior observable, and keep change reversible. We’ll examine why “flexibility” often becomes a liability, how black-box dependencies undermine safe evolution, and why overengineering in the name of future-proofing frequently backfires.
Drawing from real-world experience with long-lived, mission-critical systems, the session highlights practical patterns and anti-patterns for evolving software under real constraints such as validation, organizational pressure, and team change. The focus is on principles that hold up over time, not specific tools or frameworks.

Key takeaways include:
– What “safe change” means in practice
– How to limit risk and failure impact
– How to avoid irreversible architectural decisions