Archive

Archive for the ‘product development’ Category

CAD and Design

April 26th, 2013 15 comments

There is a ring of discussions going on. One blogger commented on another, and some left comments on LinkedIn, and now I’m adding to the loop.

The arguments all seem to be made by people who aren’t directly involved in the process. Not sure I want to go to the length to call them all desk jockeys (or more famously typewriter jockeys) again, but you get the idea. The arguments all seem to be too close to one point of view to be able to see the whole thing, or too far from getting dirt on their mouse to understand the details.

Here’s the thing. CAD and Design overlap, and have some things in common, and some things that aren’t in common. Drafting is a quaint idea that I don’t really relate to. I’m not sure what relevance it has in today’s processes.

Product development is a process that starts with an idea, and that idea usually fills some need. The quality of the idea depends on the quality of the need. If the need is just to make more money, the idea usually turns out to be shallow and not very convincing. If the need is some way to better input data into a computer – then you’ve got a better chance. This, by the way, is why I think business types will always be shackled to needing to have real problem solvers  around them.

The idea leads to identifying a need, which leads to identifying a solution. To make the solution “real”, or more than just an idea, you have to plan. “Product development” in my eyes usually starts with this idea of a solution. Inventors are tasked with forming the idea of the solution. But inventors always need help going to the next step. The next step requires the task of “design”. The design, then needs to be documented so it can be understood by others. And then the documented design needs to be manufactured.

needinvention
design
analysis/engineering/prediction
documentation
manufacture

In my experience, these phases each overlap to varying extents. And they might even be iterative, where prototyping is actually a manufacturing phase, but it’s followed by iterations of the design or even the invention. Documentation is just the CAD work. It helps you communicate the idea. My day to day work involves tasks along the continuum from invention to documentation. Some days I design. Some days I just document the design. I even go back to the beginning to help solve the original need.

One of the arguments on one of the sites said something like “CAD happens too early”. I don’t believe this at all. It’s probably someone who can’t do CAD who is saying that. CAD happens as early as it needs to, because it can be used in a number of different ways. It can be used as a 3D napkin sketch. It can be used to convey concepts. It can be used for quantitative analysis. It can be used to help visualize. It can be used to prototype or manufacture. To say CAD happens too early is to misunderstand the process, and the role technology can play in it.

There seemed to be another argument against ease-of-use for CAD. My job is not threatened if an accountant can make a stack of blocks in 3D software. Or if a high school dropout can render mighty dragons in 3ds Max. It takes more than either of those to make real products.

My job, as a professional CAD jockey is to be able to translate between the language of design and the language of manufacturing. My CAD data has to be able to take into account everything that went before, and render it in a format that allows the manufacturing process to do what it does. This is not something you learn in college, or 2 nights a week in trade school. This is something you learn by osmosis working between people with the various skills you need. You have to work with a mold builder and probably make some stupid mistakes to learn what it takes to mold a plastic part with specific characteristics. You have to work with plastics designers to understand how, why and when to use a living hinge or a snap fit or vibratory weld or heat stake.

A professional CAD jockey isn’t just a guy who makes pretty pictures, and he doesn’t need to be a manufacturing expert. But he does need to know when he needs to ask questions. He might not even be an award winning designer, but he has to be able to understand design enough to make compromise decisions between design and manufacturing, as must always happen.

Maybe my type doesn’t exist that much. I’m a degreed mechanical engineer who does mostly CAD work. Many engineers might consider detailed CAD to be beneath them, but I like to think that I bring more than just drawing lines to CAD. I bring an understanding of the complete process. I can design, engineer, and I know what it takes to manufacture. The CAD work is just translating between those two worlds in a visual language backed up by math driven geometry. I know there are others out there who do the same thing as I do. If you “only” run CAD, and don’t understand the processes that happen before and after, you’d better work at a company that takes care of the rest of it for a while to learn the ropes. I’m not sure if there’s any such thing as a “freelance CAD operator”. You’ve got to bring more to the table than that.

Categories: design, product development Tags:

Critical Review in Product Development

February 11th, 2012 7 comments

