It is a general observation that while selecting the car , the man will looks at the details like the engine capacity, fuel economy, braking system etc while his wife will look at the different color shades and the body styling available. So as a engineer , while designing a family car , the consideration has to be given what women would like as the exterior look of the car and what men would prefer as the engine, luggage space and all that technical stuff.
Many times your boss will have certain bias towards selecting a particular microprocessor while designing an embedded system and by hook or by crook he will convince you to use the same whatever be your technical opinion.
In the early eighties, when 16 bit microprocessors were just getting introduced , Intel's 8086, Motorola's 68000 and National's 16000 were in the race each having a different architecture. In comparison National Semiconductor's 16000 architecture was much superior technically compared to the segmented architecture of the 8086. But Intel 8086 prevailed over others just because IBM PC was designed around it ( initially 8088 based) and the whole world had to follow the 8086/Microsoft windows combo for the IBM PC compatibles whether they liked it technically or not.
"Gaining a better understanding of business will make you a better engineer."
Of course! Engineering is the busines of designing products that will earn profits for your employer. Cost is always a major variable in any design, and often drives design decisions. How can engineers not pay attention to cost?
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.
@RichQ The "biger picture" can force some decisions that don't look reasonable on their face.
Around 1980 my deveopment nteam had created a universal microprocessor and microcontroller development system based on a personal computer. I had to twist a sister division's arm to make a version of their in-circuit-emulator controlled by a serial cable. Our combined system sold fast and was making a big splash in the market.
Then the CEO pulled the plug on the next version of the development system and transferred responibility to the other division. I got a promotion, but the careful plans had been dashed. I later found out why the move happened when the company was acquired by anothr fiem. The decision made perfet sense then - the sister division looked stronger on paper and fetched the company a higher price.
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.
"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.
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.
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.
@nelso53 Let's not forget that the IBM PC sttled on the Intel architecture for many reasons. Having been on the edges of the dynamics that went into the PC decision, it's cricitcal to remember that the final fly-off was between the Motorola 68008 and the Intel 8088 - The TI 9900 familt was out of the running. The decision came down to a non-engineering decision (the 68008 was preferred) when Intel agreed to allow IBM to make or have made 8088 family members. A little-remembered fact: IBM took a minority interest (but very important) in Intel.
Henry, very inportant points. Market drivers have been principal drivers that trumped many Engineering decisions, and will continue to be an important driving factor. Business considerations will continue to usurp optimum designs particularly in the highly competitive Micro market. Thanks for the comments.
@henry, often, purchasing decisions overtake engineering decisions. In some companies, you don't design in a part unless there is an alternate source. That's because of price or delivery issues. But as we often know, a second-source isn't always identical, especially in an age of counterfeit parts.
@MeasurementBlues boy you said a mouthful! In addition to my experience with "better purchasing" I once had a clerk who decided that a smaller memory was cheaper, so substituted a DRAM one quarter of the specified size ... fun!
My father was a purchasing agent at several electronics component companies. He'd come home and tell me how the engineers didn;lt understant th real world whenever they specified a single-sourced part. From his perspective, there was never a good reason to do that. He didn't understand that sometimes that's the only way to build a product that did its job.
He also would come home and say how management was just as clueless.
I worked for a company that was a distributor of electronic test equipment. When we started developing our own products, we actually needed an oscilloscope. The comptroller couldn't believe we had bought a peice of equipment that we weren't going to resell.
The scope didn't have the bandwidth to be useful. Why? because management made the purchasing decision without consulting anyone.
How much did software enter into it? My understanding is that a big advantage of Intel 8088 was that you could machine translate 8080 assembly language into 8088 assembly language so that you could quickly and cheaply port 8080 software and take advantage of an existing software base. My recollection is that there wasn't much appropriate 68000 software available in 1981.
Plus, there were two 8086 operating systems available: MS-DOS and CP/M-86. I don't know what was available for 68000.
I remember that people complained about how slow programs ran on PCs versus Z80 systems. This was because the original PC was a 4.77 MHz system while Z80s were usually 8 MHz. When running machine-translated 8080 assembly language, the 8088 was only running 8-bit instructions and wasn't taking advantage of the higher-performance 16-bit instructions, so it was slower. It took a while for 8088 software to be rewritten to use 16-bit instructions and gain an advantage over Z80.
True on the IBM - Intel deal is that investment decisions often dominate buisiness decisions - Have seen this many times where a large investor will pick a small reasonably well done partner over an established player for the very reason of capital gains.
Besides this example one had investors picking RIM and pumping money into it over then much larger Nokia who also had it's Symbion line of Smartphones. Both have grew and faded in the course of less than 20 years.
Have also seen many very bad decisions by investors forcing a product launch a few months too early -- Look at RIM's Z10 and Q10 -- a few more months to get all the apps populated and vetted into the apps store would have greatly improved the success for an OS that is everything Android OS should be but is not.
@MS243 I used to keep statistics on venture investments (as far as data was available). There are a great many examples of a long term bust in technology that still amde good returns for the earlier investors. Even once high flying SUN got bit and the sahreholders at the end lost significant value (they may have regained some with the pujrchase by Oracle). But for some of my good friends who joined SUN in the early 80s, their "retirement" fund took a bath.
@betajet Good points! The "automatic translagtor" certainky existed, but on a practical basis I know few who actually used it to port code from the 8080 to the 8086 in production. It seemed like a good idea, but porting 8080 code wasn't that valuable because software architectures for the 8080 family often had specific paging algorithms built into the software to overcome the limitations of the memory space. And, as you say, te translated code didn't take any advantage of the 16 bit instructions. In experiements that I ran using the translation tool, the resulting code ran slower on the 8088 than the same code did on the 8080.
There were actaully a number of OSes offered for ther x86 - including SDOS which Microsoft licensed to enable them to host code on the x86. The original license only permitted Microsoft to resell object code for the OS. Microsoft's decision to license the source code to IBM was the object of an intellectual property dispute that ended with an out-of-court settlement in which Microsoft paid the founders of the SDOS product an undisclosed sum.
At the time, CP/M 86 was probably the better choice for software availabilty.
UCSD Pascal also included an OS kernet for the x86 and 68k. Southwest Technical Products had 68k software avaiable. Programming tools for th 68k, incouding Unix, were generally superior to their x86 cousins. There was a very large code base for the 68k because of the SUN (Stanford University Network) platform.
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.
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.
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.
It goes both ways? Not any more, at least not for me.
Earlier in my career I used to work for small to mid-sized companies. Not only did everyone in the company know the director of engineering, they frequently turned out to be the sort of person you could "buttonhole" in the coffee line and start up a conversation. Not only were they willing to discuss decisions, in many cases these had been made either by them personally or in collaboration with other management, and to some extent involved issues that were difficult to decide which they had wrestled with before resolution. They were proud not only of the decisions themselves but of the process that arrived at them, and some even figured out loud that encouraging such a level of "critical thinking" among the staff could only improve the level of both competitiveness and product quality.
Sadly I long since moved on to do contract work which involved mostly working with larger organizations. Independently though these decisions are frequently made nowadays MUCH higher within the corporation, and the chief engineer feels lucky if he's even sent a copy of the PowerPoint presentation from the meeting where the results of the decision were presented. Sadly too companies now are run by a process that I refer to as "spreadsheet management", where the fate of entire divisions will depend on the value (or sign of the value!) contained in a single cell on a spreadsheet many yards in each virtual dimension, with rows full of mostly inscrutable equations describing "management controls". Actually attempting to comment on (or even just spend the time to evaluate) what used to be regarded as "engineering decisions" generally brings on at least the calumny of your supervisor if not the absolute termination of the assignment.
I'll illustrate this with an example that actually happened to me. I was brought in a while back on a contract for a major avionics systems company to help update the architecture of a legacy component called the CMS which is a communications item. In order to save on development the new design was going to be based on whichever was the current version of Windows NT at the time (yes this was well before the proliferation of Linux). They wanted to incorporate satellite access to the internet so the customer could charge the commercial passengers for access. When I took the assignment I was handed a copy of the Microsoft Project printout detailing the activities of each staff member - for the next TWO YEARS! The item they wanted help with was the satellite link was only accessible through the X.25 protocol so they needed a driver. Now the level of management that was closer to me had already decided that they would pay an outside consultant to write such a driver for NT. Their schedule was absurdly tight and as I recall did NOT include time for the writing of a formal specification for said driver, which is generally a recipe for disaster - and they were going to count on ME to get it working! But I didn't even get a flavor of how much trouble the project was really in until I found out that the satellite link was intended to connect via "low-speed ARINC 429". OK, try and imagine a plane full of overstressed business travelers each on their individual laptop - where the AGGREGATE THROUGHPUT for the entire AIRPLANE was constrained by the whopping data rate of the 14 kbps ARINC channel, and of course they were paying a premium rate for the "privilege"! I of course made the hideous mistake of pointing this out, instantly causing them to have to reprint and redistribute the Project file for those two years - with my name omitted of course!
Like you I'm not real sure the way they're doing it now is "progress", but of course my management friends have absolutely NO IDEA what I'm talking about...!
I can tell you pretty much how "MBA education" has affected how companies are run from what I've observed. It's led to the following conclusions: "financial engineering" is real and valuable, "technical decisions" are vague, malleable and worthless. Managers are all brilliant leaders who never err in judgment, engineers are marginally competent boobs who are really crying out for leadership but are too ignorant to realize it. Short-term thinking can influence tomorrow's stock price and is therefore of the highest importance, long-term planning is only valid if it fits on a spreadsheet. We mere engineering mortals are also supposed to realize that failures that appear to have resulted from financial mistakes, like Long-Term Capital Management and Lehman Brothers, are really too complex for our small minds to accurately comprehend, but to "real managers" this is all easily understood and appreciated. According to this line of thinking Henry Ford was an idiot when he paid his workers a decent enough wage so they could afford to buy his company's products, he ought to have been smart enough to sell them to the Chinese or someone else because clearly you want to keep your own workers just barely on this side of survival and just one mistake from the poorhouse. Sorry, my take on it is I don't get why Shakespeare wrote that "the first thing is to kill all the lawyers" (Henry VI) when the MBAs would have been at the top of MY list - well, a lot of the time anyway!
@JeffL_2 In the 1980s there were whole herd of authors, consultants, and professors proposing ways to make your company attractive for merger or acquisition. And they could be used to change a company's balance sheet to make it unatractive for "green mail." One of my personal favorites (in a positive way) was proposed by Michael Hammer in his book "Reengineering the Corporation: A Manifesto for Business Revolutio," where he states that the goal of any business process improvement initiative should be to radically improve the activities in the company or even revolutionize them.
Hammer had a lot right. Alas, when the only tool you have is a hammer, you v tend toiew every problem as a nail. Unfortunately many corporate managers had but one tool that they understood: accounting. The fastest way to improve a balance sheet in the short term is to lay people off. Undereducated or under-experienced managers took this simplistic approach to solving short term cash problems, together with a lack of understanding of engineering specialties, wiped out the "greyback" engineers.
One very large company that I consulted for, offered an incentive package for early retirement to emplyees with a certain amount of years with the company. Middle mamagement took the package in droves. And execs were clueless that they had just encouraged their most capable people to leave. What was left were good employees who were missing vital pieces of HOW to accomplish their job. I, and other consultants and contractors, were paid to lead these emplyess through the whole of their jobs. At least management figured out the problem.
As someone that has mostly done Engineering for the past years, I have a strong opinion on this, which of course might not match your own experiences.
First, stating that "Engineering" is more than "Engineering Decisions" can be a double-edged sword. I say this because although I feel that it is desirable that the engineering gets involved in the upper layers (meaning customer relation, product development decisions, company focus [this one is the most important IMHO], shareholder happiness).
Engineering has (in some cases, most of the times) a clearer, more focused view on what marked demands, and how to fill those demands in a profitable way. Upper layers are often misguided by short-term (or even by bad) market prospections, and never (or rarely) hear what the engineering teams says in terms of feasibility, time-to-market, and long-term evolution. Unfortunately, not only is this my opinion, as it happened to my company in the past.
But, when the Engineering gets into the customer and business areas, this can fight back. Although, I do admit, I think that Engineering not only should but must be present in these areas, some of the Engineering decisions and opinions are opposite to the "make a lots of money, and make it quick" view of the upper layers. Engineers tend to consider things in a more, let's say, sustainable way, than the CEOs and the Product Managers. Engineers not only know the "can we, how do we", but also "for how long can we do this before clients start flooding the support lines". But if anything goes wrong, that is Engineering fault - and it is not.
if a project fails, it is not only the upper management that fails, also the tecnhnical areas fail. However it is the responsability of the technical areas to do a proper exposition of the antecipated issues to the management. If this is done as usually is, and ignored as usually does, then it's not an engineering fault, it is management fault.
To sum up,
The Engineering should overcome Management!
The Engineering and Management must not compete between each other, but rather find some sort of symbiosis so that at least the Engineering team can participate in the upper management of the products and the company plans.
A bit out of topic, let me leave you one of my favourite quotes:
"Engineering is not about making perfect things, but making things that work perfectly". (My own).
One of the hardest business concepts for many newly graduated engineers to grasp is that public companies (at least in the US) have a duty to their shareholders to maximize return to shareholders. That inconvenient truth is at the center of many disagreements from all areas of a company, but especially engineers.
Henry says: One of the hardest business concepts for many newly graduated engineers to grasp is that public companies (at least in the US) have a duty to their shareholders to maximize return to shareholders.
Ah, but is that short-term return or long-term return? Short-term return says to eliminate costs -- such as product development -- so as to maximize short-term profit. Long-term return says to invest profits in developing future products that render your current products obsolete. After all, that's what your competitors are doing. Generally, you're in more danger from lawsuits by speculator-shareholders who want short-term returns, so to Hades with the long-term health of the company. JMO/YMMV
@betajet Sadly, short term often wins out over long term health. BUT, it isn't often taken to the extreme of eliminating new product development. Someone once said that the semiconductor industry is the only business requiring you to "bet the farm" for every new major process node. Maybe that's why companioes like Intel continue to pour money into new product development - if you're going to bet big, you might as well go all in.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.