@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.
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.
@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.
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).
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.
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.
@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.
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.
@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.
@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.
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.