The title sounds a bit ridiculous, doesn’t it? What does a technical trade like software development have to say about product design, a practice more akin to art than array manipulation?
As it happens, a lot.
So in the interest of a long overdue cross-pollination, we’ll look at three areas of mutual importance: agile workflows, workspace management, and modularization.
Agile Workflows
The standard definition of perennial buzzword ‘agile’ is apt: ‘a practice involving discovering requirements and developing solutions through the collaborative effort of a cross-functional team and their target users’.
Agile, as seen in the business world
Perhaps the most closely held belief in agile is ‘say no to cascade development’ - that is, development of a product from A to Z in one huge, drawn-out effort. Rightfully so. Whether it’s creating a new application or a printable part, this is a surefire way to get an unsatisfactory result. If we had to bet on the sun rising tomorrow or technical limitations affecting emergent user needs, we would choose the latter.
The opposite of cascade development is a continual, evolutionary release cycle. So, concretely, if you’re designing a fidget spinner, determine through repeated trials the smallest ball bearing you can print. Then determine how closely they can be packed. This creates clear constraints for a housing, which likewise should be prototyped until functional. And so on.
An agile mindset might mean you iterate for a full day on ball bearing diameter before moving on. A cascade mindset might mean running three days of diagnostics on a beautiful fidget spinner that doesn’t spin, then starting all over again - if diameter clearance is ever uncovered as the root cause.
We find that the best way to keep track of iteration in print testing is, yes, Github - software development’s weapon of choice for storing, annotating, and reviewing code.
Sure, Github is overkill for a repository called ‘Fidget Spinner’ that has the text files ‘v1’, ‘v2’, and ‘v2.1’. But it’s hard to argue with free, cloud-based, and extensible.
What the file ‘v2’ might look like
User testing is another takeaway from agile. Unfortunately, we all have a cognitive bias toward a dangerous assumption: that our way of using something is universal. But an action as simple as putting on a watch is done a dozen different ways - and thus has (at minimum) as many functional requirements.
User testing corrects for this bias. Indeed, after years in the business, we’re still surprised by the disparity between intended and actual use.
Apparent simplicity means nothing; even a square can have corners that are too sharp.
Without due precaution, a boot might end up on someone’s head
Another agile technique is the retrospective, a kind of ‘after-action review’ where you record the things you’ve learned over the build process.
Though your decision to modify slicer settings to ‘coast 1.5 mm’ may seem obvious now, the motivation will be less clear in half a year. Will you remember to begin designing your next part with a specific print bed orientation in mind? Jotting it down is the only way to be sure.
Workspace Management
Your CAD workspace is more ‘factory floor’ than ‘lathe’. And as on a factory floor, you want your equipment in the right place with the proper tooling.
In CAD, that means taking full advantage of layering capabilities. Each part iteration can be given its own layer, which in turn has layers for things like lines, solids, functional elements, etc.
Pro-tip: keep things clean - and backtrackable - by creating a separate folder for each iteration’s garbage
More important yet is a custom workspace template. We recommend something like this:
It features three branches. The first is Raw Geometry, containing the ‘bones’ of the part. The second is Ideal Form, which adds complexity (e.g. fillets and ornament) to the first. (When your detailing goes awry, it’s nice to backtrack to the raw geometry, not rebuild it.) The contents of Ideal Form lend themselves to renders and client presentations.
The third branch is reserved for printable geometry - things that can be meshed into an STL file. This is the place to add custom supports, beef up walls that are too thin, adjust overhangs, etc. While branch two should look best on screen, branch three should look best in printed form.
Confining geometry to labeled squares (as pictured above) makes part identification simple. Well-chosen square sizing - say, multiples of 100 mm - allows you to move geometry back and forth between branches without a thought to alignment. And text notes alongside key pieces are the same as documentation in code: awesome.
In the end, it’s not the workspace structure per se that matters so much as its long-term legibility to you. As is said in the Zen of Python, Readability Counts. While this kind of ‘admin overhead’ might take 5% more effort, it’s worth every second as soon as revision is needed. And it will be.
Finally, maintain a consistent foldering structure for each project. That means putting STLs, CAD files, notes, slicer settings, and all other project assets (hopefully including photos of the finished product) in a predictable place.
Every project gives you the opportunity to tweak foldering, streamline geometry placement, and ultimately use less effort to get better results.
Modularization
Break CAD parts up into their smallest functional units. Yes, there will be interdependencies - say, an aperture depends on the size of the objects passing through it. But merging and consolidation is best done over known entities rather than unknown variables.
Another reason to spend a few extra minutes on creation of functional units is reusability. Things like springs, hinges, ornamental motifs - whatever the signatures of your design language - are often preserved across projects.
Such modules are a gift that keeps on giving.
Many other software development best practices carry over to design for 3D printing: say, ‘anticipation of change’ and ‘consistency’. Although in other areas, as you might expect, the analogy breaks down. Separation of concerns, for instance, while great for programming, is a recipe for CAD spaghetti.
In sum, however artful or engineery your next project may be, we believe these principles will serve you well. Give them a try - you may find yourself with a better part than you expected before you expected it.
Happy CADing!
Comments