Before moderators step-in with both sides, I will ignore the ad hominems and just leave this with an explanation because you have so misconstrued/misunderstood my posts, I didn't want to leave it with that bad take hanging. This is going far away from the thread.
May be there is a language problem. So, I am just going to leave this explanation here and end my participation in this thread.
My post was in response to a post against HDMI (because of its licensing issues) with comments of the form we don't need ARC anyway. I pointed out that HDMI is actually a good solution for almost every consumer in the intended HT market because things like CEC, ARC/eARC, integrated audio/video with minimal connections, etc., actually make it a great solution for the consumer because it solves a number of consumer problems.
The technology behind HDMI was developed by engineers, but the market requirements (not to be confused with technology) of what features to include for the benefit of the consumers are best handled by the people whose job description it is to understand the consumer and translate that into a PRD and/or a MRD. This is not just my opinion. This is why you have product managers who are part of the marketing department, not engineering department.
When engineers are put in deciding what the product features should be, they are notoriously bad at understanding and addressing consumer needs. Instead, they tend to assume "nobody needs ARC" if they don't like it. This is not a very controversial statement. It is common knowledge in any company that has both product management and engineering. Most startups started by technologists fail because of this until they learn the hard way like I did. It doesn't mean engineers shouldn't develop the product technology itself. Product managers cannot do that. You did not or do not understand this distinction.
My second point was that the HDMI protocol was arrived at a committee that was motivated by DRM issues (given its constituents) and so DRM became a part of it and an impediment to its use for non-DRM applications because of the committee that was responsible. But that doesn't mean, the requirements for things like CEC, ARC/eARC which have nothing to do with DRM aren't useful by themselves. You cannot deny the usefulness of these kinds of features because you don't like the DRM and licensing aspects of HDMI protocol and dismiss those requirements as not necessary anyway. That is a very engineer way of thinking. Not a market focused-approach of what customers need.
My problem was that the audio industry outside of the DRM-vested world could very well have developed a protocol/connector that would have been as easy to use with the convenience features already identified in the MRD of the HDMI (which have nothing to do with DRM). Whether it looks like HDMI or something else isn't the point, that is for the engineers to decide given the requirements. But unfortunately, as illustrated in that thread I linked to, engineers have a tendency to get attached to a technology rather than the requirements and try to push that as the only solution you need and deny any requirement that doesn't fit that model as something no one needs. This is why Engineers shouldn't be doing product management which decides what the market needs just as product managers shouldn't be deciding what technology should be used/developed to solve those requirements, they aren't good engineers. You didn't get this distinction either.
So all the other technologies I mentioned that have created silos aren't flawed as you understood because they were designed just fine for the goals that were set up for it but that doesn't mean the goals are solutions for the kind of consumer needs/requirements HDMI satisfies unrelated to DRM. So pushing each of those siloed solution as an alternative is a problem, and that is the problem with engineers in love with a particular technology rather than what is needed for the market.
Perhaps, the above is incomprehensible in the closeted engineering circles but it is not really controversial in the whole company/startup context.
One of the several difficulties with that prior post you wrote was the lack of any real connective path from the discussion of HDMI and DRM to your bashing of engineers.
See explanation above. You are welcome to disagree. We all speak from our individual experiences. Separating out technology development from product requirement/definition and keeping those roles separate isn't bashing anyone. I learnt this the hard way, so I wasn't facetious about you reminding me of myself a long time ago.
The only way there could have been any real connection from your token introductory comments to your bashing of engineers would be if you were blaming DRM in HDMI on engineers.
Note even close. See above.
You didn't do that, oddly. Rather, what you did was to bring up several other major innovative technologies, which you did for no reason other than to give yourself a token excuse to bash and insult engineers, in a categorical way. You said in effect that these technologies (USB, IP) are flawed because they weren't designed by the right kind of people, i.e., they weren't designed by non-engineers.
Not what I said at all. See explanation above. There is a huge difference between designing the product implementations where engineers come in and designing the product definition/requirements which is an outward facing product management job. You are not making the distinction between the two and making the above nonsensical interpretation.
You did not bother to identify the supposed flaws of these excellent technologies.
This is begging the question from the flawed interpretation above.
You would need to have done so before it would have made sense for you to blame engineers for ruining these technologies, in the way you did. Of course the suggestion that this kind of work is best done by non-engineers is ludicrous at face value. If there is something here that is so risible as to deserve a big laughing emoticon, there can be no doubt that this would be it.
This is taking the same flawed interpretation into logical extremes.
I am done. I really suggest reading someone's post more carefully before taking offense.
I couldn't have asked for a better engineer stereotype to prove my point. This level of arrogance and dismissiveness towards anything that does not fit one's limited worldview (and going fetal with "it doesn't compute") is precisely why so many engineers make bad product managers. The latter need to understand what the customer needs and wants and why they are different from what one thinks is the perfect solution mroe often than not. Unless one is in the business of creating products that are targeted only to other engineers....
