and can say that they literally describe a fuckin’ database and program to pull info from the database when queried for specific disease treatments. Input patient data, compare to other available data, display results so doctor can choose appropriate treatment plan. Thats it. The diagrams are networking diagrams showing how a DB can be remotely located and accessed through the ‘magic’ of the intarwebs. What a novel concept. Definitely worthy of these two patents and surely several more.

/sarcasm

In all seriousness though, I’m no doctor, but I am pretty sure that the medical community has been doing this FOREVER but using charts, and paper instead!!! How else can you diagnose and treat patients?

Who was claiming the government does not do drug research? I never said any such thing.

That’s why I didn’t say you did. It was one of the Anonymous Cowards. You should try reading.

Holy cow!!! You mean that EVERYONE in world was trying to figure out how to make a STEADICAM?

Well, it was claimed that only one person knew how and that everyone else was trying to “steal” it from him. Yeah, it’s a ridiculous claim and an obvious bald face lie, but that’s the steadicam troll for ya. He just seems to avoid truth at all costs.

You have yet to prove it is a lie.

You have yet to prove it is a lie.

When someone claims the impossible, that pretty much makes it a lie as far as I’m concerned.

“Your link is to someone who advocates the government taking over all pharmaceutical research. That has worked really well so far with Taxol!”

Not necessarily, he is simply pointing out that the government ALREADY funds pharmaceuticals and pharmaceutical corporations reap the befits/patents. He is simply pointing out that we shouldn’t give government money to pharmaceutical corporations and then let the corporations get patents on what they developed with government money, we can use the money they ALREADY give to pharmaceutical corporations to fund research that yields unpatented drugs. We are better off doing this than doing what we are currently doing, not that we should necessarily have the government fund research (but they already do).

I would be willing to bet that is the best thing you have ever designed.

Actually, his argument regarding “public money” was not government money, but the money from people purchasing the drugs, which he then attributed to expenditures on marketing, profits and, I presume, executive bonuses. His comment was that if these were eliminated, then we would get more bang from the buck. His suggestion seemed to be that instead of putting the public’s money into pure profits, it would be better funneled into research, which in our current system would have to go through the government.

In many engineering development functions it is quite common for the current design to be embodied in the hardware rather than the drawings, and eventually the drawings are modified to catch up with the current design of the hardware.

That’s not really very good engineering if that’s happening. Hit or miss, trial and error is more the way non-engineers tend to “design” things. They may get it to work, kind of, eventually, but rarely on the first try. But I can understand your confusion because most non-engineers probably don’t fully appreciate what’s really involved with engineering.

In some cases, the hardware itself is the design, which is quite frequent in prototyping.

Nope. The hardware may embody the design, but it’s not the design.

While the initial design may start as a drawing or sketch, the physical design can quickly run from the drawings as the design is modified to make improvements or solve problems. In electronics design, these changes are quite common.

Hey, electronics design is my specialty. Now usually my designs work right the first time. If it takes a lot of trial and error modification to get it working then I’ve screwed up and my boss will let me know that if he wanted that kind of result then he could just hire a technician to do the job instead. But if changes do have to be made to one of my designs (for some reason) then those changes will be calculated and documented before hand. What you describe is NOT common in engineering, and I should know. Not that it really makes any difference to your argument, it just shows once again how you either don’t know what you’re talking about or are being dishonest.

In many engineering development functions it is quite common for the current design to be embodied in the hardware rather than the drawings, and eventually the drawings are modified to catch up with the current design of the hardware.

Once again, that’s just not true. Unless you use a really loose definition of “engineering”, and that would be a deception all in it’s own.

Prior to updating the drawings, it can truly be said that the hardware is the design.

Once again, no. The design may be embodied in the hardware or described by some other manner, but the design itself is an abstraction that exists intellectually.

In many engineering development functions it is quite common for the current design to be embodied in the hardware rather than the drawings, and eventually the drawings are modified to catch up with the current design of the hardware.

That’s not really very good engineering if that’s happening. Hit or miss, trial and error is more the way non-engineers tend to “design” things. They may get it to work, kind of, eventually, but rarely on the first try. But I can understand your confusion because most non-engineers probably don’t fully appreciate what’s really involved with engineering.

I have worked with EE’s for about 30 years. Admittedly, all of these activities have been very R&D oriented, which often means that we are trying to do something that has never been done before. The design is generally created. A prototype is fabricated. The prototype is tested – and that is where the fun begins. We quickly discover that there is something about the interface with the equipment being controlled that was unanticipated. Sometimes the modifications are small. Sometimes they require a redesign. Regardless, this has been my personal experience with dozens of EE’s beginning in about 1975.

