Category Archives: Microsoft

You Can Go Home Again (or, Returning to Programming Languages)

About a year and a half after doing something I swore I’d never, ever do, I have to admit… it didn’t stick. While working in Windows during the Windows 10 initial cycle was fascinating and fun, it turns out that I just miss working in programming languages too much to become a long-term member of the Windows team. I had a great time working with some great people (and a few of the things I worked on are just about going to go public…), but in the end, I’ve been lured back to the PL world.

Interestingly, I’ve decided to return to the team I left seven-odd years ago just as they were beginning to start this crazy re-write of the VB and C# compilers into managed code. Now that Roslyn has shipped, I felt it was finally safe to return… So I’ve accepted a position back on the Visual Languages team. I don’t plan on doing anything specific with Visual Basic — that language is in very good hands at the moment — but will be working on some ideas about how we might leverage Roslyn to do some interesting stuff. More information to come as it becomes available!

You should also follow me on Twitter here.

I Just Did Something I Swore I’d Never, Ever, Ever Do

OK, so I’ve worked at Microsoft… a long time. This summer, it’s going to be twenty two years since I first started full time, and twenty three years since I was an intern. During that time, I’ve worked in a lot of different places in the company. The Developer Division. Office. Developer Division again. A little division that doesn’t exist anymore, the Connected Systems Division. SQL. Developer Division again. And in all of that time, I had one cardinal rule: I was never, ever, ever going to work in Windows. No matter what happened, no matter how desperate I was, I was just never going to take a job anywhere in the Windows organization. No way, no how.

It’s not that I had anything against Windows or the Windows group, it’s just that for most of my tenure here so far, the Windows group has seemed… a little nuts. Not nuts in terms of what they’ve produced (although the whole Longhorn thing, ug), but in terms of how they seemed to work. From the outside, it looked like Windows was always on one kind of death march or another, from Windows 95 all the way through Windows Vista. And as much as I might like the OS, I just never thought that I was hardcore or badass enough to be able to withstand that kind of pressure.

There was also the fact that most of my career has centered around developers in one way or another, and for most of my time at Microsoft, Windows has been content to simply outsource the majority of the developer relationship to the Developer Division. This isn’t shocking or anything–hey, “Developer” is right there in the name!–but it meant that if I wanted to be working on developer-related stuff, there was only one place to be.

By now, I’m sure you’ve guessed where this is heading. After spending two very enjoyable years noodling on JavaScript hosting (and other related stuff) on the Chakra team, I’ve decided to break my longstanding vow and join Windows. Shocking, I know.

I decided to do this for two reasons. The first one is that since Windows Vista the Windows team seems to have adopted a much more sane attitude towards the whole work/life balance, something I got to see up close while working on a component that ships in Windows. They still work hard, don’t get me wrong, just that they no longer employ burly fellows to walk along the hall cracking whips every half hour.

The other reason is that since the Windows 8 cycle, the Windows team has a much more serious attitude towards supporting developers. They’ve even got a whole organization dedicated to it that works closely with the Developer Division and everything! And so when some acquaintances started chatting with me about some of the ideas the developer team in Windows had for future versions of Windows, I got interested. And then did an interview. And then accepted. So now here I am! Most of what I’m going to do isn’t public for the time being, so not a lot to say about that at the moment, but suffice it to say, I think it’s going to be interesting!

You should also follow me on Twitter here.

Trust, Users, Developer Division, and the Missing Link

Mary Jo Foley pointed today to a very interesting post by David Sobeski entitled Trust, Users and the Developer Division. Written from the perspective of a guy who was in the Windows division through the climactic shift to .NET, he brings up a lot of really good criticisms about exactly what went on during that time. (In fact, I was just wondering last night whether it’s time yet to sit down and write the “what I learned in the VB to VB.NET transition” blog post that I’ve been putting off for a long time.) But there was one really crucial point that he missed that I think made one of his central theses–that DevDiv managers went all Colonel Kurtz on developers and decided with .NET they were going to go build their own platform–a little on the unfair side. Somehow he, and most of the comments I’ve seen so far, have managed to overlook the monster that was striking fear into the hearts of the Microsoft management chain back then. The monster that was going to come along and destroy everything they’d worked so hard to build. Can no one remember? Has it really been so long since Java was relevant?

