Software Design: Tidy First?

Share this post
Structure & Behavior
tidyfirst.substack.com

Structure & Behavior

Separate kinds of changes, separate tradeoffs

Kent Beck
Feb 9, 2021
13
5
Share this post
Structure & Behavior
tidyfirst.substack.com

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.)

5
Share this post
Structure & Behavior
tidyfirst.substack.com
5 Comments

Create your profile

0 subscriptions will be displayed on your profile (edit)

Skip for now

Only paid subscribers can comment on this post

Already a paid subscriber? Sign in

Check your email

For your security, we need to re-authenticate you.

Click the link we sent to , or click here to sign in.

Filis Futsarov
Jun 24, 2021

Hi Kent,

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

Expand full comment
ReplyCollapse
2 replies by Kent Beck and others
Valentin Tudor Mocanu
Mar 24, 2021

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
ReplyCollapse
3 more comments…
TopNewCommunity

No posts

Ready for more?

© 2022 Kent Beck
Privacy ∙ Terms ∙ Collection notice
Publish on Substack Get the app
Substack is the home for great writing