One way to deal with poor communication on a software project is simply to ignore the people around you and do what you wanted to do anyhow. Of course, this strategy can backfire, especially if you don’t know what you’re doing. But in that case, you probably won’t know enough to notice it backfiring, so it will all work out in the end.
That’s what I did at my first job. Well, I considered it my first “real” job, though it was my second steady job after I quit the grocery store. And you could have called the IT job I had previously held a “real” job, because it did involve some programming. But I considered this new job the first of my then-yet-to-be career. (Looking back over the past 20-something-odd years, I wonder whether I ever had a truly “real” job, or whether they were all just time-fillers until I figured out what I really wanted to do with my life.)
This company originally hired me as an electronics lab technician for the summer, after I finished my freshman year of college as an electrical-engineering major. Because I was only a co-op student, they paid me bargain-basement wages and gave me less than zero respect. This didn’t bother me, because I was young and impetuous and didn’t care what the old fogies thought. Still, the job turned out to be wonderful practical experience, and I continued working there part-time even after classes resumed. And it turned out to be a career-changing opportunity.
At this company, we made centrifuges. A centrifuge is a finely tuned piece of laboratory equipment, a complex, electromechanical device whose sole purpose is to spin stuff around really, really fast. You may have seen one in your doctor’s or vet’s office, that whirring, little box that spins your blood around at thousands of rotations per minute, until it’s dizzy enough to be psychoanalyzed. I started working there just after they began designing centrifuges with computer brains inside them. (Hereafter, I will use the term “microcontrollers” rather than “computer brains,” because I want to sound smart.)
In a turn of fate, I designed one of this company’s most innovative, microcontroller-controlled control systems–which sounds way smarter than “computer brain”–and I ended up dropping out of the electrical-engineering biz and taking up software engineering, forever.
It all began when my manager asked me to investigate a new microcontroller, the 68HC11, or “HC11” for short. The HC11 wasn’t actually new technology, and they actually didn’t want to use the HC11, but the old microcontroller they had been using was so obsolete, they couldn’t get parts anymore.
This company, like many, suffered under a caste hierarchy among engineering disciplines. The mechanical engineers were in the top caste, and electrical engineers were second-class citizens. This couldn’t have been good for morale. During the time I was there, everyone in the electrical engineering department quit, one by one, except for the manager, who left soon afterward.
As engineers left for greener pastures, another co-op student and I gradually took on more and more of the responsibility of developing the hardware and software for new products. And when the software engineer quit to take a better job, I ended up writing all of the the embedded software.
But if electrical engineers were second-class citizens, then what were we, the electrical co-op students? I already mentioned that they gave us less than zero respect, and this didn’t change just because we were now doing real engineering. Even though we were doing much of the design, we were never invited to the project staff meetings. And we were never consulted on specifications for the products we were designing, even though we understood the designs better than anyone else in the company. But I found a way to get back at them.
I was tasked with programming the embedded software for the first HC11 product, soup to nuts. I asked the hardware engineer to make a simple, harmless change to the tachometer circuit, which measures how fast the stuff is spinning in the centrifuge. This was to make my job easier, or at least that’s what I told the hardware engineer. In reality, the change allowed me to measure how fast the rotor was spinning about 100 times more accurately than was ever possible before.
Using the power of the new microcontroller, the HC11, I designed revolutionary, new tachometer software, coupled with a revolutionary, new motor control, which actually modeled the physics of the centrifuge. By the time I was finished, the display showed the rotor speed to within 10RPM, but in reality, the system was controlling it to well within a tenth that. None of this was in the product specs–which, by the way, I never got to see. But it was too late, we joked, because the feature was already in code, and I couldn’t take it out now.
This was a huge surprise to the marketing guy, and when he found out–or so I was later told, because I still wasn’t invited to the project meetings–he stared wide-eyed and exclaimed, “How long did you plan to keep this a secret!?”
Since then, the company has changed ownership, and the product I worked on has been discontinued. (Although you can still find it on the used-centrifuge market.) I don’t know whether any of the new centrifuges use the same software, or whether it was all too complicated for the programmers who followed me to figure out.
And I also tend to think the marketing guy was probably overreacting, because the centrifuge market doesn’t seem to care so much. Faced with the same situation again, there are some probing questions I would ask first about the true requirements of the project, before I went off half-cocked and designed a whole new, exciting control system.