Yes, before Android and iOS and so on there was Java, and at the time it really scared the hell out of a lot of important and powerful people at Microsoft. Here was a programming layer that was supposedly going to: a) be free, b) be cross platform, c) not be controlled by Microsoft, and d) abstract away the underlying operating system. I mean, now we all can look back and see exactly how the dream of “write once, run anywhere” worked out (pace HTML5), but at the time Java looked like the Trojan Horse that was going to slip into Windows via the browser and hollow out the Windows ecosystem from the inside. In just a few years Scott McNeely was going to be standing over the corpse of Windows laughing in Bill Gates face. I was just a lowly functionary on the VB team at the time (OLE Automation, FTW!) but since I had some fingers in the VB runtime pie I got included on some email chains from some very high level people (not just in DevDiv!)talking about just how worried they were about what Java might do to Windows and how it might allow Sun to wrest control of the app market away from Microsoft.

(One interesting angle, too, about this was that since the Developer Division had a Java compiler project, they also got to see firsthand just how much better development could be on a modern runtime as opposed to the creaky, old, inconsistent Win32/COM API set. The VB team lost a bunch of very bright developers who jumped at the chance to work on something as enjoyable and freeing as Java as opposed to the jumbled mess Windows programming had become. I think this added extra wind in the sails of the managers who weren’t in denial about the fact that as much as developers were tied to the Windows ecosystem, they could still be pried away if you gave them a much better way to program.)

So, anyway, this is the big piece of missing context when looking at the motivation behind .NET. The .NET initiative was, fundamentally, a way to answer the threat that Java posed to Windows, not just some way for a bunch of DevDiv middle managers to go play OS designer (although they did seem to enjoy doing that just a little too much at times). And it’s not surprising that this context would be missing from the worldview of someone who worked in Windows. I never got the impression that Java scared the Windows guys half as much as it scared the DevDiv guys because at that time Java was still mostly a language and a language runtime. It was something that we understood in a much more visceral way than they did. One can certainly argue that that the Windows guys were right not to worry about Java, but hindsight is 20/20. And, based on what’s happened since then, maybe the Windows guys maybe should have been a bit more worried about someone coming along and stealing away their position at the top of the app development heap. Just sayin’.

All that being said, I want to emphasize that I agree with much of the criticism that he levels at Microsoft’s and DevDiv’s approach to the question of trust. But I think that’s another post for another time.

You should also follow me on Twitter here.

Codename Nostalgia, or Go Speed Racer Go!

One of the great things to do in my neighborhood is to head over to Central Cinema, a small movie theater that serves food and drinks, and which has decidedly eclectic tastes. The best thing they do, speaking as a parent, is their “Cartoon Happy Hour” every Thursday where they show a wide range of cartoons for kids (and parents) to enjoy. It’s been a great opportunity to introduce my kids to cartoons that I watched as a kid (Hong Kong Phooey! Tom and Jerry! Looney Toons!) that they might not otherwise get to see.

Recently they’ve shown several episodes of Speed Racer, a cartoon that my mom would never let me watch because it was “too violent.” (Compared to modern cartoons, it’s positively milquetoast.) So it was fun to finally watch it with the kid, but when the theme song came on it triggered a nostalgia of an entirely different sort.

It reminded me of that day, long ago, when I actually got to pick the codename for a product. Looking back now, I’m not exactly sure why I was so keen to pick a codename–it’s not like it’s prestigious or anything–but I definitely was. I wanted to set the name for a whole product cycle, really wanted to. And when the cycle for Access ’97 came along, I got my chance, for two reasons. The first was that most of the team had split off to do a re-write of Access that was supposed to ship after Access ’95 but then got pushed back to after Access ’97 (and then cancelled), so pretty much all of the senior people were no longer on my team. And because Access ’97 was supposed to be a placeholder until the rewrite was finished, it was decided that the bulk of the work on the release was going to be solving the major performance issues we incurred moving from 16-bit Windows 3.1 to 32-bit Windows 95/NT.

Since I was heading up the performance work, I saw my chance and pushed to pick the codename. Of course, picking a codename wasn’t that easy–what would be cool name that would go with the idea of speed? That’s when Speed Racer flashed in my mind, and so the codename for the release became “Mach5,” named after Speed Racer’s car. In the pre-YouTube days, I even got a VHS tape of a Speed Racer episode and went over to Microsoft Studios to get them to convert the theme song to an AVI so I could send it around to the team. (Boy, was I a bit of a geek.) Mission accomplished.

