013. End of the Beginning
"I need to get off my feet." — Julie Larson (JulieLar)
It is 1992 and we’re finishing up the release of what would become Visual C++. Powering through the battles of naming a product, engaging on reviews, and figuring out what comes next keeps us all busy. At a Seattle-area event learning why Aldus (of PageMaker fame) chose Microsoft C++, I meet a career-long colleague. It is the end of the 16-bit era of Windows as far as developers are concerned, and the start of the Win32 32-bit era. This concludes Chapter II.
Comments for this post are open to all newsletter recipients. I welcome feedback on the journey so far and the structure of this work.
Back to 012. I Shipped, Therefore I Am
As we closed in on release mid-1992, the product needed a name. Naming products at Microsoft was known to be somewhere between painful and traumatic. That proved to be so for my first experience.
I already learned that my accidental naming of Microsoft Foundation Classes caused two problems. One was a cease and desist from a French bank over the use of the acronym MFC as software and banking were the same trademark category. This made us spell out Microsoft Foundation Classes everywhere which led to the second problem of absurd complexity and grammatical gymnastics in our volumes of documentation. Oh well.
It was clear the compiler was going to be version 8 because compilers just get version numbers (and continue to). C8, as everyone called it, ultimately became the world’s best and most industrial strength C++ compiler. It was an achievement.
MFC 1.0 (I’m stubborn about the acronym here) was officially bumped to version 2.0. Class Wizard and App Wizard names remained. Composer became the visual centerpiece of the product and gained the name App Studio, which was how we competed with NeXTStep Interface Builder.
Naming the individual pieces was easy. What to call the entire product was tricky. Microsoft was notorious for finding it difficult to arrive at simple names. In this case, calling the whole collection of tools C++ 8.0 or something descriptive, and the logical successor to C/C++ 7.0, seemed lame and not all that competitive with Turbo from Borland. As we debated, some advocated reusing the Quick moniker, but that represented the low-end or amateur programmer. It was complex.
In the meantime, Microsoft Languages had a huge hit product on its hands, Microsoft Visual Basic or VB. VB came from out of nowhere—it was a combination of Microsoft’s BASIC language runtime with a Windows-based “forms” editor and runtime, an idea originally seeded by an email question from BillG. A runtime or runtime library provides programmers with additional capabilities that can be accessed by the programmer as a form of reusable code. Some runtimes provided simple capabilities such as basic math functions while others can provide sophisticated capabilities for creating games or connecting to databases. Runtimes were in many ways the heart and soul as well as a secret ingredient of the early PC era. Basic had a runtime. dBase had a runtime. Runtimes were even a vibrant market where developers could buy special purpose ones for use in their applications. These runtimes presaged the world today of APIs and services.
GUI forms were windows with buttons, checkboxes, menus, and more associated with them—BillG loved forms and would spend the next decade pushing for more and better implementations from many different groups. VB pioneered the ability to rapidly draw a form then use the BASIC language to program all the logic of an application, called code behind forms. VB 1.0 released approximately 18 months earlier but took the world by storm, particularly among professional developers inside of corporations. In code name shorthand, VB was Ruby plus EB, EB was short for the embedded BASIC runtime, and Ruby was the code name of the forms package, and together had the codename Thunder. A version of the forms portion was created independently by Alan Cooper and acquired by Microsoft. Alan was later honored as an original Windows Pioneer and is known as the Father of Visual Basic for his work.1
Coincidently, Visual Basic was also loosely an ancestor in the Quick family of products and the original editor and development environment derived from QuickBASIC. It seemed logical then that the new C++ product should take on a similar naming scheme.
There were a lot of meetings, a great deal of consternation, and even some lawyers. It turned out that the success of VB spawned a cottage industry of people registering product names derived from Visual, before Microsoft. The various Languages marketing teams agreed to start a family of products, first with Visual Basic and then Visual C++. Microsoft also worked to secure a few other visual names (though Visual COBOL never made it to market). While we called the product VC++, BillG stubbornly insisted on calling it VC for some reason.
Just before we launched Visual C++, I attended a fall 1992 meeting hosted by Microsoft at the original Northup building (Microsoft’s second Bellevue location after moving from their downtown location in the early 1980s) down State Route 520 adjacent to Burgermaster, then home to Microsoft University (a.k.a. MSU), which created books and training materials for Microsoft products. At this meeting, local commercial companies talked about their experience using the new C++ compiler and tools from Microsoft—specifically, why they chose Microsoft over Borland (which was all we cared about).
Seattle was home to a couple of large independent companies building Windows software back then. The largest among them was Aldus, creators of PageMaker and inventors of the desktop publishing software category. PageMaker was an early Windows app and one of the first to require a mouse, and it was also a big product with a lot of code. Winning them as a customer over Borland was a big deal.
When it came time to present, the PageMaker engineering manager made a strong case for why Microsoft’s product was solid. She presented a full suite of Aldus benchmarks for compile time (the time to produce a running program from source code) and runtime performance for key operations (PageMaker was computation-intensive and highly dependent on how well C++ created code). She also talked about the transition from C to C++ and value of a standards-compliant compiler like Microsoft’s in their rewrite of PageMaker for modern Windows. All in all it is fair to say she did a great pitch for Microsoft. Sitting in the back with a few members of the team, we were beaming with pride.
After the presentation I went to thank the speaker. She introduced herself as Julie Larson. We talked for quite a bit in the parking lot about their internal C++ library (which sounded surprisingly Old AFX like as described by another speaker, the architect of that), and after a while she mentioned it was late and “I need to get off my feet” as she glanced down towards the ground. I was a bit confused by that comment and then realized she was pregnant, something I might have noticed at first and then did that awkward thing one might do to avoid looking down or commenting (Microsoft would soon experience its first baby boom, having just gone through a first wave of thirtieth birthday parties). I mention this only because while on leave with her new daughter Katie, she was recruited by Denis Gilbert (DenisG), the new general manager of VC++, to join the team. This chance meeting and Denis’s strong recruiting work began an incredibly important Microsoft career. JulieLar would go on to be a key leader, along with many alumni of the VC++ product cycle, in the elevation of Visual C++ to the Visual Studio product line. Later, she became arguably the company’s most significant leader and manager in building human-centric Microsoft products. For me, meeting her was the start of an incredibly important product development partnership.
Leading up to the launch event, I was quite busy learning the ropes with the press—something that I would end up doing a lot more of for the rest of my time at Microsoft. The focus of the VC++ product messaging ended up being the ability to create Windows programs, and that made me a good spokesperson. We spent a lot of energy trying to move the evaluation criteria for “compilers,” from compilation speed and code size to how fast a Windows program could be written and how easy it was to modify it.
The state of the art in evaluating products, perhaps represented best by the elaborate labs at BYTE magazine or PC Magazine, was to have dozens of PCs running all sorts of automated tests dozens of times, averaging the results and compiling endless tables of comparisons. These labs were incredible and rivaled our own in-house testing labs. There was a strong desire to distill results down to quantitative measures that readers loved, which always posed a challenge when working to tilt evaluation criteria towards what we were strong at. Ultimately, VC++ did well in reviews but still took a few years to win over the hearts of developers even if we won over the minds.
In the early 1990s, the press reviewed products in two waves. Usually at RTM the next issue of a monthly or weekly would have a first look short form that was usually not much more than the voice of the company, perhaps with a little doubt as to execution or a bit of wait and see. Then after a few months and an editorial calendar opening an in-depth review would appear. These reviews were often the work of a full team and weeks or more of dedicated work, from benchmarks to real-world usage across the leading products in the category.
The most fun was the trek up to BYTE magazine’s offices in rural New Hampshire in what was a converted agriculture or bovine research facility of some kind (no really, it had huge elevators to move cows around). The trip there always included a stay-over (because we were well outside day trip distance) in the famous Jack Daniels Motor Inn and the Peterborough Diner. Today, the only equivalent of reviews like we used to receive are those that run in Ars Technica. A typical review would be ten or more pages, with several full page tables. Part of visiting each publication, usually for a half day or more, was an attempt to influence the rows of all those tables—what criteria would be evaluated. While we were adversaries in a sense, I made a ton of great friends on those trips across editors and writers.
I mention these trips and the reviews because Jeff had instilled in me an absolute obsession with reviews and digging in and reading them in depth. This was quite different than what you hear about people in other creative fields that stay away from the potential criticism of reviews or reviewers who aren’t necessarily skilled (or whatever). Jeff’s view and that of Apps was the opposite and reviews were everyone’s job to understand, read, and absorb, and not just our reviews but the competition as well. BillG read all the reviews too and he was always current and up to date. Losing a review was almost a guarantee that you’d receive email asking why.
Everything was in the home stretch. That meant that while people were coming to work to triage and investigate, it always appeared as though they were not doing much but postponing issues and re-running tests. In the projects of this scale and duration, there was an irony that productivity dropped to effectively zero at the end of projects. Making any change was always more risky than shipping whatever was being fixed.
The Group Product Manager in charge of marketing for the Languages business picked a launch date and venue at the Software Development Conference (SD93) in February at the Santa Clara Convention Center. The event featured black-tie presenters and an orchestra theme—Visualize Your Masterpiece. This venue was generally where big tools for developers were launched, the newly recruited marketing leader Jim McCarthy (JimMcC) pulled out all the stops for a huge event.
Back in Redmond in our AFX hallway there was clearly a well-earned sense, from Jeff, of mission accomplished. He had led the creation of a new team, alignment of strategies across the historically strong-minded Languages group, and created a new category of professional development tools for Windows and in Windows. To some, he redeemed himself from that Word experience. We accomplished the BillG goal of not making the same mistakes again. The two years went by quickly and even though I felt like I had wasted a lot of time early on, looking back, at what we accomplished would not have been possible without all we had endured. I learned the classic engineering lesson that every failure is simply practice for success.
The introduction of Windows 3.0 and products like Visual C++ for Windows marked the end of the first era of personal computing and the start of the transition into the next—while Windows 3.0 and 16-bit successors were the overwhelming customer choice, attention already shifted to full, or native, or real 32-bit computing as shown by Windows NT previews. Win32 is where developers wanted to be. In fact, a quick turnaround of Visual C++ 1.0 specifically for Windows NT was in the works.
The GUI revolution was about to kick off a colossal expansion of computing throughout the workforce and home, and then the internet accelerated that (or perhaps it enabled the internet?) beyond anything imagined in Redmond.
Culturally within Microsoft, I came to understand that in a sense I completed my schooling in the worldview of Apps and I fully embraced that culture. This was almost certainly pre-ordained by my path to Microsoft having started out in computing building business apps, and at each step I saw the product built through the lens of the end-user or business problem rather than from the bottom-up or technology perspective. The Microsoft Apps culture was also one that held a distinct view of how teams are led and managed and products planned and executed, distinct from the traditions I saw in Systems and Languages. Jeff created a little Apps “island” in the sea of Languages and Systems when he created the AFX team. My Apps perspective would stay with me for the rest of my career. I owe everything to Jeff, and he was not done supporting me.
Having said that, while that perspective would prove transformative for me as a future manager, there were also times it would test me.
With 1993 coming to an end, the team geared up for future releases, including the transformation of VC++ to Visual Studio. I too was ready to build on our successful product. My mentor Jeff and HR leader Natalie Yount (NatalieY) had different plans for me as I was about to find out.
On to 014. Executing on the Expansive Vision of Bill Gates (Chapter III)
https://en.wikipedia.org/wiki/Alan_Cooper
Here is a piece of Windows trivia related to that old Microsoft building. In Windows 2.0, if one wanted to dereference a global handle (an opaque data type), one would search for the memory block named "Burgermaster" in the debugger. Then use the handle as an offset inside the memory block to find the physical pointer to the the memory referenced by the handle. People outside the company would ask why that was the name of the global handle table. It literally was on the sign the programmer saw when looking out their office window.
Burgermaster is still there. Microsoft is not.
VB was a lifesaver for me. I prototyped the Word and PPT ruler in VB and sent the .exe to the dev to play with. He called me and asked that I come to his office. He said, "Designers only send me .bmp's...we need to talk." He had some cool ideas he wanted me to prototype (like holding the alt-key while dragging the arrows to reveal dimensions) and he knew I could do it faster than he could. BTW...My design mimic'ed the physical tab-stops on a typewriter. Don Norman praised them as an example of leveraging real world affordances in the digital world. Not so true any more. But in 1992, Microsoft receptionists still had IBM Selectric's sitting next to them! 😮