Does Clean CAD Matter in FRC?

Inspired by a lovely thread currently occurring here, another question. I’d invite anyone interested in participating to give that thread a read-through.

A few things to consider:

  • Does whether clean CAD matters depend on the team?
  • If so, at what point does clean CAD start to matter?
  • How does the reuse (or lack of reuse) of CAD files affect the importance of clean CAD?

Will it automatically enable you to design top-level robots? No. Will it make designing and iterating top-level robots easier? Yes.

Since cleaning up my cad practices, I’ve found it much easier to iterate on and improve my designs, as it requires significantly less effort to do simple tasks.


For practical purposes, I’d argue that “clean CAD” has marginal benefits for FRC teams as it relates to the on-field performance of the robot.

Clean CAD =/= successful robot.

The real benefit of “clean CAD” within FRC is the educational benefit for the participants. Promoting best practices in designers early on carries forward in their careers in my experience. Having well established design processes also helps improve on boarding of new designers. This can help lower the barrier to entry for students to contribute to the robot CAD. So over time, I believe having a clean CAD with a well documented design process will lead to improved on field performance.

  1. I think that clean cad matters most in the prototyping and early design stage where your still not sure what your dimensions look like and thus might need to make rapid iterations. during that stage it really helps if your features don’t break every time you move your bottom intake roller down by .1".
  2. I think it matters at every level but different skill levels might have different definitions of clean. but generally the easier the cad and/or master sketch is easy to understand the “better” that cad is. That may or may not also carry into making your design simple and easy to follow which is something I value but w/e.
  3. Things that get re-used often are the most important to get right because often times it’s not just a matter of how easy a thing is to change but there can also be a substantial difference in performance between good cad and spaghetti cad.

For SOLIDWORKS specifically, cleaner CAD means fewer crashes, and less lost work as a result.


Absolutely, “dirty” cad can lead to broken assemblies which can be very frustrating to work with.
There are obviously some clean practices that can be skipped and some dirty practices that can be allowed. It is going to depend on how much your team relies on the CAD, how many people are working on the model, what program you are using to CAD. So as with most things in FRC, you are going to have to figure out what works best for your team. But in general, yes, clean cad matters.


I agree, there are a few principles of “clean CAD” that I consider essential, not because they directly improve the quality of the robot that ends up on the field, but because they improve the quality of life of your CADders. Editing parts whose sketches aren’t fully defined (for example) is miserable, and will take ten times as long to get right, especially for a less-experienced CADder who doesn’t look at it and immediately see the problem. Or will cause an unintended change you don’t notice until after the part is made & discover it doesn’t fit.