Of course, perhaps you are a truly great engineer and your designs work right the first time, every time. I have yet to see that happen.

Incidentally, I am an engineer.

In some cases, the hardware itself is the design, which is quite frequent in prototyping.

Nope. The hardware may embody the design, but it’s not the design.

Really? Then where is the design?

Incidentally, does that mean there is no design in the hardware?

While the initial design may start as a drawing or sketch, the physical design can quickly run from the drawings as the design is modified to make improvements or solve problems. In electronics design, these changes are quite common.

Hey, electronics design is my specialty. Now usually my designs work right the first time. If it takes a lot of trial and error modification to get it working then I’ve screwed up and my boss will let me know that if he wanted that kind of result then he could just hire a technician to do the job instead. But if changes do have to be made to one of my designs (for some reason) then those changes will be calculated and documented before hand. What you describe is NOT common in engineering, and I should know. Not that it really makes any difference to your argument, it just shows once again how you either don’t know what you’re talking about or are being dishonest.

You may well be a great engineer that makes few mistakes. However, with the projects I have been associated it is typically the technicians that report the problems with the design and the engineers that come in a fix it (or try to). In some case, significant redesign has resulted.

In the last project I was associated with, we were on about iteration 4 or 5 with the hardware, and I lost count on the software portion. We had also called in two electronics consulting firms to assist us with the design. Considering what we were trying to do, I was unsurprised. I am sure with your vast skill and experience you could have done better. Next time we will be sure to call you.

In many engineering development functions it is quite common for the current design to be embodied in the hardware rather than the drawings, and eventually the drawings are modified to catch up with the current design of the hardware.

Once again, that’s just not true. Unless you use a really loose definition of “engineering”, and that would be a deception all in it’s own.

I have not deceived anyone. I am merely relaying my experiences with hardware. Indeed, I have also made modifications to the mechanical hardware on the fly to solve problems and corrected the drawings later. I have yet to meet a productive engineer that halted everything to run back to his or her office, change the drawings, and then run back to the shop, repeat until correct. Hardly an efficient way to put a prototype together.

Prior to updating the drawings, it can truly be said that the hardware is the design.

Once again, no. The design may be embodied in the hardware or described by some other manner, but the design itself is an abstraction that exists intellectually.

Sorry. Then I have never worked with a design in my life. Ever. I have no idea how the numerous prototypes I have designed and put together do it, but they are not “abstractions that exist intellectually.” Indeed, the only way I could keep track of the design was to either get it on paper, in the computer, or into a piece of hardware. Until then, it was nothing more than a collection of ideas.

I am still wondering. If the hardware is not the design, where is the design? You keep saying the design is not in the hardware and not in the drawings (even though every definition of design says the design is in the drawings and in the hardware – but hey, you are a great engineer and a great linguist), so WHERE is the design? It is not in my head, I guarantee you. Without the drawings that I had made even I get to the point where keeping all the details is impossible. Indeed, one of the greatest innovations in the last twenty or so years was the creation of software that analyzed interferences. Though I continued to do them by hand for a time, having the software was excellent insurance (though I sometimes caught interferences the software did not, which I find amusing).

Young engineers tend to rely too much on software rather than their own abilities. Then they get stumped when something does not work as planned. Tsk, tsk.

“i dont get it.”

I get it. This doctor created a useful product that the patent holder did not create and now he’s being sued for no reason. The patent is harming innovation and that’s not good.

and seriously, now that you admit this is expensive, why would he spend the money to do this if he didn’t think he was doing the right thing? It’s not a scam, he’s the one getting sued, not the other way around, chances are he never heard of the patent, not that he intentionally infringed on it. I don’t buy that nonsense, if he had known of the patent it only would have prevented him from conducting the research which would have harmed innovation, he won’t open himself up to an expensive lawsuit.

“we know that billions are going to non-pharmaceutical research”

How many billions? We already know that 92 percent of cancer drugs were developed with federal funding.

So you complain that there is a lack of government transparency, that we’re not getting the exact numbers of how much money goes to what (though there is a lot of evidence that the government substantially funds pharmaceuticals). I think that a lot of this public funding goes into patented products where the firm reaps the benefits of the patent. Prove me wrong. Where is the government transparency? Clearly, the patent system is not encouraging government transparency. Perhaps the reason the level of transparency that you ask for doesn’t exist is because special interest groups don’t want people to know how much the government funds patented products. Why should a monopoly want government transparency when that will simply anger voters if they don’t like the results? They want to justify their patents by claiming that they fund R&D with the profits but patents give incentive to exaggerate the R&D that they spend and to lie about how much of it is government funded. We should eliminate this incentive.