Now, of course, you could never pick a codename like that. In our litigious society, people sue over codenames. I actually saw this in action–there was an old internal project at Microsoft that borrowed its name from a well-known company that makes little plastic bricks. Even though the tool was completely internal and never used or discussed publicly, the codename somehow ended up on some stray public document. The company in question was alerted to the use of the name, the lawyers got involved (so I heard), and in short order the tool was renamed to an innocuous acronym.

So… place names and colors it is, then!

You should also follow me on Twitter here.

Thinking of rewriting your codebase? Don’t.

A friendly word of advice: if you’re thinking of rewriting your codebase… don’t. Just don’t. Please. Really.

Yes, I know, your codebase as it exists today is a steaming pile of crap. Yes, I know, that you had no idea what you were doing when you first wrote it. Or that it was written by idiots who have long since moved on. Or that the world has changed and whatever style of development that was in vogue at the time is now antiquated. Yes, I know that you’re tired of dealing with the same old architectural limitations over and over again. And that the programming language you wrote it in is no longer fashionable. And that there are lots of new features in the newer versions of the language that would allow you to express things so much more elegantly. Or maybe, god help me, you think that you can write it more modularly this time and that will allow you to more quickly iterate on new features.

Whatever you think, let me make a bold pronouncement: YOU ARE WRONG. WRONG, WRONG, WRONG. FOR THE LOVE OF GOD STOP WHAT YOU ARE DOING RIGHT NOW AND PUT DOWN THE KEYBOARD BEFORE YOU HURT ANYONE.

OK, now that that’s out of my system, let’s get to the natural question: why? Why am I saying this? Because if you ignore my advice and plunge ahead anyway, you’re going to run into what I modestly call:

Vick’s Law of Rewrites: The cost of rewriting any substantial codebase while preserving compatibility is proportional to the time it took to write that codebase in the first place.

In other words, if it took you one year to write your codebase, it’s going to take you on the order of one year to rewrite that codebase. But, of course, we’re not talking about codebases that are only around one year old are we? No, we aren’t. Instead, people usually start talking about rewrites about around the 5-7 year mark. Which means that, as per the law above, it’s going to take on the order of 5-7 years to rewrite that codebase and preserve any semblance of compatibility. Which is not what most people who embark on large rewrites usually think. They think that they can do it in substantially less time than it took in the first place. And they’re always wrong, in my experience.

I first came to this law way back when I worked on Access and the leaders of the project (who, I realize now, were still laughably young, but seemed very old and wise to me at the time) started talking about rewriting Access after we shipped version 2.0 (development time: approx. 4 years total at that point). At the time, I owned the grid control that was the underpinning of the Access data sheet and other controls, and let me tell you–that piece of code was a bit of a beast. Lots of corner cases to make the UI work “just so.” I was talking to one of the leads about this and he dismissed me with a proverbial wave of the hand: “Oh, no, since we understand how that code works now, we can rewrite it in three months.” I think it was at that moment I knew that the rewrite was doomed, although it took three more years for the team to get to that realization.

The bottom line is that the cost of most substantial codebases comes not from the big thinking stuff, but from details, details, details and from bugs, bugs, bugs. And every time you write new code–even if you totally understand what it’s supposed to be doing–you’ve still got the details and bugs to deal with. And, of course, it’s almost entirely unlikely that you do totally understand what it’s supposed to be doing. One of the things that continually humbled me when I worked on Visual Basic was how we’d be discussing some finer point of, say, overload resolution, and someone would point out some rule that I didn’t remember. No way, I’d say, that’s not a rule. Then I’d go check the language specification which I wrote, and there it would be, in black and white. I had totally forgotten it even though I had written it down myself. And the truth is, there are a million things like this that you will inevitably miss when you rewrite, and then you will have to spend time fixing up. And don’t even get me started on the bugs. Plus, you’re probably rewriting on a new platform (because who wants to write on that old, antiquated platform you were writing on before?), and now you’ve got to relearn all the tricks you knew about how to work with the old platform but which don’t work on the new one.

