First comes the test of fire.
Then comes the test of ice.
Then comes the test of patience.
"Writing a Windows application is like having Microsoft give you a periodic table of the elements and asking you to make a broccoli."
This infamous remark of writer and consultant Alan Cooper, who is honored as the father of Visual Basic (Microsoft's most revolutionary programming tool of the time), pretty much said it all. Back in 1988, before anyone started making all the powerful tools that programmers enjoy today, writing an application program or "app" that ran on Microsoft Windows was complicated and confusing. Most programmers, under the pressure of some arbitrary deadline, had little time to really learn the system before diving in and trying to get their projects off the ground. That's why they called on us in Microsoft's Developer Support Group.
I had a deadline of my own. As mentioned at the end of the last chapter, I was given only two weeks from the day I started before I was on the phones. Fortunately, I picked up the periodic table quite quickly and made my first "broccoli" in the somewhat short span of three weeks. It was a little program that drew an assortment of interesting spirals using lines, circles, diamonds, and, my mother's favorite, the silhouette of a Scottish Terrier. While this app wasn't particularly useful and is the kind of thing you can write in a couple hours with today's tools, it was a major accomplishment given the circumstances. I had every reason to be very proud of myself—I had learned to walk quickly enough that, proportionally speaking, it should be a matter of only weeks before I would learn to run, fly, and sail to the stars!
Goaded by my success, I soon conjured up a second project that would actually produce something useful. As an engineering student I had to work through an endless stream of computational problems. For these I had always employed my trusty Dynatone scientific calculator, the one for which K-Mart grossed $10 during my first year in high school. Cheap, to be sure, but it was far more helpful than the small calculator program that came with Windows at the time: an on-screen rendition of one of those chintzy four-function jobs that you get free with a completed credit card application or a paid subscription to some consumer magazine. Woefully inadequate for my needs. So using my precious Dynatone as the model, I set out to create a full-blown scientific calculator for Windows.[*]
The original Calculator (not mine) in Windows version 2.
Success! In again only three weeks, between the support calls I now routinely handled, I completed my new project. It had all kinds of interesting features. It would of course add, subtract, multiply, and divide like the existing program, but this one would also do factorials, logarithms, and hyperbolic cosines to twelve significant digits! It could perform statistical calculations with piles of data and could do logical operations in binary, octal, and hexadecimal number systems—a must for computer engineers. And it even allowed you to "paste" in a series of operations written out in text, which it would then work through as if you had keyed it all in manually.
An early screen shot of my calculator during the development of Windows 3.0 (note the 1989 date) showing my name as it appeared in the final product. This was taken on an EGA monitor, if you remember those.
My little creation was a smash hit among my full-time co-workers, the ones whom us student intern types looked up to with a certain degree of awe. Every day one or more of them would thank me for what was proving to be a very valuable little program. Bob Taniguchi, my group manager, liked it so much that he proudly showed it to the development team working on the next release of Windows, version 3.0.
Success again! The Windows team dumped the old calculator in favor of mine. "Yippee!" I cheered! I was thrilled. To have any piece of your code included in a commercial software product—that was the greatest achievement that any college intern could hope for, especially for a humble little co-op student in Product Support. And to have your work become so visible in your company's flagship product? Wow!
Not only that, but Bob successfully lobbied the Windows team to display my name in Calculator's "About" box. Boy, was I proud. Hall of Fame, ho![†]
I imagine that at this point my more experienced associates were shaking their heads in amusement. Here I was, imagining myself a highlight in the Who's Who of Programming while yet wholly ignorant of the hard reality to come, namely that every program needs considerable refinement before it reaches maturity. And in my excitement I didn't bother to notice that my contribution was about as important to Windows as a small concession stand is to a major-league ballpark.
My ignorance was soon remedied. After the Windows team added my code to their project it became subject to the rigorous testing (no joke!) that Microsoft applies to all its products.
Microsoft development groups have three basic roles: program manager, software engineer, and tester (or "software engineer in test"). The program managers are the ones who try to dream up things that customers can't possibly live without and are therefore willing to buy in quantity. Their job is to write the product specifications. These "specs" are then passed along to the software engineers whose job it is to manifest those specs in a working program. That program is then passed on to the testers. And their job is to mercilessly abuse the tar out of the thing to see whether it lives up to the spec. (there's more to test and quality engineering, of course, but you get the basic idea of how it worked at the time.)
As a programmer, you are supposed to love your test team because they're critical to the production of decent software. But you really hate them because they're usually just too damned good at it! If, for example, you give them a shiny new car that you truly believe meets the indestructibility standards of a military transport, they will dutifully drive it through a suitable war zone. Then they'll hand you the wreckage with some really helpful comment like "it broke." You as the programmer get to figure out why it broke, and you get to figure out how to fix it. Then once you think you've got it figured out, you have to let those pitiless thugs thrash on it all over again. Only when they're satisfied with your work is it deemed ready for the kinds of abuse that customers will inflict on it, which is, of course, far worse.
My first version of the new Calculator was about as solid as a car that expected to be gently rolled along a dead flat, newly-paved road at a gentle 4mph. The testers, in other words, were soon sending me shrapnel. At first I balked at the idea that there could be anything at all wrong with "my baby," but then learned to accept the fact that they were actually helping me fine-tune it.
"OK," I said to myself, "if that's the goal then let's really do it right!" I resolved to do my utmost to create the ideal program, as small and efficient as possible with absolutely "zero defects," and throughout the rest of my six-month internship I happily corrected any errors that the testers discovered. Then when I returned to school that fall, the Windows team offered to make me an "unofficial" contractor so I could keep in touch with them and continue bullet-proofing my program. This really meant only that I got to retain my Microsoft email account: I didn't get a penny for my work. But that didn't bother me—the sheer glory of having my Calculator included with Windows was enough of a reward.
Now although I learned to appreciate the testers, I can't say the same about the program managers that began weaseling into the picture. They kept asking me to make "improvements" to Calculator that seemed totally ridiculous: modify the user interface, change this color, add this feature, remove that function. To make matters worse, a number of times I'd make a change only to be asked to remove it a week or two later. It started to drive me nuts! Wasn't my program already designed as well as it could be? How could they have the nerve to change something that was already so clearly perfect? Why were they asking me to do things to my program that obviously didn't have anything to do with its efficiency? In my youthful ignorance I just couldn't understand what the hell they were trying to accomplish. I even got really irritated when their requests caused the size of Calculator's executable file to deviate from a precise 40,000 bytes!
I trust by now that I've communicated the nature of my own arrogance in the matter. I didn't like the way things kept changing, especially after I'd committed myself emotionally to one way of doing things. Attachment is a sure-fire recipe for frustration.
What I failed to understand was a somewhat unique aspect of Microsoft's product development cycle. In other companies, so I've heard, specifications are actually finalized before the programmers start writing any code at all. Not so at Microsoft: in the dynamic world of personal computer software, every member of the product team works simultaneously. Program managers, in particular, are constantly adjusting a product design according to changes in the marketplace or the simple feasibility of implementation. As a consequence, they keep on changing the specs and the software engineers have to keep changing the code: the specs, in fact, are not considered final until the day the product itself goes to manufacturing! And by then you're already well underway with the next release. (Today, the approach called "agile" shortens the release iterations much more dramatically, allowing for weekly or daily releases, and even sometimes many releases per day.)
For this rather fluid arrangement to work, it is vital that a product has an overarching vision or ideal to guide it. The primary focus of Windows 3.0, for instance, was ease-of-use, itself only one facet of Microsoft's overall corporate mission: to improve quality of life through personal computer technology.
You might notice that unlike many corporate mission statements about becoming "the market leader in non-chlorine toilet bowl cleaners" and the like, these abstract ideals like "ease-of-use" and "quality of life" say nothing about Microsoft's own success. This stems from the fact that Bill Gates, contrary to popular opinion, did not create Microsoft out of a desire for personal gain or glory but from a sincere desire to share the joy of personal computers with everyone. He rightly assumed that success would naturally follow.[‡]
With this high ideal enshrined at its very heart, Microsoft (in my experience) continually challenges its product development teams to operate on a scale that transcends their own goals as well as those of any individual. Employees are encouraged to maintain an expansive outlook in their work, seeing it in terms of offering something of real value to the world rather than merely making money. In this way, corrosive office politics and interpersonal rivalries are rare. Managers seldom have to give pep-talks or sermons on teamwork and just about everyone is willing to put out a little extra effort when necessary.[§]
So although I thought I'd entered into programming history with one spectacular leap, the truth is that these first baby steps of mine, wonderful as they were, merely brought me to the base of a steep mountain. And if I was to climb that mountain—that is, if my little Calculator was ever going to see daylight—I would have to let go my own personal "ideals" and embrace the broader vision of Windows 3.0.
With my desire to have my name in lights (or at least on-screen) being stronger than my attachment to particular colors, features, or the size of Calculator's executable, I gradually became willing to do whatever the program managers asked of me. And by focusing more and more on the higher purpose of the overall Windows product, my own whims and fancies fell away. In fact, I eventually forgot about my credit line in Calculator's "About" box altogether.
This is exactly the purpose behind all high ideals: they help us forget ourselves and our personal concerns and embrace a larger reality. Growth of any kind cannot happen without some kind of expansive vision. We must have something toward which to grow if we are to grow at all. As Voltaire put it, "If God did not exist, man would find it necessary to invent him." Yet we shouldn't get carried away with lofty thoughts and lose sight of the fact that growth—whether technological or spiritual—is a step-by-step process, never a sudden change. Patience, it has been well said, is the fastest route to God—or any other grand aspiration.
Observe, for instance, how NASA successfully put men on the moon and returned them to earth months ahead of President Kennedy's so-called "impossible deadline. Starting with next to nothing, NASA engineers first learned the basics of space navigation with Project Mercury using simple one-man capsules attached to the top of existing Army rockets. From there, and despite many failures, they designed the more ambitious Gemini projects through which they learned complicated maneuvers and refined longer-term life support systems. Then with Project Apollo they learned how to launch much greater payloads into orbit and to send spacecraft around the moon. With all the pieces in place they were finally ready to take one small step for a man and consummate that one giant leap for mankind.
Similarly, one of Microsoft's greatest strengths has been the willingness to work toward an ideal product in distinct stages, putting off certain features for many years until the development team is ready to implement them and the market is ready to accept them. Consider Microsoft Windows itself, which spent several years in development before first hitting the streets in 1985. Well, "hit" isn't quite the word—version 1 hardly drew a glance from the public eye. In the broader context, however, it was the necessary foundation for the much-improved Windows 2.0, released in 1987. And although version 2 still failed to gain widespread popularity, it paved the way for Windows 3.0, released in May of 1990. This version finally caught on and began the Windows revolution. Even so, the product hadn't yet reached the designers' original vision: it took another eight years to really get there through the releases of Windows 3.1, Windows 95, and Windows 98. In that time, of course, the vision itself continued to expand, as seen in the more recent incarnations of Windows that are themselves intended to set the stage for even better things in the future.
Within an ever-expanding reality like this, it's important to add new features only when the time is right and no sooner. Otherwise a project (including one's inner growth) just gets way, way out of hand. There was once an ambitious database project called Omega, for instance, that was as glorious as it was impossible to actually build. What we know today as Microsoft Access was resurrected from the ashes of that fiasco. Microsoft Exchange and Outlook similarly grew from the remnants of an idealistic do-everything-in-the-workgroup-universe product code-named Laser (which we'll meet in Chapter 3). And the highly popular programming tool called the Microsoft Foundation Classes (MFC) sprouted on the grave of an earlier design that, though thought to be absolutely perfect, had to be trashed in toto when its initial implementation virtually imploded.
I consider it an act of grace that I fell prey to this sort of impractical rapid-expansion spirit at a point in my career when I could cause only minimal damage. But I did my best! It was the spring of 1989 and I had been working with the Windows team on Calculator for nearly nine months now. By this time, I had fully embraced the higher ideals of Windows 3.0 and had even proven myself to be a reasonably competent software engineer. For these reasons I was offered an official (that is, real money) contractor's job to do some needed work on the other small accessory programs that came with Windows, such as Notepad and the since-retired Cardfile, Calendar, and Clock.
One of my tasks was to incorporate a new digital font into the Clock program to make it look, well, more digital. The font given to me for this purpose was nice but the numbers seemed a bit stiff—they were all straight up and down, like 12:35, not slanted slightly to the right, like >12:35, as one usually sees on a digital LED clock. So I didn't just add the new font, I went a step further and italicized it. Sure, it wasn't part of the spec, but what harm could there be in it? Surely everyone else would like my little aesthetic adjustment—after all, we were doing everything we could to improve Windows 3.0, right?
Within Microsoft development teams, people generally don't walk around all that much and talk face to face. On large projects, especially, a great deal of communication happens through email, instant messaging, and various sorts of project-management software. At the time, one tool in the latter category was called RAID (as in the bug spray) that primarily maintained a huge categorized list of feature requests and known program bugs.[**] Every entry in the list described the problem or request, its entire history, who was responsible for dealing with it, and its relative priority in the project as a whole.
Whenever program managers wanted you to add a feature, they created and assigned you an entry in RAID. Testers did the same when their ruthless throttling invariably revealed problems in your code. As a software engineer, then, your personal "to do" list were those RAID entries currently assigned to you. Every day you looked over your list and work on whichever ones had the highest priority. When you finished adding a feature or correcting some problem, you marked the appropriate entry as "resolved" and assigned it to the test team for verification. If they were fully satisfied, they marked it as "closed" and all was well. Otherwise they'd "activate" it again with some comment about what didn't work, and the whole process started over. Sometimes things had to go back to the program managers to be redesigned; occasionally a single bug would cycle around the chain several dozen times! [††]
Between email and RAID, then, you could get all kinds of work done without talking directly to another human being. This was helpful when you consider that everyone in a Microsoft development team was generally free to come to work whenever they wanted, day or night, or, oftentimes, day and night. During "crunch" mode, especially, you could usually find someone actively working and someone actively sleeping at any hour of the day on any day of the week. As for myself, I did most of my work during evenings and weekends around my daytime school schedule.
I had italicized the clock font with the hope that people would see it and like it, perhaps even drop me a compliment or two for my creativity. The only response I got, however, was a new RAID entry assigned to me in which some tester, whom I didn't know and had never met, stated with heartless indifference, "it's not in the spec—remove it."
Well! I'd already become somewhat proud and attached to my special feature and wasn't going to be put off that easily! So instead of removing the italic font I simply made it optional: you could toggle italics on and off by pressing Control-I. Problem fixed! I resolved the bug in RAID with a glowing report of my latest brilliant innovation. Everyone else would surely accept my work now.
No such luck. Little features like mine, no matter how innocent—or even useful!—were considered a serious liability to the overall project. Features needed to be tested. They needed to be documented. They made the project unnecessarily late and unnecessarily bloated. And on a project that was already late and already bloated, the project managers—known as the "code police" by the more renegade programmers—were hell-bent on keeping out any and all superfluities. This included italicized clock fonts as much as it did the hidden bits in one of the system's core modules that displayed, when you issued the secret command, a Klingon battleship with the slogan "go ahead, make my day." If such needless waste was allowed in the final system, it might all add up to several more floppy disks in the product box (we didn't have CD-ROMs let alone DVDs or digital downloads yet). This would raise the cost-of-goods per unit. This would cut into net profits. This would lower Microsoft's stock price. This would reduce the value of everyone's stock options. This was a cardinal sin.
Well, as a lowly contractor and member of They Without Stock Options, I didn't know about any of this—nor did anyone bother to educate me. In fact, this time I wasn't even told to remove the italics: someone else did it for me!
When I discovered this latest snubbing of my "genius," I became truly rebellious. "How dare they!" I cried. "I'll show them!" I shrewdly added my feature back in again without noting the change in RAID. If they didn't know they wouldn't care, right?
Wrong—my change was still obvious. In a big development group, there has to be some kind of control system built around a project's source code (all that weird-looking symbolic stuff that only programmers understand). Without such a system, programmers would overwrite, undo, or erase each other's work without even knowing it. This, as Microsoft discovered years earlier, is very, very bad.
This we had another set of tools called the Source Library Manager, or SLM, to coordinate code changes. SLM, which we affectionately pronounced slime, maintained a single copy of a project's source code on a central network server. [‡‡] To become part of the project you first "enlisted" in it. After that you could "check out" individual files to take exclusive control over them. This allowed you to make modifications with the assurance that no one else would be doing so. When you finished your modifications, you checked those files back in. This merged them into the central copy of the source code and once again made them available for others to check out. This much I understood.
What I didn't know about SLM is that every modification to a source file was automatically recorded in a change log along with your email name. What's more, everyone enlisted in the project was notified of the event!
Needless to say, the Software Inquisition watched these notifications like psychopathic snipers. They saw my change and took it out again without comment. I still have no idea who these people were, but they were sharp.
Stubborn as I was, I still didn't admit defeat and resorted to an even more subversive tactic. If you had sufficient mischievous intent you could readily access the central SLM computer and directly modify source code files without checking them out, without checking them in, and without creating entries in the change log.
I was sufficiently mischievous.
Once again I silently made my change.
And once again it was silently discovered and silently removed.
To my lasting astonishment, no one told me about it, no one asked about it, I wasn't held accountable for it, nor was I disciplined in any way. Perhaps I was laughed at behind my back, but I heard only silence. With fortune still on my side, I finally (and wisely!) gave into the truth that my great inspiration simply wasn't going to happen: reckless idealism had met final defeat at the hands of practicality.
Later on I finally learned that the only reason for the digital font in the first place was so Microsoft could say that each and every one of the accessory programs in Windows 3.0 had been in some way improved. For Clock, this one change of the font was sufficient—no more, no less. It was the one and only step needed at the time; other steps would be taken later, when appropriate.
Thus ended my period of youthful idealism. "To every thing there is a season and a time to every purpose under the heaven." This famous Biblical dictum held true in the case of Clock. Microsoft's next step for it in Windows 3.1 did allow you to italicize the font. In fact, you could actually choose any font you wanted and make it italic, bold, or underlined. This was a much better solution than mine but was too ambitious for Windows 3.0. I at least feel somewhat vindicated that my idea was going in the right direction. In any case, the whole point is now moot—since Windows 95 the clock has been only a tiny speck on the "task bar where the font is far too small to even be an issue.
Looking back, it's clear to me now that through all my foolishness—albeit sincere foolishness—with Calculator and Clock, I was simultaneously being taught valuable lessons about the importance of idealism itself and the importance of being patient and practical in that idealism. Without these it's altogether too easy to lose perspective. Without direction, your steps fail to produce meaningful and lasting change, and you lose hope. When the steps are too big, the path before you begins to appear increasing difficult and you gradually convince yourself that high ideals are wholly unattainable. Either way you simply stop growing.
Few lessons in life are more critical than this one. As I said earlier, it was an act of grace that it came at a time when the risks were so minimal. Coming when it did, it taught me an approach that has simplified my daily life quite considerably: yes, let your ideals inspire you to the highest you can imagine, but let them also inspire you to find ways to make them real and meaningful, right here, right now. Be willing to put things off until you are ready for them; work toward your ideals with patience. For by applying them to your present reality they will harmoniously lead you, one step at a time, toward that which you seek.
It is, after all, how we put men on the moon.
And it's how each one of us can reach for the stars.
Myself in Vancouver, British Columbia on our honeymoon, July 1988. (Photo by Kristi Brockschmidt)
[† The Windows team agreed to this because I wrote the program on company time and thus wasn't eligible for any other kind of bonus. Bob also promoted the idea that such visible credit would be helpful when I (supposedly) interviewed with other companies after graduating from college. Thus the credit line "Developed for Microsoft by Kraig Brockschmidt" first appeared in the Calculator of Windows 3.0 (as shown earlier) and—to my continued amusement—in every copy of Windows and Windows NT until 1998, numbering well over 100 million. The credit disappeared only in Windows 98 after I'd left Microsoft, while the program, without the credit, continued to be included with every copy of Windows through Windows Vista. After that, the program went through extensive revision but still retained the behaviors of my original. For an example, see the talk at Microsoft's //build 2013 conference given by the engineers who wrote the Windows 8 Calculator app, http://bit.ly/29KsibB. In any case, having my name appear for as long as it did was an incredible run especially considering that I didn't touch the program after the summer of 1989. And it's a fun way to introduce myself. [Return to text]
[‡] From what I saw of Bill, this motive runs far deeper in him than any thought of personal reward. Otherwise I imagine he would have jumped ship years ago rather than endure the persecution to which both he and Microsoft have been subjected. His activities with the Gates Foundation since his retirement from Microsoft bears witness to this. [Return to text]
[§] Of course, like everything else in our imperfect world, Microsoft is not entirely successful in its expression of this ideal. "Extra effort" can be taken for granted or even made a requirement; personal desires do flare up from time to time, and did especially in the early years when Microsoft stock wasn't performing like people thought it should. But by and large these are the exceptions and not the rule. [Return to text]
[**] In programming jargon, a "bug" refers to a flaw in a program that makes it malfunction or produce incorrect results. The term came from the era when computers were built with vacuum-tubes and mechanical switches rather than solid-state transistors. Apparently a moth got into one of these computers—either the Harvard Mark I or the Army/University of Pennsylvania ENIAC—and got squished inside a relay. As moths are generally not electrically conductive, the relay didn't make contact like it was supposed to. Thus it was a literal bug (though entomologically a moth is not an insect) that caused an error in the program. And the fact that it took an annoyingly long time to discover the real source of the problem set a bothersome precedent that has remained in effect ever since. [Return to text]
[††] A friend of mine who worked as a tester on Microsoft Excel once logged a bug against the cartons of milk in the free drink coolers. He noticed that the chocolate milk failed to list the ingredient "cocoa" whereas the plain 2% milk did. An intense discussion in raid over the relative merits of these "features" continued for three or four weeks and involved as many as a fifteen different engineers. I think it set some kind of record. Anyway, someone finally went so far as to notify the dairy itself and the bug was closed as "won't fix—assigned to vendor." [Return to text]