Deelip Rants
Deelip Menezes is a CAD plugin developer in India, who writes a blog discussing a variety of CAD related subjects.
He's pretty good at stirring the pot: he writes long blog posts, with plenty of opinion, and lightly filtered rants.
His most recent rant is about CAD users who think that CAD programmers are not CAD users. He points out that he has 44 or so CAD programs on his computer, which he uses. Therefore, he is a CAD user.
Here is my thought: A CAD user is not merely a person who uses CAD. A CAD user is a person who is a domain expert in the use of CAD software to solve a design or engineering problem. It may be that a CAD user speaks only one CAD tool "language" (e.g, Solid Edge, ComputerVision, Anvil 4000), but if they can wield that tool skillfully to solve their design or engineering problems, they are a CAD user.
Deelip claiming to be a CAD user, because has a bunch of CAD programs, and can use them to develop CAD plugins, is like a person claiming to be a mechanic because they have a bunch of wrenches, and can use them to tighten bolts.
While Deelip is a domain expert in the development of certain types of CAD plugins, that expertise doesn't necessarily translate to related domans. (Though that doesn't stop him from jumping in with both feet.)
In his post, and the related comments, a large number of CAD-related domains are discussed: CAD use, CAD programming, CAD development, CAD plugin development, CAD analysis, CAD writing, CAD reviewing, CAD QA, CAD testing, CAD demonstration, CAD usability analysis, CAD failure analysis, CAD UI design, CAD documentation.
If I were looking for a domain expert in CAD plugin development, I might put Deelip pretty high on my list.
But the other domains? Not so much. Here are a few possibilities:
SolidCAD use: Matt Lombard.
CAD programming: Mike Riddle or Tim Olsen.
CAD development (big picture): Chuck Grindstaff or Mike Payne.
CAD analysis: Ken Versprille or Mark Halpern.
CAD reviewing: Al Dean.
As for me: I may be a domain expert in some disciplines, but I'm not fool enough to think I could give any of these folks a run for their money in their particular domain. Well... except maybe Al. But, then, he'd still kick my butt in terms of how fast he gets reviews done.
Now, back to Matt Lombard's question, as expressed by Deelip:
"To the best of my very poor memory, all of the proponents of Direct Editing as the New World Order for CAD are non-users, and the proponents of history are users ...[snip]... Any comments on that?"
My answer is that it's not his memory. It's more likely to be confirmation bias.
His question is straw-man: Most serious proponents of direct feature modeling that I know have expressed the sentiment that a two-trick pony is better than a one-trick pony, unless the one-trick pony meets your needs.
Translated: A lot of people will benefit from having both modeling technologies. Some will do fine with just parametric feature-based modeling. And some, especially those for whom feature-based modeling is just too hard, will benefit from having just direct feature modeling.
Parametric feature based modeling isn't going away. At least, not for a long time.
References (1)
-
Source: Users and Non-Users


Reader Comments (1)
In the last month along with 20 ‘hours’ of training new CADD users I have been tasked with solving a problem with the design of the positioning of burners and supporting systems on a very large furnace, creating the 3D models and documentation for several new ‘curvaceous’ basins, modeling new tapware, a complex curved ramp access for an existing old building and new design for a pulse jet (the later for me).
Watching the comments in relation to modeling methods is always interesting. Having, earlier on several occasions, commented, about how ‘warped’ they are, I won’t repeat. However using the examples/mixed projects outlined above, I’ll ask this questions; how does a self employed person working across multi-disciplines cope with the use, and more importantly selection and purchase, of CADD software?
There are many answers, for sure: the answers I most frequent receive are “buy appropriate/more software”. Replies received from vendors (no surprise there) but also from other users; who, on examining their backgrounds, have all been found to have been fully/company employed. In such a situation the cost(s) are not bourne by them – personally – and as a result they are unable, or unwilling, to understand and accept that what they have been able to ‘get away’ with, in a large multinational, is not possible at micro/individual level. But their choice significantly influences what is available to me and other small users! This also applies to vendors who fail to recognize the importance of the ‘little’ guy.
The ‘drawing board’ covered multi-discipline requirements with absolutely no problems but CADD vendors (3D in particular) struggle to match that capability, why? Part of the answer can be found in the arguments expressed about the ‘form’ of 3D modeling. There is a polarization of thought in users that follows/mirrors those of the developers and visa- versa. The choice of development direction, of a CADD system, may vary, but once the path is chosen, marketeers, developers and a ‘group’ of like minded users work very hard to promote and protect the process; arguing their case, always from their perspective – rarely from a point of view of what would be ‘good’ for industry as a whole.
The foundation stone of my comments has always been couched in the word ‘flexibility’. A ‘good’ CADD system, I believe, is one that does not inhibit, control or direct a designer/draughtperson down a set path. It should be a system, a collection of tools, an individual can assemble, and use, in any combination and order.
We have seen, and lost, tools of this nature because of the shortsightedness of vendors, marketeers and developers, supported by their protagonists and, the result is a mess!
What is needed? A CADD developer who understands his tools/product has to have - at its core - an ability to allow the designer/draughtperson to work as freely as the past allowed whilst at the same time leaving open the avenue(s) for the initial data to be directed down differing, equally flexible paths or more specialized (less flexible) paths.
In a multi disciplined environment it is better to have ‘less CADD than more’. You get criticized but in the long run using CADD is about the users making money. Having to use/learn/implement many systems is not the best way; but it will remain on the table while users, and others, continue to argue about ‘which way is best along specific paths’, instead of actually looking for ‘which way is best’.
We need more than a “two-tick pony” Evan we need a ‘multi-trick’ pony; who’s up to it?