8 Comments

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.

Expand full comment

Hi Kent,

Could we say Behaviour is not reversible because Behaviours produce change? :)

Expand full comment

It's change in the outside world. We have sent money. We have filed a tax return. We have launched a rocket. No undo.

Expand full comment

Got it! that's a good one. Thanks! And thanks for helping geeks feel safe in the world

Expand full comment

Change in the outside world.

Expand full comment

Totally agree. Thank you!

Expand full comment

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.

Expand full comment

Great insights Kent, thanks!

The phrase "...strive to make as few structure changes irreversible as you can" to me connects perfectly with many techniques we may use to keep structural changes easily reversible: refactoring (a series of small behavior-preserving code transformations) is the first one for me, and more generally speaking a "development by small increments" mindset.

Expand full comment