Live data from Hacker News

Apple's Mistake

paulgraham.com

111–120 of 285 posts

Re: Apple's Mistake

#111
post #10

A customer recently asked me to look into a program that used to run in 5 minutes but now took 1 to 4 hours. It's used by thousands of people all over the world all day long. It iterated through an array doing 3 SQL SELECTs against non-indexed files for each element. There used to be about 50 elements in the array; now there were more than 5000. I rewrote the whole thing in one day to do a total of 4 SELECTs and run…

Agreed. The last company I worked at we had some similar idiocy. We had a backend process that connected out to a network and did some things. However, the network it connected to changed their protocol, so our backend process was broken - didn't do anything - completely non functional. We created a fix, but had to wait for it to go through QA for ages. What's the worst that could happen? It doesn't do anything like…

The worst? Data Loss, or corruption, which is worse than "not working".

Likewise, more likely it could just not work well, be buggy and require several updates to get it right, burning out your team's (or your company's) image with the customer. Before you deployed your fix, it's whoever changed the protocol at fault. After that, it's you that can't fix it.

Again, not justifing it taking ages, just saying there's never an excuse to skip QA.

Re: Apple's Mistake

#112
There are two logical flaws in this essay, and I think a misperception in the essay as a whole.

The first logical flaw is to point out how developers love Apple's support for developing desktop software, and then a few paragraphs later say that they [Apple] "don't understand software". Obviously they do understand software.

The second is that Apple's control over the app store review process will create a closed monoculture. So the original iPhone development model of using web apps has been forgotten already? Mobile Safari is continuing to support new standards and APIs, enabling new kinds of app to be delivered that way, and it will continue to be a competitive option for developers in the future. These apps will work in other phones and do not require an approval process.

The misperception of the essay is that the app store, and specifically its approval process, is evil. But this doesn't make any sense.

Apple just handed to small, independent developers a way to distribute their software to tens of millions of customers with a real, working single payment mechanism that is so easy it affords impulse buying from anywhere at any time. The cost to enter this program is $99--less than the cost of the phone itself and an entry barrier so low it's practically nonexistent.

So we now have apps developed by the recently unemployed--while sitting on their living-room couch no less--making tens of thousands of dollars in a few weeks.

This is unprecedented and incredible. It's one of the best things that has ever happened for independent developers since the microcomputer. And then they made it even better by adding in-app purchasing through the same payment mechanism. This is huge.

The inconsistency of the app rejections points to the problem of hiring and training people to interpret the policies, not the policies themselves. They aren't likely to find people who want to do that kind of work, and I'm figuring that the turnover is probably as high as it is for call centers. And given some reports that app store submissions (or at least approvals) reach 2000 per day, I would be amazed if these kinds of problems didn't happen in even the best run and most benevolent company in the world.

But while everybody is calling Apple evil for these growing pains, Apple is busy learning how to do App Stores. Statements made by Tim Cook, the rejection-reversals that come from higher up, policy changes and clarifications, suggest that Apple does actually care and is (slowly) improving the process.

Apple has a clear vision of what they want to deliver to the customer, and the review process is part of how they're trying to make that vision work. I think they're going to stick with it until they get it right.

I think it's likely that Apple will eventually find a way to solve these problems. When it does, it will have a competitive advantage that Android and Palm and even Microsoft won't be able to match for years: an app store that customers trust and will readily make purchases from without second thought, and a simple, painless way for independents to get their apps in. This would pave the way for an Apple TV App Store, a iTablet App Store, a Book/Magazine/Newspaper store and so-on.

It'll probably take a while to make it as painless as it should be for developers, because these kinds of problems are _hard_. Harder than engineering.

This isn't Apple's Mistake, this is an extra $100 or more per share of AAPL in the next few years.

Re: Apple's Mistake

#113

Earlier quoted context omitted.

Faustian bargain? Assholes? Evil? .. really, if this is the most serious accusation of "evil" one can level at Apple then it isn't really going to affect my buying decisions. It's not like they're dealing in small arms or manufacturing cluster bombs. If you step back and think about it all Apple is doing is stuffing up their own app store, which can be classified as monumentally stupid and short sighted but not reall…

General Electric, now there's a company that's "evil". http://www.google.com/search?q=%22general+electric%22+%2Bevi... Do you see my point? To anybody outside the app development community it's going to look a little bit "self important" for developers to be using such strong language and talking of boycotts over something most folks would agree is not evil. I agree what Apple is doing is stupid, in the long term the…

Yeah, but it's Paul's point that it's the developer's opinions that matter, hyperbole or not. Microsoft didn't get into the business of operating systems until Apple kicked them off of theirs. If Apple makes it too hard for developers to write software for them, developers will go to the next best thing, even if it's DOS.

Re: Apple's Mistake

#114
post #29