In my experience, there are three ways around this rule:

  1. You’re working on a small or very young codebase. OK, fine. In that case it’s perfectly OK to rewrite. But that’s not really what I’m talking about here.
  2. Decide that you don’t care so much about preserving compatibility or existing functionality. Downside: Don’t expect your users to be particularly pleased, to put it mildly (see: Visual Basic .NET).
  3. Adopt a refactor rather than rewrite strategy. That is, instead of rewriting the whole codebase at once, take staged steps towards the long-term goal, either rewriting one component at a time, or refactoring one aspect of the codebase at a time. Then stabilizing, fixing problems, etc. Downside: Not as sexy or satisfying as chucking the whole thing out and “starting clean.” Requires actually acquiring a full understanding of your existing codebase (which you probably don’t have). Plus, this will take a lot longer than even rewriting, but at least you always have a compatible, working product at every stage of the game.

Rewriting can do enormous damage to a product, because you typically end up freezing the development of your product until the rewrite is done. Maybe at best you leave behind a skeleton crew to pump out a few minor features while the bulk of the team (esp. your star coders) works on the fun stuff. Regardless, this means your product stagnates while the rest of the world moves on. And if, god forbid, the re-write fails, then you run the risk of your team moving on and leaving the skeleton crew as the development team. I’ve seen this happen to products that, arguably, never really recover from it.

So please, learn to live with that crappy codebase you’ve got and tend to it wisely. The product you save may be your own.

You should also follow me on Twitter here.

The Story of the Bill Gates Quote

Recently I told the story of my one product review with Bill Gates, and I said that there was one other terrifying encounter I had with him (well, really, his world) but it would have to wait for another day. As luck had it, I was talking with someone a couple of nights ago who works in Bill’s extended universe and ended up relating my second story, so I thought I’d go ahead and share it here too.

Those with long memories may know that I wrote a book on Visual Basic that came out around the time of Visual Studio 2003. Here’s a picture of it, from Amazon:

Book Cover

If you look up there at the top of the book cover, you’ll see a teeny quote that reads:

Visual Basic is a cornerstone of Microsoft’s development tools–and this book is a key language reference for Visual Basic. — Bill Gates, Chairman, Microsoft Corporation

How exciting! Bill f**king Gates read my book! Well, not really. Here’s what happened…

It all started when my publisher said that they were going to be meeting with Steve Ballmer to discuss the .NET book series that my book was a part of. They said that they were going to ask if maybe Steve would be willing to write a forward for my book since BASIC has such a long and storied history at Microsoft. I said that sounded great and then it hit me that I was friends with Bill Gate’s technical assistant at the time, and so I said that, hey, maybe I could see about getting a forward from Bill himself (since of course, BASIC was his first product!). They thought that was a great idea, of course, so off I went.

My friend directed me to Bill’s writer (the guy who did speeches, etc.) and I had a nice chat with him through email. He said there was basically no way that Bill would do a forward since, as you can imagine, he was getting millions of requests to write forwards and they just had a blanket policy of saying “no.” In talking a little, he did say that he thought it would be OK to do a quote for the cover, assuming that everyone understood that: a) this was a one time thing, and b) not to go around talking about how Bill gave me a quote for my book, since they didn’t want to open the floodgates or anything. He thought it was a small enough thing that I could just come up with the quote, he’d wordsmith it and approve it, and we’d be done–no need to get Bill involved in something so small. Great! I told my publisher and they were ecstatic.

Then one morning I come into work and I’ve got an email in my inbox from someone in my VP’s office saying, “I need to talk to you about a quote your publisher is getting from Bill? Do you know anything about this?”

Oh, s**t.

You see, if there’s one thing I’ve learned about powerful people, it’s that they tend to have an “external immune system” made up of people who’s job it is to filter out the avalanche of requests, demands, pleadings, and just plain crazies who want to get some part of them. It’s just a fact of life. And, furthermore, if you’re dealing with a powerful person you do not want to trip this immune response because it can get pretty tense pretty quickly, especially when you happen to be working for the company that they run. Which it became clear pretty quickly was exactly what I had done.

What had happened was that someone high up at my publisher had met with Bill for some reason or another, and in conversation had thanked him for providing the quote for my book. At which point, Bill apparently said, “What quote?” And BOOM! the immune response started gearing up, trying to figure out exactly where this “quote” had come from and who exactly it was who was claiming to speak for one of the richest men on the planet. Within hours, I was in conversation with senior people at my publisher, with Bill’s personal assistant, with my VP’s personal assistant, with my VP himself, and with Bill’s writer (who, understandably, was not pleased that I had managed to screw up this favor he did me). In the end, I profusely apologized, the quote was vetted a bit more, the immune response quieted down, and the book got published. But it was very tense there for a moment. I really didn’t want to be known to upper management only as “the guy who tricked Bill Gates into giving him a quote for his stupid book.”

