Stop Looking for the Perfect CAD System

Why the best design toolkit may be the one that knows when to use another tool.

By Tim Elliot

© 2026 Tim Elliot. All rights reserved.

When did CAD stop meaning drawing?

There is a small historical argument hiding inside the initials CAD.

They have been used for both Computer Aided Drafting and Computer Aided Design.

Those are not quite the same ambition.

Drafting is principally about communicating a design: producing drawings, dimensions, annotations and documentation.

Design is the larger activity: deciding what something should be, how it should work, how its form should develop and how its components should relate to one another.

The distinction matters because early computer graphics were very good at demonstrating that a machine could draw. The Computer History Museum describes early CAD as essentially a better drafting tool before it became a way of modelling complex surfaces.^[1]

That transition is one reason the same three letters can describe rather different activities.

I encountered the distinction first-hand while editing CAD magazines in London. One of the publications I worked with deliberately explored CAD&D — Computer Aided Design and Drafting, also rendered CADD, because it seemed to acknowledge both sides of what the technology was actually doing.

Looking back, that seems rather sensible.

The vocabulary often becomes settled before the technology does.

How does some CAD software remember how a model was built?

Some design software remembers a model as a sequence of modelling operations.

You might create a sketch, turn it into a three-dimensional form, round an edge, add a hole and then repeat that feature elsewhere.

Each step can depend on something that came before it.

CAD users commonly describe this collection of operations and their relationships as a history tree.

Think of it as a recipe. The computer remembers not just the finished cake, but how you made it.

History-based parametric modelling can be extremely powerful because dimensions and relationships can be used to make later changes predictable. But the relationships also create dependencies: changing one modelling decision can affect many later operations.

The result can be wonderfully intelligent.

It can also become wonderfully complicated.

When does history become a needle in a haystack?

Anyone who has spent enough time with a large history-based model will recognise the moment.

You need to change something that looks extremely simple.

You start looking for the modelling step that created it.

Then you discover that step depends on something earlier. That earlier operation depends on another one.

And suddenly the innocent little boss you wanted to move has acquired a family tree worthy of a medieval dynasty.

Sometimes that structure is exactly what you need.

Sometimes it isn't.

Research into parametric computer-aided design has examined how modelling strategies affect design reusability and how relationships between features influence later modification. The practical lesson is familiar to experienced modellers: the way a model is constructed can determine how easy it is to change later.

The history may not have malfunctioned. It may simply have followed its instructions.

The problem is that the designer's mental model and the software's dependency model can drift apart.

And then you have a choice.

Find the historical cause.

Or fix the geometry.

That sounds trivial.

It isn't.

Was the history tree originally about design intent?

Perhaps not entirely.

This is where the history of computing becomes particularly interesting.

A documented CAD updating method describes an approach used by some systems in the early 1980s in which the computer could replay all of the modelling operations rather than storing all of the intermediate results.

The reason was brutally practical:

Replay the history, save the memory.

The trade-off was computation. Replaying the whole history after a change meant rebuilding the model from the sequence of operations, so the time required could depend on the overall complexity of the part rather than simply on the size of the change.^[2]

That is a very different story from the polished modern description of a history tree as an elegant representation of design intent.

It was elegant.

But it was also a practical response to the machines available at the time.

Think of it as remembering the recipe rather than keeping every stage of the cake in the fridge.

And something rather clever happened.

The sequence of operations was not only useful for rebuilding the shape. It also contained information about how the designer had constructed it.

As modelling systems became more sophisticated, that procedural history could become editable, associative and increasingly rich in dimensions, relationships and features.

Something that could begin as a computationally economical way of reconstructing a model could therefore become something much more ambitious:

a representation of design intent.

That was a genuine technological achievement.

But it leaves us with a fascinating question.

Would we build CAD this way if we started again today?

It would be tempting to tell a neat story:

“Computers were too weak for direct modelling, so engineers invented history-based modelling.”

The evidence does not justify something quite that simple.

Solid modelling itself developed through different approaches. Modern academic accounts commonly describe the major progression as solid modelling in the 1970s, parametric modelling in the late 1980s and direct modelling as a later commercial paradigm. Constructive Solid Geometry and boundary representation were already established approaches within early solid modelling.^[3]

So the more defensible — and more interesting — conclusion is this:

CAD architecture evolved in a particular technological environment, and that environment influenced what was practical, what was valuable and what designers learned to expect.

Then the technology improved.

The architecture remained.

Eventually, a solution to a particular set of problems can start to look like the natural way computers ought to work.

So what does Rhino do differently?

Rhino takes a more direct approach to working with the shape of an object.

Rather than requiring every change to pass through a long chain of dependent modelling steps, you can often work directly on the geometry in front of you.

This is generally called direct modelling.

That does not mean Rhino has no History.

It does.

McNeel's current documentation describes Rhino History as storing the connection between a command's input geometry and its result so that changes to the input can update the result. Crucially, McNeel recommends leaving the general Record setting at No and selectively recording History when it is useful, noting that recording History uses computer resources and makes saved files larger.^[4]

That is a surprisingly revealing design philosophy.

In Rhino, History is a tool. It is not the architecture of the model.

If you need a particular relationship to persist, use it.

If you do not, Rhino does not insist on carrying that relationship around with the geometry.

