Hubris: “overweening pride”
It’s funny to me that Martin Hash has a rant about the hubris of Microsoft and most of its employees. I have no doubt that it’s Martin’s hubris that is driving some of the bone-head decisions that make A:M the second rate application that it is. I make the statement that A:M is second-rate because as soon as anyone gets something decent done with it, and attracts attention, they either go to work for someone using a first-rate application, or if they own their own studio, they start using a first-rate application in order to improve their productivity. If A:M were first-rate, the switches from A:M to something else would not be taking place, or would occur much less often. (I have no doubt that certain areas of A:M are first-rate, but to be considered to be first-rate, you have to win in enough areas, stability being one of these, that you are ‘over-all’ better than all or most of the other choices.)
The fact that Ken Baer, A:M MacOS programmer, thinks A:M will be the only thing standing in a year or two is the very definition of hubris. Maya’s owners could go out of business today, and the application would continue to be used and expanded by third-party developers to the extent that A:M would never catch up with it. A|W and the other companies may have to layoff their research scientists, program testers, marketing whizzes, VP’s of Technology, etc. but they’ll survive, IMO. And of course, a completely unexpected app could come up and take the lead from everyone. The time of admiring certain aspects of A:M as being both an advantage over other apps and unique in the industry is coming to an end. There are too many offsetting advantages in other apps, and A:M’s advantages are being nullified by new additions to the other apps, while A:M’s feature list is full of half-baked features that do not quite function at more than a minimal level of functionality. Three or four years ago, A:M was very attractive, overall, in comparison to Lightwave or Max, for example, but this just isn’t true anymore! Especially if you need a dedicated system to run A:M! (How many times have we heard that A:M is a thoroughbred application that needs a clean OS and good hardware? How many times have we heard that A:M is the animation application for the one-man animation studio? I have come to the conclusion that these two statements can only be true if the one-man studio has a high-end system dedicated to running ONLY A:M and nothing else, it would sill be debateable even then.)
It is weird that you get this attitude from Martin and the Hash programmers that A:M will someday rule the 3D application marketplace, while at the same time, they are obviously not attempting to produce a tool for high-end use. Hash’s marketing strategy, at least in the near term, seems to be to ignore the relatively few high-end users, and just focus on the pure amateurs – what some have called the Poser crowd.
Some people think Hash must be stupid, insane, or extremely short-sighted for their apparent marketing stategy, or even for ignoring the wishes of the larger amateur segment of their user-base that is clamoring for more stability, and more meat in the existing features, rather than another orgy of additional half-baked features. We could talk about cloth, dynamics, flocking, etc., but why not go back up the list to DOF, basic import/export, or some of the other basic things that the Hash programmers never really completed. They rush to add the next new feature, so that they can claim to have ‘cloth dynamics’, ‘hair’, or ‘deformation cages’, and they never take the time to COMPLETE or improve the features they claim to have. Depth of field is a feature that’s been around for a while, and it’s minimally useful in A:M, IMO. For certain shots, it will work out OK, but never the shot that YOU want to do! You can do a tie or a pony tail with the cloth/spring system capabilities of A:M, assuming you are using one of the more stable versions, but you would never want to try to make extensive use of it.
But I don’t believe that Hash’s actions, and apparent marketing strategy are ‘stupid’. Marketing-wise, you might say that they are doing something that will return them a very nice profit year after year, regardless of what the mainstream animation market is like. There will always be fresh meat willing to plunk down a few hundred dollars for the promise of creating their dreams and visions, to rephrase P. T. Barnum’s famous maxim.
However, following this marketing strategy, and at the same time, expressing opinions such as those of Martin’s and Ken Baer’s, that A:M will rule the 3D application marketplace is either indicative of stupidity or something else. Rather than simple stupidity, I believe it is sheer hubris. Hubris is capable of making highly intelligent individuals do or say incredibly stupid things. Martin and his crew are so enamored of his patch technology and the A:M application in general, that they refuse to consider alternatives. They are blind to paths they could have taken long ago that would have made A:M a much better application today. Why is it that Zpider has to single-handedly create so many plug-ins to do what I consider to be essential to advanced modeling in A:M? Same thing for Arthur Waselek’s work. Why does a third-party need to create a plug-in that does something as basic as .obj import/export? How in the world can Hash make statements about ruling the 3D world, when things as basic as Depth of Field rendering, motion blur, and UV coordinates are so poorly or incompletely implemented, or not implemented at all?
I’m not saying that patch technology isn’t great. It has lots of benefits. I’m not saying that A:M doesn’t have the potential to be truly great. It does. But there seems to be a fundamental schism between what Martin and the programmers think of A:M’s future, and how it is actually being developed and marketed. I know that Hash and his programmers are highly intelligent people. Therefore I have concluded that the only reason for this schism is either a cynical promotion of A:M as a high-end tool with the intent to make as much money as possible off of beginners and amateurs, OR it is pure hubris: they believe that even with all of the warts, half-implemented ‘features’, and shortcomings of A:M, it truly will be the eventual winner in the 3D application marketplace.
Anyway, I obviously disagree in part with Arthur and some of the other A:M supporters. I think many of the things they say are absolutely true, but that doesn’t mean that the various A:M detractors are absolutely wrong. There is more than one side to these issues, and many of these complaints are from the perspective of professional users needing to generate output on a realistic schedule, not amateurs attempting to create a short in their spare time. The same difference in perspective is true with Steve S. and the A:M support staff. They may be great people if you meet and interact with them in person. But it is a fact that Steve can be extremely petty and assinine in his actions on the list and in his email correspondence. Sorry, Steve, but it is quite obvious to many people. It doesn’t help when he insists on all bugs being reported to him, and acting like there are no stability issues with the software in his list and email communications.
My own experience with Steve has completely turned me off to A:M. I reported an interface bug recently. It appears to be a possible corruption of the memory structure that is used in the display of the project tree, and the result is that the project tree display is corrupted, and it becomes impossible to select certain item in the tree. On my system this comes up fairly often, and the only way to get rid of it is to quit A:M and restart. I have gotten this error in 9.51b repeatedly, and along with all the other problems, I set A:M aside for awhile. I have only just installed 9.51e, so I’ve not encountered this particular bug yet in it, but there is no mention of it being fixed in any of the 9.51 or v10 bug-fix lists, that I can see. When I reported it to Steve, he requested a file or else repeatable steps to reproduce the bug, and gave no indication that he had reported the bug to the programmers. Unfortunately, this is not a bug that affects or can be captured in a file. It occurs too randomly for me to figure out how to reproduce it, and any programmer knows that there is a large class of possible bugs that are not reproduceable by user-initiated steps. (How does a user exactly reproduce the interaction of various programs, hardware drivers, and associated .dlls?)
Jay
