I’m assuming you’ve heard of the Prisoners’ Dilemma. My summary: 2 people are arrested. If neither tattles they both go free. If one tattles & the other doesn’t, the tattler goes free & the other person goes to jail for a long time. If they both tattle, they both go to jail for a shorter sentence. (The payoffs vary in different versions of PD.)
One really easy way to overcome the prisoner's dilemma is to just coordinate.
Obviously in the dilemma, you aren't allowed to, but if bosses and employees can't come to such an understanding, the trust must be very low indeed. Don't know how you get anything done in an environment that low trust.
yes i agree. at the end it should be reduced to communication and feedback issues. two basis of healthy environment. but in real life i can feel the pain where communication is done in one way only (chain of command) and valuable true feedback is rare. if anyone has a solution to break that i'm happy to learn more.
"reduced to communication & feedback" -- in the presence of a power differential this is easier said than done. Or rather, easier for the relatively powerful person.
I've been thinking and it seems to add an unbalanced trust into the equation. I have to prove my trustworthiness every day as an employee and still will be hard to get it. on the other hand the one in power takes it as something already earned by just being in power.
The big difficulty is between the lead and senior programmers. They engage the most difficult questions together, but are in serious career contention. Leads have a very strong incentive to extract good ideas and seed bad ones to protect their position, and they have the default external authority.
The only enduring allocation of authority/responsibility I've seen is the code silo, with people and teams taking ownership. This flies in the face of almost every efficiency and coordination principle, but endures because, as you say, software is about relationships, and it's the only thing that reduces the impact of those relationships.
"If I change an API that you use, then I either migrate your usages myself or we do it together or I maintain backwards compatibility."
True, but this is only an issue if you're working in an architecture where significant changes are (a) common and (b) disruptive.
If my building changes the mains power supply (like voltage or connector type), we'd have a similar disruption, but fortunately that almost never happens. At some point, decades ago, everybody sat down and said "This proposal isn't perfect at anything, but it's good enough at everything, and we'd all be 1000 times better off if we used the same system, so this is what it is", and they wrote the NEC, and that's it. End of discussion. No clever installers saying "We could be 10% more efficient if we ran a cable through the sink".
In software, 99% of the APIs I use could be this reusable, if only people cared to look at existing standards. I fear that the situation is going to get as bad as the early days of electricity, and the government is going to have to step in and force everyone's hand, and it'll be worse than if people just cooperated on their own.
The human brain have something called 'Egotism', that we all have. Its about our thinking is inside us, and mostly about our self. Maybe you have noticed in a dialog when you talk about some experience you have, and the other person goes direct into his/hers experience, without listening first. Some definition is: the drive to maintain and enhance favorable views of oneself and generally features an inflated opinion of one's personal features and importance distinguished by a person's amplified vision of one's self and self-importance. With that in mind the software is most of the time made from the individual, and if more people working on the same feature, dissonance will occur. The trick is to be aware of this, and make the dissonance carry the feature forward.
And I'm excited to see what you recommend and how you analyze this problem!
Nevertheless, I think the software case is a pretty good analog of the general problem we have as a society of deciders off-loading externalities to people who didn't benefit from or make the decisions.
Two specific common cases:
1 - Between tech designers separated by time: the defection goes both ways. Designer today makes trade offs that hurt designer tomorrow. Designer tomorrow blindly throws designer before under the bus for all current problems.
2 - Between non-technical decision makers and technical designers: Designer says "this will take 6 weeks to do properly." Non-tech says "Don't worry about properly, we need it done by Tuesday." Tech delivers, but a few weeks later the solution blows up at an inconvenient time (due to the foreseeable deficiencies ), and non-tech blames tech. Even if culpability is acknowledged, the pain of fixing under time pressure (before AND after) falls on tech, the gain of delivering by Tuesday goes to non-tech.
If you have solutions for these, Nobel or not, I'll be really excited and impressed! I truly hope I'm just being too cynical!
One really easy way to overcome the prisoner's dilemma is to just coordinate.
Obviously in the dilemma, you aren't allowed to, but if bosses and employees can't come to such an understanding, the trust must be very low indeed. Don't know how you get anything done in an environment that low trust.
yes i agree. at the end it should be reduced to communication and feedback issues. two basis of healthy environment. but in real life i can feel the pain where communication is done in one way only (chain of command) and valuable true feedback is rare. if anyone has a solution to break that i'm happy to learn more.
"reduced to communication & feedback" -- in the presence of a power differential this is easier said than done. Or rather, easier for the relatively powerful person.
I've been thinking and it seems to add an unbalanced trust into the equation. I have to prove my trustworthiness every day as an employee and still will be hard to get it. on the other hand the one in power takes it as something already earned by just being in power.
That's the nature of power. However, you always have the option of defecting,, either to another employer or to RIP (retirement in place).
The big difficulty is between the lead and senior programmers. They engage the most difficult questions together, but are in serious career contention. Leads have a very strong incentive to extract good ideas and seed bad ones to protect their position, and they have the default external authority.
The only enduring allocation of authority/responsibility I've seen is the code silo, with people and teams taking ownership. This flies in the face of almost every efficiency and coordination principle, but endures because, as you say, software is about relationships, and it's the only thing that reduces the impact of those relationships.
"If I change an API that you use, then I either migrate your usages myself or we do it together or I maintain backwards compatibility."
True, but this is only an issue if you're working in an architecture where significant changes are (a) common and (b) disruptive.
If my building changes the mains power supply (like voltage or connector type), we'd have a similar disruption, but fortunately that almost never happens. At some point, decades ago, everybody sat down and said "This proposal isn't perfect at anything, but it's good enough at everything, and we'd all be 1000 times better off if we used the same system, so this is what it is", and they wrote the NEC, and that's it. End of discussion. No clever installers saying "We could be 10% more efficient if we ran a cable through the sink".
In software, 99% of the APIs I use could be this reusable, if only people cared to look at existing standards. I fear that the situation is going to get as bad as the early days of electricity, and the government is going to have to step in and force everyone's hand, and it'll be worse than if people just cooperated on their own.
The human brain have something called 'Egotism', that we all have. Its about our thinking is inside us, and mostly about our self. Maybe you have noticed in a dialog when you talk about some experience you have, and the other person goes direct into his/hers experience, without listening first. Some definition is: the drive to maintain and enhance favorable views of oneself and generally features an inflated opinion of one's personal features and importance distinguished by a person's amplified vision of one's self and self-importance. With that in mind the software is most of the time made from the individual, and if more people working on the same feature, dissonance will occur. The trick is to be aware of this, and make the dissonance carry the feature forward.
"aligning authority & responsibility"
That doesn't sound too small! If you can solve that you should win a Nobel! ( not sure what field covers that... 🤔 Maybe Economics? )
I won't be covering the general case, just what happens in software design.
And I'm excited to see what you recommend and how you analyze this problem!
Nevertheless, I think the software case is a pretty good analog of the general problem we have as a society of deciders off-loading externalities to people who didn't benefit from or make the decisions.
Two specific common cases:
1 - Between tech designers separated by time: the defection goes both ways. Designer today makes trade offs that hurt designer tomorrow. Designer tomorrow blindly throws designer before under the bus for all current problems.
2 - Between non-technical decision makers and technical designers: Designer says "this will take 6 weeks to do properly." Non-tech says "Don't worry about properly, we need it done by Tuesday." Tech delivers, but a few weeks later the solution blows up at an inconvenient time (due to the foreseeable deficiencies ), and non-tech blames tech. Even if culpability is acknowledged, the pain of fixing under time pressure (before AND after) falls on tech, the gain of delivering by Tuesday goes to non-tech.
If you have solutions for these, Nobel or not, I'll be really excited and impressed! I truly hope I'm just being too cynical!