The basic idea is to get insider information directly from honda engineers, who in theory could be reading this forum, and could contribute to the discussion.

Great in theory, but if it actually happend, someone would get fired then sued.

I do engineering work in the defense industry. Nothing secret, but certainly proprietary. If I discussed why my company made decisions, they'd string me up by my thumbs.

 

The reasons for the changes has nothing to do with which is better, but everything to do with the fact that the performance levels are virtually identical, and everything to do with the differences themselves. I don't see why that's proving hard for some to grasp ... What part of that is confusing?

 

So if you are a HMC engineer reading this, please risk your job and end our argument. We'll take up a collection.

 

[QUOTE=hey_i'm_new,May 8 2007, 03:17 PM]because... change is often brought about for a reason?

 

I figured you probably had some kind of technical background. It shows.

I got started working on classified projects when I was just a kid and in the Air Force, and once you have clearances, it's hard to walk away. You know all this stuff that is valuable, but it becomes useless if you change fields, so you're stuck doing stuff you can't talk about. For me, the upside was that I was well paid for playing with cool toys.

As an engineer, do you agree that we can see into the mind of a designer by examining his work?
(I'm not sure where I'm going with that question, but I hope you find it interesting. )

 

Yes, but unfortunately, I think the marketing, accounting and legal departments have as much input as the guys doing the design. For example the CDV. They could have made the rear stronger, but instead, they went for the least expensive solution.

But the engineer in me is saying that even if the honda engineers were the only ones making the calls, there's no reason to believe that they were the correct calls. Only seat time will tell.

Nice car collection BTW.

 

@ least i know there are some people in this forum who actually think instead of jumping the bandwagon...

 

I like _redruM's posts. The topic of engineering and the mind of Honda is far more interesting than discussing whether or not we can put an end to any great debates.

I just asked _redruM a question that I see as related to reverse-engineering. For those who don't know what that is, just think if it as taking a product and figuring out how it works. With complex products and systems this sometimes involves "getting into the minds of the original designers." As a trivial example (and valid any example is really non-trivial ), back in the days of 8-bit processors, there was a popular OS that had a jump instruction at address zero. This was a three bite instruction, where the first bite was the jump instruction, and the next two bites were the address (the location where execution of the program would continue execution). The hardware forced the processor to start execution at address 0 when the computer was turned on, so obviously the address was in initialization routine that needed to be run when the computer was powered up. It is clear from the design that the data at locations 1 and 2 are an address. BUT, if you dissassemble the OS code you find subroutine calls that point to location 1. THAT means that the CPU will be executing an address rather than code, and that can't be right. What in the heck was the guy thinking when he produced code to jump to an address that would result in data being executed rather than code? Is it obvious what he was thinking? Obviously (if you just think about it) he thinks there is executable code at that address. There is simply no other reason to write code that starts execution at a given address. It is done because that address DOES contain code. SO, either sombody screwed up, or the stuff that was an address on startup is actually an instruction that can be executed. If you start dissassembling code at address 1 instead of 0, guess what? Bite one is a perfectly good instruction, and bite two is the data it operates on. More code follows. What would normally be a coding error is actually a trick the guy used to get the most out of limited and costly memory, and once you understand how it works it's obvious why he did it the way he did. At that point, you have seen into the mind of the designer, and understood his thinking, without ever having spoken to him.

I have may reasons to believe that you can do the same thing with any highly focused product. Does anyone here think that's BS?

 

[QUOTE=RED MX5,May 8 2007, 07:14 PM] I like _redruM's posts.

 

[QUOTE=__redruM,May 8 2007, 09:57 PM]Yes, but unfortunately, I think the marketing, accounting and legal departments have as much input as the guys doing the design.