010. Our BillG Review

Back to 009. Password is NeXTStep

The story of my first BillG review, except I’m too junior to attend. Soon I will find myself doing nothing but BillG reviews for almost two years. For now, I had to sit out this transformational meeting. All is not lost as I was on my first business trip which also proved transformational.

Jeff scheduled a BillG Review for a week or so after App Month. I could not imagine why as we had nothing to show so it seemed like an opportunity to get yelled at. Still, Bill was anxious for our progress and Jeff, having learned some valuable lessons about overpromising, was careful to moderate Bill’s expectations. But the prospect of a looming BillG Review was intense, I quickly learned.

In 1991, a BillG Review was a big deal, a really big deal. The company was large enough that most teams were not having routine (say monthly) in-person contact with Bill (though email was nearly constant), but it was also small enough that he knew most of the key developers and program managers, especially on the main products. AFX was a main product, sort of as it had the attention of one. Our team was small and I was too junior and never shipped anything so obviously wasn’t invited. I felt left out, but I also relieved. I was too new to be called stupid or to say “the dumbest thing” BillG ever heard. I had not established my “IQ”. These were all examples of well-known Billg-isms, right up there with rocking back and forth in his chair. But still I felt I was missing out.

The team was supposed to show Bill our progress and how close we were to state-of-the-art tools for GUI and beating Steve Jobs at his own game. Any indications of progress were poor. Our code was big and bloated. Our tools were not revolutionary. We could not create GUI programs quickly. But we understood the existing tools well. We wrote many memos on how NeXTStep, Borland, ET++, and several other commercial products were superior to Microsoft’s lack of products.

Jeff knew Bill and understood how he worked better than most anyone. Jeff asked us to put together our materials—literally printouts of code, APIs, benchmarks of memory usage, competitive product briefs, and more—and assemble them into a binder. Back in those days a “good” review came with a big binder of papers that were sent over a day or so before the meeting so Bill could prepare. Bill read everything. Bill remembered everything he read. Jeff knew we had to be buttoned up, of course.

We also knew we had been poor engineers.

I spent many evenings standing in RickP’s doorway talking and learning from him. Rick was the nicest, most thoughtful developer and, at the same time, he was unbelievably hardcore, the ultimate Microsoft accolade for a developer, focused on every line of code, every byte of memory, and every CPU cycle.

Ahead of the BillG Review, he did a group presentation summing up his App Month. He had slides—everyone was flummoxed! Rick never made slides or even led meetings. Our conference rooms had overhead projectors so when we used slides (which MikeMap referred to as the IBM word foils) we prepared them in PowerPoint (or Word), printed them out, and then photocopied them onto transparency pages.

The title of Rick’s talk read, “What Would Make Rick Happy?”

Through a series of slides, Rick took his perspectives of building real shipping apps and his hardcore focus on performance and reliability and defined a broad set of criteria for how a reusable framework should be built. He played back all the choices made on the Excel layer system but applied them broadly. This presentation hit me like a 16-ton weight. He converted me to a performance zealot in 20 minutes—a transformation of the highest order. Whenever I encounter a buggy, slow, fat product I think back to how unhappy that would make Rick and ask myself, “What Would Make Rick Happy?”

In addition to being hardcore about performance and bloat, Rick made a number of incredibly astute observations that would carry great weight moving forward in terms of distinguishing our product. First among those was that we tried to “fix” the operating system. We took building a cross-platform framework as a chance to cherry pick the best concepts from each target operating system, or more likely simply our favorites. We thought of that as making a new and better OS. In fact, it was just different.

Jeff had a great way of describing this both to BillG and back to us. He would remind us that the OS groups were huge teams of 100 engineers compared to our team. How could our tiny team possibly “compete” with those big teams at designing an operating system. Even more straightforward, was how could our team of one contract documentation writer compete with the dozens of books about programming Windows, Macintosh, or OS/2 that filled Tower Books. There would never be enough to learn about our framework. What is amazing about this point is that literally every framework was doing this same sort of fixing of operating systems. Even more amazing, this tradition of cross-platform tools inadvertently creating new platforms without the resources to maintain or document them, or even to be competitive continues to this day.

Rick also had some other observations about working with an operating system that proved especially important as our strategy would unfold after the BillG review. In particular Rick cautioned about redundancy and reimplementing concepts already in the OS. A common example was how the OS maintained a list of windows but so did the framework. Not only was that more memory, more code, but it was a chance for the two lists to disagree, and introduce bugs. The whole concept of not maintaining copies of information the OS already had was critical to performance. If an app needed to know something then there needed to be only one place to look.

In general these observations, rules if you will, formed the foundation of what was to come. They were more than observations or theories, however, as we learned them from our experience building the framework that didn’t work. Jeff felt leading with what we learned was a key way to engage BillG on failure. These concepts proved the core of what we learned.