Suffice it to say, time has gone on. I moved on from VB, Bill’s moved on to other pursuits (as has my old VP), and the book, while it did OK, was never updated past 2003. But just reading the old emails, which I did in preparation for writing this, got my heart going again just a bit. Not something I think I’d ever want to repeat…

You should also follow me on Twitter here.

My (Terrifying) Meeting with Bill Gates

This being Halloween and all, I thought I would relate one of the most frightening experiences I’ve had in my two decades working at Microsoft. I was reminded of it this weekend when we had a small reunion for everyone who’s worked on Access over it’s 25-or-so year history–it was a bit of old home week, seeing people who in some cases I haven’t seen in well over a decade and a half.

Anyway, it reminded me of an old practice at Microsoft called the “BillG review,” which was a (I think) twice-yearly meeting every major product team had with Bill Gates. They’d go over their progress since the last meeting, talk about their future plans, and give him the chance to ask questions and give direction. As one can imagine, this was a really huge deal (especially back in the days when Microsoft was still a 12,000 person company). A bad BillG review could be extremely traumatic, especially since Bill was not particularly known for his warm-and-fuzziness, nor did he suffer fools gladly. It could also radically alter product plans, depending on whether he agreed with what you were doing or not.

For most of my time in Access, I was too junior to actually attend these reviews, much less give any part of the presentation. I’d mostly just hear about it in the form of a flurry of design changes after each one. But by the time we’d gotten to working on Access ’97, a large majority of the senior folks had split off from the team to work on an ill-fated rewrite of Access. The main focus of Access ’97 was doing something about all the performance we’d lost moving to 32-bit (i.e. Windows 95) and integrating COM and VBA for the first time, and I had self-elected myself to be in charge of the development side of that effort. So when it came time to do the BillG review, I was tapped to give part of the presentation on the performance work. I was also there to throw to the lions in the eventuality that Bill started drilling in on some highly technical question, as he was famous for doing (c.f. Joel’s discussion of his first BillG review).

So the day of the review rolls around and I show up at Bill’s executive conference room with the rest of the team and various Access leaders. Of course, Bill’s running late, so Tod Nielsen (who was Access business unit manager at the time, I believe) decides to entertain us with colorful stories of BillG reviews past. And he decides to tell us the story of the final Omega BillG review.

Now, Omega was the desktop database project that preceded Access. They worked on it for about a year and a half (I think) before it got cancelled, all the code was thrown out, and they restarted on a new project that became Access. I wasn’t around for Omega, but I had heard lots of horror stories about it getting cancelled from people who’d been on that team. As you can imagine, then, the final BillG review for Omega was probably not a particularly happy event.

As I remember Tod telling it, he said that they were going through a list of what wasn’t going well with Omega when, all of a sudden, Bill loses it and starts swearing. “Get f–king recruiting in here, I want f–king recruiting in here right now!” Everyone’s a bit puzzled (and worried), and so they say, “OK, Bill, why do you want recruiting?” He replies, “Because I want to find out what f–king colleges we recruited you guys from and tell them not to f–king recruit there any more because they clearly produce f–king idiots!” Ouch. At that point, the team knew the review was over, so I they basically said, “All right, Bill, we’ll let you calm down and talk to you later,” and left. Tod thought the whole thing was hilarious… now. (It’s also possible he embellished the story a bit, I can’t testify to the veracity of his tale…)

Of course, as the person who was about to present about the primary feature of Access 97 to Bill f–king Gates, I was absolutely terrified. Great, I thought, I’m totally screwed. I’m going to die. Thankfully, Bill showed up, we did the review, and aside from one tense moment, everything went extremely smoothly. Then I got to sit and listen while Bill and the VPs sat around for a little while and discussed when they were going to merge our division in with Office, like they were moving pieces around on a chess board. Fascinating.

Not coincidentally, my other “scariest story” from my time at Microsoft also involves Bill Gates, but that’s a story for another time…

You should also follow me on Twitter here.

I used to be a blogger like you…

…until, well, you know. I realize it’s been quiet around here. Sorry about that.

