Apple's Mistake
91–100 of 285 posts
Re: Apple's Mistake
#92Part of Paul's reasoning depends on Apps being central to the iPhone experience the same way software is central to the desktop experience. I'm not totally sure this is the case. While apps are certainly a major component to the iPhone, are they really the major factor in end-user adoption? With the exception of games, how many killer iPhone apps are there that don't already ship with the phone? The phone shipped for…
Part of it may be a byproduct of the way the console games distributed on ROMs or disks. That may change, for consoles nowadays have network connection and can get updates anytime. There's another part, however, that some type of games fits this "done is done" philosophy. Like novels or movies, which you don't expect them to be improved over time.
Well, I don't defend the app store process either, and I believe majority of software should be developed in the iterative process. It's just interesting that games may be a marginal area that has some peculiar properties.
Re: Apple's Mistake
#93Re: Apple's Mistake
#94Part of Paul's reasoning depends on Apps being central to the iPhone experience the same way software is central to the desktop experience. I'm not totally sure this is the case. While apps are certainly a major component to the iPhone, are they really the major factor in end-user adoption? With the exception of games, how many killer iPhone apps are there that don't already ship with the phone? The phone shipped for…
You're sort of right, but that's true for all other platforms as well, so it doesn't really tell us anything about the state of app use on the iPhone platform. The OS bundled ones are the ones people use the most. Across the board. If I had to guess, I'd say third party apps are just as often or more used on iPhone than on, say, Windows and Mac OS X. Simply because, on iPhone, a lot of web apps out there are used via…
I don't think there are any killer mobile apps yet. Maybe for some it's FourSquare or FB, but I can't think of one app I'd miss that's not built in.
Re: Apple's Mistake
#95A 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…
This might be a controversial opinion, but does anyone else think that if the QA team is reading your source code then you are doing QA wrong? Or do you really mean "held up by code review" when you say "get through QA"?
Re: Apple's Mistake
#96Earlier quoted context omitted.
I strongly disagree with your conclusion. Both smack of 'religious' thinking. Your point 1 is essentially 'be thankful to the merciful god who has ended the drought'. Your point 2 doesn't solve the problem, it just throws more priests at it. The solution is to open the platform to all developers. Imagine if Microsoft had vetted every DOS and Windows app, or if we had to submit Linux apps to Linus for review.
I keep seeing this notion of opening the platform brought up here. I'm having a hard time visualizing how this works out. Does Apple continue the overhead/cost of the app store? Do they have a giant disclaimer that they do not support or condone the applications, take no responsibility for any damages, etc? Do they still act as the payment gateway? How does this impact Apple's brand and the consumer trust of the prod…
Re: Apple's Mistake
#97If you want a developer environment that fits in your pocket, look no further than the TI-83 graphing calculator. Much of my free time in highschool was spent creating games on it. It's extremely easy to develop for (it uses a variant of BASIC), and the menu system is designed to minimize keystrokes, which means you can bang out your code very quickly. Of course, the platform is very dated: 6 MHz CPU, and a 96×64 mon…
That's a mobile experience that I'd get excited for.
Re: Apple's Mistake
#98Earlier quoted context omitted.
I strongly disagree with your conclusion. Both smack of 'religious' thinking. Your point 1 is essentially 'be thankful to the merciful god who has ended the drought'. Your point 2 doesn't solve the problem, it just throws more priests at it. The solution is to open the platform to all developers. Imagine if Microsoft had vetted every DOS and Windows app, or if we had to submit Linux apps to Linus for review.
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…
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 -- and the user will probably try to get it replaced under warranty rather than admitting that they did something stupid with their phone.
Re: Apple's Mistake
#99A 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…
Value - stuff should work after it's been through them
Costs that I've seen - more stuff doesn't get done/fixed because of the delay time associated with QA - things don't get scheduled because of lack of QA bandwidth - additional specifications required in order to go through QA - programmers / PMs worry less about catching bugs because they feel it'll come back from QA
When is it better to QA something rather than just measure when it's broken? Everything we do goes through QA but I'm sure most of it is a net loss.
Anyone have a good way of knowing what to QA and what to simply monitor?
Re: Apple's Mistake
#100Part of Paul's reasoning depends on Apps being central to the iPhone experience the same way software is central to the desktop experience. I'm not totally sure this is the case. While apps are certainly a major component to the iPhone, are they really the major factor in end-user adoption? With the exception of games, how many killer iPhone apps are there that don't already ship with the phone? The phone shipped for…
The year that iPhone existed without the App Store, no smartphone competitors came close to replicating it's core functionality and user experience. I don't think that's quite true anymore, and so I think that the App Store is one of the iPhone's key advantages. Specifically, the iPhone didn't need the App Store to differentiate itself from RIM and WinMo in 2007, but I think it absolutely needs the App Store to differentiate itself from the Pre and Android in 2009.
I don't think there is one killer 3rd-party app on the phone that everyone needs to have, but there could very well be many third party apps that smaller niches need to have. For me personally, MLB At-Bat (live streaming of baseball games) and the Kindle reader are actually the two biggest factors keeping me from switching to Droid. Those applications could easily be ported to Android, but haven't been yet, and in both cases a third party holds the distribution rights for the content so it's not like me or another hacker could replicate those apps easily.