The macroscale of micro frustrations
I have experience with two GPS navigation systems. My Android phone has Google Maps. My car also has one, powered by TomTom. All things being equal (as when I drive my car) both are in direct competition. I have to put my trust in one of them. I can’t objectively tell which one is better. Yet, somehow I tend to use one of them often and avoid the other.
In this case, my decision-making process seems as irrational as the ones software developers have while adopting frameworks and tools. So I got intrigued and tried to debug and backtrace it. The more I think about it, the more I believe both are influenced by the same perception of reality.
The facts
Google Maps navigation got me in trouble twice. Both were attempts to avoid a traffic jam. Several years back, it navigated me through a road that didn’t actually exist. It happened in Romania. The “road” turned out to be a narrow path in the middle of a cornfield. The second time was last summer in Poland. The bridge that was supposed to bring me back to the main road after a 40km detour didn’t exist either.
I have never had the same issue with the TomTom navigation in my car. In fact, I can’t recall a single time it was significantly wrong about a road. But man, it’s so frustrating. It changes directions without asking or even notifying. Sometimes it does so while I’m in the middle of an intersection. Several times it made me “avoid” a traffic jam, only to return after the exact same vehicle I had in front of me before. It tells me how long to the next gas station, but not if it’s on my side of the highway. It directed me on a paid road that requires an e-toll account. I had to pull over, call the highway service, and ask how to pay the highway fee to avoid a significant fine.
The perception
The two major issues I had with Google Maps didn’t ruin my trust in it. I can understand how mistakes like those can happen. I almost don’t remember them. I only recall them occasionally as a fun story. Also, those were several years apart. They seem to be the exceptions of otherwise well-functioning software.
On the other hand, the TomTom system in my car causes micro frustrations almost every time I use it. None of them has the severe consequences of a missing road or bridge. But those pile up quickly. Those micro frustrations build up the feeling of a fragile, not well thought, underdeveloped, etc., product. I know that is not the case. I have good friends at TomTom (I was once considering joining their team in Poland) and I know many super-smart folks work there. I admire the things they do.
The difference
The fundamental difference is that while TomTom is great with maps, Google is great with user experiences and not terrible with maps.
An OK product providing a great user experience will almost always be more appreciated than a great product having an OK user experience. The same rule seems to apply when the users are software developers. Just because they understand the value of a framework or API and appreciate the effort put in building it does not mean they will survive ever piling micro frustrations.
In the last decades, I’ve observed some great technologies (like Portlets and OSGi to mention a couple) that ignored the micro frustrations factor for way too long. They gained adoption while there was nothing comparable feature-wise. Eventually, they lost the battle with not-so-good but less frustrating alternatives.
The adoption (and thus the potential commercial success) of a developer-focused product is a function of product quality and the developer experience it provides.