MESSY STUFF
I think this sentence could regard more of the reality extending beyond only one problem domain (you are an expert within your own problem domain). By having many domain experts (of which you are one) McNeel can potentially make a better software which solves problems in several problem domains (or “workflows” to be less abstract).
But most important - a tool maker is not always the domain expert!
I think I have sen you say that you are not a software developer. And nothing wrong with that. But here lays a big problem, namely to design and produce the perfect race car intended to win races out there, without being a race car driver yourself (which is the most common case, developers are typically NOT the domain experts for the use cases of the software they make, which btw is why I have suggested that developers consult UX experts for that part of their jobs).
I’ve myself been in the position to design and implement a very complex business system covering a “problem domain” which I had no (zero) experience of when I started up the project as the chief architect. And without a super-good communication with the domain experts in the field the project would have failed miserably (and some say that about 50% of systems with the size I designed typically fail).
But a software like Rhino is technically speaking more complex than most business systems, and still the statistics about the success rate of business systems (which typically has it’s complexity centered around concepts rather than complex technology) is terribly low. Terribly low.
From all this I can conclude that statements like “can do better” and “should do better” are statements with little or no general meaning. The technology stacks we use today is a complete disaster compared to what it SHOULD be if the so called advancement in technology would have kept up with the advancements in other fields of tech.
We landed on the moon when I was a little boy, and more or less all the basic concepts that we use today in software development were already invented in those days. But since then we have only made it so much more complicated to develop even the simplest functionality in software applications or system with ever increasing complexity. Exponentially increasing complexity.
For this reason I think you should be critical, not of the developers drowning in the ongoing havoc, and instead direct your frustration at the madness of the IT-industry in general of the last decades which went down this route of making even the simplest things incredibly hard.
Nevertheless, the need for a useful UX remains, but as I said in an earlier post; if a good UX wasn’t planned and designed already in a very early stage of a software, it’s not going to be easy, and sometimes not even possible, to add it later in the development process (try make major changes in your own design in later stages and you’ll know what I mean. It all too often means , “start again, from scratch”).
You being a domain expert in your field is the only possible way for a company of McNeel’s size to get the right input, in an early stage (meaning, lotsa bugs) and…
In my opinion McNeel developers are doing incredible work given their preconditions. And I think they listen carefully to us users. But please regard the “technical debt” madness (über-complexity) they are working in.
At last: Lots of sharp minds are currently trying to find way to get out of this mess. And what is needed is a paradigm shift. But McNeel isn’t into that part of the IT industry which caused the mess, instead they also use development tools made by others, in their work to make (CAD) tools for us.
IT-technology is in a state of mess. Let’s not make it harder with unrealistic expectations.
// Rolf
[edit: spelling etc]