Up until that point, I had almost exclusively only interacted with other software design engineers, developers or devs as we called ourselves. A unique role, particularly in Apps, was Program Management or PM. PM originated in the Excel team as a role responsible for making sure the product being built was easy to use, met the needs of customers, and achieved business goals. The role came about as a way to make sure developer schedule time would be used more efficiently by avoiding false starts and rework, while connecting the dots between the ever-increasing number of features.

Prior to the introduction of PM, most debates about what to build were settled by the developer writing the code and based on what they felt was right, however they defined right. If it didn’t work out then it would be rewritten. If developers did not agree, an endless email thread ensued, and continued until someone got bored or more likely the most forcefully expressed point of view would win. We called this pre-PM era “testosterone-based development”. PMs created processes reflecting customer needs in the product, at least something more than just asking friends in the hallway which constituted feedback and planning in the early days. PMs also represented the product to other teams and was generally viewed as the face of the team, even though they were peers with development and also software test engineering.

Generally PM led the BillG Review. Clif Swigget (ClifS), who joined from the Macintosh apps team where he worked on a well-known database product called Microsoft File, jumped right in. What a challenging way to begin. ClifS and the team were as ready as they could be for a meeting where we basically had nothing but a year’s worth of learning to show. BillG was not likely to be impressed by mere learning.

To sum up our learning we referred to our “condition” as oopaholism. That’s how we described ourselves to BillG.

We drank far too much of the object-oriented programming Kool-Aid, using techniques and approaches that might be good in academia or look great on paper but were wholly inappropriate for building industrial-strength, commercial software at scale. Maybe this was naïve, but every new wave of technology comes with it a certain amount of religion and zealotry, even if it isn’t immediately practical. There was an optimism that the new way would solve all the old problems and be better, faster, easier, and cheaper. In reality, things almost never worked like that. OOP proved itself to be more of a passing fad and a lot less than a whole new approach. OOP influenced everything to come but was not the change-agent the zealots believed it would be. A recurring theme in new technologies is how often the first try at something serves, to a much larger degree, as inspiration and influence rather than as a foundation for implementation.

My contribution, entirely a failure, was about to go through my first BillG Review, and it terrified me. Not only was I not at the meeting, but I would be out of town when it took place. That was a blessing, as it turns out.

While it was happening, I attended the 1991 USENIX C++ Conference in Washington, DC. As conditions for attending, Jeff insisted that I fly coach, book a cheap room, eat no elaborate dinners, and, above all, I was to write a trip report and lead a group meeting on what I learned when I got back. It wasn’t just that Jeff believed we should spend Microsoft money like it was our own last dollar, but that spending should result in a contribution to the group not for the benefit of one. The worst part: I was OOF for a couple of days. OOF is common tech community jargon originating back with mainframes meaning out of [computer] facility that also had a specific implementation in Unix email where you could leave an automatic reply message with the details of the absence. I edited my .oof file saying I’d be back by the end of the week and detailed the conference I was attending. Before the broad use of mobile phones and laptops—a ubiquitous Compaq LTE laptop was still more than a year from reality—I was able to check my voice mail using my Microsoft AT&T calling card, something I’d do at the inevitable layover at the ORD United terminal. Those were the days?

The conference seemed small, and everyone seemed so grown up. They had big titles, like chief scientist and vice president, and they were with big companies, like AT&T, IBM, General Electric, and Texas Instruments, but unlike me, they were real adults. It terrified me. I made the rounds, booth to booth, sporting my first ever conference badge with Microsoft affiliation, and in the small hotel ballroom used for the main session I quietly sat in the back row, quiet and intimidated.

Over the course of the conference, about twenty papers were presented, and all were extremely relevant to what I was working on. Long before there was Linux, there was UNIX, the famed operating system from 1970s AT&T Labs favored in academia and research. USENIX was more of a bottom-up conference of system administrators, programmers, and scientists, all working on the leading edge of the UNIX system, not a highbrow academic conference. The C++ language originated from this community, and the first gatherings focused on C++ language design were hosted by this group. Unlike the strictly academic conferences I followed in graduate school, the USENIX conferences were geared toward industry or at least non-tenure track faculty.

The debate at the conference centered around the controversy over evolving the C++ language, which at the time seemed premature. This was a language almost no one was using commercially and with almost no tools support beyond UNIX, but that’s the world they worked in. Contributors debated the use of “proposed” C++ features such as multiple inheritance, templates, and even my old favorite, garbage collection. All the while there were reports about new class libraries being developed everywhere.

In one small session, Martin Carroll, a well-known AT&T C++ proponent, gave a talk on some detailed aspects of the language, and toward the end in Q&A someone asked about using the feature in their code. The answer was something I would use for years. “You’re writing code for your product, not a compiler test suite,” meaning the presence of a feature in the language didn’t mean it had to be used. There was no reason for code to touch every language feature. This presentation later led to my own version of “What Would Steven Like?” My thoughts were racing with ideas to develop a set of rules to govern our use of C++ while making sure RickP got what he wanted for performance.

