Whoops!

Is it me or did MS make a typo in this ad:

Overconfidence Bias, or Why You Must Participate In Organizational Politics

Old gem from Overcoming Bias: Bosses Prefer Overconfident Managers Great comments, too.

Organizational politics are complicated, but interesting. Even with my limited experience I can see why so many software entrepreneurs cite frustration with existing organizations as their main reason for going independent.

(The Planning Fallacy might convince you that most people are overconfident about the difficulty of new projects.)

EDIT: I don't have a cite, but I'd be willing to bet money that studies would find VC's prefer overconfident entrepreneurs, too.

EDIT 2: Scott Adams on Bad Management Stimulus. Comments are usually not that good there.

Apple is evil? Yes, but it's not news...

Paul Graham recently looked at Apple's iPhone app store approval process and concluded they're becoming evil. His conclusion is correct, and it's a solid article, but this isn't a recent change for Apple. (Android also isn't as neglected as Paul thinks it is, but there's less buzz around it because Google isn't a marketing organization like Apple is. They grow their projects more organically and more out in the open. In a year or two we'll have a better idea what the prospects for Android are.)

But really, I wanted to talk about Apple. They have a long history of being actively hostile to developers. I spent a while dabbling in the Mac indie development scene around the turn of the century and got to enjoy such marvels as Apple giving Arlo Rose the finger with Dashboard and Apple giving Karelia Software the finger with Sherlock 3. Despite their huge and growing wad of cash, they seemed allergic to doing the ethical thing and buying out solid developers. I don't know how Apple's been behaving lately since I haven't used MacOS X since 10.3 or so, but I'm obviously not the only one who was disgusted by this behavior.

It's also hard to forget the way Apple killed off support for tens of thousands of legacy applications (many of which were single-platform applications specifically designed to run on the Mac) by deciding to drop support for the classic environment when they finally moved to x86 about 10 years after they should have. Microsoft actually has a far better track record in terms of maintaining backwards compatability.

Apple thinks its main business priority is to optimize its users' experience, and if that means pissing off a few developers, well, that's just unavoidable collateral damage. And maybe they're right; maybe that is the best strategy for them. But here's the thing: most users aren't really that invested in their platform, and they'll switch to whichever one is most trendy or shiny when they're in the market for something new. Maybe they'll buy an iPhone this year, and an android phone when they renew their contract in two years, and whatever Apple's brand new thing is 2 years after that.

Developers are different: they have to invest large amounts of time becoming familiar with APIs and conventions, and their livelihoods are tied to the prospects of their chosen platforms. If the company behind a platform might screw us over, it matters, and we pay close attention. Developers don't forget a company's bad behavior as quickly as users do, either. I remember, Apple. I remember.

An NES Emulator written in... wait for it... Javascript!

This is an NES emulator written in javascript. We are using dynamic languages to write emulators now? I know, I know, it's crazy.

Performance must suck, right? Well, no, it easily runs at 60fps in Chrome. But I can barely get 5fps out of it in Firefox 3.5. This agrees with my subjective impressions of Javascript performance in both browsers: although Firefox appears only perhaps twice as slow as Chrome in many synthetic benchmarks, for many real world applications it is almost an order of magnitude slower. Add to that Firefox's ridiculous garbage collector that can lock the entire browser, including the UI, for 4 seconds at a time at 60 second intervals repeatedly going over dead Javascript objects that it is never able to collect, and you've got a seriously, fundamentally broken browser.

Sorry Firefox, you are dead to me.

Nose: multiprocess

One of the coolest things about Nose's multiprocess plugin (aside from the fact that it can run your whole test suite in a fraction of the time on a quad core) is that it discovers, by way of causing your tests to fail, many of the areas where you didn't exactly write religiously-pure unit tests.

This is a rather ad-hoc and incomplete method of finding these problems, though. I'm reminded of a tool I played with in college that intentionally ran a program's threads in every possible order looking for deadlocks: how about running your unit tests in every possible order to automatically discover the dependency problems?

Of course there's a combinatorial explosion to worry about, but it might be worth the CPU cost every time you add a bunch of new tests.