Structure & Behavior
Separate kinds of changes, separate tradeoffs
One of TF?’s observations is that changes to the structure of the system are fundamentally different from changes to the behavior of the system. Both might look similar—lines of code change, PRs are issued, reviews are reviewed—but one thing separates them and it’s not a little thing: reversibility.
If I change the behavior of a program and, say, change the values printed on a report sent to the IRS, it’s not easy to say, “Whoopsies. Never mind.” It’s hard to bring back prospects who got dumped out of a sales funnel. Behavior changes are hard to reverse.
If I change the structure of a program, though, it’s easy to reverse. Don’t like my extracted helper function? Inline it. Just like it never happened.
Treat reversible and irreversible decisions differently. Reversible decisions don’t need the same level of scrutiny, so pass them on through. That will leave more time & energy to double check those irreversible behavior changes.
(There are irreversible structure changes, or at least expensive-to-reverse structure changes, like extracting a service. Be more careful with those. Also, strive to make as few structure changes irreversible as you can.)
Hi Kent,
Could we say Behaviour is not reversible because Behaviours produce change? :)
Structure changes are developers' decisions. Behavior changes encapsulate business. We can always change/improve our design, but we cannot change the encapsulated business without customer change requests. So we want to be able to manage development-related decisions without effect encapsulated business. imo That is great support for refactoring and for design evolution.