Running CAD is like Programming

And that's not necessarily a bad thing.

Let's step back. CAD is like programming from two perspectives. From a basic perspecting - on an "talking to the tool" level - when you click any command in the software you enter variables (like "edge id", "radius") that are sent to a function (like "fillet") to execute and recalculate the geometry of your model.

That is true for both Boolean and Parametric CAD packages.

But for parametric packages you're also programming on a "talking to the user" level where you set up a program flow (call it History, or Feature Manager) and routines that use variables (call them Sketches, Link Values, Equations) that will execute a sequence of steps to reconstruct your part. If you have bugs in your routine they will show up as errors and warnings to the users. Future users may have to look at your code, change it, and rerun it (via CTRL-B Rebuild) and hope that it still works. It might be weird for us non-programmers to think that we are actually doing some abstract coding - and SolidWorks' role is hiding that from us - but it is not that farfetched.

Why is this important? If we can actually consider our CAD activity as programming, we may look towards programming to get some suggestions for best practices to run our piece of software.

A quick search finds various websites showing best practices for various programming languages. I'm giving three examples here, and here, and here. Don't read them, just look at them if you're curious.

I'm going ahead and apply a significant filter to the info in the links to generate a sample list of eleven:

  1. Try to reduce intermodule dependencies
  2. Put commonly used code into libraries
  3. Don't optimize code & Use the principle of "least astonishment"
  4. Don't write deeply nested code & Don't write very long lines
  5. Do not comment out old code - remove it
  6. File headers, revision history. File Header, description. Bad: Function names which do not reflect what the functions do. Bad: Variable names which are meaningless
  7. Trouble from unexpected corners. ... implementations generally differ in some aspects from each other. It helps to stick to the parts of the language that are likely to be common to all implementations.
  8. When choosing a variable name, length is not important but clarity of expression & Naming Conventions: avoid names that differ only in case.
  9. Many programs fail when their input is missing. All programs should be tested for empty input. This is also likely to help you understand how the program is working & Don't assume any more about your users or your implementation than you have to. Things that "cannot happen" sometimes do happen. A robust program will defend against them. If there's a boundary condition to be found, your users will somehow find it!
  10. Requirements gathering is an essential aspect of software engineering that is consistently overlooked in Web development... When you're working on a new site or feature, ask requirements questions up front.
  11. Don't repeat yourself. ... Web developers tend to work fast and prioritize time-saving efficiency right now. What saves you time in the moment, though, may not save you time in the long run.

And here are analogies to running parametric CAD.

  1. Try to reduce external references.
  2. Reuse data by using design libraries.
  3. Don't be too elegant and do things confusingly in the fewest features possible. Keep is simple and obvious.
  4. Don't create hundreds of little subassemblies. Don't put everything into one assembly.
  5. Design out features you no longer need. Don't just suppress them or extrude-cut them off.
  6. Communicate, communicate, communicate. Annotate your design. Add comments. Rename your features.
  7. More suggestions for keeping things simple. Do you know that this specialized function will still exist in SolidWorks 2015?
  8. Set up naming standards for filenames and feature names and be consistent.
  9. You don't know how your design will be modified, so flex it. If sketches aren't fully defined, drag the blue lines and rebuild. Even better, pick any dimension on any feature, increase it by 25% and see what happens.
  10. Plan before you start. This is the concept of Design Intent.
  11. Plan while you work. Sometimes the fastest way there is not the shortcut from here. Keep your requirements in mind and think about how you would want to interact with the information if somebody gave you your design 5 years from now.

And here is a nice one to make it a dozen:

Refactor me out of here!
Software engineers have learned the hard way that some code is so awful that you just have to replace it. ... Rather than gut your software, you simply redesign it so it's easier to work with. ... Over time refactoring still results in code that is simpler, clearer, and easier to maintain, making it easier to get to the enhancements and bug fixes you wanted to do before. In my own experience, refactoring is often faster than overhauling software. In many cases it's also more reliable than trying to make a change by brute force.

Now that just sounds like the "my model has so many errors, should I just start from scratch or brute force fix it?" discussion I could be having with any CAD user.

Still don't think you could be considered a programmer? Good luck out there.