“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.)
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.
You have got me thinking, but I am still working through it. So you have given me a puzzle to solve.
I think that some behaviour change is for the "changers" because it reduces the costs in the discounted cashflow and somehow risk reduction/anticipation is really an option. It all seems to work but I will take a little while to clarify it all in my mind.
This is a great way to think about this and reflect on these two (very valuable) perspectives. I'm not sure what the perfect analogy or communication tool for this sort of thing is, but it's always something I struggle with with a new Product Owner / Customer. I might use this post, the next time
IMO quick first, do something as isolated as possible, dirty and cheap, no migrations, issolated data, sort of a POC with monitoring.
When you are sure the feature is there to stay, start working on a definitive solution, integrate it with your current domains if it makes sense and when done start a/b migrating features and data if required.
As for managing that, an idea would be to have rules like;
- POCs don't evolve, ever... seriously, they should end in a backlog POC to Feature re-implementation task, a new POC or the trash bin.
- Every n deployed POCs must have *a pair* assigned to it for monitoring full time.
- More than one pair needs to be involved in POC to Feature implementation, extra pair(s) can join from a low workload POC monitoring task.
- If any, at least one POC to Feature needs to be worked on at all times.
I believe it may work in keeping a balance between waiters and changers.
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.
You have got me thinking, but I am still working through it. So you have given me a puzzle to solve.
I think that some behaviour change is for the "changers" because it reduces the costs in the discounted cashflow and somehow risk reduction/anticipation is really an option. It all seems to work but I will take a little while to clarify it all in my mind.
This is a great way to think about this and reflect on these two (very valuable) perspectives. I'm not sure what the perfect analogy or communication tool for this sort of thing is, but it's always something I struggle with with a new Product Owner / Customer. I might use this post, the next time
IMO quick first, do something as isolated as possible, dirty and cheap, no migrations, issolated data, sort of a POC with monitoring.
When you are sure the feature is there to stay, start working on a definitive solution, integrate it with your current domains if it makes sense and when done start a/b migrating features and data if required.
As for managing that, an idea would be to have rules like;
- POCs don't evolve, ever... seriously, they should end in a backlog POC to Feature re-implementation task, a new POC or the trash bin.
- Every n deployed POCs must have *a pair* assigned to it for monitoring full time.
- More than one pair needs to be involved in POC to Feature implementation, extra pair(s) can join from a low workload POC monitoring task.
- If any, at least one POC to Feature needs to be worked on at all times.
I believe it may work in keeping a balance between waiters and changers.
Depends on whether by 'behavior' we strictly mean functional behavior, or we also bundle up any system behavior under the same rubric.