Discover more from Software Design: Tidy First?
Behavior Change = Revenue Versus Structure Change = Option
“Wait, that can’t be right!”
One of the great things about writing a book is that by digging into a topic, even one you think you know, you discover nuances that had escaped you. Sometimes these nuances are a little disturbing. This is one such. (I’m writing about it to all of you because I’m still sorting out my thinking. Chapter(s) to follow.)
If you’ve been following Tidy First?, you have seen this diagram:
A central problem in software design is finding a balance between investment in structure & investment in behavior that maintains the relationship between waiters (W above, those with ideas but no way to directly implement those ideas) and changers (C, those who can implement). (It’s going to take all 3 books to cover this.)
For today, the salient point is that we change the behavior of the system or its structure (& I suggest never changing both at the same time), & these changes compete for resources.
A second point is that the economic value of a system is the sum of:
Its discounted cash flows as of today.
Options on creating future cash flows.
Here’s the point that struck me hard enough that I’m still absorbing it—every behavior change is a potential source of cash, either through higher revenue or lower costs. Behavior changes can also reduce optionality by making the next behavior change harder/riskier/more expensive. (Behavior changes can also increase optionality by making the next behavior change easier—hadn’t thought of that.)
Structure changes, on the other hand, always (should) increase optionality. Structure changes are never a direct source of revenue. Great, that calculation is now an independent service. We can’t charge for it, not unless we change the behavior of the system to open up an API.
I’ve always been puzzled why the balance between structure & behavior investment seems so hard to maintain. I’m also puzzled why the balance we see in the wild is so heavily tilted towards behavior changes when as I geek I think it should be more balanced.
If “behavior change = revenue” & “structure change = option”, then the struggle for balance makes more sense. It’s not about the personalities of Product versus Engineering. It’s not about short-sighted versus visionary thinking. The struggle is economic—do we make some money now or more money later? The answer is always “both”. We have to make some money now to survive. We want to make more money later. Fear versus greed.
No wonder it’s so hard to get time to refactor.