When I became a mentor for my current team they had only been doing CAD for a year or two and had a lot of bad habits & lack of best practices, and as a result spent a very large amount of time beating their heads against the wall. The “clean CAD” rules I introduced were all chosen to solve specific problems I saw them having, not an abstract sense that clean CAD is good (“if you had followed Clean CAD Rule #3 yesterday, your assembly wouldn’t have gotten completely screwed up when you edited that part”) and have made a big difference. I can think of more things we could do to make it even cleaner, but I don’t think they would be worth the additional time investment.


I think that there is a point where there is “too clean of a CAD.”

Clean CAD is about maximizing efficiency, so once it gets to the point where the more time spent “cleaning” doesn’t result in more time saved, then it is not worth it. i.e. Law of diminishing returns.

Also, there are lots of things you can do that will save time, but won’t necessarily result in a cleaner CAD like setting up hotkeys.


My $0.02

It depends on what you use CAD for. Almost our entire robot is cut on the router, so we need a clean, up to date CAD.

Our first two years, however, were not super dependent on machines, so we had a good CAD model but nothing super accurate. Basically, just enough for us to make things and get a good concept of what we need to make

Likewise, the stuff that is not cut on the router has less attention to detail in the cad.

There are diminishing returns. I’d rather spend more time prototyping and practicing than more time CADing, neither of which we do super well yet

1 Like

Dirty CAD (like code) can be done dirt cheap.

Whether your team needs clean CAD really depends on what you are building. Our product is students. Robots are just part of our factory equipment.

1 Like

I don’t like the implication that if your priority is building up your students there’s no reason to care about the CAD. Why bother teaching them to do anything well if that’s the case? Holding students to a high standard, showing them they are capable of doing high-quality work, and teaching them ways to make their workflow fun instead of miserable are all important aspects of building up empowered students, and that’s why I care (up to a point) about clean CAD.


Actually, since we are building students we should care MORE about clean CAD, not less. That’s what I meant to imply.


Thanks for clarifying! That makes way more sense :slight_smile:

1 Like

To share a code-related story (but one which is perfectly analogous to OP’s question):

This summer, I got lucky that for a number of meetings, we had a nice 1:1:1 ratio of mentor, student, and robot. I got to work with that student to teach programming fundamentals in context.

For autonomous - we started with a design pattern that was really really easy to write for simple “drive-forward, turn-left, drive-forward” sequences. This meant it was really easy to understand what the robot was doing, and to wrap your mind around the core concepts of what autonomous code needed to do. It also meant it was easy to get that “huzzah! success!” good feeling.

But the design pattern was purposefully flawed - it was painful to scale up. I was then able to introduce a more rigorous object oriented approach, which was fairly straightforward to teach: We already knew the basics of how to code, what the autonomous code needed to do functionality-wise… the only “new” thing was the code architecture and organization.

I’m hoping to continue the exercise with a lot of the other libraries and architectures that our team and WPI have put out.

Hopefully it will go well - this season will tell.

Overall, the goal though is to slowly introduce the need for “cleanliness” as a solution to obvious pain that students are feeling. Without having them first feel the pain of not being clean, it’s hard to really motivate the need for keeping things clean.

Which gets to the point that a lot of us are indeed circling around:

IE: Have just enough process to keep it fun. That’s gonna look different depending on the size of your team, the collective time/resources/perfectionism in the team, etc.

1 Like

I don’t think any team I’ve been on has had what most people would call clean CAD at the end of a build season. You need enough CAD to build the robot and be able to iterate on the robot. If you use a waterjet to run your machine that means you probably need a way to make DXFs. If you use a router, you need a way to generate G code. If you use a chopsaw and drill press you can get away with even less. 67 literally had the entire robot drawn in 2 or 3 large DWG files and just copied chunks of those out to DXFs to get manufactured.

Encouraging good practices to make CAD stable and frozen (dimensions of a part won’t change after you’ve built it because it’s constrained / defined properly) is necessary, being able to identify what a part is is necessary (doesn’t necessarily mean you have to use part numbers, just avoid naming your parts ‘cool thing Mike designed.sldprt’), but do you need the perfect labelled and sorted feature tree - I don’t think so. What we get away with in FRC would never fly in industry.


Below is my own subjective assessment (ranking 1-10) of the team’s I’ve been on, in terms of how good the CAD was and how good the robots were.

I do think there’s some impact to having clean CAD (with there being a ceiling where adding CAD sophistication doesn’t create value add and a floor where having CAD at all is just taking resources that would be better spent elsewhere). This is pretty high up on the hierarchy of needs chart. For example, for every robot 8 and above below, I don’t think we could have accomplished them without at least average quality FRC CAD. For the others, we could have skipped it and I think the robots would have had similar or better performance.


As the original poster of the thread “What does clean CAD mean to you”, here’s why it matters.

The Tale of Two Brothers
Let’s start by observing what’s happening when you CAD. One creates small parts to represent a portion of the design. These parts are then assembled into assemblies, and those assemblies can be made into larger assemblies.

This methodology is the same as what is used to develop software. Problems are decomposed into simpler problems. These simple problems are solved, then composed into larger solutions. Thus, the creation of code and CAD are very similar.

We can go further than just similar. CAD is a subset of programming. The construction is the same.

Why Clean Code Matters
If one can conclude that code and CAD and the same (or at least extremely similar), it follows that considering whether clean code matters could inform our thinking about CAD.

Consider a few excerpts from Robert C. Martin’s 2009 book, Clean Code.

Bad Code
"Have you ever been significantly impeded by bad code? If you are a programmer of any experience then you’ve felt this impediment many times. Indeed, we have a name for it. We call it wading. We wade through bad code. We slog through a morass of tangled brambles and hidden pitfalls. We struggle to find our way, hoping for some hint, some clue, of what is going on; but all we see is more and more senseless code.

Of course you have been impeded by bad code. So then - why did you write it?

Were you trying to go fast? Were you in a rush? Probably so. Perhaps you felt that you didn’t have time to do a good job; that your boss would be angry with you if you took the time to clean your code. Perhaps you were just tired of working on this program and wanted it to be over. Or maybe you looked at the backlog of other stuff that you had promised to get done and realized that you needed to slam this module together so you could move on to the next. We’ve all done it.

We’re all looked at the mess we’ve just made and then have chosen to leave it for another day. We’ve all felt the relief of seeing our messy program work and deciding that a working mess is better than nothing. We’ve all said we’d go back and clean it up later. Of course, in those days we didn’t know LeBlanc’s law: Later equals never.
(p. 3 - 4)

“Have you ever waded through a mess so grave that it took weeks to do what should have taken hours? Have you seen what should have been a one-line change, made instead in hundreds of different modules? These symptoms are all too common.
What does this happen to code? Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that requirements change in ways that thwarted the original design. We bemoan the schedules that were too tight to do things right…but the fault, dear Dilbert, is not in our stars, but ourselves. We are unprofessional.”
(p. 5)

Primal Conundrum
“Coders face a conundrum of basic values. All developers with more than a few years of experience know that previous messes slow them down. And yet developers feel the pressure to make messes in order to meet deadlines. In short, they don’t take the time to go fast!
True professionals know that the second part of the conundrum is wrong. You will not meet the deadline by making the mess. Indeed, the mess will slow you down instantly and will force you to miss the deadline. The only way to make the deadline-the only way to go fast-is to keep the code as clean as possible at all times.”
(p. 6)

Notice that Martin points out that a mess begets a mess. Poor code leads to increased development time, and increased development time leads to the feeling that one needs to write poor code to catch up. This leads to an endless cycle of writing poor code. This cycle is referred to as code rot.

CAD is the same way. If we refuse to be disciplined in writing clean CAD, the mess of the system will lead to increased development time in the future. Learning the art of Clean CAD is critical. But what does it mean to be able to write clean CAD?

Again, let’s see what Martin has to say about writing clean code, and see if it makes sense in terms of CAD.

The Art of Clean Code?
The bad news is that writing clean code is a lot like painting a picture. Most of us know when a picture is painted well or badly. But being able to recognize good art from bad does not mean that we know how to paint. So too being able to recognize clean code from dirty code does no mean we know how to write clean code!

Writing clean code requires the disciplined use of a myriad of little techniques applied through a painstakingly acquired sense of “cleanliness”. This “code-sense” is the key. Some of us are born with it. Some of us have to fight to acquire it. Not only does it let us see whether code is good or bad, but it shows us the strategy for applying our discipline to transform bad code into clean code.

A programmer without “code-sense” can look at a messy module and recognize the mess but will have no idea what to do about it. A programmer with “code-sense” will look at a messy module and see options and variations. The “code-sense” will help that programmer choose the best variation and guide him or her to plot a sequence of behavior preserving transformations to get from here to there.

In short, a programmer who writes clean code is an artist who can take a blank screen through a series of transformations until it is an elegantly coded system.
(p. 6 - 7)

Everything above translates directly to CAD. In some instances, it almost appears to be writing for CAD instead of coding. Cleaning CAD is a skill that is developed and taught.

The above passage may prompt some concern. Martin’s use of the phrase “painstakingly acquired sense of cleanliness” may alarm some. This philosophy seems like a lot of work for a CAD document that will stick around for one year, then never be used again. Is it worth the time?

More than just a Build Season
In 2005, a white paper by FRC 1114, Strategic Design, prompted the rise of a new mindset; It’s really important to have good processes and methods to approach each season (Corsetto, 2020). Clean CAD is one of these good processes. To get good, you must practice. One is not purely CADing for the season, but rather CADing in preparation for the season.

Furthermore, any prototype made in CAD may want to be referenced for the future. Clean CAD this prototype to stay relevant in the future. CAD models of commonly used parts can also be pre-imported and constrained so they can be easily referenced in the future.

These cases show that CAD outlives the season, and might very well outlive our time on the team. If kept clean, it can be used in the future. If not, it rots like a 2-year-old bologna sandwich. It is our responsibility to set up the future team for as much success as possible.

Optimize for Change
It should be noted that Clean CAD doesn’t guarantee you a good robot. Some very strong teams don’t have Clean CAD. However, what it does guarantee you is “Optimizing for change”. By setting up CAD in an orderly way, it can be quickly adapted and understood by others. Optimizing for change is critical for one of the hardest and most sought-after parts of FRC, growth.

When views like code, it is clear that Clean CAD is essential for development. CAD lives longer than the moment it was created, but only if cared for and not allowed to rot. Learning the art of Clean CAD is critical to the growth of the team. Thus, Clean CAD does matter in FRC.

Corsetto, Mike. [@Michael_Corsetto ] (2020, April). Goal Setting with Mike Corsetto from 1678 - RSN Spring Conferences Presented by WPI [Video]. Youtube.
Martin, Robert C., (2009). Clean Code. Pearson Education.

@Karthik I mention the 2005 paper Strategic Design within this post. Do you happen to know a link to it or the most recent iteration?


I design in the opposite direction, but I agree with your general points.

1 Like

Okay, it’s absolutely wild to me that it’s been 17 years (the original version came out in the fall of 2004) since I put that paper/presentation together. I’ve attached the most recent version. Also here’s a link to the best videos of the presentation.

Part 1:

Part 2:

Effective FIRST Strategies - September 2020.pdf (6.2 MB)


The truth never goes out of style.