Seriously, why don’t we have access to this data. How much government funding goes into funding pharmaceuticals, how much of that goes into funding patented pharmaceuticals where the firms reap the benefits of the patents? Where is the transparency?

Hey, I thought was what he meant as he was breaking out his numbers. However, that this money comes from the government makes no sense either. He clearly said that his information came from the company’s financials. I picked Merck (kind of thinking that they had to be representative) and looked at their annual report. There does not appear to be a mention of support from the NIH in any of their financials.

Of course, I may be missing something. Would you care to show me the page in Merck’s 2008 financial report where this government support comes in?

We know that 92% of cancer drugs were developed with government money?

Okay, how many patents are there on these drugs?

Who holds the patents?

Where is the documentation showing that the government provided the 92% of the support for the development of the cancer drugs?

Thank you.

Of course, perhaps you are a truly great engineer and your designs work right the first time, every time. I have yet to see that happen.

Incidentally, I am an engineer.

So you’re a supposed engineer and you’ve never even seen a design work properly the first time? I’d fire your sorry ass in a heartbeat.

I have not deceived anyone. I am merely relaying my experiences with hardware. Indeed, I have also made modifications to the mechanical hardware on the fly to solve problems and corrected the drawings later. I have yet to meet a productive engineer that halted everything to run back to his or her office, change the drawings, and then run back to the shop, repeat until correct. Hardly an efficient way to put a prototype together.

You’ve never heard of an engineering field notebook and claim to be an engineer? Not likely. And trial-and-error prototyping is the often most inefficient method of design. I am reminded of what Tesla once said about Edison’s methods:

“If Edison had a needle to find in a haystack, he would proceed at once with the diligence of the bee to examine straw after straw until he found the object of his search… I was a sorry witness of such doings, knowing that a little theory and calculation would have saved him ninety per cent of his labor.”

Once again, if that’s typically how you go about it then I’d fire your sorry ass.

Sorry. Then I have never worked with a design in my life. Ever.

I could certainly believe that.

…WHERE is the design? It is not in my head, I guarantee you.

Again, I could certainly believe that. In fact your demonstrated inability to understand abstract concepts leads me to question as to whether you are indeed a qualified engineer at all (and don’t tell me that you drive trains). Yeah, I have come across many people who called themselves “engineers” who really were not. Working with the military, one of my pet peeves is the way that some installations give the people who go around mowing the grass the title of “Civil Engineer”. Or like the other day when my wife was riding a cab home from the airport and the cabby ask her what her husband did for a living. When she told him that I was an electrical engineer, he replied “Oh yeah? I’m an engineer too! A transportation engineer!” Just calling yourself an “engineer” does not make you one.

You don’t have to be an engineer to design things, but there is a difference in the way engineers and non-engineers generally go about. One of the first engineering projects I worked on (not the lead engineer) was for an implantable heart pacemaker/defibrillator. I guarantee you we did not use a trial-and-error approach to the design, killing of a bunch of patients along the way. And I sure hope I never cross a bridge or enter a structure designed by an “engineer” like you. Your trial-and-error method would likely get people killed and your ass sued off (and hopefully imprisoned as well). That’s why there are laws regarding the practice of engineering: to keep people like you away from certain kinds of work and protect the public safety.

Incidentally, I would guess the odds are extremely high that you have used one of the products that I either designed or co-designed…and you seem to be fine. Thank goodness for you that we have a rigorous testing program to work out the bugs before we go to production – which is typical for most mechanical hardware, whether it is designed in Japan, China or the United States.

What is a patent, a patent is a government sanctioned monopoly. That’s what this is, not much difference. The effects are the same, the incentives it creates for corruption are the same.

Patents are covered by the Constitution and specific laws under 35 USC and 37 CFR. FDA approval is completely different and separate. Even if patents did not exist, FDA approval would.

“I am starting to think that either the people claiming all this support are outright lying, or they are deluded.”

Then why isn’t this information publicly available if there is no conspiracy? What have they got to hide? Conspiracies do happen, they have happened many times in the past and continue to do so, so we’re not deluded. Prove to us that we are deluded or lying. You are making an accusation, prove it.

and the only reason for for opposing a system that assumes mistrust and proves trust is if the government or someone has something to hide. Otherwise they should have no problems with complete transparency.

And I would not have your cocky ass working for me, so I would never have hired you in the first place.

Don’t worry, you’d never get that chance. I can’t imagine any competent engineer working for you.

