Designing software for change

The only constant in software is that requirements change. Teams that accept this design differently from teams that believe they can get it right the first time.

Accepting change means: boundaries between modules are more important than the modules themselves. A clean interface lets you rewrite a module without touching its consumers. This is the single highest-leverage investment you can make.

It means: prefer composition over inheritance. Prefer data over logic. A system where behaviour is determined by configuration (or data) is easier to change than one where behaviour is hardcoded in control flow.

It means: test behaviours, not implementations. Tests that assert on internal state break when you refactor. Tests that assert on observable outcomes survive rewrites.

The goal is not to predict what will change. It is to build a system where change does not cascade. Where you can replace one piece without rebuilding the whole.