Back to 010. Our BillG Review
Finally, in the Spring 1991 we had clarity on our platform mess, but complexity in how to move forward. I get promoted to a lead software design engineer. I worry about getting fired for ordering T-shirt. We “rm -rf” all that old work so we have a clean slate and refer to all of that as “Old AFX”. We are building tools for Windows, running on Windows, and a class library that was dedicated to building Windows apps.
Note: This is a bit longer than I expect sections to be normally. Lots going on in a short time.
With our BillG review completed we needed to regroup. We knew what we did wrong technically, but we lacked a strategy to build a product that involved target customers and product goals. We were a technology team in search of a problem. Microsoft’s strategy was coming into focus and Jeff set our small team up to be the glue by amplifying our efforts. We needed to ship. Shipping is everything.
The traditional C compiler team was working on C++ after the death march release of C 6. They were making progress on what was an enormous task. The team of about two dozen brilliant compiler and code-generation expert developers added Martin O’Riordan (MartinO), who pioneered the implementation of many of the esoteric features of C++ in the Glockenspiel compiler (the one we had been using for ET++ and AFX). The team was making significant progress at the core compiler technology and immersed itself in the language standardization process ensuring Microsoft had a front row seat for C++.
Windows 3.0 shipped and exceeded any and all expectations. Pre-installed sales in its first few months shot up to more than one million copies. By the time our BillG Review happened, Windows 3.0 sold twice that or more. Work was well underway for the successor, Windows 3.1, which would make substantial progress in using the latest Intel processors, significantly improving networking and file sharing, and adding new user interface APIs that would make building Windows programs easier.
Its success meant that our strategy was handed to us. With all the conflicting goals and external relationships, knowing what to do or having a feeling about what made sense from a technology perspective is not the makings of a strategy. Strategic shifts, like the one BillG orchestrated with the transition to GUI in the first place, take clear, top-down, direction. We had anything but that, still.
Windows morphed into Microsoft’s main strategy, from a side project. While the Apps team was already heavily invested in Macintosh, when it came to Microsoft’s operating systems we were inconsistently spread across MS-DOS, Windows, and OS/2.
Often, in times of strategic turmoil or doubt, a few simple observations on the state of the world expressed plainly can lead to an effective strategy, removing ambiguity and doubt.
Our team knew we needed something to compete with NeXTStep and we knew we were going to use C++. We had two big problems.
First, AFX was given the mission to develop tools for all of the platforms Apps might build for, which included Windows (which at the time would always mean some of the older versions and the newest ones), Macintosh (where the money came from), OS/2 (because that was the company strategy), and even MS-DOS (where most of the customers still were).
Second, we had been strategically focused on professional developers, which might not sound like much but implied many things about the product such as using character-based tools instead of GUI and not worrying much about how easy it was to write programs. The most important apps of the new era were being written by professionals, not hobbyists, but now Borland was attracting professionals.
We were hamstrung by the perceived need to cater to professional developers who were focused on the complex Microsoft platform strategy of MS-DOS, Windows, and OS/2. How could we pick one without breaking the strategy? Who were we, the small group in Apps, to make such a decision?
The answer was right in front of our faces. Windows 3.0 sales surpassed Macintosh sales. In the entire first year, Windows 3.0 sold about 4 million units, almost twice the number of Macintosh computers sold and over twice the number of all Windows units sold previously since 1985. Windows sales were doubling in months and Macintosh was growing sporadically but about 30% per year on average. The rest of MikeMap’s Apps organization turned to focus boldly and clearly on Windows (and Macintosh) at the expense of MS-DOS and OS/2, which led to only one conclusion: Focus our efforts on Windows. Borland was already doing that. Many application vendors were starting to do that (except for the biggest ones). The situation for programmers was rapidly becoming one where if someone was building a new app, then it would be on Windows. For existing companies, the question was not if the focus would shift almost exclusively to Windows, but when. Even Macintosh started to be questioned in some commercial circles, simply because of the growth rates and urgency around Windows.
This change happened in the span of months and was as dramatic for us as it was for everyone, including our friends and co-workers in Systems. In Systems they were still trying to get OS/2 to work and executives were still navigating a relationship with IBM. That relationship had cooled substantially in public with increasingly political statements being made about who would support what and when. Rather than clarify a partnership, these began to clarify a reality. Windows was the breakout. Everything else was going to be left behind.
This was a classic case of the internal situation making something seem bold, but from the competitive marketplace the choice was obvious. Windows.
The summer of 1991 would prove to be a pivotal time for Microsoft and the industry. In hindsight, this was most decidedly a moment along with a memo to prove it and decisions around that. Rarely in corporate evolution do incredible successes so easily connect to specific dates and choices, but Microsoft’s early years seemed to be marked by several BillG moments. Microsoft, just a decade earlier, closed the deal with IBM and the single decision to codify Microsoft’s right to license MS-DOS to other PC makers was documented in a succinct business plan memo. And just a few years after that, Microsoft stopped building new applications for MS-DOS to focus on GUI at an offsite led by Bill. It is amazing that the most early and key strategic choices the company made could be connected to specific events and moments in time.
In the Spring of 1991 BillG set aside a week, as he was doing regularly, to get away and update himself on the latest technical developments, called “Think Week.” As I would learn personally in just a few short years, most of the time was spent deep in reading, but he would also commit to writing. This particular week, deep in the success of Windows 3.0 and ongoing development of Windows 3.1 and the ongoing frustrations of OS/2 development, he took a step back to consider, and decide, Microsoft’s big platform bet.
As I would come to learn this was a prototypical BillG memo. It was a series of seemingly unrelated points, usually detailed in a bulleted list, each with a block of strongly imperative and candid text. It was also, for lack of a better word, a bit paranoid (especially in hindsight when one considers all the issues). Yet when reading the memo in the context of the moment, it is clear that while these might be a bit of a laundry list of everything he was worried about, it is just as much a list of all that must go right for a strategy to be successful. Bill knew more than anyone just how fragile the world of software can be to companies. While I’m forward referencing a bit, he was fond of saying that a company’s most difficult times are seeded when things appear to be going perfectly well. The list of just PC software companies in decline or that vanished was already long.
Bill detailed this strategy in the widely read email he originally sent to only the executives, but quickly raced around the company (and is now online1 due to leaks and also the discovery phase of litigation where some of our best emails are now available). Microsoft had always been an exceedingly open culture when it came to mail forwarding or including others in email. This was from the top-down. BillG, more than anyone, overshared, whether on the CC line or simply forwarding and asking for views then forwarding those views to others. I did not personally know this yet, though had already seen many BillG mails.
In the same way that DEC’s strategy for the ’80s was VAX—one architecture, one operating system—our strategy for the ’90s is Windows—one evolving architecture, a couple of implementations. Everything we do should focus on making Windows more successful.
Bill Gates, May 16, 1991
This was the first BillG Memo that I saw, and in hindsight it showed the deep thought that Bill put into focusing the company on Windows in a time of change. The May 16, 1991, mail also made it into the San Jose Mercury News and Wall Street Journal and then even into some of the trials and tribulations with regulators. I was too naïve and too much of a true-blue believer to even consider the negatives or theories in the press on what was significant. I took the memo at face value. The memo was abundantly clear. “In the same way that DEC’s strategy for the ’80s was VAX—one architecture, one operating system—our strategy for the ’90s is Windows—one evolving architecture, a couple of implementations. Everything we do should focus on making Windows more successful.”
The press mostly focused on the sections of the memo expressing concerns about competitors. The Wall Street Journal headline was “Microsoft Founder Gates, in Memo, Warns of Attack and Defeat by Rivals” and discussed the widening rift with IBM, even saying Microsoft “lashed out” at IBM. The memo’s ever-present competitive tone using war-like terminology such as “attack” and thinking through competitive battle scenarios were too exciting to be omitted from coverage.
The simplest summary is to repeat our strategy in its simplest form -- "Windows -- one evolving architecture, a couple of implementations and an immense number of great applications from Microsoft and others.
Bill Gates, May 16, 1991
In fact, the memo codified what the market had seemingly decided—the winner was Windows. Bill was clarifying, crystalizing, and emphasizing that point with specific calls to action. He made sure that everyone knew OS/2 was no longer a priority and that we now had a strategy that was entirely Windows. In concluding he restated this as “The simplest summary is to repeat our strategy in its simplest form – ‘Windows’ – one evolving architecture, a couple of implementations and an immense number of great applications from Microsoft and others."
For most of us in Apps, the part that seemed more newsworthy was a clear mention of what until then was simply known as “Advanced Windows” or usually OS/2 3.0, was now a full bet on Windows and that Microsoft was no longer committed to making the imminent release of OS/2 2.0 a priority. The memo acknowledged that the relationship with IBM would be difficult but optimistically noted that Microsoft would come out a bigger and stronger company no longer successful simply because of support from IBM.
The "a couple of implementations" is a somewhat humorous reference to the fact that our NT based versions and our non-NT versions have a different code in a number of areas to allow us to have both the advanced features we want and be fairly small on the Intel architecture. Eventually we will get back to one implementation but it will take four years before we use NT for everything. I would not use this simple summary for outside consumption—there it would be more like "Windows—one evolving architecture with hardware freedom for all users and freedom to choose amongst the largest set of applications.
Bill Gates, May 16, 1991
In hindsight there is a fun section in the memo where Bill points out the reality that Microsoft currently has “a couple of implementations” of Windows technologies and it would take “four years before we use NT for everything.” It would be almost ten years and eight or so releases of the two different main code bases to get to one operating system code base, Windows XP.
The bet on Windows, the bet on what was now becoming known as simply NT internally was now clear. While initially NT was an abbreviation for “New Technology” it was common knowledge that we were not to confirm that brief history and to say it is just the two letters (something about lawyers and trademarks was the hallway talk). Literally overnight the efforts around OS/2 and MS-DOS fell from most everyone’s plate and certainly all new projects reset their focus to be Windows.
Where did that leave our AFX effort and competing with NeXT? The memo also pointed out that the most important differentiator between operating systems and most important criteria for winning in the market would be “hardware freedom for all users and freedom to choose amongst the largest set of applications.” It was our job in AFX to build the tools to enable the largest set of applications to exist.
Our challenge was that the C++ product team, managed in a different group reporting to MikeMap, did not have it so easy. Unlike AFX, which had no existing code or commitments, the C++ product group was committed to delivering the C++ compiler which was becoming essential for the creation of NT and to deliver C++ for Windows 3.1 and later. That support was for the professional tools, professional in the sense that they were character-based command line tools.
Oh, and Windows NT already had a target ship date towards the end of the year. This was an experienced team that was making progress. There was a real urgency to have C++ tools for the upcoming developer preview release of NT. Microsoft was already planning a big conference for professional developers and part of that conference would be a preview of Windows NT and the tools required to build applications.
There was a lot going on and while the strategic shift was clarifying, the next level of detail when it comes to figuring out the ordering and priorities of projects still needed to be worked out.
At the same time, there was no way for us to build, from scratch, an entire suite of GUI tools competitive with NeXTStep in the months remaining in 1991. Jeff was a master at schedules and understanding where groups really stood relative to where their optimistic plans were—he lived through 10 years of app schedules and death marches. Plus, the C 6 team just shipped after their own march and they needed a significant update, C 6.0a, to address concerns that the initial product was buggy.
A key insight Jeff brought was directly connected to his experience working with Apple and Steve Jobs, most recently reflected in ChrisP’s “Shipping Software” tech talk. The idea that being grand architecturally is a distant second to being pragmatic and shipping product. Steve Jobs famously rallied the Macintosh team with the mantra real artists ship, a play on Picasso’s famous saying, “Good artists borrow, great artists steal.”
Jeff told us to put our oopaholic problems aside and said, “Enough is enough. It’s time for us to ship.”
Like all lofty goals, we needed to break the project down. There was an obvious step to take. First get C++ done, which was necessary since our tools were built in C++. From there, we could build the Windows GUI tools in C++ and fully bootstrap or self-host. This two-step plan also created an opportunity for our AFX team to ship “something” or “anything” with the forthcoming character-based C++ compiler.
The C++ compiler coincidently needed something as well. Borland was busy building an application framework. Microsoft had none. Borland led the way in telling a new generation of programmers how to use the latest in object-oriented tools to build Windows programs, on Windows. That meant Microsoft was ceding control of the actual platform it was creating to Borland.
When it came to class libraries, we still needed a philosophy or point of view that helped to guide us—all we had was a failed oopaholic view. That’s where my experience at USENIX came in. Returning to the slides I presented, as per the JeffH requirement, after laying out the context of the conference one slide was all that mattered.
Restating my conference lesson, I put on a slide “C++ is a programming language not a religion.” Certainly obvious, but not to anyone on the leading edge of technology who believed that C++ required a new way to think about programming. I went on to say that the lessons I took away from the conference were that C++ was a better C, not a new way to do everything. The most effective way to use C++ was to stick to a “sane subset” of the language, which was basically heresy to all the people advocating for adding new features and complexity to the language. While the Languages team was required to implement the public standards (which were being developed at the time and we were active members of the ANSI committee), there was no reason for our own class library to serve as a “compiler test suite.”
This philosophy of C++ minimalism was the first step in building our class library. The second was the impetus of ScottRa and RickP. Both had built many layers to insulate people from variations in different operating systems and platforms and both knew the cost in memory size and code complexity that comes with that. While it always seemed like a good idea at the time, eventually the team building the layer found itself having to do as much work as each of the operating systems. That meant a small effort turned out to require two or three times the effort of some large teams, which were, effectively, competition.
Given the realignment of MikeMap’s Apps division around Windows versus being everything to everyone along with our newly minted religion around C++ minimalism versus oopaholism, we had a strategy. We would build tools for Windows, running on Windows, and a class library that was dedicated to building Windows apps, not an academic exercise in OOP.
During a doorway conversation with Jeff, we discussed how we would ship. We were trying to find a way to break down the problem to give the team time to build our NeXTStep competitor. Jeff asked if there was a way to ship part of the class library with the forthcoming C++ compiler and then ship the rest with an update that included the new GUI tools.
In hindsight, I think Jeff knew the answer. Yes, we could. Still, I gave him that answer. Our ideas for a minimal class library could easily be partitioned into parts applicable to Windows and parts that were more in line with the focus on the first C++ release that was about character mode. We sketched out what was known as the class hierarchy based on what we called foundation classes and Windows classes. These foundation classes would be the minimal product we could ship in time for the developer conference, and would simply give a bit of a flavor of the class library to follow. They weren’t even all that helpful for writing Windows programs…yet.
Jeff asked if I would lead the near-term project—the first release of AFX that was aligned with C++ 7.0, the obvious next name for the compiler product.
I had no idea what lead meant except that I was being asked to ship, and that was exciting. I still reported to ScottRa, but Jeff promoted me to manager. One day I was not a manager. Then I was. At first, I thought, Wow, everything is going to be different. Except at Microsoft in those days, especially working for Jeff, that was not the case. Jeff’s idea of a manager was to take people who were so productive that they could do the previously required work but also have enough extra time to manage. The management part was an add-on. There was no such thing as a manager who didn’t also code. ScottRa was a full-time developer. So was GarthH. Everyone was writing code. Managers just did some extra stuff for a half a day a week or so.
My first direct reports were RickP and Eric Schlegel (EricSc). Eric recently graduated from Dartmouth and knew everything there was to be known about Macintosh. RickP, a pioneering engineer on the Excel team who created much of the layer of code that helped Excel work across Windows and Mac, was a legend. While we became great hallway friends, the idea of me managing Rick was absurd. I had literally nothing to offer him. Rick wasn’t looking for anything, though, and it ended up being a great chance for us to officially hang out. He knew the work that needed to be done and wanted to do it. He was better at it than anyone else. Eric was going to work on some Mac-specific tooling as part of a broader project that remained in place.
We defined a project and built a schedule. Next, we needed to ship. We needed to create a source code project, an SLM project. In a symbolic gesture of ridding ourselves of the past evils of oopaholism, we created the new afx source code project, deleted the old project, and, for good measure, I deleted the last copy of the code: “rm -rf afx”. That wasn’t quite the command for the source control system but became how we symbolically told the story of becoming recovered oopaholics by using the well-known Unix terminology. I deleted all the files from our failed project, which we started referring to as Old AFX.
We had a clean slate.
But first things first, we needed a T-shirt. Without a T-shirt there was no way to start a project, and frankly that explained a lot about the previous years. Getting a shirt in those days was no easy task. First, it had to only be one color because silk screening multiple colors was prohibitively expensive. Second, a big deposit was required as was a commitment to a certain quantity. There was a place by the Kingdome, in industrial Seattle, where we went to check proofs. It was crazy.
I needed a design. The lesson that came out of the BillG Review for us was that we had not been in tune to the market while at the same time we were sloppy. At the time my uncle, a banker, was working at Prudential, which had the slogan, “Rock Solid. Market Wise.” I called him up and asked him to send me some letterhead or a poster or something (there was no internet). I received a big FedEx tube the next day (wow!) filled with all sorts of slogan items. At the Microsoft library I made a scan of the logo using the public scanner. Using Windows Paint, I added “Microsoft Foundation Classes” across the top of the Rock of Gibraltar along with the (trademarked) Prudential tagline. Then our group’s administrative assistant, Kathleen Thompson (KathT), who later contributed to the thousands of pages of documentation as a writer, guided me through the process of getting a T-shirt made.
There was one problem. I did the classic Microsoft thing of acting first and not asking permission. Thinking about the minibar incident, I chose to pay for the shirts myself and work it out later. I wrote a check for $450. Two weeks later, we had T-shirts. And apparently, we also named our first product. Microsoft Foundation Classes (MFC), which I came up with for the shirts, had stuck. We were building MFC 1.0.
I proudly gave Jeff a shirt when they arrived. His first comment was not “Did you get permission for the logo?” but rather “Who paid for these?” My answer was “I did,” and before I managed to ask for reimbursement he smiled and mouthed, “Good answer.” It was a different era. People thought of company money differently, as if Microsoft was still a start-up, and as crazy as it was to pay for T-shirts, I understood Jeff’s point as we started to see the spending all around the company increase. A few weeks later, a reimbursement check (a physical check) arrived. Jeff worked the amount out with KathT.
Coding the project was a whirlwind through the next few months. The Languages team worked under a deadline that wasn’t realistic, but we were only a small deliverable to their big project and were not in a position to play schedule chicken, a common description used when two groups shared an unrealistic deadline.
Surprisingly, decision-making clarity came from having a clear point of view, a tight deadline, and constraints. This idea of a “clear point of view” was something Jeff instilled in me during one of our many conversations. He would use the expression to highlight a unique perspective or belief that defines a product, or guiding light. It was new to me, though years later I understood why it was referred to as a North Star.
While this was all happening to me, it was also changing me. While I was on the job for almost two years, I had not really transitioned from graduate school to industry. And then I did, and it happened fast. Big and small things were happening to the product quickly too, seemingly all at the same time.
We had to choose naming conventions for objects in our source code—what the code looked like in books and what happened when thousands of programmers typed each day. This was essentially a life-or-death struggle and picking wrong could be legitimately alienating. Microsoft Apps championed a specific and rigorous naming convention called Hungarian, which we learned in ADC. It was pioneered by CharlesS and was his Stanford PhD dissertation. Windows took Hungarian and basically broke it in ways that made Apps people cringe. MFC was both a new language with many new idioms and straddling the world between Apps and Systems. But time, pressure, and clarity of mission made it simple, and we picked a few conventions that came to define C++ for a generation of programmers: Classes start with a C as in CString; member variables start with an m_; and everything starts with our main class CObject, which was super lean and had no memory cost. That was the whole oopaholic philosophy swung 180 degrees from conventional wisdom. Also, when it came to tabs versus spaces, we chose correctly.
What previously took weeks, we dispensed within a day.
Scott and I worked on diagrams for the class hierarchy, sort of a family tree of the product. We drew them in PowerPoint, which only had basic shapes then and didn’t even have good alignment tools, and then at night I took them to the all-night Kinko’s on Capitol Hill where they could make copies the size of posters. Class hierarchy posters were the currency of the C++ world, and we had the best.
Sticking with the RickP philosophy of not duplicating code from Windows, we made a lot of choices that went against what people hoping for cross-platform code would have liked. We used existing Windows OS implementations for most everything in MFC 1.0, including files, strings, and more. If the intention was running this code on another OS then it meant basically implementing those parts of Windows. It wasn’t about being sneaky, it was about being efficient for people writing Windows programs, which we felt was where the world was heading. It was our strategy to make Windows programs efficient and easier to write.
We decided that for credibility with developers we would ship our library source code. Microsoft never shipped source code and guarded it closely. In this case, though, Jeff thought this was important and supported us. This meant, however, that we needed to make our code pretty and free of the kinds of things that routinely peppered the code of Microsoft products—comments like //BUG or //DON’T TOUCH THIS CODE. As part of this we also chose to use the Afx prefix in the code as well, which ended up being the source of many rumors trying to discern its meaning.
Finally, we were absolute zealots about performance and memory usage. We were running on 16-bit computers with Windows 3.0 and memory was tight. RickP taught me a bunch of ways to measure and report on memory usage that I not only implemented but reported out every single day. Every night, late, I mailed out the changes to the project in lines of code, size of compiled code in bytes, and size of the most trivial program, “Hello World.” Displaying Hello World on the screen was a technique pioneered by the creators of the C programming language. It allowed programmers to compare programming languages (which they loved to do) by looking at the simplest program.
If something went in the wrong direction, we were required to explain it. Every. Single. Day.
While this was going on, we were helping the compiler team to ship. There was a massive amount of work to build a C++ compiler and we were one of the only products under development using C++.
Since we still needed to compete with Steve Jobs, our team was simultaneously working on an even bigger project. Version 1.0 of the Foundation classes were a fraction of the scope of what we needed to get done.
The Usenet postings at the bottom of the BillG memo are terrific. I loved reading those at the time, the industry speculation about DOS/OS2/Windows/NT. So many keystrokes, so much bloviating and prediction and posturing.
(adapted from my own memoir writing drafts folder - seemed to fit your post)
I had been brought back to Autodesk in the Fall of 1992 to lead development of a completely new architecture for AutoCAD that would allow it to play well in a world where all desktop computing was going to be based on GUI development. I was chosen for this because of having developed Windows apps since 1986, having 3 years of NeXT development experience, and having become the leader for AutoCAD development on the Mac. Though we historically did all core AutoCAD development on Sun workstations and shipped on DOS and Windows using 1–2-man porting teams, these products, while all identical, had user experiences and architectural shortcomings that prevented them from running well with expected user interaction models. This was fine in a world where AutoCAD on DOS was a bespoke environment for users on a platform that was standards-free with respect to interaction models. But the GUI was clearly where all our platforms were going. AutoCAD was built around its famous command line which relied on a keyboard-polling architecture which was not suitable for event-driven environments. This did not allow for newly expected idioms such as modeless dialog boxes, floating palettes, dynamic tear-off menus that reflected program state, and so on.
I had successfully convinced the company that Windows would be the dominant platform and I had successfully and painfully convinced the founders that yes, one could develop the very-large AutoCAD and associated add-ons using the newly released NT. We would eliminate portable C idioms we had used for over a decade and move to portable C++ with Win32 APIs used for the basic architecture. We would rely on portability framework for providing Win32 APIs on non-Windows platforms (Bristol Wind/U and Mainsoft - yeah, those guys - for Unix and Mewel for DOS) and we considered and prototyped with all the C++ or Objective-C Windows application frameworks that would allow us to develop in a style akin to NeXTStep's AppKit.
We tried them all - XVT, C++Views, Objective-C Views, a few more I can't remember, and Zinc from some friendly guys in Utah that we were able to get working in DOS using Mewel, a Win32 API implementation for DOS. After a lot of prototyping and examination by two dozen engineers, we chose Zinc. We paid a corporate license for it of $1-2M and began work. Zinc shipped us a pallet of boxes of the software, and we distributed copies to 100 engineers. We were building AutoCAD on MSC for the first time ever (was a MetaWare High C app for years on PCs, like dBase, Paradox, and other large DOS programs), and all was going well with AutoCAD on Zinc design and MSC conversion for the code base.
Then Visual C++ came out with MFC 2.0. I should say, MFC 1.0 was looked at and was a non-starter, for reasons you would know. There were two engineers who had worked on the NeXT platform in the entire company - myself and a guy I brought with me from the company where we had done this. We opened the box and pored over the manuals, installed it, and got to coding over a delirious 2 days. We were shocked, to say the least.
The framework, the wizards and everything else reminded us of Interface Builder/Project Builder systems, and the rest of the environment was particularly good. Our experience and that of many other people I knew in the valley (including my many NeXT friends) told us that using frameworks like AppKit had a 10x effect on productivity and program understanding for newly onboarded people. MFC 2.0 seemed like it would have the same effect.
Since our portability strategy for other operating systems was based on a Win32 layer, I called Bristol and they agreed that they would have Wind/U working with MFC ASAP. Our DOS guy thought he could get it to work.
Now I had to convince our VP of Engineering John Lynch that despite all the effort that had gone into engineering a solution on Win32 and Zinc under my leadership, despite spending millions on Zinc software and months of training that **this** was the platform we needed to use instead. John was livid, saying that we'd look stupid and indecisive, but I pointed out that we were not told about MFC 2.0 until that week and had jumped on it and analyzed it inside and out. None of that mattered anyway I said, moving exclusively to MFC was the right thing to do to create a Windows-centric code base for all our products and everybody would have higher job satisfaction working with MFC (better on your resume, etc.). He said fine, but that I needed to present this about-face to our CEO myself.
In the meeting with Carol Bartz, I walked through the details of the decision process, and was reminded by her questions that she had a computer science background and had an immediate understanding of most of the issues. She can be very intimidating (ask Steve who won in the Yahoo deal). Finally, she said, "it sounds well thought out; it's just too bad that NeXT didn't win, because all of these advantages would be available to us on a 4-year-old platform".
My response was, "MFC provides almost all of the same advantages but with an important advantage - it runs on a platform people actually buy".
Carol said, "That’s it. Go do it". We did.
Today all of Autodesk's core revenue-producing software was developed using MFC, on Windows. That decision simplified our product development and enabled us to go from $200M to $1.8B while I was there. I should thank you for my career.
My tagline when explaining my decision and why I moved the company in this direction became "MFC is NeXTSTEP on a platform people actually buy". You couldn't use it, but I could.
I was right for 15 years, anyway.