Notes in a notebook are not a design,…

You’re right, they’re not. They’re documentation of a design, they’re not the design itself; a concept beyond your grasp.

Actually, bridge builders in fact do you “trial and error,” if you wish to call it that. blah blah blah

Heh, you don’t even know the difference between prototyping and modeling. You’re no engineer.

Full scale build – Again, though the bridge passed analysis and prototype testing,…

Err, modeling.

…one additional factor was not considered in how the bridge responded to the wind…

Sounds like someone screwed up.

On the other hand, it is obvious that you would have built the bridge without any errors or modifications, because you are a great engineer who knows better than all other engineers.

No, I’m merely competent.

Please tell me exactly what products you have designed.

I mentioned one above. Yourself? Yeah, that’s what I thought.

I want to be sure I do not purchase any of them.

Well most of them are not the kinds of things someone such as yourself would probably purchase. For example, I’ve never designed anything for Mattel, so that should help you a lot. But I also suggest you never get an implantable heart pacemaker/defibrillator or get into an airplane. If you’re in the military, then your options to avoid to avoid any of my work may be limited. And if you’re an enemy of the US, then you’ll certainly want to avoid some of the stuff I’ve done. I fact, you’d probably like to kidnap or kill me if you could. US forces, on the other hand, have benefited greatly from my work.

I do not trust that you spent enough time in the “trial and error” phase before going into full scale production. Incidentally, I would have fired your ass for not going through that phase. You are a menace to public safety.

Yeah, right. I tell you what, I think I’ve made my points and I don’t have any more time to truly waste on you. So go ahead, you can have the last word now.

sp/Of course this is nonsense, there is no reason to believe posts necessarily correlate with posts./Of course this is nonsense, there is no reason to believe posts necessarily correlate with traffic.

You mean when Bayer sold Aids Tainted blood and the FDA allowed it and no one got arrested. Or when Vioxx lied about their data and censored data and no one got arrested.

Another example of our corrupt patent system.

“The first two fair price agreements were for Taxol and a separate agreement with Bristol-Myers Squibb to market the AIDS drug ddI, a drug patented by NIH and licensed to Bristol-Myers Squibb on an exclusive basis for ten years. “

http://articles.mercola.com/sites/articles/archive/2001/08/15/drug-war2.aspx

The NIH (taxpayers) funded R&D, patented the drug, and allowed a private entity exclusive rights to it.

I think you underestimate the power of “trial and error,” though you may be thinking of “trial and error” as something other than what is being described. There are many great engineers known for “trial and error.” Clarence Kelly, who had a master’s degree in aeronatical engineering, was a great believer in designing as you go; i.e., “trial and error.” One of the things that made Kelly a great engineer was his ability to sketch out a design, and then make it happen, modifying as he went to solve problems. Perhaps not the rigorous engineering approach that you learned, but fast and effective, and his approach created what remains two of the greatest aircraft ever built, the U-2 and the SR-71.

There are numerous other stories of engineers creating “trial and error” solutions that were fast, effective, and often cheap alternatives. Certainly, military contractors are full of such stories. Do these “trial and error” engineers sometimems fail? Yes. Witness the famous Tacoma Narrows bridge, where engineering neglected to remember that it was a physical science.

Another example of “trial and error” are the little winglets you see on modern aircraft. Someone wondered what would happen if you stuck little winglets on wings. I can imagine the first person that flew a plane with those things on it was nervous regarding what the airplane would do.

Some people call the experimental approach to engineering “thinking out of the box,” doing something other than what conventional engineering would dictate – but that something can lead to wonderful surprises.

I would also suggest that there are many different approaches within engineering, all of which are ultimately effective. Medical engineering must, of necessity, take a different approach than bridge building or construction of buildings.

I am unsure of what you call “modeling” versus “prototyping.” In engineering for the military 1/4 and 1/2 scale prototypes were frequently built to do wind tunnel tests of designs. The test data from these prototypes was fed back into CFD models, and the process iterated until final designs were achieved. This was the was the way that the AV-8, F-15, and F-18 were built. I presume a similar technique was used for previous aircraft, and I presume something similar or a substitute is being used for subsequent aircraft.

This story is true and accurate. Dr. Charles Moertel from the Mayo Clinic developed the cancer use of the drug using NIH money. Johnson & Johnson’s only argument was that they supposedly spent a lot of money researching Levamisole for use as a cancer drug (which remains unproven). Regardless, the FDA quickly approved the use of Levamisole as a colon cancer drug based on Moertel’s research, not Johnson & Johnson. The primary question is whether the government should have permitted Johnson & Johnson to take possession of a drug the application of which was largely funded by the NIH. Furthermore, and the worst thing of all, the drug cost pennies per pill prior to evidence that it worked on colon cancer, and the price exploded to $5 or $6 per pill for use in cancer treatment. Tsk, tsk.