At any rate, after about 18 months in the SQL engine, I’ve moved yet again. I think I gave a good run at it, but in the end I decided that it wasn’t working and that it was time to do something different. Ironically, I think the biggest reason SQL ended up not working out for me was something that the team decided to do right, namely going all-in on the cloud (i.e. SQL Azure). The problem was that when I originally joined the team, they weren’t quite there yet. The SQL organization was just starting to look beyond SQL Server 2012, all options were on the table, and one of those options was that the team might be willing to take a harder look at the language processing parts of the engine and their future. Then, about a month or so after I moved over the team coalesced around the decision to go all-in on the cloud and make SQL Azure the most amazing cloud data platform possible. And while I think that was totally the right call, it did mean that priorities got shifted and there just wasn’t going to be the kind of headroom to do the kinds of things that I was interested in doing. So instead I got to spend about a year and a half learning a lot of interesting things about the cloud and running a service in the cloud. But in the end, that’s not where my heart lay and so I decided to try something new.

Well, sort of new.

You see, I was chatting with some of my old compatriots back in the Developer Division (including some people I’d spent a lot of time working with on VB) and found that they were doing all kinds of interesting things with this weird little language that apparently a lot of people think sucks. It turns out that somewhere along the line this language that a lot of people think sucks somehow became this totally important language that lots of people were very, very interested in. And they were looking for some more people to work on it. And would I be interested? After thinking about it a bit, I decided that it could possibly be a lot of fun to work on a language that most people deride as a horrible language but which somehow is the crucial underpinning of lots of important things. (Reminded me of some stuff I worked on a few jobs back.) So I decided, why the heck not?

So, I’m now a newly-minted member of the Javascript team. Part of my job is just contributing in any way that’s useful to all the cool stuff that we’re already doing (yay Windows!). Part of my job is to do some looking forward as to where we might go with Javascript. After all, there’s lots of interesting things being done with Javascript beyond just running web pages.

So now you know.

You should also follow me on Twitter here.

Software patents, revisited

So, seven years after I managed to make slashdot, now I’ve managed to make the front page of Hacker News. I have to say, the IsNot patent is the gift that just keeps on giving. I think my comments from the original patent discussion still apply, quoted here since the original post has been lost:

In the wake of the IsNot patent brouhaha, aside from the "you are scum" comments, people have had several reasonable questions about my own feelings about the situation. So let me pause and talk about software patents for a moment. Lest there be any question about this, what follows are my own personal feelings about the matter and have nothing to do with official Microsoft policy.

Personally, I don’t believe software patents are a good idea. I realize that algorithms lie in that grey area between a mechanical process (which is patentable) and an abstract idea (which is not), but at a purely practical level I think that software patents generally do much more harm than good. As such, I’d like to see them go away and the US patent office focus on more productive tasks. I have nothing but contempt for any company that tries to use patents to achieve what they could not through purely competitive means. This includes Microsoft, should they ever choose to do so or have they ever chosen to do so. (I’m not aware of any such situation, but I’m hardly omniscient.)

However, software patents do exist. So while the good fight goes on to get rid of them, I also believe that it would be dangerously naive to not play the game as best we can in the meantime in as principled a way as possible. There are a lot of people who would love nothing more than to just take a piece out of Microsoft either because they can or because they want to get rich and not for any better reason than that. I’ve been around long enough to see the kind of trouble that patents can cause us, and so I believe the best defense is a good offense. While I don’t believe in using patents in an unprovoked way, I do believe in having a robust patent arsenal with which to defend ourselves should someone get it in their head that they want to hold our products hostage for money or just to cause trouble.

One of the most unfortunate aspect of the software patent system is that there is a distinct advantage, should you have the money to do so, to try and patent everything under the sun in the hopes that something will stick. If someone has a patent on "a biological system used to aspirate oxygen gases to fuel biological processes" (i.e. lungs), I wouldn’t be surprised. (If there isn’t, no fair submitting the patent before me!) This is bad both because it jams up a system that’s not really equipped to handle software patents well in the first place and because it increases the likelihood of broad, random patents slipping through the system. Microsoft has been as much a victim of this as anyone else, and yet we’re right there in there with everyone else, playing the game. It’s become a Mexican standoff, and there’s no good way out at the moment short of a broad consensus to end the game at the legislative level.

So that’s how I feel about software patents in general. As far as the specific IsNot patent goes, I will say that at a personal level, I do not feel particularly proud of my involvement in the patent process in this case. Beyond that, there’s not much to say: many comments addressed legal questions which I am woefully unqualified to comment on and for which speculation would be very

