TDD: Flip sides of the same coin?

[DeanLong]

I am soliciting opinions on TDD with specific focus on skels, PGs and ECGs.

While I know this is a HIGHLY subjective and potentially contentious issue I believe a golden nugget of "respectful" discussionwould be beneficial. I am currently within an environment that uses it exclusively and extensively.I have noodled on how I would phrase the questions I must ask, knowing that I will get varied responses from many different Design and Engineering disciplines. I understand that engineering tires is not the same asengineering aroller coaster. I am notinterested for specifics uses of TDD, skels, PG's, ECG's etc.... I am more interested in the following questions:

1. At what point do you find the point of diminishing return using TDD? Stated another way, at what point along the development cycle does the need to go back to the "basis" geometry start to become counter-productive? Hint: Think in terms of how and why TDD began in the first place. Multiple users working on one project consisting of concurrently changing, multiple inter-related parts and assemblies.

2. At what point (geometric complexity /amount of geometric feature)do youend the master / skelworkand begin driving ECG's to parts?

3. What mechanisms / procedures do you have in place to ensure novice users do not build the "House of Cards" within the Master / skel to ensure, later down the line, the revision process is not bogged down to a counter productive pace due to lousy reference control and modelling practice? Stated another way, how do you keep the little kids's hand's out of the Pro/E cookie jar?

From the responses I will follow up with additional thoughts and specifics.

thanks

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[DeanLong]

Something I forgot to mention, as I have already begun to receive responsesfocused in the wrong direction. Very respectfully, I don't need a lesson on how to do TDD. I already know what TDD, PG's, ECG's and skels are all about. I use it everyday.

In essense, the golden nugget of my question is: When is too much of a good thing...too much? In other words, in your opinion when does the power of all the inter-relationships of PG's, skels and ECG's, spead across multiple filesbecome counter-productive?

In Reply to Dean Long:

I am soliciting opinions on TDD with specific focus on skels, PGs and ECGs.

While I know this is a HIGHLY subjective and potentially contentious issue I believe a golden nugget of "respectful" discussionwould be beneficial. I am currently within an environment that uses it exclusively and extensively.I have noodled on how I would phrase the questions I must ask, knowing that I will get varied responses from many different Design and Engineering disciplines. I understand that engineering tires is not the same asengineering aroller coaster. I am notinterested for specifics uses of TDD, skels, PG's, ECG's etc.... I am more interested in the following questions:

1. At what point do you find the point of diminishing return using TDD? Stated another way, at what point along the development cycle does the need to go back to the "basis" geometry start to become counter-productive? Hint: Think in terms of how and why TDD began in the first place. Multiple users working on one project consisting of concurrently changing, multiple inter-related parts and assemblies.

2. At what point (geometric complexity /amount of geometric feature)do youend the master / skelworkand begin driving ECG's to parts?

3. What mechanisms / procedures do you have in place to ensure novice users do not build the "House of Cards" within the Master / skel to ensure, later down the line, the revision process is not bogged down to a counter productive pace due to lousy reference control and modelling practice? Stated another way, how do you keep the little kids's hand's out of the Pro/E cookie jar?

From the responses I will follow up with additional thoughts and specifics.

thanks

[mlocascio]

I think that I understand where you want this conversation to lead.



Maybe some old buzz words will help here: form, fit and function? I mean it
almost sounds redundant here. However another word comes to mind: design
intent.



Personally I work for a company that doesn't have full assembly
"privileges." In order to create skeletons and use TDD one needs to have a
"full" license of Pro/Assembly. Maybe that is old news too. I suppose that I
assumed that it was an essential part of the bundled module. I know .I know.
This is a bit off the beaten path.



Do you have component items that are in a state of constant change? Do they
appear as base components? Once again this seems almost redundant. I am sure
that you are looking at these types of things. I always have thought of TDD
as "the table cloth" mentality. If I want to change the table cloth QUICKLY
.etc etc etc.



Well, a "good" discussion may follow.



Michael P. Locascio

[dgschaefer]

