Another strategy to reduce ergodicity is diversification. It's implicitly treated in Luca's book but not explicitly mentioned. How would that translate in software development? I think modularity in code structure and cross functionality in teams would be important aspects.
Rotating pairs is what springs to my mind. Everyone is exposed to all the activities in development, even if they spend half their time doing what they are (currently) good at.
Cross functionality definitely is a form of diversification. Other possibilities include (and I know that what I'm about to write only applies to some companies):
– asking more than one person or team to come up with a feature / solution / idea, and see which one develops or tests more promisingly
– diversifying target users / use cases / focus features, and see which one resonates the most with the market
"When you get a new idea, try over-apply it. That’s the only way you’ll find the boundaries of its application."
This throwaway comment deserves much more attention. There are many fads that come and go in software development. And an excellent way to test their value to your org or your project is to over-apply them and from that derive what benefits they bring and their limitations. IMHO this is the surest way of assessing the techhnology's value and drawbacks for *you*, rather than having experts/consultants tell you.
The overconfident, young developer in me would like to -think- I fit into the more ergodic side of things, but I honestly have to say that much of my work is probably non-ergodic. I think so because I asked myself, with respect to having skin in the game: Am I actually sitting in with other developers, sitting in with users? No. Much of the work at present is silo'd and detached from the result. I write tests, sure. I am even responsible for the system if it breaks (on-call). But I would argue that if I am detached from the users and the other players making the system, then I am probably working in a way that is more liable to hit that "Game Over" state.
So I suppose I ought to ask myself if I am able to do anything about that, and if I am, take notes of the least obstructive (to the wider community of the organization) way to put more of my own skin in the game.
"Damn it! That was 2 hours of work I just lost. I'll have to start over & miss dinner with my kids." "Sorry my dude. That was the bug I just introduced."
This is much clearer & emotionally impactful feedback than, "You JIRA queue in the category #bugs increased from 454 to 455 items."
I see what you mean: something breaks in prod, oncall feels the pain... and the person who introduced the bug will feel bad. I wonder if "sitting together" really means that the team is small enough that everyone knows everyone else as a person (as opposed to knowing a chat nickname from some remote location on a different continent).
However, you triggered me with "Programmers are on call for production support".
I completely get the positive intent of this idea, but have so often seen it abused by organizations that want to skimp on tech support, infrastructure planning, user training, etc. that seeing it without a LOT of qualification makes me see red.
Programmers definitely need to take professional responsibility for the resiliency of their apps, but for the world to be safe for programmers, they aren't the only ones who need more skin in the game!
I absolutely agree that skin-in-the-game needs to go further (and also that this is very difficult to achieve). Skin-in-the-game also means that the people who are on-call are also empowered to prioritize reducing the frequency & severity of incidents. The dysfunction I've seen is that a "Product" team insists on more features sooner, the "Engineering" team is exhausted by on-call, but "Engineering" isn't able to prioritize productionizing the system.
I also don't want to go back to the days when the only people wearing a pager were "Operations", whose incentive was to reduce changes to the system as much as possible. That was not skin-in-the-game either.
Agreed. What we both want, I think, is everyone involved to include and prioritize support, error handling and resiliency user stories as essential. The social mechanism to achieve that state of affairs needs careful consideration as well.
Another strategy to reduce ergodicity is diversification. It's implicitly treated in Luca's book but not explicitly mentioned. How would that translate in software development? I think modularity in code structure and cross functionality in teams would be important aspects.
Rotating pairs is what springs to my mind. Everyone is exposed to all the activities in development, even if they spend half their time doing what they are (currently) good at.
Cross functionality definitely is a form of diversification. Other possibilities include (and I know that what I'm about to write only applies to some companies):
– asking more than one person or team to come up with a feature / solution / idea, and see which one develops or tests more promisingly
– diversifying target users / use cases / focus features, and see which one resonates the most with the market
The term I've heard used for these strategies is Set-Based Development. From Donald Reinertson originally, but I think TPS was the original source.
The objection is, "Yes, but only 1/nth of that investment is worth it." Well, if you knew which N it was we wouldn't be having this conversation.
Very nice. Total common sense. When is the book being released.
End of October
"When you get a new idea, try over-apply it. That’s the only way you’ll find the boundaries of its application."
This throwaway comment deserves much more attention. There are many fads that come and go in software development. And an excellent way to test their value to your org or your project is to over-apply them and from that derive what benefits they bring and their limitations. IMHO this is the surest way of assessing the techhnology's value and drawbacks for *you*, rather than having experts/consultants tell you.
I'll hammer this point home in Thinkies.
The overconfident, young developer in me would like to -think- I fit into the more ergodic side of things, but I honestly have to say that much of my work is probably non-ergodic. I think so because I asked myself, with respect to having skin in the game: Am I actually sitting in with other developers, sitting in with users? No. Much of the work at present is silo'd and detached from the result. I write tests, sure. I am even responsible for the system if it breaks (on-call). But I would argue that if I am detached from the users and the other players making the system, then I am probably working in a way that is more liable to hit that "Game Over" state.
So I suppose I ought to ask myself if I am able to do anything about that, and if I am, take notes of the least obstructive (to the wider community of the organization) way to put more of my own skin in the game.
> Everyone sits together (or is on frequent video calls) so user problems are immediately experienced by those who caused the problems.
I don’t understand how sitting together leads to experiencing problems faster. Could you elaborate?
"Damn it! That was 2 hours of work I just lost. I'll have to start over & miss dinner with my kids." "Sorry my dude. That was the bug I just introduced."
This is much clearer & emotionally impactful feedback than, "You JIRA queue in the category #bugs increased from 454 to 455 items."
I see what you mean: something breaks in prod, oncall feels the pain... and the person who introduced the bug will feel bad. I wonder if "sitting together" really means that the team is small enough that everyone knows everyone else as a person (as opposed to knowing a chat nickname from some remote location on a different continent).
Yes and... as a leader you can encourage or discourage this kind of direct, human engagement.
Meta cognitive note is instructive. I agree. It's a good way to form life principles.
I’ll know after 5 minutes of conversation whether someone has this habit.
Hi Kent, great post, great concept!
However, you triggered me with "Programmers are on call for production support".
I completely get the positive intent of this idea, but have so often seen it abused by organizations that want to skimp on tech support, infrastructure planning, user training, etc. that seeing it without a LOT of qualification makes me see red.
Programmers definitely need to take professional responsibility for the resiliency of their apps, but for the world to be safe for programmers, they aren't the only ones who need more skin in the game!
I absolutely agree that skin-in-the-game needs to go further (and also that this is very difficult to achieve). Skin-in-the-game also means that the people who are on-call are also empowered to prioritize reducing the frequency & severity of incidents. The dysfunction I've seen is that a "Product" team insists on more features sooner, the "Engineering" team is exhausted by on-call, but "Engineering" isn't able to prioritize productionizing the system.
I also don't want to go back to the days when the only people wearing a pager were "Operations", whose incentive was to reduce changes to the system as much as possible. That was not skin-in-the-game either.
Agreed. What we both want, I think, is everyone involved to include and prioritize support, error handling and resiliency user stories as essential. The social mechanism to achieve that state of affairs needs careful consideration as well.
And throwing some sharp elbows, if experience is any guide. Setting boundaries is part of relationship building.
Nice song. The style is too "high" to gain popularity.
Surface scratched. "Not dying...I always get a lot of mileage out of that..."
Coincidence? Not. Great breakdown of the song I quoted. https://www.tiktok.com/t/ZT8FvAXRG/