It’s been a (explative deleted) long time since I’ve posted here. I haven’t had a dependable internet connection in my apartment, and attending to personal obligations at work is a no-no, so my blog has gotten the shaft. I’m sorry, blog, it’s not that I don’t love you; I’ve just been busy, you know. No, I haven’t been posting to that other blog. I just read a few others. Oh, come on, you told me I could look at whatever blog I wanted to, as long as I didn’t touch. You are still my one, true blog. I promise.
I’m winding everything up here at Microsoft. Just finished my co-op work report, which must mean that I’m really about to be finished. I have quite a bit of work to finish in these next two weeks, but it will get done, one way or the other.
I’m still struggling a bit with the overall atmosphere here. I can’t describe exactly what it is, but things just seem a little “off”. I suppose that it isn’t difficult to see why so many people here have drank their share of the Kool-aid, but I’m hoping my cynicism will keep me immune, at least until I get back to RIT.
On the surface, everything appears so well-thought out and everybody seems to be motivated by something righteous. It’s about helping others, about making the whole world more efficient, about making customers happy, about being quality, etc. Most people give off the air of intelligence, and the industry seems to respect Microsoft’s hiring abilities, agreeing with the company meme of “The best and the brightest” (meme in the way that even when it isn’t being verbalized, everyone seems to keep it in the back of their mind in whatever they do).
So, let’s pretend we can just mathematize this, and make it into a simple, discrete function:
Righteous motivation + good design + smart people = ?
What would you conclude to be the right half of that equation? I would conclude something along the lines of “the most amazing software products imaginable, outdoing every other company and individual in the world.”
The thing is, it doesn’t seem (to me, at least) that Microsoft products are the best of anything. They may be great, or even good, and they usually aren’t that bad, but they are never as good as they should be.
I think the biggest flaw is best served by an inept anology, for which I hope to be famous, one day.
For those of you (including myself) who are artistically incapable of producing anything that could be remotely considered “good”: have you ever looked at one of those books that tries to walk you through drawing something? You can produce all of the steps, but your drawings never really look correct.
Microsoft is like that. They follow the “rules” of good design, the ones that tools like lint and FxCop preach as “good” design, but they never quite get it (whatever “it” is). In fact, they don’t even get the basic rules right all of the time. For example, Microsoft defines (or seems to define) a useful abstraction as:
1) making difficult things easier
2) making impossible things possible
Seems good, right? Look a bit closer, and you’ll realize that we are missing one:
3) keeping easy things easy
One of the recent demos I witnessed, which was hailed by many people as “really cool”, is a great example of this oversight. The application he wrote (and by “wrote” I mean copy-pasted from a txt file) was the equivalent of printing out the current date to standard out. It took him about 20 minutes, and he had to fix numerous bugs along the way, bugs that only his team would know how to fix (another problem for another day: horrible failure handling and reporting). In the end, he had a console application that spanned 4 msbuild projects and about 5 or 6 source files (C#). He had written about 5 lines of meaningful code, and about 100 of overhead.
Nobody here seems to see why this is a problem. If not for the fact that I’m disallowed from talking about what I’m doing (the particulars), I could tell you great stories where I am picked on for seeing a problem with this. You see, I don’t think the third rule is less important or as important as the other two, I think it is the most important – no abstraction should make the easy things much more difficult. In the case of the “current date” demo, I could have written the equivalent C# program (print the current date) in about 10 seconds. Since he spent 20 minutes, he took about 120x longer that I would have, and his application had no real benefit from the other crap he added.
So, that is my lesson for today. Before I came here, I thought that the “keeping easy things easy” was so obvious that it didn’t need to be said, and that it was just as important as the other two. Now, I see that it seems to be easily overlooked, both in groups here (read: Avalon, Indigo, and Workflow: spend some time learning and working with them, and see how impossible it is to do really easy things) and elsewhere (*cough* *cough* J2EE *cough* *cough*).
That’s it for today’s moment of Zen. Which reminds me: for those of you who haven’t, go buy a copy of Zen and the Art of Motorcycle Maintenance. It’s worth it, really. Spend your time and spend your money, and then I’ll buy you a cup of coffee and we can talk about it. Actually, I would prefer a cup of Tetley tea, which my officemate has gotten me hooked on. Either way. Cheers.