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.
Sounds to me like the same underlying idea as the P/PC balance from Steven Covey. I’ve always noticed an over emphasis on production at the expense of production capability.
Over the years when I have suggested increasing investment into production capability I’ve often run into a knee jerk (irrational, emotional) negative reaction.
It seems to me that failure on the side of too much investment in structure leads to embarrassing and painful sudden failure and too much investment in behavior changes leads to a slow and painful decline. As a result, people don’t have a violent reaction to the latter mistake and seem more likely to engage in it.
The latter mistake is just as catastrophic but it doesn’t bear the psychological intensity. It’s the disease of mediocrity that seeps in and becomes normal and is impossible to break out of.
The economics metaphor is very interesting for me on a few fronts. We all feel in our bones that we've been frustrated by the tough decision of making this choice: do we spend time to get the next feature out the door, or improve on the big thing we've already invested in. Which one will pay off and how much is essentially a bet against an uncertain future --a gamble and a risk (poker anyone?)
This choice depends heavily on (a) **context** e.g. startup vs established operation, (b) **future** value and risk, the gamble of whether a choice will pay off, and (c) **timing** e.g. how much time you have (to see it pay off) vs the opportunity costs.
Toil - let me call out the easy case for structural change. If we've written out a pattern a bunch of times (say three) and we recognize we're doing it again, it's time to make that pattern generic or modular. We stop and turn a series of steps into a function, or we turn a bunch of functionality into a library, etc. The risk is low and the reward is clear. In economics this is akin to "economies of scale" and like the industrial revolution, we take a process and turn it into a kind of mini-factory to do a thing well and repeatedly (specialization), for much profit later.
Velocity - re-structuring is often about tidying so that future work is faster and less effort. Economically I think this is something like a pre-pay plan or a debit card where you're paying up front, and the transaction is smoother and maybe even discounted later. Similarly, keeping our desk clean makes the next assignment easier. We could do it without cleaning first but then we're more likely to get distracted. Things just take longer and longer the more dirty our space is (including mental space). In finance, banks and payment systems also exist to reduce transactional overhead and increase velocity with a very clear cost structure.
The same is true in code. Usually we're already in the process of adding a new behavior when we find it's taking longer than it should. We make the current work a little bigger but clean up along the way to clear the path for that next code change. For that effort to be worthwhile, we have to feel that there are more changes we want in this area of the code --that there's some real future value.
Economically, this also looks a bit like "own the means of production" because if you're making a product, then stopping to build a factory just for the widgets you need in your product, you will save yourself money on those widgets long-term, but it's a big investment for no reward --temporarily. In software we're often faced with these economic choices when it comes to "build vs buy" decisions, but let's put that line of thought on the shelf for now.
Leverage in finance - it means borrowing to do something that you believe will be more profitable down the road. For example, taking money from VCs to build a company with the belief that you'll turn out huge profits for everyone later.
Selling Leverage - sometimes making a structural change is not about velocity, it's somewhat about options, but perhaps it's more about flexibility or leverage. The current thing can't support some of the new things we want. In software, imagine you've written a messaging system for SMS, but now you want to handle twitter and facebook messaging also. By splitting the current system into the generic messaging vs the specific SMS parts you can create a basis for the twitter and facebook features. Without that new structure, this new behavior or these "future features" would be about 3X more work to write.
I've probably already sold you on the idea, but there's a deeper and harder to see (or sell) point here: when the next messaging platform comes along it's now much easier the option is to add it too. You've leveraged your work to be resilient to an uncertain future. I think of this as architectural agility, but I'm not sure if there's an economic metaphor.
If I haven't convinced you yet, only the really astute or creative technical readers will see the other value here. If I have a messaging core system, with SMS, twitter, and facebook messaging on top there's other *collateral* or secondary benefit: You get a system where and an SMS user can send messages to their friends on facebook.
Leverage can be a huge multiplier. The dark side is accidentally over engineering to build things that people don't actually want or need, or taking more time than you can afford. It's especially dangerous for startups where your debt will come due sooner rather than later.
Startups - startups are a whole different context. They operate to fail repeatedly in the quest to learn which products or services are actually valuable to a market and customers. As such, they need to turn out behaviors cheaply, test them quantitatively and quickly, and repeat. Once they find a problem they can solve that customers value enough, they have a period of building that, and only that, in the MVP. The notion of investing in structural change is usually strictly forbidden, until the next pivot.
Time value of money - as a programmer most of what I write needs to be replaced in about 3 years (when it's handling 10X the current load). We have an architect in the family who designs structures that will be around for decades if not centuries. Contrasting this with startups, the economics in both these cases is about already knowing what's needed and why (the problem space) but providing a better implementation (the solution space). The architect's choice to make a structural change is high storm-term expense, but can also save a ton of future expense. It's a surprisely similar economic calculus.
What's funny about this is there's a small portion of what I've written that has been running in production for over 10 years, which is considered a really long time for the industry; and that's funny because that code is stuff I never would have predicted would last. One typically needs a wide portfolio to benefit from the occasional big hit.