Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's Mistake

paulgraham.com

Post reply on HN
Print view View original

121–130 of 285 posts

Re: Apple's Mistake

#121

Post by rapind »

lt wrote: post #33
edw519 wrote: 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…

That's only true some times. Unless the data is mission critical, or you introduce a really major bug, the company in question could be losing customer's and / or significant revenue due to the slow down of the application.

I'm not saying you're wrong, I'm just saying there's no hard rule on this. I've had to push code many many times without any outside testing and while occasionally it's been detrimental (but fixed quick, because I didn't have to go through QA), the large majority of times has been beneficial.

A large and formal QA process can kill a product / project just a quickly as cowboy code.

Re: Apple's Mistake

#122

Post by tjogin »

tshtf wrote: post #90
pohl wrote: post #18

Earlier quoted context omitted.

Imagine if Microsoft had vetted every DOS and Windows app Or, hold constant that Microsoft didn't vet DOS/Windows apps and imagine that every DOS/Windows machine had access to a cellular network owned by a some other company. I agree that the review process is completely broken, but I don't think the solution is as easy as having no controls whatsoever.

I've owned two Windows Mobile phones over the past 5 years. Both allowed me complete access to install any third-party applications, in spite the fact they were on third-party cellular network. Same for Nokia. No application vetting whatsoever. Mobile platforms tend to separate critical functions in the radio from what a developer can do with the exposed APIs. Of course neither had an app store, but there were no con…

Apple's actual reason for the approval process is quality control. And by quality control, I mean everything from ensuring a lack of bugs to a polished interface and, last but certainly not least, lack of malware.

Apple wants people to actually buy apps — imagine that. And how do you accomplish that? Make absolutely sure that users don't for even a second think that the app they're interested in might be crap or malware.

Nothing kills spontaneous app shopping like a fear of malware, that's what Apple wants to make sure stays out of their garden.

Re: Apple's Mistake

#123

Post by Aegean »

"It's too complicated for a third party to act as an intermediary between developer and user"

That's a good summary of the situation.

Re: Apple's Mistake

#124

Post by Periodic »

lt wrote: post #33
edw519 wrote: 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…

QA is basically your testing framework. It's there to do all the tests to make sure the software actually does what you say it does.

No developer is good at testing their own code because deep down no developer wants to break the code they just lovingly crafted.

Re: Apple's Mistake

#125

Post by cakesy »

Xichekolas wrote: post #53
edw519 wrote: 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…

I find when this stuff happens with QA teams, it's almost always a case of protecting turf. When no one is looking (the first, buggy, submission is made), they will do the minimum necessary and approve it, often quickly. Then, when everything goes to hell, all eyes are on them. The developers submit a fix with the note "this needs to be approved ASAP to put out fires"... the QA person resents being told what to do, a…

Very cynical.

It is more like there is a problem with an important application, everybody gets the blame. The developer, QA, PM.

So everybody wants to make sure it goes well. The developer. The QA.

The QA doesn't always understand all the contraints put on him, that he has to follow. For example, if this is a fortran program, the indenting will cause it to break. So rather than second guessing every step, he follow every step of the book. So if there is another problem, he doesn't take the blame.

Re: Apple's Mistake

#126

Post by joecode »

Talk about it. I just got a rejection today for a major bugfix on my last update. The only change in the update is to use utf-8 encoding---one tiny change on one line of code. After 2 weeks, they tell me they can't approve the update because I'm using undocumented APIs in a couple places. Sure, OK, looks like I was using some methods that went from deprecated to undocumented... but that's exactly what's in the store right now... ugh. Meanwhile, users are, rightfully, pissed-off.

I'd say about 50% of the time my submissions get rejected, and always for a stupid reason like this; this is one of the better ones, actually. Will I stop developing? Probably not, because it's good money. But am I seriously considering moving to Android? You bet.

Re: Apple's Mistake

#127

Post by dylanz »

edw519 wrote: 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…

You indented with spaces instead of tabs!? Just kidding of course, but the QA team might have been on the other side of that holy war. I'm going to have to start using your TSA parallel though... it's so painfully true.

Re: Apple's Mistake

#128

Post by rev_null »

I think Paul dismisses Android a bit too quickly. Mobile may not be Google's core business (yet), but they are certainly investing a lot into seeing android succeed.

I also think that on a long enough timeline, the more open solution always ends up being dominant. Aside from being convenient for developers, open technologies are also more adaptable to different hardware platforms, which gives them a greater chance at achieving ubiquity. This isn't even the first time apple has made this mistake. Microsoft dominated the OS market in the 90's by not trying to lock their software down to particular hardware.

Re: Apple's Mistake

#129

Post by rapind »

Periodic wrote: post #124
lt wrote: post #33

Earlier quoted context omitted.

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…

QA is basically your testing framework. It's there to do all the tests to make sure the software actually does what you say it does. No developer is good at testing their own code because deep down no developer wants to break the code they just lovingly crafted.

As amusing as that statement is (and I think you meant it jokingly), I definitely have to disagree. There's just too many different developer styles to say No developer. Personally I like to ship quality code and am pretty anal about it's quality as well as it's interface, so you can bet I refactor my code a lot... and I mean a lot.

(In fact I just refactored this comment to fix a spelling mistake... but I published it without writing any automated tests, or running it by QA... somehow I don't think many people noticed)

Re: Apple's Mistake

#130

Post by steveklabnik »

onewland wrote: post #32
tptacek wrote: 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.

In high school, I thought that the CodeWarrior IDE (which was, as far as I knew, the dominant development environment) was absolutely terrible. I'm not sure how good my judgment at that time was. That said, with OS X they really became a lot more developer friendly just because they adopted a UNIX base. At this point, I'd say they're the default platform for ruby/web development. Look at all the rails job postings fo…

Oh man, I had so many CodeWarrior shirts... "Blood, sweat, and code," "X Rated" for their OSX version...

I'm pretty sure that it was dominant at the time. I remember reading a lot of examples that used it.

Post reply on HN