Though I can't marshall any evidence to support this claim, it was specifically not my impression that Apple was a company pro developers loved working with before the iPhone.

I make Mac apps for a living and have, over a few years built up nice relationships with Apple. In spite of only being a small, not US-based, company (11 people now, but only 5 when we won our first Apple Design Award), it was never hard for us to get noticed by Apple, or to get in touch with the people at Apple we needed to talk to at any given point.

Our first app was built using 'unsanctioned' technology, PyObjC (before PyObjC shipped with 10.5); the app would have never seen the light of day on the iPhone, but then again, we would never have built it in PyObjC for the iPhone to begin with. Everyone we've ever met at Apple has been supportive from day one, and we owe a lot to many of those people.

We have not shipped any iPhone apps, so I can't say how I'd like that, but as a Mac app developer I love working with Apple.

Re: Apple's Mistake

#115
post #55

Earlier quoted context omitted.

Do you think Apple should look at Microsoft's mobile strategy with envy?

That's not what I, or the original commenter, was talking about. Having no approval doesn't mean chaos for carrier's networks.

Conversely, having a horrible train-wreck of an approval process like Apple does clearly doesn't mean you can't have unparalleled success either. So I guess we're back to square one.

Re: Apple's Mistake

#116
post #33
post #10

A customer recently asked me to look into a program that used to run in 5 minutes but now took 1 to 4 hours. It's used by thousands of people all over the world all day long. It iterated through an array doing 3 SQL SELECTs against non-indexed files for each element. There used to be about 50 elements in the array; now there were more than 5000. I rewrote the whole thing in one day to do a total of 4 SELECTs and run…

Not that the indentation complaints are valid, but the fix should definitely go through QA while the users continue to suffer. While I'm sure it works on the developer machine, it is much better to have a program that takes a long time and works right than for it to give incorrect results to users, or make a different part of the application stop working. If the feature was really critical and important, QA should fi…

I've seen lots of software that's gone through QA but didn't work. Ever use Microsoft Windows?

QA is important, but determining how many spaces a line of code is indented is not QA. That is a code review, which is important, but not critical. There should be automated acceptance tests, so that new releases can be shipped immediately. (It's also worth noting that stuff like indenting, naming conventions, etc. can be automatically checked at checkin time. See Perl::Critic, for example.)

If there is some feature or corner case that the users test but isn't in the acceptance test suite... well... yeah, the software is going to be unreliable. So don't do that. Write a test.

(I worked somewhere with a QA department once. They didn't like it when the programmers wrote tests, because they felt their job would be threatened. It was true, so we were asked to only write unit tests; no "integration" or "acceptance" tests. I quit a few weeks later.)

Re: Apple's Mistake

#117
"Google and Apple. If Microsoft was the Empire, they were the Rebel Alliance."

I always think of them more in terms of Animal Farm. Microsoft was Mr Jones, Google and Apple are Snowball and Napoleon.

Re: Apple's Mistake

#118
post #98

Earlier quoted context omitted.

Yes, PG makes the point very well. Apple thinks of themselves as ensuring quality, when in reality they are having the exact opposite effect. What they need to do is just let all apps through, and make it easy for customers to report problems, and then Apple can proactively pull apps that have too many problems. They could do that at half the cost and have much better overall quality, to say nothing of the developer…

Of course, then Apple couldn't screen for the things that they care about but that users won't report. For example, applications that use Apple/iPhone imagery wouldn't get reported because users don't care about the dilution of Apple's brand. Likewise, applications that encourage the user to do things that might damage the device (swinging, throwing, or dropping) wouldn't be reported because the device is broken -- a…

I'd add to that that it's probably best that Apple catch malware before it enters the app store, not after.

Re: Apple's Mistake

#119
> Could anyone make a device that you'd carry around in your pocket like a phone, and yet would also work as a development machine?

I can answer this one: there are already a few people who are interested in Hecl for this reason: they want to use it to write code on the phone. That was never my intent with the system, as it seems painful to me, but if there are already a few using my little language, which is not well publicized, there must be a bunch more out there. And if people are doing that with existing phones, I think things will only get better in the future.

Re: Apple's Mistake

#120

I have now two published apps in the App Store. Both business apps - one in finance and the other in business. The biggest change they have made that took me off their platform was their recent policy to not show updated applications along with new releases. Let me explain. For the longest time, if you looked under released applications you could see applications that were recently updated. This was a great incentive…

This was a great incentive for developers of existing applications to keep updating their applications and getting it easily noticed by users. It was also a great incentive for developers to game the system and swamp the reviewers by submitting trivial updates every week to keep their apps at the top of the list. Tragedy of the commons.

Actually, I think it's a positive thing to the user, since it encourages incremental development. Anything that incentivizes "release fast and iterate often" incentivizes good development.

On the other hand, it did tend to swamp the review process.

Post reply on HN