Earlier quoted context omitted.
> Fine, but why are they so bad at weighing it against long term trust? I want to remind the loss aversion and status quo bias. We tend to evaluate losses more important than they are, which is why for example it is hard to throw seldom used things away. That said, why should feature removal mean automatic loss of trust? Because this feature is not important to me personally, it actually increases my trust that they…
Never heard the name "status quo bias" before, thanks for bringing that up. I don't really care about this particular feature, but I do care about the trend. Why should a feature be sunset? It seems like this must be because of (a) bugs/maintenance burden or (b) a poor design or one that is mismatched with the current product direction. The fact that Google sunsets so many features and products suggests that both of…
I imagine this picture; a “tech-smith” is building an elaborate, complicated machinery and we as the users are watching it, clapping to it, interacting with it. Some are asking “this machine should have bells”, some go “it should have whistles”, and the techsmith wants to add and remove those based on those parameters. In reality, no one knows what the final machine should look like and no one knows how exactly they will use it. So there is a sweet spot in which unexpected changes are budgeted for so that it can change to conform better to what we want and what we find useful as we gain experience with the machine. Which means sometimes the techsmith will need to go “you know what, I’m going to take this bell away because not many are using it and it is causing me problems, and instead I’ll use the materials and energy to add these extra wheels” even after having invested a lot to that bell initially (which is laudible, because they are also fighting against their own sunken cost fallacy).
This should be familiar to software engineers; “why the requirements were not perfect before I started writing the software” doesn’t work well in real life. In reality as the engineer and the user gain more experience with the system that is gradually emerging, they acquire new participatory knowledge of that system and that causes a change in requirements, in a dynamical, reciprocal fashion. (Which is one of the reasons why waterfall processes are not as popular today for most products). I think the same goes at a higher scale, if not complexity, for these comnplicated machinery big tech builds that is used by billions of people.