Perhaps it would be useful to define what we mean by "commoditization" in terms of software. I would say a software product that is not commoditized is one where the brand still can command a premium, which in the world of software, generally means people are willing to pay non-zero dollars for it. Once software is commoditized it generally becomes free or ad-supported or is bundled with another non-software product or service. By this standard I would say there are very few non-commoditized consumer software products. People pay for services that are delivered via software (e.g. Spotify, Netflix) but in this case the software is just the delivery mechanism, not the product. So perhaps one viable path for chatbots to avoid commoditization would be to license exclusive content, but in this scenario the AI tech itself becomes a delivery mechanism, albeit a sophisticated one. Otherwise it seems selling ads is the only viable strategy, and precedents show that the economics of that only work when there is a near monopoly (e.g. Meta or Google). So it seems unlikely that a lot of the current AI companies will survive.
I guess I'm lucky not to have worked at a place with a role for software architects who don't actually write code. I honestly don't know how that would work. However, I think I can appreciate the author's point. Any sufficiently complex piece of existing software is kind of like a chess game in progress. There is a place for general principles of chess strategy, but once the game is going, general strategy is much less relevant than specific insights into the current state of play, and a player would probably not appreciate advice from someone who has read a lot of chess books but hasn't looked at the current state of the board.
Inheritance is not necessary, but then very few programming constructs are absolutely necessary. The question is does it help program clarity or not. I think that in some cases, used sparingly, it can. The main danger of inheritance is not that it is OO, but that it is not OO enough. It breaks encapsulation by mixing properties and methods between base classes and derived classes without clear boundaries. Composition is safer because it preserves encapsulation. In general, I think that protected abstract methods are a code smell, because they usually indicate close coupling of details that should be kept separate between the base and derived classes. But used correctly, inheritance can be more succinct and convenient.
Two of the three Starbucks locations in my home town removed all of the seating. Across the street from one of them, an independent coffee shop opened up with lots of seating. Whenever I walk by the Starbucks is empty and there are a lot of people inside the independent shop. I have to wonder about their strategy.
The Starbucks near me doesn't even brew coffee any more. They switched to these automatic machines that "brew" a cup in about 15 seconds (ie. vending machine quality). Its undrinkable now. In future would only order espresso drinks or cold brew.
I had a similar issue recently. I used the Windows Photo app to import & delete photos from my iPhone. When it finished, I realized that a significant fraction of the photos had been corrupted. Not sure where in the pipeline it happened, or if they were already corrupted on the phone.
It would be interesting to explore further why this topic is still so sensitive for a lot of people, and why the metaphorical talk is still so appealing. I feel like the reasons given in this article couldn't alone explain its enormous staying power (even to this day).
