Predicting when software will be ready to ship is hard. Especially when the software involved is:
- a complete rewrite from scratch of already existing software.
- being written by a completely different team (and company) than the one that wrote the original code.
- a system software component that interacts with virtually every 3rd party app on the platform.
- required to be fully compatible with the existing software, plus new software and hardware in development.
But that was exactly the scenario I was in, along with Rich Blanchard and the rest of the development team, when I was at Adobe Systems circa 1991 writing a replacement for Apple’s LaserWriter printer driver. And the software we were writing was a critical part of Adobe’s strategic plan for preserving its largest income source at the time, PostScript licensing revenue. No surprise that there was a lot of scrutiny about the project and when it was going to be completed.
Years later, the website MacJournals.com did a write up about the project, including quite a bit about what role the LaserWriter driver software played in the printing system on Mac OS at the time. I have my minor quibbles with some of the details of that write up but one thing was true: that software project really burned me to the ground and was a major factor in my deciding to leave Adobe for greener pastures in 1993.
The Definition of Bad Management
There are a lot of stories about the project I could tell that would raise the hair of every software engineer on the planet, but one clearly defines the term “bad management”.
Part way into the project, Adobe hired “Stoy Aho” to manage the project and the engineering team. As far as I could tell, Stoy had no experience managing a software project or software engineers and there was no evidence that he knew how to write software beyond simple UNIX shell scripts. And even that ability became suspect.
As the completion date for the software kept being pushed out (see the bulleted list above for why), upper level management at Adobe started having meetings every day at 8am to discuss the status of the project. Stoy went to these daily meetings to report how things were going. In order to satisfy his need for something new to report, each team member was required to write a status report each day.
But we were converging on completing the software and some of the tension the engineering team members were feeling began to dissipate; things were looking good. So it was a complete surprise when Stoy came to me and told me how worried Adobe management was about the project. It turned out that he was showing them information he had calculated from our bug tracking database. By using the rate we were fixing bugs and observing the rate that new bugs came in, he had potentially useful information about predicting when the software would be ready to ship.
And that is why he was alarmed. Despite our sense that things were going much better, his analysis of the data indicated that they were getting progressively worse. I asked how he computed the results that he obtained and Stoy said he’d written an AWK script to process the raw bug count data. I immediately demanded that he show me the script.
I didn’t know the AWK programming language but it didn’t take me long to find the problem. At a critical point in his computations, Stoy had inverted the numerator and denominator in one of the calculations, causing his script to produce results that were the exact inverse of the truth! His program showed that the faster we fixed bugs, the longer it would take to ship.
Repeat after me: Stoy’s AWK script showed that the faster we fixed bugs, the longer it would take for the software to be ready.
This occurred over 20 years ago so I don’t remember exactly what I said at the time, but I’m pretty sure my response at the time was something besides AWK.