And Rhino's own training material is explicit that History is not the same thing as a feature or parametric modelling system.^[5]

Where does Rhino really win?

Rhino's great strength is freedom to work directly with complex geometry.

That matters when the form itself is the problem you are trying to solve.

You may not know what the final design will be when you start.

You may want to explore several radically different solutions.

You may decide that your original modelling approach was simply wrong.

In those situations, being able to work directly with the shape can be liberating.

You can ask:

“What should this be?”

rather than:

“Which earlier modelling operation should I change to make it become that?”

Sometimes that distinction saves an enormous amount of time.

Does Rhino's freedom sometimes become a disadvantage?

Absolutely.

If a relationship is important, you need to preserve it deliberately.

If a dimension must always remain fixed, you need to model accordingly.

If another designer will inherit the file, you need to make your intentions understandable.

Direct modelling does not eliminate design intent.

It simply does not automatically encode all of it for you.

That is the trade-off.

A history-driven system can make future engineering changes wonderfully predictable.

Rhino can make exploration and geometric intervention wonderfully uncomplicated.

Neither wins every contest.

And that is precisely the point.

What happens when the rules themselves become the design?

This is where Grasshopper enters the story.

Grasshopper is a visual environment within Rhino for creating rules and relationships that can generate or control geometry.

It can be extraordinarily powerful for repeated structures, complex patterns, generative forms, optimisation and computational geometry.

But there is a trap.

You can spend an impressive amount of time building a wonderfully clever system to automate something that would have taken five minutes to model directly.

Sometimes the smartest parametric model is the one you do not build.

Why might the best CAD toolkit contain several different systems?

This is where the argument gets bigger than Rhino.

The modern design workflow does not have to be:

Choose one CAD system and use it for everything.

It can instead be:

Choose the best tool for each part of the problem, then make the tools cooperate.

A designer might use a history-based solid modeller for mechanically critical components.

Rhino for complex curves and surfaces.

Grasshopper for generative work.

A specialist application for rendering.

Another for simulation.

Another for manufacturing.

This is not necessarily a failure to find the mythical application that does everything.

It may simply reflect the fact that different problems benefit from different ways of thinking.

What does a lifetime in CAD teach you about technological certainty?

I have been working with computer-aided design since 1983.

That gives me the dubious privilege of having watched several generations of CAD orthodoxy arrive, become fashionable and occasionally become inconvenient.

My introduction to computers was not particularly auspicious.

Company directors asked me, as a designer, why we were not using computers.

I laughed at them.

Worse, I persuaded them not to take that revolutionary step.

I was wrong.

I had made a judgement about a technology I had not bothered to understand.

I then watched the company go bust.

It was a remarkably effective education in the danger of certainty.

Years later, after selling my AutoCAD reseller business, I found myself looking at a very different part of the industry. Bob McNeel suggested that I talk to CoCreate because they were doing something interesting.

They were.

I subsequently worked with SolidDesigner 6 in Germany, at a time when the industry was wrestling with the transition from workstation-based CAD towards the Windows desktop.

By 1998, SolidDesigner 6 supported Windows NT as well as HP-UX and SGI IRIX.^[6]

I then returned to England and organised SolidModelling '99. I have continued working with Rhino from its early years.

I mention this only because it gives me a useful perspective on the question at the heart of this article:

Which parts of CAD are genuinely fundamental, and which parts are simply the way we learned to do things?

Where should the design intent live?

Perhaps this is the simplest way to understand the whole argument.

A history-based modeller asks:

“How should this design behave when it changes?”

Direct modelling asks:

“What should the geometry be?”

A generative system asks:

“What relationships and rules should generate the geometry?”

All three are legitimate questions.

The skill is knowing which question you are actually trying to answer.

And perhaps that is the mistake we make when we ask which CAD system is best.

We are asking the wrong question.

The better question is:

What are we trying to design, and where should the intelligence that describes it live?

Sometimes the answer is a history.

Sometimes it is the geometry itself.

Sometimes it is a set of rules.

And increasingly, it may be several different applications working together.

Can the best CAD workflow be knowing when to leave CAD alone?

This sounds heretical until you think about what we are actually trying to achieve.

The purpose of design software is not to make us admire the software.

It is to help us solve a design problem.

Sometimes the right answer is a carefully constrained engineering model.

Sometimes it is a freely developed surface.

Sometimes it is a set of rules generating geometry.

Sometimes it is a high-quality renderer.

Sometimes it is another specialist application entirely.

And occasionally the answer is to stop trying to make one application behave like another.

The best workflow may simply be the one that gets the job done with the least unnecessary resistance.

Stop Looking for the Perfect CAD System

The perfect CAD system may be a myth.

Not because today's software is not remarkably capable. It is.

But because design itself is not one problem.

Mechanical relationships, free-form surfaces, generative systems, simulation, rendering and manufacturing all ask different questions.

Why insist that one application should answer them all?

The best designer is not necessarily the person who knows one system inside out.

It may be the person who knows which system not to use for a particular problem.

And sometimes, after twenty minutes searching through a history for the modelling step responsible for the tiny boss you wanted to move, you discover that changing it will destroy half the model.

At which point there is a perfectly respectable engineering solution:

Delete the bloody thing and remodel it.

There is no shame in that.

Your computer will not judge you.

And if it does, do not tell the grandchildren.