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.)
It seems like "behavior change" as you use it here implies "has an effect" in the functional programming sense. "Interacts noticeably differently with the outside world".
I would love to see this understanding of "behavior" become more common; it would help us avoid many arguments that amount to violent agreement.
Hi Kent,
Could we say Behaviour is not reversible because Behaviours produce change? :)