I was going to take a shot at ripping apart this Leander Kahney article in Wired magazine on how Apple is the anti-Google and therefore evil, but I figured if I waited long enough that John Gruber at Daring Fireball would do it for me. Gruber didn’t disappoint, noting that “by Kahney’s logic, any company that is different from Google – and clearly most companies are far more different from Google than Apple is – is evil. I can’t tell if Kahney is being willfully obtuse or is simply a shithead.” Heh.

The accompanying list of 5 ways that Apple “breaks the rules” makes me wish that Gruber had gone after it as well. Software should be decoupled from hardware, huh? So it can run on just any phone or computer? We have a name for that kind of application. It’s called a web application. You know, the kind of application that Apple encouraged people to develop for the iPhone, and that all the pundits said wasn’t sufficient. Now Kahney slams Apple for encouraging people to build apps that run on the iPhone natively. What does he really want? Maybe Kahney is really asking for the iPhone OS to run on any old phone hardware platform. I can tell you that I can think of no surer way to ruin the user experience, and the brand, than to cram the iPhone software onto a piece of crap like the Sony Ericsson phone I just got rid of, or even onto my wife’s Blackberry Pearl.

The third point, that every Mac is preloaded with Apple software, makes me laugh. You think PC users like having a bunch of crap applications preloaded on their machines? Windows Media Player, which is preloaded on Windows everywhere but the EU, is an OK media player and it’s the default, unless the OEM changes it. But that has nothing to do with the OEM’s concern for the end user’s experience, and everything to do with the revenue they get from the partner from whom they are bundling the software. To be fair, Apple chooses not to bundle competing products, but they have bundled third party software, notably Quickbooks and trials from the Omni group. On both Windows and the Mac, the user can change the default music player (or any other default program) very easily. Would Kahney prefer that Apple shipped with no default player and made the user download one?

And the whole point about the iTunes/iPod closed loop is such a piece of crap. One word: MP3. Available on every platform. You can rip your CDs to MP3s, using iTunes, and put the MP3s on your iPod. One point in favor of this argument: iTunes for Windows doesn’t support syncing to non-iPod players, but there’s a free plugin to fix that.

The fourth point, love your customers, sounds like a page from the Good Product Manager blog. How to be a bad product manager: give your customers whatever they want and ask for in your product, regardless of the cost of support and regardless of whether the resulting product actually does what your customer wants it to do. How else to explain Kahney’s inexplicably picking on the “no floppy drive in an iMac” decision, which in retrospect was not only one of the smartest things that Apple ever did but also created the market for USB thumb drive storage? And the MacBook Air “no optical drive” situation has been covered over and over again. It’s called making intelligent trade offs. It’s what every product manager does.

I enjoyed the Fake Steve Jobs smack-down on Kahney, and wish that he had gone farther. There’s a lot of good lessons to learn in the article for a product manager with half a brain; you just need to dig in and question every assumption that Kahney makes.

I’ve been fighting it, but now it seems the cold, or rather miscellaneous bug of the week, is upon me. Too bad, too, because it’s a nice day and I can see the future of my iPhone getting much brighter.

There is an article to be written about the effectiveness of Apple’s product management—introducing the iPhone as a purely consumer device, then creating a massive developer ecosystem in a single announcement yesterday—but I kind of like Fake Steve Jobs’s take on the announcements even better.

I came into Gizmodo’s liveblog of the iPhone SDK announcement a little late, but the good stuff has already started, beginning with the announcement of native Exchange support for the iPhone. If I just worked in a Mac world I wouldn’d care so much about this, but with one too many IT administrators who don’t care to open up MAPI on their Exchange servers—plus the need to get access to calendars and address books—I’m thrilled that this is coming.

The internals of the SDK are really interesting, too. Of course the hacker community has known about this stuff for a long time, but seeing the full list of what is supported on the phone—certificates, Bonjour (aka ZeroConf networking), the Keychain, SQLite, the address book, threading support, location management, audio mixing and recording, video playback, 2D Quartz, plus a touch-optimized version of Cocoa.

And the development tools stack looks great too, including a true iPhone Simulator. Question: What about test automation? It’s been a long time since I looked at Xcode; does it include a test automation framework?

And I would never have expected a heavy emphasis on games on the first demo of the SDK, but all of a sudden it makes sense. The iPhone is not just a Windows Mobile killer, it could also be a PSP killer.

Now. What I’m waiting for is guidance for IT administrators so I can go have a conversation with my IT guy. And, of course, for the first iPhone apps to show up.

Update: SalesForce.com client!

An interesting article on using GTD with the iPhone led me to a web based task management service called Remember The Milk. It features a clean iPhone interface, email and Quicksilver integration, location based tasks, and all sorts of other goodness.

Which begs the question, I suppose, of how many features a task management service really needs.

I’ll try to work with it and see how things go.

My current employer is built around a couple of concepts: certain kinds of needs are better served on demand than by buying a tool, and certain kinds of software testing (in our case, application security testing) can be automated. There are other concepts that come into our business model, but those are kind of at the core of what we do.

Like so many other things in the world, our concepts aren’t new (though we do have some unique tricks that make them uniquely valuable). Automated testing, in particular, has a long lineage. I didn’t realize how long, however, until I came across a reference to MonkeyDA on Andy Hertzfeld’s Folklore.org, a collection of stories about the creation of the Macintosh.

MonkeyDA was a Desk Accessory, a tiny program that could be run without forcing another program to quit. (Desk accessories were a response to the lack of multitasking in the early Mac OS, and the many use cases of working with a modern graphical computer that essentially demanded having two programs open at once. They ran on top of the currently running program in a different memory space.) But it was a “special” DA. It simulated user interactions with the Mac, by feeding a random stream of events to the OS resulting in the cursor moving on the screen, text being typed, menu items being selected, etc. It was kind of designed to see if it could break the Mac OS or its applications by subjecting it to all sorts of abuse—just like a monkey banging away at the keyboard and mouse would. If the program crashed, it meant the Monkey had found a condition that a user might eventually find. The Monkey is no substitute for human testing based on test cases, but it’s an important complement.

The punch line, of course, is the size of the Monkey program. Written back in October 1983, its binhex is only 2791 characters long. That’s less than 3K of compressed code. That you could create that much mayhem with that small a program is a reminder that code has power, and that you never know what someone else’s code is going to do.