The value of TDD diminishes over time. Its power is in capturing design
intent in the skeleton and using it with PGs, CGs and ECGs to push
changes to a design down the tree automatically. So, as a design
matures and stabilizes, the value of TDD diminishes, and it even starts
to get in the way. What's needed is some kind of metric or procedure to
decide when it's no longer needed and what to do at that point. It's
not a simple thing.



To me, this means, for one, you implement TDD from the start. I've
heard users, usually folks with little TDD experience and a bit
intimidated by the concept, say I've gotta get something done, I'll put
the skeleton in later. That makes implementing harder and greatly
diminishes the value of TDD. You need to start with TDD and do it 100%,
in my view. If two parts share any geometry, put that geometry in the
skeleton and publish to those parts. I haven't figured out a way to do
TDD effectively at less than 100%. I want all that shared stuff in the
skeleton, managed my Pro/E so I don't have to keep track of it. So I
start with full TDD immersion up front.



A logical break, for me, with TDD is when the part or product is first
released for tooling or production. At this point, you have physical
assets (tooling or inventory) tied to that geometry. The link to the
design intent in the skeleton then is potentially dangerous. Do you
want a skeleton change to produce a change to apart that negates the use
of current inventory or invalidates an injection mold? No, you need to
manage this more on a part by part basis than a design-as-a-whole basis
at this point. That's the time I'd say start setting your GCs and ECGs
to independent.



How that decision is made is a matter of company policy. Do you set all
CGs and ECGs to independent at first component release? That may mean a
pretty early point if you have long lead tooling items. On the other
hand, not doing so may make those early released items not match others
that are still skeleton driven. Another question is how do you
communicate models where the CGs or ECGs have been set to independent?
How can I tell if this is still skeleton driven or not?



To me, how it happens is a bit fuzzy and each organization will have
their own preferences, but once you transition from a 'development'
mindset to a 'manufacturing' mindset, it makes a lot of sense to make
those TDD links independent.



Doug Schaefer

[rreifsnyder]

Doug,

I respectfully disagree. I have done several copier projects where we used the pre-skeleton, map part concept very successfully. We used the map for placing the interface components only. Mismatches between the parts would be found in interference checks for the most part.

Rob Reifsnyder
Mechanical Design Engineer/ Pro/E Librarian
L
Mission Systems & Sensors (MS2)
497 Electronics Parkway
Liverpool, NY 13088
EP5-Quad2, Cube 281

[ksauter]

One simple way of looking at it: when you spend more time managing the design process than actually designing, the process is becoming counterproductive. I have found that when I put a lot of relationships into a part/assembly, it limits my ability to change it without a major hassle. Since I frequently change things in ways that Proe thinks I shouldn't, I have to break relationships to get the result i want. As a result of that, I make it a point to avoid implementing a lot of relationships. I spend a little more time checking things, but I don't spend a lot of time fighting Proe. And checking is a good thing.

Ken Sauter

[kimndave9]

In the Skeleton and Copy Geom world, one top-down Pro/E feature I've come to like is the lowly Layout.

It's a bit uncomfortable to use - like threading one's belt the -other- way, but it works just fine and can be very useful.

Can PTC ever get the nomenclature right, such as the command "Use Layout" instead of "Declare Layout?" Sigh.

Can't really answer the first two questions, but the third - <sarc> Just let novices build what they want. They are working on low level parts to begin with and it doesn't matter how much damage they do to the people who juggle the top levels. It's best to let the least trained drive the design process. </sarc>

Dave S.

[dgschaefer]

Ken,



My experience with TDD is that the more relationships and design intent
I put into my models, the less I worry I have to manage the design
process. I determine what's related and how, I build that into the
models and I don't think about it anymore, I let Pro/E keep track of it.
My goal is that if I'm changing things that affect multiple parts, I
want that stuff to fail so I'm aware to look at ramifications I may not
have considered.



To me, it's a major hassle to keep track of those relationships myself
rather than letting Pro/E do it.



Doug Schaefer

[DeanLong]

Thanks for all the responses here and privately. I will call this one closed and post a summary.