A while ago, I started a long story about my experiences working on a project that "two big I" companies developed together. The story starts there, and the previous installment is here.
Today's story is the sad tale of the terrific chipset. One of the two big I companies makes a living designing wonderful, complex chips. Our division's mission was chips that would play video and show pictures on a PC, in a year when this was still revolutionary. The hardware designers asked the marketing planners what the video chip should do. The marketers, basically, said "Everything!" At that time they could foresee most of what a video chip might be asked to do on a computer, but they could not prioritize, nor accept a design that would support only a few choice morcels of the full potential.
The hardware people responded by designing a pair of chips that, together, did Everything. They developed these chips and handed them off to the programmers. Can you see what's coming?
The video chipset that did everything was horribly complex to program (and expensive to manufacture, too). A customer programmer could easily misprogram it so as to hang a computer or even destroy a CRT. One of the big I's programmers was given the task of learning the hardware and writing a software package, a programming interface ("API"), that would make it possible for a programmer to use the video chips safely. He did this. In the process, he supported only about 50% of what the video chip could do.
His API was still to complicated for most humans to use. Another programmer studied this API and wrote two more APIs that used it, one for still images and one for motion video. He implemented a portion of what the first API supported, exposing perhaps 25% of all the magic the chips could do.
The other big I company realized that these two APIs - for video and pictures - were still too complicated to release to customers. (This is a fascinating issue that I will discuss in the future.) They insisted on one more API - to call the other APIs - that would only allow a customer programmer to do safe things easily. That was my job: an API to display pictures and play video EASILY and safely. I eventually doubled the total amount of software and supported less than 10% of what the hardware could do.
Why did each of us programmers support less and less chip functionality? In principle it was possible to support all of it, but it was very time consuming to allow more features while preventing the customer programs from issuing ridiculous command mistakes. Prudence, and a limit to programming resources, dictated a strategy of limiting functionality to whatever seemed safest to support.
The hardware designers knew what was going on, and they were wildly upset that the software was preventing access to most of their chips' capabilities. They could have designed a chip to do the little that I was supporting much faster and much cheaper.
I had no sympathy for them. I believed that Marketing (which was pretty happy with our eventual subset) should have prioritized in the first place. And the hardware designers should have refused to implement Everything when Marketing asked them to.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment