Monthly Archives: January 2014

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.

Writing a Compiler in Haskell

In the useless memories department, xkcd’s cartoon today took me back:

In my junior year of college, I took the standard programming languages course that goes over fun stuff like how programming languages are put together. The main project for the class, of course, is to build a compiler for a small language. The twist was, that the professor for this class happened to be one of the designers of the Haskell language, so you can guess what programming language the compilers had to be written in.

The thing is, this class took place probably in the fall of 1990 or the spring of 1991. According to Wikipedia, Haskell debuted in 1990, so first and foremost the tools we were working with were… uh, primitive at best. I think the Haskell interpreter was written in Common LISP, and basically you took your program, invoked the interpreter on it, went and got yourself a nice cup of tea (so to speak), and then came back to an answer (if you were lucky), an undecipherable error message (if you were only kind of unlucky), or just nothing (most of the time). Definitely honed the skill of “psychic debugging.”

Anyway, with a brand-new language (that, of course, had no manuals or books written about it yet) and an alpha-level (at best) compiler, as I remember it at least half the class never even managed to get something working. I somehow managed to grok enough of Haskell to be able to write a functioning compiler that took our toy language in and produced correct output. I was one of the lucky ones. But here’s the thing…

It was, without a doubt, one of the most beautiful programs that I’ve ever written. Just a real work of art, with the data flowing through the code in one of the most natural ways I’ve ever seen. Just awesome. It’s the one piece of code that I look back on and wish that I still had a copy of.

So I’ve always had a soft spot in my heart for Haskell. Even if nobody else could actually understand what it was doing or why.

You should also follow me on Twitter here.