Yeah, you might be right there. We did not account for the differences in location.

Their financial statements are pretty easy to find. Just pick a pharm company and go to investor relations. Most of them have their annual reports listed.

But I think I know how drug companies are avoiding reporting the support. The Levamisole thing was interesting. The drug was developed at the Mayo clinic using NIH money. Once the drug was developed, Dr. Moertel apparently gave Johnson & Johnson the technology. I am little fuzzy on why and how, but Johnson & Johnson did not report nor did they have to report the money spent by the NIH. Very sneaky.

Essentially, the public did not get the full benefit of the money spent on the research.

“any drugs developed by the government should be provided equally to all drug manufacturers.”

In other words, any drug funded with government funding should not be patented.

“Rx3 Pharmaceuticals, Inc., an anti-infective drug discovery company, announced today that it has recently been awarded two new grants totaling $1.5 million.” (2006)

http://www.biospace.com/news_story.aspx?NewsEntityId=30983

Not sure to what degree the results turned out to be proprietary (though it’s not hard to believe that they yield patents for the company. More transparency on this would be helpful).

“LINCOLNSHIRE, Ill.–(BUSINESS WIRE)–BioSante Pharmaceuticals, Inc. (NASDAQ: BPAX) announced today that the company has been awarded a $150,000 Small Business Innovation Research (SBIR) grant from the National Institutes of Health (NIH) to support the company’s development of formulations for the pulmonary delivery of interferon alpha (IFN-α) using its proprietary calcium phosphate nanoparticulate (CaP) technology.” (2008)

http://www.fiercebiotech.com/press-releases/biosante-pharmaceuticals-announces-receipt-nih-grant-inhaled-interferon

Since it’s using it’s already existing proprietary product there is a good chance that the outcome is also proprietary as well.

I do not think any of the posts above claimed that the AV-8, F-15 or F-18 were built by trial and error. That would be insane.

Perhaps you should give me your friend’s name and e-mail. I worked the SR-71 many years ago. Sadly, it is no longer flown. That aircraft was simultaneously great and awful, depending on your point of view.

He is quite correct that aircraft are built by design, modelling and analysis.

However, that being said, all new designs encounter problems, and then one must decide how to solve the problem. In the “ideal” world, one stops everything and goes back to the models and tries to figure out what went wrong or what was missed in the model. In the real world, millions in tooling and hardware have already been procured and may be sitting in an assembly area. The solution is to go figure out the best way to solve the problem in the current configuration and incorporate the design change in the next configuration.

Clarence Johnson was a master of solving problems encountered during the construction of some of the greatest aircraft ever built. The list of trial and error that went into the SR-71 is lengthy, and helped all those engineers building later aircraft.

For example, there was little knowledge of how to work with titanium. Engineers quickly discovered that ordinary grease pencils could not be used on the titanium as it would eat into the metal (we call this trial and error – note that this was not planned, it was not modelled, it was not prototyped – it was discovered and accommodated).

Another problem that needed overcome with a previous design was navigation for the U-2. Kelly’s team tried several alternatives (trial) only to reject each (error) before finally settling on a sextant.

I am surprised that anyone in engineering would belittle trial and error, or to even deny that it exists and has worked for millenia. Are we better now than we have ever been? Of course we are. However, we still push the envelope, we still try to do what has never been done. Each time we do those things we will make mistakes and we will learn from them. If we are not making mistakes and doing better each time, then we have forgotten how to advance.

As for models and prototypes, I think there is some hair splitting. A prototype is often defined as a full-scale working model. Yeah, duh. However, when you produce a full-scale model of a component in plastic when the actual version will be metal, is it a prototype or a model? Rapid prototyping houses will say prototype, but perhaps it is a model. I am unsure of when something transitions from model to prototype – or whether a prototype is indeed a model, it just happens to have more characteristics of the final device than does a “model.”

What happens when you build a fully operational half-scale model of a device? Is it a model because it is not full scale or a prototype because it is fully functional? I suspect you will get different answers from different people. Is terminology so important to engineering design that it stops it, or do we just agree to what the terms mean and move on? After working in a half dozen industries, you quickly discover that different industries use different terms and the terms mean different things. Accommodate and move on.

I do not think any of the posts above claimed that the AV-8, F-15 or F-18 were built by trial and error. That would be insane.

