My dog chewed up my slick black XBOX controller last night – the right thumb stick is gone. I feel much cooler and dangerous using the black one, so being inclined toward do it yourself handiness, I thought I’d just swap out a replacement part from my dorky white controller. Genius! I fetched my tools and sat down for an enjoyable session of tinkering when my progress was immediately halted. Apparently our friends at Microsoft don’t want Neanderthals like me monkeying with these things, so they used crazy torx screws with a center post that they KNOW no one will have the bit for :( Why oh why couldn’t you have used a regular screw type, so that “power users” could unblock their “scenarios”? The inset image is a picture of the required tool – guess I’ll add it to my tool acquisition list.

As I sat there dejected realizing that I’d be forced to play Fallout 3 tonight with a broken controller (or a sissy white one) it struck me that this is analogous to the decisions made during API design on sealing Types and making members internal. We sit around the table designing APIs, and for the most part unless we have time to actually think through the extensibility/usage scenarios and ensure they’re safe or at least make some sense, and have time to actually test those scenarios, we seal those bad boys off to protect users from themselves. Just like me and my plans of controller dissection, poor coder Joe partying in VS doing some prototyping of a cool app idea or framework extension discovers that a Type they’d like to subclass is sealed in the framework, or an interesting API they’d like to leverage is internal. “Why’d they lock this API down?” they fume. Then they’re off looking for a workaround, reproducing a bunch of framework code in their own codebase, or using reflection for nefarious purposes. Hmmm, I guess I can’t complain too much about my tamper resistant controller now, since when it comes to API design, I’m in the the “seal it” camp. Just like XBOX support doesn’t have the bandwidth to deal with calls from a bunch of gamer geeks wondering why their “tricked out” custom controller jobs are producing smoke and getting them killed in Halo, we in DevDiv creating frameworks don’t have time to participate in long forum threads attempting to help debug crazy Rube Goldberg extensibility scenarios that we never dreamed of (they’re trying to do whaaat with our APIs??).

I summary, I guess I’ll have to concede that the XBOX controller guys probably made the right decision, and while it pains me that they don’t trust me enough to go in there and do a little minor surgery, perhaps they know best. It’s highly likely that there’s some spring loaded assembly of intricate little parts just waiting to burst forth the moment it’s cracked open – all tinkerers have to admit they’ve been there and wished they’d never cracked the case :) Likewise, that seemingly innocuous API you wish you could call publically might be spring loaded with all sorts of devilish subtleties that even the author of the code can barely navigate. With all that off my chest, I guess I’ll go out to the garage now and duct tape my thumb stick back on :)