Through a comedy of errors in 2008, SW PR offered to let me interview Paul Chastell,  at that time the director of SolidWorks software development. I wanted to talk to someone who could talk candidly, using English that users could understand. I didn’t want canned answers out of the SolidWorks playbook. But it was all I was getting, so I sent him my questions. Now Paul is not a bad guy, but he was definitely in the wrong place at the wrong time, as far as the interview went. I actually feel badly about the way I handled this situation with Paul, which is something I’ve never owned up to in writing. For what it’s worth, 4 years late, I’m sorry for what happened.

The resulting article is still on my blog, called Inadvertent Straight Talk.  This is the kind of thing that should have gotten lost in one of the two blog meltdowns I’ve had since it was written. It’s not worth reading it, but I include the link mainly for reference.

I was trying to write about the role of a Devil’s Advocate in product development for the critical review of ideas. I believe that in order to distill the best idea from any initial idea, you have to have real debate, point and counterpoint. You have to see an issue from multiple points of view. In physical exercise, you don’t improve without some resistance, and I believe the same about developing ideas. Business doesn’t seem to recognize this. So much of business leadership is pathologically focused on the “non-negative”  that ideas get through the system which have not been properly vetted based entirely on enthusiasm. Enthusiasm is a great thing, but it’s not the only thing.

To me, this was the problem with the changes in SolidWorks 2008. The changes were based on a lot of good or even great ideas that had not been thought through. The ideas solved the problem as stated – “interface needs consolidation”. It’s just that no one thought to consider what problems the new solutions might cause. In the end, it took two full releases to fix 2008. This is why I always cringe when SolidWorks implements a customer idea – too often there is a huge caveat that makes it unusable.

Folks at SolidWorks and certain fanboys didn’t understand why I was so opposed to some of the changes. “We did all this customer research” was the common response to any doubts. One huge sign of trouble is when a person or a group doesn’t allow any doubt. It usually means the idea is untested.  It’s that same unassailable belief in fantasy that most people find so annoying in door-to-door vacuum cleaner salesmen.

Anyway, the customer research. SolidWorks can find support among customers for just about anything. What I’ve learned from the SolidWorks Top 10 exercise every year is that users themselves are the source for a whole lot of really bad ideas. There were several ideas in the Top 10 voting this year that had negative tallies. SolidWorks seems to keep track of people “interested” in a particular idea, and then they contact them during the project  for some sort of validation. Two things here. “Interested” to SolidWorks means they support the idea, not that they have experience, an opinion, a real need, or whatever. So the deck is stacked against critical review from the beginning. Second, “validation” is exactly what they are looking for. They are not looking for “negation”. If SolidWorks is talking to users, it is my experience that it is already too late. The idea is already framed, and they are just looking for support. So you often get a one-eyed view of any given issue.

Then there’s this word – grinfuck – which you can read about from Suster, Feld, urban dictionary, and here and there. It means that someone is just telling you what you want to hear, without being honest. Some people call it “being polite”, although I never thought that lying through your teeth was polite. It happens all the time in business, and in personal life. It might even be more common than telling the truth.

There are ways of asking questions in which you form the answer in the hearer’s mind. So it’s possible that SolidWorks is habitually asking to be grinfucked. A lot of people will also just be very polite out of habit, even if that means handing you a major load of bullshit. Other people just like the attention, so if you buy them lunch, or give them special access, they will tell you anything you want to hear, so long as it prolongs the relationship. Just to say that there are a lot of ways to collect bad information using the methods SolidWorks uses, without the expectation of critical review.

You could consider what Paul Chastell did to me as this sort of corporate sanctioned jive. I asked questions, and he replied with playbook pleasantries that didn’t have any real meaning – stuff that is designed for “the press”, not for end user blogs.  But on the other end, software users also grinfuck product definition people by just basking in that glow of being behind the scenes, saying “Yeah! That’ll be GREAT!!” with great enthusiasm. So it happens all the time on both sides.

Over the years, the development of the SolidWorks software has become more and more driven by internal corporate politics (which is corporate jive for “egos”), and the customers just provide justification. Four years ago, when I wrote that misguided blog post on “Inadvertent Straight Talk”, I was really appealing to SolidWorks to filter their ideas through more critical thinking. The ideas that come out the other side will be much stronger, with a broader appeal and usefulness. This concept applies to all stripes of product development. If you can some how coax users to be less “polite”, and more honest, you’ll develop a better product. Read the Mark Suster article for more on that.

