I’m unsure why the original idea seems silly, when it simply states a possible reason for this problem today. Giving a developer observability is the first step, that’s what they are pointing out —- some ways developers interface with features don’t include information that could deliver a higher value feature. A company can choose whether to deliver that higher quality or not with that information, ignorance removes that choice.
If a company has that information and doesn’t care, that’s one thing. There’s more than a handful of companies that just don’t have the information to even know if they should care.
I think most people would agree that we should use tooling to make it so that developers are aware of their blind spots, such as supporting systems with lower resources or a more inconsistent network. The Netflix blog had a nice post that included a tool they used to observe the UX under certain failure cases, which is a nice example of this [0].
If a company has that information and doesn’t care, that’s one thing. There’s more than a handful of companies that just don’t have the information to even know if they should care.
I think most people would agree that we should use tooling to make it so that developers are aware of their blind spots, such as supporting systems with lower resources or a more inconsistent network. The Netflix blog had a nice post that included a tool they used to observe the UX under certain failure cases, which is a nice example of this [0].
[0] https://netflixtechblog.com/keeping-netflix-reliable-using-p...