Prabhak I am fully intuned to your perspective! THe dominance of rthe IBM/INTEL partnership obscured any technological edge at National. IN the end good marketing and overwhelming product acceptance will always trump any engineering considerations. The end user just wants something that's popular and functional. The Systems Engineering sub-discipline was designed to bridge these considerations of cost, technical specs, and schedule. These 3 attributes translate into our producibility, TTM, and customer requirements. Essentially this is where all engineering decisions should begin and end when we finally verify our products before shipping to the marketplace.
To explain by example what I meant by "a matter of degree." I bought a new stereo amp some years ago. It had the same general specs as the older (but hardly old) one. Same power output, same distortion rating. So, why did I buy it?
Because it was full complementary symmetry, input to output.
My wife, naturally, thought I was nuts. Perhaps a non-engineer wouldn't have obsessed about circuit topology. So, this sort of small difference might apply. But other than that, there's no reason why many non-engineers might not be aware of a lot of technical minutiae as well.
"Here's the thing, though. Don't non-engineers also have to make "engineering" decisions? Or, simply they are incapable of doing so..."
Of course they do. I've always been opposed to this notion that engineers are totally unlike anyone else. Applies to buying a car, or to (what was the other one?) oh yeah, ability to be hackers. It's mostly a matter of degree.
One of the hardest things to do as an engineer is to stand up and say "horse puckey" when any manager is making a bione headed decision. It can be done gently or pretty harshly. The genius is in figuring out HOW to tell a superior that're full of it.
I've had a good number of engineers (and other professionals) ask me what it took to do my job. My response was "are you ready to be fired?" Product Line Managers, General Managers, and Division VPs jobs are on the line every day if they're actually DOING their job. And a passion for what the job entails is what keeps you going.
You raise an interesting question. From where I sit, "business decisions" need to be made by a constant give and take discussion between engineers and other stakeholders in the business. I'm reminded of a situation from long ago where the company I worked for decided that purchasing (a part of finance) was better equipped to select cost reductions for a product - through "better buying decisions". The only problem was that purchasing, driven by an accounting group, decided that the product cost could be lowered by substituting resisters and capacitors from a lower cost supplier. All was well until the first machine came off the assembly line, and it failed final test. So did the second, and the third, and the fourth - and ALL 100 machines. After days of engineering work sleuthing out the reason, we discovered that the new components had different characteristics than those originally specified in the Source Control Document. Yes, the resistor values were the same, and so were the capacitors, but the performance of the substituted parts rendered the large number of analog circuits unsuitable for our product. That decision cost the company more money than we could save by "better buying." The right business solutiuon was to institutionalize an approvalcycle that required engineering to sign off on all substitutions. More paperwork, but better resulkts. And yes, we did cost reduce the machine by smarter decision making made by all.
I don't think that engineers should be just drones, either. There's no question that cost is important. Every design has an objective, and the objective has to be met within certain constraints. Cost is one key constraint. And there are many others.
But engineers also have the responsibility to set things straight, when management is making bad decisions. Engineers have the responsibility to "sell" their designs to management, and the give and take is part opf the engineering process.
I had to chuckle about the auto example. The implication that engineers must make purely objective decisions, sort of like robots, seems silly to me. Of course, you include objective requirements, but then after those are met, you go with what you like. For instance, I wanted a 6 cylinder engine last time I bought a new car. I didn't want a buzzy four. If I was after nothing more than a people mover, I would have not cared. Engineers who don't care to that degree, in my opinion, leave an very important ingedient out of the engineering process. Passion is important too. Esthetics is important too. Let's not kid ourselves.
There have been research that show people who were cognitively impaired due to sleep deprivation can be quite unaware of this impairment when asked to give opinions on their cognitive state.
Humans seem to fundamentally have a blind spot when it comes to self-evaluation and as Daniel Kahneman remarked, it's always much harder to find our own faults. This goes for people who think they are 100% rational.
Engineers can be especially susceptible to this, as the profession revolves around logic and we have a self-image that we all behave as such.
But any engineer should also know that, there is never 100% of anything under all conditions and that goes for rational behaviour.
Even if engineers consider cost, a better understanding of their business will help them understand which cost is important. I've had situations where I suggested a design change that would save on maintenance costs for our produce, and had it vetoed. Turned out, the management was trying to make the current quarter look good because the product line was being sold to another company. They didnt care about maintenance cost, they cared about current expenses.
Faced a similar situation where I wanted to purchase some tools to improve design effeciency and reduce the cost of completing the design. But my business didnt want the capital expense even though it was less than the operating expenses that would have been saved. Again, it had to do with how the expenses were ranked in priority. It wasn't just the dollard, but when and how they were spent. As I learned the company's objectives for managing its costs, I was able to make "better" engineering decisions - for that situation.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...