Post 266 seems to be saying just that. And yes, my friend thought it was insane.

And the kind of trial and error apparent being discussed is the type where things are just tried without any prior calculating or planning. It is only after something accidentally works that it is even documented. See post 230. That is much different than some kind of methodical iterative design process.

Perhaps you should give me your friend’s name and e-mail.

I don’t go around posting other people’s info. That you would ask me to do such a thing really says something about you. Tell you what, post your name and email address and I’ll forward it on to him. If you’re for real, I imagine he’d love to talk to you.

Uh huh, that’s what I thought.

I am surprised that anyone in engineering would belittle trial and error, or to even deny that it exists and has worked for millenia.

As described above, I can’t imagine any engineer endorsing it. But no one is claiming that it doesn’t exit, either. So why make up that strawman?

As for models and prototypes, I think there is some hair splitting.

Actually, he went on to explain that a model in engineering is something that substitutes as an analog for something else for the purposes of analysis. Whereas a prototype is an actual first or early version of the actual product. That seems like a hair about the size of the Grand Canyon to me. Go ahead and post that name and address of yours, maybe may friend can clear it up for you.

Perhaps you should give me your friend’s name and e-mail.

I don’t go around posting other people’s info. That you would ask me to do such a thing really says something about you. Tell you what, post your name and email address and I’ll forward it on to him. If you’re for real, I imagine he’d love to talk to you.

Uh huh, that’s what I thought.

trialanderror1956@yahoo.com

trialanderror1956@yahoo.com

What, that’s really your name and address? Your mama really named you “trialanderror1956”? Man, I bet you had a hard time in school. And it doesn’t say much for your mama either.

Of course, on the other hand you could just be full of you-know-what.

You think I am going to put my real name out here? Your friend may e-mail me. I would be happy to talk with a “real engineer” about airplanes.

Interesting that you are devolving into name calling. Running out of any real arguments?

No one ever suggested (and if it appears I did so, it was unintentional) doing engineering without planning, designing and modelling.

Oh, but they did. You can read up above where it was claimed that is how engineering is commonly done. In fact according to what has been said above, engineers commonly don’t even produce any documentation until after a successful prototype has already been built, and then they go back after the fact and make drawings of whatever it was that finally worked. It may not have been you who originally made that claim, but that’s what this discussion has been about. You jumping ship now?

Your mommy named you Wingman?

You seem to claiming that I said that was my name. I didn’t.

Kind of says it all, doesn’t it? You gonna fly away now?

Ditto.

You think I am going to put my real name out here?

Interesting that you would ask me to do the same with my friend’s name then isn’t it?

Interesting that you are devolving into name calling.

How’s that? You replied to a request for you name (and addr) with trialanderror1956@yahoo.com, so what do you expect? So now you accuse me of name calling for calling you what you put forward as your name? OK then, I’ve got a “descriptive” name for you now: “Lying Hypocrite”. How’s that one?

I would be happy to talk with a “real engineer” about airplanes.

Oh, I seriously doubt he would be interested in talking to you now. I know I’m not.

You are reading something into the post that is clearly not there. Updating the drawings does not mean starting from scratch. Ask your real engineer friend the definition of “updating drawings.” Somehow I suspect that does not mean to “create drawings.”

No wonder you are confused.

Incidentally, have you given your friend my e-mail address yet?

Updating the drawings does not mean starting from scratch.

In the context of this discussion, that’s exactly what it meant. The claim was made that prototypes are often the only documentation of a design and that if something happened to the prototype then the whole design was lost. Gee, I wonder what happened if an SR-71 prototype crashed? Did Lockheed have to start all over because the prototype was the only documentation and without that sample nobody knew how it was built? I doubt it.

Yep, you seem to be jumping ship all right.

Incidentally, have you given your friend my e-mail address yet?

I told him where he could find your supposed name and address in this discussion.

Tell you what, post your name and email address and I’ll forward it on to him.
…
trialanderror1956@yahoo.com

Gee, I guess that exchange never occurred, did it?

And guess what? My email address consists of my_real_name@my_isp, so a response to query for your name and address could conceivable be answered in the manner you did if you claimed trialanderror1956 as your name.

I know you are [probably] bright enough to understand that.

Oh yes. I’m also bright enough to not believe everything you say and to recognize trialanderror1956@yahoo.com as a probable honey-trap address (and to point out your silliness and hypocrisy for even trying such a stunt). Too bad for you that you weren’t bright enough to realize that and move on. So now I get to call attention to it again.

Care to step in it again now?

