Hey, this might be my first ever rebuttal-to-another-blog post. A post by Paul Hamilton showed up in my feed reader. I don't know who he is or why I'm watching his blog, but his profile indicates he is CAD-related, so I must have read a previous posting and subscribed.
Today Paul argues that costs can be saved with history-free CAD modeling. This might ultimately be a true sentiment, but Paul argues it badly. I see that a previous post of his argues the benefits of history-based modeling, so maybe he is just playing devil's advocate this time around, which would explain the weakness of some of his points.
The first set of ten points addresses improvements in effeciency. Let's take a closer look.
1. Lower your training costs with history-free modeling. There is simply less to learn when there is no history tree to create and manage. Intuitively interact with the geometry, directly.
Speaking as a former CAD trainer, I suppose there is some slight merit to this point, but it certainly isn't significant. For an introductory class with 20 chapters, one (maybe two) was spent on history, so for a five day class we are talking about a couple hours, tops. Significant? Hardly. Would the omission of this topic enable dropping to, say, four days? No.
With CAD, you have to know how to create stuff, and you have to know how to modify stuff. I haven't seen anything in the history-free world that suggests the creation tools are really significantly different and/or easier. Call that a wash. So how about the modification tools? Well, you have to know what you are doing in either case. Even within the realm of a history-free modeler, there will be rules and nuances that will still need to be trained or otherwise learned with experience.
2. Get the right people engaged at the right time. Eliminate CAD knowledge from the criteria for assignments and resource management.
So, history-free modeling is so easy that anyone could do it, eh? Right. This ignores the knowledge required for CAD model creation.
3D modeling is a mind set much more than a skill set. It's an ability to visualize the desired item so that you can sit down and make it happen on the computer. If you can do that, then the tools are just a matter of training. If you can't, it doesn't matter how easy the software is. I have encountered everything from the newbie with zero CAD experience to grizzled old veterans, and not once has the ability to interpret a history tree been the deciding factor between "gets it" and "doesn't get it".
3. Hire the best designers and engineers, not just CAD jockeys. Eliminate CAD knowledge from the criteria for hiring/staffing.
I haven't encountered too many quality designers or engineers who were not highly skilled with computers and the appropriate tools for the job, which should include CAD. Indeed, at my previous company, most of our best engineers were hired without experience in the specific CAD program (which is history-based), but they did have decent CAD backgrounds, so training wasn't that big of a deal.
There is nothing, absolutely nothing, about history-free modeling that equates to "nothing to learn", so the notion that you can remove an item from your desired skills hiring checklist is ludicrous.
Besides, those guys that are "the best" are going to want to be paid accordingly, so how does this help to reduce costs? This point would make more sense if it argued in favor of hiring lower-caliber people, since you supposedly wouldn't be paying for CAD experience.
4. Enhance the concept design process with flexible 3D modeling. Concept design and history-based modeling are like “oil & water”; they don’t go together very well.
Since this is about concept design, naturally we are talking about model creation, so refer back to my previous point about the creation tools. As the modification process goes forward, it is really going to come down to the specifics of what you are doing and what needs to be changed; that it is hard to generalize in favor of either direction. And really, this point is more about design intent than history modeling. If you put in a lot of design intent up front, then you are going to be frustrated when a necessary change doesn't jive with that intent. I'm forced to assume that even history-free modeling possesses some means of capturing design intent - otherwise it would be nearly useless - so this is still a wall you can smack against. Some changes may be easier to implement in a history-free environment, but I can find just as many cases that would be easier with history. This simply isn't a good point to generalize about, because it is so case-by-case.
5. Improve productivity for each individual by focusing on design, rather than model creation methods, technique and process. Reduce costs by focusing all effort on product design rather than 3D modeling.
There aren't creation methods, techniques, and processes in history-free modeling? All I have to do is think it and the model appears on my screen? Incidentally, I think that last sentence is a sales slogan for many history-based CAD programs.
CAD is all about shapes, obviously. So in the design process, the quality CAD user is thinking to himself "how do I make that shape in this software?" That thought process still has to exist even in a history-free environment. There are still steps to take to create the shape. Maybe one CAD program has a handy command that does what you want in one shot, maybe another CAD program requires two or three steps to accomplish the same thing. History or not, you still have to know what you are doing, and how to make it happen.
6. Repurpose existing data easily with no need to understand model history. Optimize parts once and reuse to the max.
Maybe I'm not understanding the point being made here, but how does part reuse correspond in any way to how it was constructed in CAD? If the 3-spoke widget you designed for Product A might also be used in Product B, then go use it in Product B. How does history even enter the equation? Optimization is a function of FEA and testing, not history, so test it against the requirements in Product B and determine if it is appropriate for use.
This is a data management point more than a CAD modeling point.
7. Greatly improve teamwork, team design and interaction with downstream and upstream partners to improve quality, innovation and reduce costs. By eliminating the history tree, team members can immediately interact with the CAD data. No need to study the model history.
This is such a curious sentiment from someone with PLM experience. The whole bit about teamwork is completely a function of the data management capabilities, and has nothing to do with CAD modeling. Do you really want your vendor making changes to your model? Of course not. But you do want a nice handy way for your vendor to convey those requested changes back to you. So now we're in the realm of geometry viewers, markup capabilities, and managed permissions. This has absolutely nothing to do with the CAD creation methodology.
And again, assuming that even history-free modelers possess design intent capabilities, then you absolutely should study your model before diving right in.
8. Get the maximum value from your rich CAD data by making it available, and understandable, to the extended team.
Why is history-free CAD data rich? Is an IGES or STEP file rich? In my world, we call those dumb solids for a reason. And again, data availability is a function of data management and viewers, and has nothing to do with CAD creation methodology.
9. Minimize IT infrastructure load. Utilizing explicit history-free modeling technology can reduce average file size by 60% to 80%. Can minimize RAM requirements, storage space requirements and network traffic. This is made possible by eliminating data space requirements that are typical of the history tree.
I don't buy this for a second. With history-free, you are storing all geometry all of the time, and that will always be larger than the instructions to recreate the geometry if necessary. Which occupies more space, the house or the blueprints? If you want to say that instructions + geometry > geometry alone, fine, but at least you have the option to strip away the geometry and go with the instructions alone.
The stated percentages are going to be a function of how much geometry the history-based modeler stores, and this will be a function of each software's implementation. If the history-based modeler stores only the final geometry, then the resulting file size should be within a tiny percentage of the history-free's model.
10. Improved general performance and load/store times for each CAD user by taking advantage of the lightweight footprint of explicit history-free modeling.
Lightweight models are not unique to history-free modelers.
So 10 ways to improve efficiency with history-free modelers, of which most having nothing to do with the CAD modeling paradigm, and what's left really doesn't create a convincing argument. If anything, several of these points are fine arguments for the implementation of a decent data management system, which of course has nothing to do with how the CAD model was created.
Paul then goes on with 10 ways to reduce waste. He makes better points here, so let's take a look.
1. Eliminate the waste of history tree management and structuring. Focus on the task of design. And don’t make the incorrect assumption that you cannot capture design intent without a history tree.
Ok, so he confirms that there is indeed design intent in a history-free modeling paradigm. This alone kills any implication that there is nothing to worry about in such an environment. I'm willing to grant that history tree manipulation can be a big deal, but this is also a factor of each software's implementation. Figuring out the design intent is going to be the key task, and my gut says that this is more easily done with a history tree, but I'm willing to be proven wrong.
2. Eliminate the need to rebuild models, something that is too common with history-based tools. (especially if you do concept design with them)
So, with number 12 we finally land on a completely legitimate point, no question. About the only thing I'd like to add is that the time spent on rebuilding is highly dependent on software implementation, and hardware capabilities. For example, SolidWorks smokes I-DEAS on pure rebuild performance, due simply to having a newer, faster algorithm. On the flip side, I-DEAS provides some methods such that a complete tree doesn't need to be rebuilt (however, there is some of that history tree management involved). I'm going to guess that on average, if the hardware in question has the necessary guts to do live changes on raw geometry, then it can probably burn through a history rebuild without too much trouble also.
3. Eliminate the need to create and manage standards and best practices for creating and managing history trees / history-based models.
Although I can think of some general best practices off the top of my head - mostly dependent on the software implementation - I can't remember ever feeling burdened by them, nor were they ever enforced. Start with a coordinate system (manual in I-DEAS, automatically there in SolidWorks), put fillets last, that's about it.
4. Add intelligence (features, parameters, …) to models and assemblies only when needed. History-based systems may force the addition of this intelligence whether it will be used or not. They will force relationships (parent/child), again whether this added information is actually useful or not.
Parent/child is about the only legitimate difference between history-based and history-free. Aside from that, you can do unconstrained modeling in most history-based programs. "Only when needed" is a comment on design intent, which exists in both paradigms, so I don't see much of a point here.
Also, the implication that there are no parent/child relationships in history-free modelers is false. There may be fewer of them, and they may not be as rigid, but they are there. Some operations, like fillets and draft angles, have to occur after other geometry is created. You can't fillet something before the geometry is created, and if some of the participating geometry is removed, the fillet can't exist. That is a parent/child relationship.
5. Upward compatibility can be a big issue with history-based modeling and can result in rework and duplication of effort. There is no compatibility issue when working with geometry; i.e. explicit history-free modeling.
"No compatibility issue" is certainly a bold statement, and given the various issues I've seen with IGES files over the years, one that I'm willing to believe could be proven false easily. While it may be true that there is less to break with a history-free model, to suggest it is unbreakable is placing far too much faith in our robotic overlords. It implies that nothing more needs to be fixed, or no more performance needs to be improved, in the code which is never the case. Messing with code carries along with it the possibility for breaking with legacy data.
6. Greatly reduce the effort of data exchange with suppliers and vendors. History trees are proprietary.
Pretty much all of the vendors I've ever worked with wanted either whatever their native software uses, or IGES or STEP files which are easily generated by history-based modelers. While history trees may be proprietary, so are file formats, so unless these history-free modelers are working with something like IGES as their native format, this is a moot point at best. Unless someone developed the holy grail of open, widely-recognized and utilized 3D formats when I wasn't paying attention, there is still the potential for translation and compatibility issues, regardless of the modeling paradigm.
7. Eliminate the need for other team members to study the history tree of other team member models just to make use of them.
I'll say it again: you still have to study the design intent. History is merely an element of the design intent. I have yet to encounter an environment where design intent is completely unnecessary and completely undesired.
8. Designers will spend an estimated 25% of their “CAD time” managing and manipulating the history tree and related attributes and data. Your designers can be 25% more productive by eliminating this activity.
This sounds like a made up statistic, because there is zero chance I've spent anywhere close to 25% of my time on history manipulation, but let's take it at face value. What percentage of that time is spent on interpreting design intent, an activity that will still need to occur in the history-free environment? I'd be willing to bet that the difference will be made up in the additional time spent in the history-free environment, where the user does not have the history tree to provide additional information about the design intent.
9. Greatly reduce the need to recreate CAD data just to get it into an editable format
Under what circumstances? 2D -> 3D would be no different. Changing CAD programs? The file will still need to be exported and converted (again, if there is some commonly-accepted history-free file format that all history-free modelers are using and can easily exchange, I'm willing to be educated). After we decide that history actually was kinda nice and we need to go back to it? Oops, it's all gone, have to start over...
10. Reduce the time consumed in the change cycle, but eliminating the need to study the model creation history. Focus on the process of change.
How many bullet items need this same point? And I'll keep repeating mine: you still. have. to. study. the. design. intent. first.
I can't shake the feeling that Paul really doesn't believe that much about what he wrote, but felt like he needed to make a counterpoint to his previous article. I'm not sure what his motivation was, but as far as sales pitches go, this was not convincing.
Incidentally, the gist of each of his points - make CAD available to more people (or everyone), easier to learn, easier to do, focus on design and not CAD - are almost verbatim the same things that the SolidWorks folks say, and SolidWorks is - wait for it - history-based. Lack of parent/child relationships and lack of rebuilding are about the only legitimate points to differentiate history-free, and the rebuilding one is the only one that is hands-down a weakness of history-based. Parent/child will depend on the situation.
Really though, I see nothing here justifying a history-free approach that would not also be on the order of magnitude of simply switching to a different CAD program. Performance improvements here, easier to learn there, less expensive over there in the corner, and so on. In my case going from I-DEAS to SolidWorks, I'm going from old, Unix-based, expensive software that hasn't significantly been enhanced in years, to relatively new and cheap Windows-based (actually, maybe that should be despite being Windows-based...) software that is being rigorously and regularly updated. There's going to be a huge amount of win there, no question. That most likely would have also been true had we gone with SolidEdge or Inventor instead. In fact, nearly every point that Paul made could apply to our transition to SolidWorks. So why would I want to go with a history-free approach, and give up the things that history does provide? No thanks.