Microsoft's internal software development

Often times, when working in .NET, BizTalk, or some other MS software package, I comment on how well, for the most part, MS’s own tools work reasonably well together.

<pause for laughter>

Now, seriously, here me out. When working with software from MS, it works reasonably well together. BizTalk works pretty well with .NET & Visual Studio .NET, .NET works pretty well with Office, Office works pretty well with IE, etc, etc…

Now, I know what you’re thinking:

“OF COURSE they work together, they’re from the same company and MS made secret deals with the devil. Wait, no, Bill Gates IS the devil, and MS is just a manifestation of his evil plans.” and so forth.

BUT, once you get past all of that, really think about how easy it is for a company to make its’ products work well together. Think of ALL the companys’ that you may have been at, and then think of trying to make a good % of their internal software work together, seemlessly. I mean standards help, like COM & .NET, but as we all know, the devil is in the details.

Frankly, it’s hard enough to get teams owning seperate TIERS of an application ( DB, UI, Middleware ) to work together well enough together, I can’t imagine trying to get one application to have to work well with 3-5 other applications from different teams.

And let’s not forget that MS is a product company, and each team has to support multiple versions of their products. Imagine that version matrix.

Maybe people deplore MS for it’s competative practices, but you have to admire their internal software development practices.

Griffin vs. MapQuest

So I just spent two hours wrestling with MapQuest’s .NET API and trying to figure out why I couldn’t connect to the web, through a proxy, using their API.

After a reflector session, several spikes, and more than a few packet sniffs, I finally figured out WHY it wasn’t working: the MapQuest API has a bug. Actually two.

Breaking down the MapQuest API uncovers two bugs:

  • MapQuest constructs their own, raw HTTP Request as opposed to using the standard .NET BCL objects, and they didn’t test their proxy code, so the HTTP request doesn’t construct the proxy section correctly.
  • MapQuest implements their own Base64 scheme, again, as opposed to using the standard .NET BCL, which, you guessed it, doesn’t encode correctly.

Why, oh why did MapQuest implement their API this way? Because they didn’t “implement” it, they converted it. That’s right, they took their Java API, and ran it through the JLCA. You only have to look at far as their “Collection” objects. Not only do they not support enumeration via IEnumerable, but their API is the same horrible java collection based API: GetAt(int), Size(), etc…

Horrible, just horrible, and the fact that it’s a company the size of MapQuest just makes it worse.

Come Tuesday, my only option may be to decompile the .NET assembly, fix the HTTP request construction, and recompile and use that. That’s a bad solution because if MapQuest releases a new version, we’d be screwed.

Or I could try and contact MapQuest, and see if they could fix the bug. HA! We’ll see how that goes.

Favorite Movies

Everyone always asks me about my favorite movies, and I can never come up with a numbered list. I can never come up with a #1, so I decided to make a list centered around themes, with my favorite movie centered around that particular theme listed:

I’ll keep updating this list as I think of more. Comments welcome!

Ciao.