A few points. I am currently in the situation where the company I work for has been wasting millions, slipping schedule and increasing risk due to picking a wrong environment for the project (Android instead of Linux. Android is necessary for apps, but terrible beyond belief for IoT, where one does not need the playstore.) The owner of the company drank the Android Kool Aid and the project manager refuses to tell him what this marketing gimmick ending up costing. It would be impolitic for me to challenge the two of them, and it’s not my money that is wasted. We have an occasional “this would be so much easier on Linux” moment, but it goes nowhere, because the decision has been made and any change in the course, even if projected to save money, would be perceived as risky and would expose someone’s incompetence. So we are stuck at the “agree to disagree” stage, and the project manager makes the call, without any interest in discussing the merits and getting angry at any mention of an alternative.
Re your set of attitudes. I find that one does not need to believe in anything like “objective reality is real” to use the technique. So, let me modify your list a bit
Epistemic humility: “maybe I’m the wrong one” → “Maybe my approach is not the optimal one” Good faith “I trust my partner to be cooperating with me” Belief that objective reality is real → Belief that better approaches are possible ”there’s an actual right answer here → “there is a chance of a better answer, where “better” can be agreed on by all parties” , and it’s better for each of us if we’ve both found it” Earnest curiosity
Agreed, and I’d be more specific with the modifications:
“maybe I’m the wrong one” → “Maybe my approach is not the optimal one” → Maybe there are dimensions of optimization (like solution search costs or budget justification) that I’m weighting differently from my boss.
“I trust my partner to be cooperating with me” → “I trust my partner (and am willing myself) to spend a bit of effort in finding the causes of disagreement, not just arguing the result”
And it goes both directions—be honest with yourself about what dimensions you’re weighting more heavily than others for the decision, and what optimization outcomes might be different for you than for your customers and boss. A clear discussion about the various impacts and their relative importance can be very effective (true in some companies/teams, not in others. In some places, you have to either trust that the higher-ups are having these discussions, or convince yourself that the decisions aren’t intolerable (or seek work elsewhere)).
On the object level, I write software that supports lots of IoT devices, some using Linux, some Android, some FreeRTOS, some Windows-ish, and a whole lot of “other”—microcontrollers with no real OS at all, just a baked-together event loop in firmware built very specifically for the device. There are very good reasons to choose any of them, depending on actual needs, and it’s simply incorrect to say that Android is terrible for IoT. Very specifically, if you want a decent built-in update mechanism, want to support a lot of off-the-shelf i/o and touchscreens, and/or need some kinds of local connectivity (bluetooth audio, for instance), Android’s a very solid choice over Linux.
Thanks, all good points. Wish we all cared to apply modifications like that.
I also agree with off-the-shelf support advantages of Android, though the update mechanism outside of the play store seems to be nothing special. As for weighing the dimensions differently, there is definitely a significant difference: he puts premium on not rocking the boat, while mine is on delivering simple maintainable low-risk solutions. In general, simplicity is greatly undervalued. You probably can relate.
1. I’m just removing an unnecessary assumption, to avoid the discussion about what it means to be right or wrong, and whether there is a single right answer.
2. I don’t have the clout to change the boss’s mind. Making suboptimal decisions based on implicit unjustified assumptions and incomplete information, and then getting angry when challenged is something most of humans do at some point.
A few points. I am currently in the situation where the company I work for has been wasting millions, slipping schedule and increasing risk due to picking a wrong environment for the project (Android instead of Linux. Android is necessary for apps, but terrible beyond belief for IoT, where one does not need the playstore.) The owner of the company drank the Android Kool Aid and the project manager refuses to tell him what this marketing gimmick ending up costing. It would be impolitic for me to challenge the two of them, and it’s not my money that is wasted. We have an occasional “this would be so much easier on Linux” moment, but it goes nowhere, because the decision has been made and any change in the course, even if projected to save money, would be perceived as risky and would expose someone’s incompetence. So we are stuck at the “agree to disagree” stage, and the project manager makes the call, without any interest in discussing the merits and getting angry at any mention of an alternative.
Re your set of attitudes. I find that one does not need to believe in anything like “objective reality is real” to use the technique. So, let me modify your list a bit
Agreed, and I’d be more specific with the modifications:
“maybe I’m the wrong one” → “Maybe my approach is not the optimal one” → Maybe there are dimensions of optimization (like solution search costs or budget justification) that I’m weighting differently from my boss.
“I trust my partner to be cooperating with me” → “I trust my partner (and am willing myself) to spend a bit of effort in finding the causes of disagreement, not just arguing the result”
And it goes both directions—be honest with yourself about what dimensions you’re weighting more heavily than others for the decision, and what optimization outcomes might be different for you than for your customers and boss. A clear discussion about the various impacts and their relative importance can be very effective (true in some companies/teams, not in others. In some places, you have to either trust that the higher-ups are having these discussions, or convince yourself that the decisions aren’t intolerable (or seek work elsewhere)).
On the object level, I write software that supports lots of IoT devices, some using Linux, some Android, some FreeRTOS, some Windows-ish, and a whole lot of “other”—microcontrollers with no real OS at all, just a baked-together event loop in firmware built very specifically for the device. There are very good reasons to choose any of them, depending on actual needs, and it’s simply incorrect to say that Android is terrible for IoT. Very specifically, if you want a decent built-in update mechanism, want to support a lot of off-the-shelf i/o and touchscreens, and/or need some kinds of local connectivity (bluetooth audio, for instance), Android’s a very solid choice over Linux.
Thanks, all good points. Wish we all cared to apply modifications like that.
I also agree with off-the-shelf support advantages of Android, though the update mechanism outside of the play store seems to be nothing special. As for weighing the dimensions differently, there is definitely a significant difference: he puts premium on not rocking the boat, while mine is on delivering simple maintainable low-risk solutions. In general, simplicity is greatly undervalued. You probably can relate.
This sounds plausible (although curious if this is something that you’ve seen successful, or just seems like it should work?)
Have you tried anything like “unilaterally making the conversation better” with your boss(es), or does it just seem too entrenched?
1. I’m just removing an unnecessary assumption, to avoid the discussion about what it means to be right or wrong, and whether there is a single right answer.
2. I don’t have the clout to change the boss’s mind. Making suboptimal decisions based on implicit unjustified assumptions and incomplete information, and then getting angry when challenged is something most of humans do at some point.