I have no idea what “honey-trap address” is.

Care to step in what? I have stepped in nothing yet, and to the extent I have made an error I owned up to it. Making up things said about drawings is something you have yet to own up to.

Making up things said about drawings is something you have yet to own up to.

OK, point it out.

Point out what?
…blah blah blah…
(1) Create drawings
(2) (Optional) Analyze, model or create additional documentation.
(3) Build prototype or model.
(4) Modify prototype or model as needed.
(5) Update drawings to reflect modification.

Now, would you care to provide support for any other viewpoint?

Sure, for a real engineer it might generally go more like this:

1. Obtain objective, specifications (document)
2. Analyze problem (document)
3. Develop/refine/optimize solution (document)
4. Verify solution (document) (analysis, simulation, modeling)
5. If results are not satisfactory, go back to step 3.
6. If there is to be a prototype phase, go on to next step, else go to end.
7. Build prototype (document)
8. Test prototype (document)
9. Analyze results (document)
10. If results are satisfactory, go to end, else back to step 3.
11. End: Produce deliverables (usually documents)

Note that this is not a “seat of the pants” affair and analysis is not “optional”. Also note the absence of ad hoc, undocumented prototype testing and modification. A step is not complete until the documentation for that step is complete. As for testing, there is a whole specialty of engineering sometimes used called “test engineering” employing specialized test engineers.

My friend relayed this little story to me about the importance real engineers are taught to place on documentation.

When he was in engineering school lab classes they had to keep lab notebooks documenting their work. The notebooks had sewn bindings and preprinted sequential page numbers so that pages could not be inserted or removed without detection. At the beginning of each lab session (and projects could take several sessions, lasting weeks in all) the student had to date the session and describe the objective and the planned procedure for that session. During the session the student had to note any changes to the plan before making the change and note all significant observations. In other words, they were to document everything before doing it and then document the results. At the end of each session the student had to sign and date it and get the TA on duty (or other faculty) to witness and sign it also. So there was always a verifiable paper trail of their work. The department made it very clear that the students were being taught what would be expected of them as engineers after graduation and anything less would be considered unprofessional.

To show that they were serious, TAs (and sometimes even a prof) would occasionally walk up behind a busy student and ask them what they were doing, and the answer had better match what the TA/prof was seeing. Then they would then pick up the students lab notebook and see if it was up to date with what was being done. If not, the notebook was confiscated and the student was told to start over with the entire project. This was significant because the student might have already have invested weeks of work on the project that would now have to be repeated (and it was a struggle to complete projects in the time allotted to begin with). That was for a first offense. Second offense was said to get a an automatic F on the project and a third offense got an automatic F in the course for unprofessional behavior. He said he knew of a couple of students who got caught on the first offense, but never heard of any second or third offenders. And he said that engineering programs are usually rigorous like that (and I’m not even going into what he said about senior level design reviews that could bring students to tears). The typical engineering student entering the program he was in had come from the top 1 or 2 percent of their graduating high school class and the vast majority of them still washed out, never to make it as engineers. Again, typical of most programs.

And true to his training, this was something he practiced after he graduated and throughout his career. Later, as an engineering manager, engineers working for him didn’t make it very far with poor documentation either. There was one who desperately wanted to be transferred to a prestigious new project dealing with the space program. He was technically qualified, but due to poor documentation habits he was denied. He also encountered situations in which technicians took it upon themselves to make design changes and “improvements” and then later tried to pin it on the engineers. Lack of preceding documentation is what caught them.

Now some of the commenters here have claimed that engineers commonly design and build stuff without the preceding documentation (which would of course include analysis, calculations, observations, procedures, etc.) and then kind of go back and fill in the documentation later. A prototype change is a design change. Some have even claimed to be actual engineers themselves working in such an ad hoc fashion. Considering the story above, I find that a little hard to believe and think anyone who had actually been through such a program would know that. A pretender might not grasp it.

Hey, you are a real winner. Your statement was proved false, and your little scenario above, while interesting, merely indicates that you provided more detail than the other guy did. He was not wrong, just less complete. You, on the other hand, claimed he said that engineers use no documentation, which was clearly untrue.

Hey, you are a real winner. Your statement was proved false, and your little scenario above, while interesting, merely indicates that you provided more detail than the other guy did. He was not wrong, just less complete. You, on the other hand, claimed he said that engineers use no documentation, which was clearly untrue.

Heh, “he” who? I looked through all of Wingman’s statements and couldn’t see where he attributed that statement to anyone in particular, so you’re obviously lying claiming he did. But looking at comment 208 I can see where somebody, I don’t know who, clearly said

In many engineering development functions it is quite common for the current design to be embodied in the hardware rather than the drawings, and eventually the drawings are modified to catch up with the current design of the hardware.

And in 232

I have yet to meet a productive engineer that halted everything to run back to his or her office, change the drawings, and then run back to the shop, repeat until correct. Hardly an efficient way to put a prototype together.

So indeed someone(s) did make statements that would boil down to engineers supposedly not using documentation (writing something up after the fact isn’t “using” documentation, that’s reporting). I suspect that “someone” was yourself since you’re so vigorously trying to deny it. Maybe you’ve worked under engineers and had your ass busted a few times and developed a chip on your shoulder over it. I used to know a nurse (not a very good one) who felt that way about doctors.

And the two design procedures certainly look different to me. One looks professional and rigorous, while the other looks like how a half-ass amateur wannabe too lazy or uneducated (We don’t need no stinkin’ math!) to do analysis (Analysis? What’s that?) might go about it. Care to guess which is which?

Seems to me that you’re the real winner.

And I don’t think “scenario” means what you think it means, either.

From what I read above, probably not very good ones. But I guess you’ve probably got a few duds in every profession. That wouldn’t make it common though.

I work in a very large company that employs somewhere around 1,000 engineers. I did a quick survey of about a dozen engineers and asked them the same question: Do you make changes to physical prototypes or models and update the drawings later?

The answer I got was that every one of them had made a change to at least one physical model or prototype without updating at least drawings first. Many had done so without consulting the analytical model, but they thought, knowing the analytical model, that making the change would not compromise the design or functionality.

All of them also said that the physical models or prototypes nearly always needed modifications to work for a variety of reasons. Either something was machined improperly or something was missed or miscalculated in the design.

All of them also thought that trial and error, while not desirable, was in fact still necessary and still used.

So, based on a limited survey, I guess most engineers are duds.

Marketing: Provide objective and initial specifications

Engineering:

1. Create Drawings
a. Analyze problem
b. Develop a solution
2. Analyze solution
a. FEA
b. CFD
c. Bending moments
d. Sheer strength
e. Interferences
f. Tolerance analysis
g. Others as needed
h. Performance analysis
i. Theoretical inputs and outputs
ii. Theoretical efficiencies
iii. Theoretical life
iv. Proposed maintenance intervals
3. Refine and Optimize the solution based on the results of step 2. Iterate steps 2 and 3 as needed to obtain a solution that meets the objective.
4. (Optional) Build model(s)
a. Procure components
b. Modify model, if needed
c. Analyze, test and review components.
d. Modify model, if needed
5. Use results of 4 to verify, to the extent possible, steps 2 and 3, and to update documentation in steps 1, 2, and 3.
6. Build prototype(s)
a. Procure components
b. Measure prototype components
c. Machine, as needed prototype components
d. Test individual components, if needed
e. Assemble components, modify components if needed
f. Test assembly
i. Life tests
ii. Cycle tests
iii. Environmental tests
iv. Harsh duty tests
v. Specialized tests for specific products
7. Analyze results of step 6 (typically ongoing).
8. Determine whether documentation of steps 1, 2, and 3 need revised to correct problems or to reflect changes made during testing. Repeat all steps until a satisfactory solution to the original objective is obtained.
9. Present solution to marketing.

Marketing: Approve solution to the objective.

Engineering & Operations: Transition product into production, which is another set of details.

Are we going to do a Gantt chart next?

Heh, “he” who? I looked through all of Wingman’s statements and couldn’t see where he attributed that statement to anyone in particular, so you’re obviously lying claiming he did.

Hey Bob,

Yeah, I’d been careful not to attribute certain statements to any particular individual, that’s why I asked him to point it out (knowing he couldn’t). And of course he fell for it. I did that for a couple of reasons. First, to see how many different identities would pop up in defense (smoke them out). Second, just to see if he’d keep lying. Of course he did (presuming it’s the same individual).

And I think you could be right about “Jason’s” motivations too.

Now I see he’s now gone back to his Anonymous Coward moniker and come out with another pack of whoppers, including a bunch of made up credentials. Well, I think most of what needed to said about real engineers and this wannabe has been said at this point. Now it’s time to leave him all alone because I’m pretty sure hardly anybody else is reading any of this anymore.

So long Bob.
Bye bye to you too, “Jason”.

By the way, “Bob,” still waiting for your e-mail.

“You must be a patent lawyer.”

You must not be. It really would be easy to initiate an inter partes reexam of these patents.

Learn a little bit about what you’re trying to spout.