This discussion is really for current users of history-based systems. People who already use direct edit software will probably think it a little pedantic. I just want to establish that the need for history-based modeling isn’t inherent in CAD. It might be simple enough to just say that, but I’m going to try to make the case for that point of view.
You can’t create entire parts like the one on the right in one fell swoop, so you have to start somewhere, and end somewhere. Basic training for SolidWorks has been pretty successful at teaching people how to model with history-based systems. But not everybody gets it right away. There is no obvious connection between the ability to design mechanical parts and the ability to conceptualize them as time-dependent features.
What you are really interested in here is dependency. But dependency doesn’t have to be determined by which feature existed first. The shape of the rib connecting the two cylindrical bosses depends on the shape of the bottom plate. The locations of the gussets depends on the locations of the circular bosses. So yes, I agree that within mechanical design, you have to worry about dependency, but that dependency doesn’t have to be based on a time-based parent/child concept.
I can still remember when the light went on for me, and I first really understood history-based modeling. Some people described it as a “recipe”, but I wasn’t much of a cook. Instead I understood it as being much like programming, but using geometrical logic instead of process-based logic. Programming has to execute line-by-line, and it matters what the order of operations is. If something goes wrong, the whole process stops. You have to go back and fix things as they go wrong. You can’t always plan a program perfectly, so you are always editing it. Sometimes with programming, you can get a result that is wrong. Even if it doesn’t fail, it might still not be right.
Just like with programming, history-based modeling has a lot to do with planning, and fitting the end product into the process. You spend a lot of time thinking about “how” to do things and about the CAD tools, rather than thinking about the design itself. There has been some discussion lately about the allocation of brain power between design and tools on the Dezignstuff blog. Many of the ideas originated on Evan Yares’ blog. How much energy do you put into discovering, documenting, teaching, and enforcing “best practice”? Best practice is all about the tools. With history-based modeling, “how” you accomplish something matters very much because it effects how others will edit it, but it doesn’t add any value to the design.
Most programmers don’t really understand the applications that they develop. They are in the end specialists in the programming tools. It’s interesting to me that the creator is often unaware of how his creation will be used. The metaphor extends to mechanical designers. Most of us don’t use the things we design. Just think how much better things would be if the people who created them were actual users. But we can’t do that because all the tools require specialists who may or may not understand design in general and a particular product in specific.
Editing a part in history based CAD is like troubleshooting a program. You have to search back through your code (feature list) and see where the problem is. Are the inputs correct? Am I using the right calls/features? Have I set the parameters/options properly? And once you have found the problem, you run it again to see if you got the output you were expecting. Some edits are easy. Some are difficult. Some edits require a restructuring of the program.
Truth be told, I enjoyed programming until I figured out that I wasn’t any good at it. Being a good mechanical designer doesn’t make you a good programmer. Finding people who can do both really well is rare.
Part of the argument for history-based CAD that I originally felt compelling was that you edited features in the same interface used to create them. So it was consistent, and made more sense. But even if editing and creating are done with the same interface, they are still worlds apart conceptually. If you’ve done much CAD in real world projects, you know that you create once, and edit many times. You also know that it’s easy to create something, and much more difficult to edit it, even if the interface is the same. When you create, you’re only worrying about order in a kind of existential way. The only way to create dependency is to have order. But when you edit something, the order no longer matters. Only the dependency matters.
This brings us to a difficult question. Sometimes a feature eliminates the thing it was dependent upon. For example, fillets remove edges, and yet they were dependent on the edges. In reality, fillets are dependent on faces, but let’s stay with the edges for a minute. In this kind of case, applying the fillet with some sort of time-dependency really does make sense. Solid Edge can edit geometry where fillets are “just geometry”, but there are some limitations. There are other kinds of cases where certain driving topology gets eliminated, and these are all candidates for working with “ordered” features on top of the synchronous model. This is exactly what Solid Edge (ST3 and later) does. The real power here is the ability to combine both paradigms. This is what I find so compelling about Solid Edge.