Why does this come up now?  SolidWorks World is a place and time to meet SolidWorks employees. They will be looking for validation. If you start talking to someone, tell them what you really think. If you’re in a situation where you have to sacrifice politeness or honesty, always be honest. If there’s something you value, say so. If something doesn’t look like a good idea, let them know. Don’t just smile and say “Yeah! That’ll be GREAT!!” if you don’t really mean it.

Categories: product development, rant Tags:

Concept to Production: Edit, Reuse or Rebuild?

April 7th, 2010 Comments off

Mark Biasotti asked an interesting question over on the SW forums,

how can we  make SW better at reusing or carrying forward concept and prototype work to the final design.

This is another bit of advice you can give SW here if you haven’t already done so on the SW forum. Chime in in the comments and let your voice be heard.

Here’s my bit:

I hope that SolidWorks is not trying to develop a process for moving from concept to final model. SolidWorks is not really good at developing processes. I think they need to stay with developing tools and allow users to figure out how to fit the tool into the process.

In fact, I wish SW could just try to remember that they do build a tool, not some decorative gewgaw or fashion kit that changes with the blowing winds of trend. A suite of tools that needs to accomplish actual engineering tasks. Users should be able to string the tasks together to create their own workflows.

I think to do all of this, the single tool that needs to be most improved is the FeatureManager, this is the tool that presents the feature data to the user.

I receive data from a wide range of sources, and these sources all have different purposes for their concept models. Some are hacked imported data, some are simple representations of what will hopefully be a more complex developed model. Some are attempts (good or bad) at making a complex shape which I need to develop further. Sometimes I have to work from my own concept models, which might be something quick I put together for display only.

These range everywhere from yeah, I can use it with some tweaks to it just being easier to start from scratch. So we might as well talk about both ends of the range, since I think you’re going to need to accommodate both ends. I don’t believe there is a simple single answer to your question.

To be able to work with existing data, the biggest impediment right now with the software is the visualization and capabilities of dealing with consumed parents. Plus, several entities are dealt with different from the rest. Curves for example, are probably the most problematic, since they cannot be reused or shared between features, and once used by one feature cannot be referenced even by another sketch. There are several other problems with curves, though, which includes the poor accuracy of the curve compared to sketches, faces and edges. They really need to be on par with the rest of the entities in the software in order to work on the same data. And please don’t take that to mean that the rest of it needs to be more sloppy.

We also need the ability to show the FM as a single straight history based list of features, without stuff reordered or indented, and the ability to manipulate feature order in this state. The current Parent/Child window is woefully inadequate. It needs to encompass the entire model, not just the current feature. We need the ability to show which features do not have children, which don’t have parents, which don’t make any faces that show up in the model as currently displayed, and a Solid Map like “family tree” representation of the relationships between features in the tree.

I would really like to be able to reorder back and forth across the rollback bar, and also to suspend recalculation until you are done with multiple reorders and rollbacks. I’d like the ability to show multiple panels of the tree (stacked side by side), especially for long trees, so you can see all of the features.

Further, when recreating models that can’t simply be repaired, Solidworks needs the ability to copy sketches from part to part. Sketches, features, and groups of features and sketches complete with parents as necessary. When sketches copy, they should ALWAYS copy to the same relative position relative to the part/sketch origin, instead of using cursor position for some types of copy. Deleting parent featues (for example a plane or a feature that another feature is sketched on) should not delete the dependent feature. There are times now when that happens with no explanation, such as hole wizard revolved profile sketch planes.

You guys like automatic stuff, so how about something that will automatically reorder other features while you’re editing another feature. For example, I want a sketch to reference an edge, but that edge is consumed by a fillet. It would be nice to be able to move the fillet before the sketch (while the sketch is open) and continue on your merry way.

In order to make SW better at editing models, well, I think that’s going to be a lot of hard work that would mostly involve – and this is going to sound sarcastic, because it is – going back and fixing the software to work the way it was originally meant to without all of these silly and lame limitations that we have accumulated over the years. SolidWorks has so much unfulfilled promise. I really think the software needs to go back to having a single vision that drives the development, not the fragmented vision that leads to lots of half completed projects, none of which really completes the mission they started out on.

Focus, guys, focus.

Categories: product development Tags: