I like engineers. On average, they’re smarter, more pleasant, and more useful than most. But engineers, more than any other type of human being on the planet, occasionally fill me with the desire to wrap my hands around their throats and strangle them. There is no other profession that seems to combine such amazing technical ability with an awe-inspiring capacity for missing the relevant point.
Years ago, Chris Taylor and I came up with the idea to use my company’s 3D hardware for games. Since the company was designing a 3D chip that would do shading, I lobbied hard to have texture-mapping included in it after seeing the two Johns demonstrate what could be done with software-based texture-mapping in Wolf 3D. I must have had ten conversations with the lead engineer in which I told him exactly what was required for the game industry at that time, namely, perspective-correct texture-mapping running 1024×768, 16-bit graphics at 30 frames per second. I could tell he wasn’t really listening and didn’t want to look at the information I was providing him, all he would say was “yeah, yeah, yeah, I know what texture-mapping is, I know what I’m doing.”
The chip came out months before NVidia had their first chip done. Jensen Huang even used to call me, posing as a game developer called “Jensen Software”, in order to find out what we were doing and how far along we were. Big Chilly and I had prepared a 2.5D game demo, a sort of sci-fi Wolf 3D that used pictures of me wearing a flight suit and a swimsuit model friend wearing a wolfshead mask as enemies. The frame rate was great, but everything looked wonky. When I asked what was wrong with the perspective-correction, the engineers looked blank and said: “Perspective-correct? We didn’t know it had to be perspective-correct!”
I could have killed them.
That chip ended up being successful in the CAD and Windows-acceleration markets, but the lack of perspective-correction ruined all the deals that were in the works with the various board manufacturers, and the company eventually disappeared as the CAD and Windows-acceleration markets dried up courtesy of the technology curve. All because a very smart engineer refused to pay attention to what the non-engineers were telling him.
For the last year or so, I’ve been working on a new project which I’ve mentioned a few times here and there, and we’re getting a lot closer to being able to speak intelligently about it. It’s going really well, the development team has done an excellent job and the engineers were just testing the last important feature before going into production mode. This feature is not absolutely necessary, but it will significantly add to the utility of the product, at least as far as I’m concerned, and add an additional degree of unique functionality.
So, I was extremely annoyed when I was surprised with the bad news that this special feature wouldn’t work because it was too slow. But, drawing upon more than two decades of doing technological development with engineers, I elected to ask a few very specific questions rather than go peacefully into the dark slough of despair. How slow was too slow? How was the speed measured? The interrogation revealed that the “delay” was measured in nanoseconds, more importantly, that delay meant that it would run at exactly the same speed as related features in every other product of its type around the world!
Translated into non-engineering terms, this means that the feature works just fine. I swear, sometimes I think they do it on purpose.