When I got back to the office, I was anxious to hear how the BillG Review had gone. Unsurprisingly, my voicemails pining for details had gone unanswered.

Was BillG in a good mood? Did anyone say the “stupidest thing” BillG had ever heard? Was there yelling? Did anyone get called “random”? Maybe someone was called “high IQ”?

A BillG Review was generally viewed as an exercise in survival more than an opportunity to shine. At least that’s how we, the broad base of people who only heard about the meetings after the fact, perceived them.

I walked the hallways in search of the scoop. Given that we had nothing to show and that Bill was anxious to compete, ScottRa, who attended the meeting, said that it went “as well as could be expected.” He said there was no yelling but a strong sense of disappointment. Jeff, I was told, took the brunt of the negatives and discussed many of the challenges—tools that didn’t yet exist, cross-platform development, new team, and new technologies. ScottRa said we needed to come up with a plan.

Finally, in a hallway chat, Jeff later reiterated that the meeting was rough and Bill was disappointed but he “behaved,” and that Scott and others did well. The meeting was replayed a dozen times that day pairwise. Each of us must have heard the story several times from each participant, trying to gauge the tone and every nuance. It was like hearing about an amazing concert that I didn’t get to attend, but instead of music it was my future career at Microsoft.

Jeff detailed the meeting summary from BillG. It was not the kind of summary anyone expected.

He said that Bill concluded the meeting by saying something like, “It is disappointing that we haven’t made the progress we would have hoped. But it sounds like the team has learned a lot while making many mistakes. The thing we can’t do is make those same mistakes again while we come back as soon as we can with a product that is competitive.”

That sure didn’t sound like the BillG we were all terrified of.

As Jeff explained, Bill appreciated learning and understood, if not embraced, the failure that could happen while learning. While at events like intern parties or new hire gatherings he often told stories about appreciating failure (like Xerox not capitalizing on the invention of the GUI), he never seemed to use examples of failure from within Microsoft.

It was a relief. It would also foreshadow that the caricature of BillG was not always the same as BillG the manager, leader, and CEO. At least I had one counterpoint.

I still had to give a presentation on my trip. My presentation about what I learned was presented as a series of new rules for using C++ that we should follow. I won’t dull down this exciting story with a diatribe about programming language design but suffice it to say we took to heart the idea that as powerful as OOP was, using C++ as a better C would be our hallmark. We would apply RickP’s and the Microsoft hardcore ethos to OOP. I don’t really know what made me assert all this stuff in what was supposed to be a trip report. In hindsight, I think I was just totally jazzed by attending a conference and also in a bit of a panic over what was now coming up on my second anniversary with no shipping code. Maybe it was just that we made it through the BillG review, though that was all Jeff’s doing.

From that point forward, we became reformed oopaholics. AFX was the hardcore OOP group. We still had no product plan, but as a team we lived through a failed project and as I know now that is something that can become a team building experience. I don’t think BillG was thinking about that point, but Jeff certainly was.

Not only did we survive what should have been a horrible meeting, but at least by Microsoft standards it was motivational. We were given license to regroup, plan what to do, but to execute quickly. We needed a focus.

Focus was difficult to come by given how many operating systems or platforms we were on the hook to support. NeXT only had to support one. Apple Macintosh only supported one. Microsoft was, on its own, building MS-DOS, Windows, OS/2, and supporting Macintosh, and more…

Shipping would clarify things. Shipping was everything. This was just sinking in for me. If you’re not shipping you’re literally not doing anything. Excel 3.0 had just finished. This was the version of Excel that took advantage of Windows 3.0 memory management and also worked on the Macintosh. It was an amazing product.

It also shipped 11 days later than its original schedule. A noteworthy event. A memo was circulating about a talk Chris Peters (ChrisP) gave as a TechTalk to developers. I did not know Chris personally, yet. He was already a legend in the hallways and JonDe’s manager. His talk was Shipping Software On Time and by all accounts he was the master of the new shipping software religion in Apps based on leading the Excel 3.0 project. The memo hung on my relite for years (yes, my relite was crowded). This memo meant everything and was also everything we were not doing.

The essence of the memo was commitment and accountability to a ship date, not a target ship date, not a date like “first half” or “second quarter.” Those were, as Chris would say, “180 dates” or “90 dates”. There are many variables in a project, the ship date cannot be one of them. He went on and on about shipping. Everyone on the team has one job, “SHIP PRODUCTS”. And to really hammer the point he explained how everyone else comes to work trying to prevent a team from shipping. Hardcore. Hardcore Software.

We needed to ship. Something. Fast. On time.

On to 011. Strategy for the ‘90s: Windows

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hardcoresoftware.learningbyshipping.com