To my original blog post, I would add a few things. The first thing is that, thankfully, I believe the IsNot patent has long since either been rejected or abandoned, and in this things are exactly as they should be. The second thing is that while I still continue to hope that we will rid ourselves of software patents, I recognize now in hindsight that the general problem of patents—that there is a strong financial incentive to patent everything under the sun—is an inherent trait of a game that gives the “winners” huge economic advantages. Even if software patents disappeared tomorrow, there’d still be lots of stupid and silly patent applications in non-software areas. Since I think that, overall, the patent system is a good idea, this means some aspects of this are simply inevitable. (Still doesn’t justify the IsNot patent application, though. That was just dumb.)

My final comment regards my assertion that I would hold “nothing but contempt” for any company that used software patents in an offensive, rather than a purely defensive, manner. That is still the case and, sadly, I am profoundly disappointed with some of the things that Microsoft has done in this area since I wrote that post in 2005. The best I can say is that I continue to hope that we will do better in the future.

You should also follow me on Twitter here.

Black Hole Projects

OK, so I may have reset my blog, but there were some interesting posts that probably shouldn’t disappear totally down the memory hole. This is one of them, which I am rescuing from back in 2004 because of it’s continuing relevance. It seems that six months can’t go by without something I hear making me think of this. Edited from the original for clarity and to bring it up-to-date.

Many, many years ago, Steve Maine took the opportunity to reminisce about a project at Microsoft that was being worked on while he was an intern. He says:

[ When I was an intern… ] there was this mythical project codenamed “Netdocs”, and it was a black hole into which entire teams disappeared. I had several intern friends who got transferred to the Netdocs team and were never heard from again. Everyone knew that Netdocs was huge and that there were a ton of people working on it, but nobody had any idea what the project actually did.

I also knew a few people who invested quite a few years of their lives into “Netdocs” and it got me thinking about the phenomenon of “black hole projects” at Microsoft (and elsewhere, I’ll wager). There was one I was very close to very early in my career that I managed to avoid, many others that I just watched from afar, and one or two that I got dragged into despite my best intentions. I can’t really talk about most of them since most never saw the light of day, but it did get me thinking about the peculiarly immutable traits of a black hole project. They seem to be:

  • They must have absurdly grandiose goals. Something like “fundamentally reimagine the way that people work with computers.” Nobody, including the people who originate the goals, has a clear idea what the goals actually mean.
  • They must involve throwing out some large existing codebase and rewriting everything from scratch, “the right way, this time.”
  • They must have completely unrealistic deadlines. Often this is because they believe that they can rewrite the original codebase in much, much less time than it took to write that codebase in the first place.
  • They must have completely unrealistic beliefs about compatibility. Usually this takes the form of believing you can rewrite a huge codebase and preserve all of its little quirks without a massive amount of extra effort.
  • They are always “six months” from from major deadlines that never seem to arrive. Or, if they do arrive, another milestone is added on to the end of the project to compensate.
  • They must consume huge amounts of resources, sucking the lifeblood out of one or more established products that make significant amounts of money or have significant market share.
  • They must take over any group that does anything that relates to their absurdly broad goals, especially if that group is small, focused, has modest goals, and actually has a hope of shipping in a reasonable timeframe.
  • They must be prominently featured as demos in public settings such as company meetings, all-hands, conferences, etc. to the point where people groan “Oh, god, not another demo of this thing. When is it ever going to ship?”
  • They usually are prominently talked up publicly by high level executives for years before dying a quiet death.
  • They usually involve “componentizing” some monolithic application or system. This means that not only are you rewriting a huge amount of code, you’re also splitting it up across one or more teams that have to all seamlessly work together.
  • As a result of the previous point, they also usually involve absolutely massive integration problems as different teams try madly to get their components working with each other.
  • They usually involve rewriting the application or system on top of brand-new technology that has not been proven at a large scale yet. As such, they get to flush out all the scalability problems with the new technology.
  • They are usually led by one or more Captain Ahabs, madly pursuing the white whale with absolute conviction, while the deckhands stand around saying “Gee, that whale looks awfully big. I’m not sure we can really take him down.”
  • Finally, 90% of the time, they must fail and die a flaming death, taking down other products with it (or at least severely damaging them). If they do ship, they must have taken at least 4-5 years to ship and be at least 2 years overdue.

It’s kind of frightening how easy it is to come up with this list – it all kind of just poured out. Looking back over 19 years at Microsoft, I’m also kind of frightened at how many projects this describes. Including some projects that are ongoing at the moment…

You should also follow me on Twitter here.