Don Melton talks about his time working for Apple at NSNorth. It’s a fascinating (and accurate) talk about building things at Apple, which in reality is a lot different than what people on the outside think it’s like. (for even more from Don and Nitin Ganatra, another ex apple development manager, check out iMore’s podcast Debug episodes 47 and 48. Fascinating stuff).
All of this matches up my experience at Mama Fruit. I spent most of my time — and all of the time after Steve returned — in IS&T where the deadline dynamics were different but just as intense. I never had to demo software for Steve, but I did watch as Steve would obsess about placement of a comma in a marketing email during a launch. He sweated that kind of detail on that many things around the company, which seems insane for a company of that size — and maybe it was — but it was one way to install that level of detail sweating into every aspect of the company, and that’s part of how he changed the company DNA to value and demand that kind of quality at all levels. That, I think, is a big reason why Apple is the company it is today.
You don’t “change corporate culture” by issuing memos. You do it by living it and embracing those changes starting at the top, and Steve knew that. It also at times requiring putting someone’s head on a stake outside corporate headquarters, and Steve wasn’t afraid to do that, too, when he ran into an organization head that wouldn’t buy in — and that was a huge problem at Apple when Steve came back and one Gil Amelios was fighting every day (and often losing).
So if you’re curious about Steve and Apple, these are much better glimpses into the insides of the company than most, because Don was there, succeeded in it, and survived to show off the scars…
When I was wrangling developers for Palm, one of the things I used to tell them was to be very careful about building applications around third party systems where they had no guarantees their stuff would continue to work. In many cases they were scraping/hacking sites without formal APIs (like Google Voice, which hosed people more than once — but which never had any official access, so it’s not Google’s fault), but even with these published APIs, I suggested that if there were no guarantees of continues access/compatibility, or if the API ‘agreements’ included the standard ‘we can change our mind and do anything we want any time we want without warning’ clauses, I encouraged people to think twice about programming against those APIs. For the most part developers went with their enthusiasm, and unfortunately, some of the developers got seriously screwed along the way and had their applications killed off out from under them.
And then Twitter decided the developers that built all of the clients that basically made Twitter successful were inconvenient, and screwed the entire developer community built up around them. Which is exactly the kind of worry I had when I was telling developers to be careful about working with companies that don’t partner with third parties or give them any guarantees on access into the future. It was the perfect storm of how a company should never treat those that have been committing resources to help a company succeed by building an ecosystem around it.
And now Twitter is saying “well, forget that. things are all better now. really. come back”. It would be a cold day in hell before I ever wrote a line of code interacting with Twitter, to put it bluntly. They haven’t rebuilt any trust and I would never suggest someone get involved with this new “we don’t hate you any more” system. Not unless Twitter goes a lot further into guaranteeing they can’t — in their formal agreements — do to developers again what they did last time.
And in general, when you’re considering writing an app using an API, stop and look at what the agreements are; not just what they let you as the developer do, but what the company promises in return. Because you don’t want to invest months of development time only to wake up one morning with a broken app and a “we decided to go in a different direction” from the company you used to think you were a partner with.
There’s an even longer, larger, and more profanity-filled version of this discussion having to do with my long, deep look at diving into IOS programming in my “after Palm” life, and why I decided not to, because what I’ve just written goes just as strongly for App Stores like Apple, and Apple is a place that does not treat it’s developers well at all, and you need to go in with eyes wide open when treading into writing Apps that go into one of Apple’s App Stores. Just ask the Pcalc guy.