The Forecast For iCloud
Marco:
Is this interesting at all?
Casey:
I don't know.
Casey:
I'm bored.
Casey:
What are we talking about tonight, then?
Marco:
I don't know.
Marco:
Is there anything to talk about with this Sumley thing?
Casey:
I don't know.
Casey:
I thought your post about David was really interesting.
Casey:
And this is obviously mutual admirationist society.
Casey:
But I thought it was very it was very prescient and impressive that he was smart enough not to reveal his age and then made an oops.
Casey:
And like you said, suddenly every article about Tumblr became about his age rather than the fact that Tumblr was really well done.
Casey:
And that's too bad.
Casey:
But I've never used Summly, so I don't know if it's any good.
Casey:
Apparently you say it's not good.
Marco:
I don't know what they did in the last six to nine months.
Marco:
They have their whole app that was this whole news browsing thing.
Marco:
That all came about fairly recently.
Marco:
Before all that is when I tried it.
Marco:
So I didn't try any of the new stuff.
Marco:
So I can't really speak to what it was.
Marco:
But the...
Marco:
Originally, the whole summarization engine I was really not impressed by.
Marco:
I think it was a reasonable idea to try to do something like that, but it wasn't that compelling.
Marco:
The idea of this thing is to take any web article, news article, whatever the case, and summarize it into three little one-sentence bullet points.
Marco:
And so the idea is that you don't have to read everything.
Marco:
Well, first of all, as somebody who likes reading things, that's kind of missing the point.
Marco:
But okay, there's some uses for that.
Marco:
I can see that.
Marco:
The problem is that the summaries were so bad.
Marco:
Occasionally it would get maybe one and a half of the three bullet points would make sense.
Marco:
But that was like the best I ever saw it do.
Marco:
So it was a way to poorly summarize news stories sometimes.
Marco:
And so to me, I just don't have anywhere where that fits into my life.
John:
You guys probably don't remember this because you didn't start using Macs until recently, but back in the classic Mac OS days, Apple made a big stink at one point in its sad decline in the 90s about a system-wide text summarization service where you could select text and ask it to summarize it, and it would summarize it down to a couple sentences.
John:
Is this sounding familiar yet?
Yeah.
John:
Yeah, exactly.
John:
And this was classic macOS.
John:
And that feature, it might still be in there.
John:
You should go look in like Automator and see if there's a summarized text thing.
John:
But it predates macOS 10, my recollection.
John:
And yeah, that feature did not set the world on fire.
Marco:
I don't know what the state of the art is with natural language processing doing summarization.
Marco:
I'm sure there's probably good stuff out there, but the thing with lots of natural language processing or AI-type algorithms is that...
Marco:
a lot of times the best they can ever do is an 80% job.
Marco:
And so there's a lot of cases in the world where that's useful.
Marco:
But usually when you're directly between the data and the human and you're trying to do just this one smart thing that involves language and concepts and very subjective, difficult, complicated things...
Marco:
it's not usually a good idea to expose the AI's output directly to people.
Marco:
Let's say it's 95% good.
Marco:
5% is still pretty often.
Marco:
You're still going to hit that a lot.
Marco:
John, you've talked a lot about speech recognition software, because you've used it a lot, and dictation software.
Marco:
What do you think is the highest acceptable error rate that you would still use it?
John:
For summarization or for speech recognition?
Marco:
For speech recognition.
John:
Well, speech recognition, I mean, the error rate is pretty high, and I think I'd be willing to put up with a much higher error rate than I currently get.
John:
In fact, I think I'd be willing to trade correctness for responsiveness, because when you're trying to speak, you don't want to be waiting.
John:
The built-in dictation in OS X is the worst case, because
John:
you activate the little thing and then you see a little blinky cursor in front of you, then you talk, then you have to like activate the thing again to say, okay, take what I just said and do something with it.
John:
And then you stare at the blinky thing and then a whole bunch of text comes on the screen.
John:
And that's when you find out whether it has been totally off the rails.
John:
Whereas if it has exactly the same error rate, but did it a word at a time, you know, kind of like the difference between Siri and the Google, you know, iOS talk,
John:
speech-searching thing.
John:
Responsiveness, I think, is more important than correctness.
John:
Obviously, if it was 70% error rate, you'd be annoyed, but I think being responsive is more important than being exactly correct, because Dragon has really, really good accuracy, really high accuracy, but it still frustrates me sometimes when I'm talking faster than the text is appearing, and I have to stop
John:
Maybe I don't have to stop, but I do stop to wait to see the last, you know, 15 words come splatting out on the screen, usually all at once, to see that it's on the same page.
John:
Because if you don't do that, if you just, like, close your eyes and talk, it will do an amazingly good job.
John:
But every once in a while, I'll get something off, and I'll go back and I'll rebut what I, you know, quote-unquote wrote by speaking, and I'll have no idea what the hell I was saying.
John:
And I'll have to, like, I'll look at it and try to think of homonyms, you know, like...
John:
Which word that sounds like the words on the page?
John:
Because when you make your own typos, it's like, oh, I was typing the right word and I screwed up a couple of characters.
John:
You could figure out what it was you said.
John:
But when you do like speechos where it transcribes the wrong thing, it could be so far off semantically.
John:
And I've literally had times where I say, I have no idea what the heck I was trying to say here because the sentence actually makes no sense whatsoever.
John:
They don't make any sense, and I don't remember what I was saying, and I've got to say the word as written out loud and close my eyes and think of what it sounds like.
John:
But, I mean, I don't think many people would choose to use speech recognition.
John:
Let's put it this way.
John:
I wouldn't be using it if I didn't have RSI things with typing.
John:
I think that's when you'll know speech recognition has really arrived, when people who can already type very quickly choose to use speech recognition instead because it's like...
John:
Either equally as fast or, you know, it's so accurate that why would you bother flicking your fingers around, you know?
John:
But we're far from that right now.
Casey:
Well, plus it's not a group activity.
Casey:
What I mean by that is, if you're working in an office full of cubicles, like John, I presume you do, and I certainly do, if all of us are talking to our computers, that's going to be a bit loud, to say the least.
Casey:
And furthermore, doing the sorts of things that all three of us do, which is write code, which is a far cry from regular prose,
Casey:
I've never imagined nor tried to do speech recognition for writing code, but John, I can't imagine you're writing Perl and regular expressions, which is basically the same thing, using speech recognition.
John:
It is not the same thing, and no, I am not using speech recognition for that.
Marco:
That was a good troll.
Casey:
I do my best.
Marco:
I feel like there's places for this stuff.
Marco:
A lot of people have said that, first of all, there are opportunities for anything that could be considered an assistive technology for people.
Marco:
Dictation is great for people who can't type, and RSI is usually mild, but still a handicap, and
Marco:
And so if you can't or would rather not use your hands to type, then it's great to have alternatives.
Marco:
But the place for a lot of this stuff is, in other contexts, people who don't permanently have a specific disability but who might temporarily have one.
Marco:
For example, when you're driving, you really shouldn't be typing.
Marco:
And when driving, you're also theoretically, hopefully, partially blind to your computing device.
Marco:
So that's why things like voice commands and audio cues can be so useful in a mobile app that you're expected to use while you're in the car.
Marco:
And so Siri is great for that, but Siri is not good enough for me to dictate everything that way.
Marco:
As John said, when you have alternatives, you'll take them, but it's still good...
Marco:
to have this thing when you don't have alternatives or when your alternatives are worse.
John:
I'm trying to look up the text summarization service from classic macOS and Google, and I can't find it.
John:
All I can find are the references to it existing in macOS 10.
John:
So maybe I'm misremembering, but I could have sworn that this was like from macOS 8 or whatever.
John:
But anyway, if you want to just fire up text edit now in macOS 10, paste a bunch of text in there from an article, select the text, go to the services menu, summarize will be in there if you didn't deactivate it in your pref pane.
John:
And you get a little slider that lets you, you know, crank it down to, you know, one sentence if you want.
John:
So, like, I don't understand how – I don't know anything about this summary thing except for what I read on Marco's blog and, like, one or two other news stories.
Yeah.
John:
And summarization is not the whole thing.
John:
I think it was like it would, you know, it was basically a way to let you consume news without you having to look through all the news.
John:
It would try to give you a condensed version, but not, you know, am I getting this right?
John:
But not having a human do it, having the computer do it.
John:
And summarization would be a part of that.
John:
But if it's the summarization part that they were excited about, again, this feature has obviously existed for a long time, whether it's in classic Mac or not.
John:
No one cares that it's there.
John:
Is it patent encumbered?
John:
I still don't understand why they paid $30 million for it all.
John:
I don't understand it at all.
Marco:
And so that's what a lot of the debate has been about.
Marco:
First of all, it's cool to say Yahoo is being stupid because Yahoo's had some pretty bad decades.
Marco:
So everyone's like, oh, look at how stupid Yahoo's being.
Marco:
But I don't think it's them being stupid.
Marco:
Usually, if you think a company is being stupid, usually you aren't looking at the whole picture or there's something that you're missing or there's some better reason for what they're doing that's better explained than they're idiots.
Marco:
Yeah.
Marco:
So I think you can... Unless the company is RIM, now called BlackBerry.
Marco:
Anyway, they actually already... But for the most part, everybody else, when the explanation is, oh, they're being stupid, there's usually more to it.
Marco:
So I think in this case...
Marco:
A lot of people have suggested – so here's the deal.
Marco:
They bought Summly, the product and part of the staff, for $30 million, most of which was cash.
Marco:
I think they said 10% was stock, but all the numbers are actually rumored or from inside sources that are unnamed.
Marco:
The numbers were not officially made public, but everyone's saying $30 million, mostly, in cash.
Marco:
And it's a classic textbook, Aqua Hire.
Marco:
The product is immediately shut down, and Yahoo paid, for this size startup, it's a relatively modest sum, for basically for three people, for the three most important people by their definition, to work for Yahoo for a minimum of 18 months.
Marco:
So basically they've paid like $10 million a head for these key people.
John:
That sounds even more crazy.
John:
Now that you're telling me more about this, I'm thinking it sounds even crazier than I thought.
John:
So they're shutting down the stupid product that summarizes stuff?
John:
Oh, it's gone.
Marco:
They pulled it from the App Store already.
John:
I don't understand it at all.
John:
There's no way those three people are worth $30 million.
John:
There's just no way.
Marco:
There's part of the debate that some people are saying that the technology was actually licensed from SRI, the parent company of Siri before Apple bought it, that the speech recognition or the natural language processing technology was actually SRIs and it was licensed from them, that somebody didn't develop that.
Marco:
But then...
Marco:
The Summly people are denying that, so it's unclear what is the truth there, but at least what Yahoo bought, at least what we know that they bought, was they paid $30 million for these three people, one of whom is the 17-year-old kid, Nick... Oh, God, I should not try to pronounce his last name...
Marco:
uh d yeah starts with a d aloysio maybe d aloysio i'm sorry nick i i'm probably butchering that um nick d uh he but not nick denton yeah gosh this is tough um anyway nick d aloysio sorry um
Marco:
He started this company when he was 15.
Marco:
Now he's 17.
Marco:
So now he's a 17-year-old tech whiz kid millionaire, which, of course, the press loves to bang on that angle so much.
Marco:
And I kind of ripped them apart yesterday for that, as we were saying at the top of the show about how that was originally a problem at Tumblr, because David was so young.
Marco:
But...
Marco:
So all the stories are about how young this kid is, or about the tech press freaking out that why the heck did they buy this and why the heck did they pay so much.
Marco:
But to bring this back a little bit, a couple weeks ago we had a question from Avi Beckert.
Marco:
He suggested an interesting topic.
Marco:
He said, what if Apple bought Yahoo?
Marco:
And the idea there was, like, Apple needs good server-side and services talent.
Marco:
And Yahoo might have that.
Marco:
And I thought about this topic for a little bit.
Marco:
Yahoo is still very popular, especially among non-geek demographics.
Marco:
Yeah.
Marco:
like normal people as we like to say in the geek world, which is probably condescending or somehow weird, but sorry about that.
Marco:
Anyway, we brought, I don't know.
Marco:
I don't know what the right term is.
Marco:
Non geeks.
Marco:
I think it's fair.
Um,
Marco:
But I think Yahoo is, for the most part, resting on their previously achieved laurels.
Marco:
And I don't think they've really done a lot in the last decade, maybe, to really get new users and to really grow the company.
Marco:
And that's why everyone has said they've been in trouble.
Marco:
And that's why it was interesting when they brought up Marissa Meyer as CEO from Google.
Marco:
So that was interesting.
Marco:
But either way, this is a company that needs to make a comeback of some sort.
Marco:
They've also, in the last decade, gone through a lot of layoffs.
Marco:
A lot of very talented people have left or gotten fired or gotten laid off.
Marco:
So they...
Marco:
I don't have any inside sources at Yahoo, but I have to imagine they probably have a talent shortage.
Marco:
Because if you're really good, you probably were not happy working at Yahoo in the last decade, and you probably left or didn't go there in the first place.
Marco:
Because they've just lost so many good people over the last few years.
Marco:
So...
Marco:
And they have some good properties like Flickr that we've just seen just, you know, languish and stagnate as all the good people have left or they've gotten fired.
Marco:
So Yahoo, talent-wise, I have to imagine is not in good shape.
Marco:
So the other angle people are discussing with the Summley deal is, first of all, Nick D'Aloisio, again, I'm sorry, he might be a really good product sensibility person.
Marco:
And that's the kind of person that in one way Steve Jobs was.
Marco:
It's the kind of person certainly that David Karp is at Tumblr.
Marco:
Believe me, he is definitely the kind of person...
Marco:
And that's a very valuable kind of person, just shorthand, just called product people.
Marco:
Product people can make or break a company because they make the decisions about what a product should be, and they have the sensibilities to know what people will like and what will work.
Marco:
So if Nick DiAluisio is a really good product person...
Marco:
then it would be valuable to bring them onto Yahoo, because Yahoo needs people like that.
John:
Not $30 million valuable.
John:
I'm trying to think of some sane reason that you'd pay $30 million, and here's what I've come up with, and it's not great, and it's based on no information.
John:
One, there's a bidding war.
John:
You're not the only one who wants to buy these people.
John:
You pay what the market demands.
John:
If you want them more than someone else, you just go up, up, up, and we get them in.
John:
And two is intellectual property.
John:
They have some stuff that would... It would cost you...
Marco:
it's more important for you to own this intellectual property because it would cost you more to let someone else scoop it up and then you have to license it from them long term those are the only two things i can think of well what i'm thinking is there there are two factors here that could have driven the price up a little bit artificially uh one is that yahoo is again not in good shape and
Marco:
You could argue that having a really good product person is very valuable to the company.
Marco:
You could counter-argue that, well, he's only obligated to stay there for 18 months.
John:
It doesn't matter how good you are.
John:
18 months is one thing, and the second thing is unproven.
John:
Show me you're a great product person.
John:
Where's your great product?
John:
Was it this thing that we just can't and no one was really interested in?
John:
Because that ain't great.
John:
I mean, even Steve Jobs didn't get $30 million the day he arrived at Apple in 1997.
John:
He had to kind of sort of A, kick out the old CEO, and B, kind of sort of prove himself before like they were like, okay, well, you know what I mean?
John:
He didn't come out the gate and say, oh, Steve Jobs, you're wonderful.
John:
We're going to immediately let you take over and give you tons and tons of money and shower you with praise.
John:
If Steve Jobs has to prove himself, this kid has to as well.
John:
You don't pay $30 million for a couple of employees, no matter who they are, even if they literally are the best employees in the entire world.
John:
You just don't pay that much money for it.
John:
You wouldn't have to.
John:
You could get those employees for less money if they didn't know.
John:
They obviously know they have something or think or know they have something that's actually worth much more than they would be individually as employees.
Marco:
Well, maybe Yahoo can't get them for less.
Marco:
Again, Yahoo has a problem because if you're really good in this industry, do you want to work at Yahoo?
Marco:
Probably not.
Marco:
That's a problem.
Marco:
I think $5 million a head for 18 months would do it.
Marco:
So anyway, one thing I think they can justify the high price by saying, well, we're Yahoo, we need people, we need good people.
Marco:
The other thing is Nick DiAluisio, again, I'm sorry, is extremely relentless and really, really good at self-promotion.
Marco:
This guy, there was – I linked to this Gizmodo article, which is really kind of tasteless, honestly.
Marco:
I felt bad even linking – I almost didn't link to it.
Casey:
Wait, on Gizmodo?
Casey:
Really?
Marco:
Yeah.
Marco:
Weird.
Marco:
Because when – you know, this – you got to keep in mind, this is a teenager, or at least he was.
Marco:
Well, he's 18 now, I guess, or 17, whatever.
Marco:
But this is a teenager.
Marco:
Like, if I –
Marco:
I started a company when I was a teenager and got a whole bunch of publicity and got all over the press and was able to email people who were important in the industry.
Marco:
I don't know that I would have acted that much better, honestly, because when I was a teenager, I was an idiot.
Marco:
And I guess I'm probably going to look back at this time in 10 years and say I was an idiot now, but I at least feel like I'm way less of an idiot now than I was when I was a teenager.
Marco:
Yeah.
Marco:
So I got to give this kid the benefit of the doubt that, okay, you know, he was 15 when he started all this stuff.
Marco:
And when I was 15, I was an idiot.
Marco:
So anyway, but he emailed this Gizmodo reporter relentlessly, like every day, making up all this stuff like, oh, my boss is going to get on my back if you don't put my app in the Hall of Fame or something like that.
Marco:
And everything was marked urgent.
Marco:
So I didn't see that story when it came out.
Marco:
But Nick...
Marco:
gave me a similar email barrage about six months later, trying to get me to integrate Summly into Instapaper.
Marco:
And I mean, the emails he sent were... I don't want to be mean to the kid, but I mean, it was ridiculous.
Marco:
He would email me like multiple times a day on some of these days.
Marco:
Everything was marked like super urgent, even though it wasn't urgent, which is just kind of a rude thing to do.
Marco:
And...
Marco:
He would impose this artificial sense of urgency, and everything had to be done quickly.
Marco:
Right now, oh my god.
Marco:
A lot like a high-pressure car salesman.
Marco:
High-pressure manipulation, I would say.
Marco:
I was not left with a very good impression of Nick from these emails, just because I felt like I was being manipulated and badgered and annoyed.
Marco:
So...
Marco:
Because he did the exact same thing as somebody else, I have to imagine this is just part of his personality where he can badger the crap out of people until they do what he wants.
Marco:
If you look at his company, his company has some fairly prominent investors who
Marco:
He had a promotional video done with Stephen Fry, among other people he did a few things with, too.
Marco:
And he has a lot of connections, obviously.
Marco:
And I don't know if he badgered his way in or if he earned them or what.
Marco:
This kid is really, really good at...
Marco:
getting people on his side, and badgering people into paying attention to him and doing what he wants for his product.
Marco:
So it's very possible that just Yahoo's desperation and that could have been the only two factors that made this price go way higher than we think it probably should have.
Marco:
That seems highly unlikely to me.
Marco:
You didn't get these kids' emails.
John:
I read the articles.
John:
Yes, he's enthusiastic and annoying, but there's obviously something there that...
John:
That we don't have information about.
John:
There's something.
John:
It's a bidding war.
John:
It's intellectual property.
John:
It's obviously not the product because they can that.
John:
Do the product have a big user base that they're transferring?
John:
No, I don't think that's it either.
John:
It's got to be something else.
Marco:
The product had less than a million downloads and no revenue.
John:
Think about it.
John:
If you're running a company, you can't hire a superstar person
John:
For, you know, $10 million ahead, all your existing people who are like, wait, aren't I a superstar?
John:
Why don't I get $10 million for $18 million?
John:
It doesn't, you just can't do that.
John:
There's got to be something there worth money to the company.
Marco:
besides those human beings i i think it's clear i think you're right that we we don't know the whole story here because obviously this still seems ridiculous but i don't think there needs to be that much more to it for it to be understandable or or plausible like i don't think they had some kind of awesome super duper natural language processing technology that yahoo now owns i don't think that's it at all because i saw the technology and it wasn't that compelling
John:
Well, it might just be patents.
John:
Like I said, intellectual property doesn't have to actually be awesome.
John:
It can be super-duper dumb.
John:
In fact, those are the best kind of patents, the super-dumb patents.
Marco:
I don't think they were in business long enough to get a patent issued.
Marco:
Oh, everybody's got a patent.
John:
Everyone's got a patent.
Casey:
Well, and I read somewhere today, and I wish I remember where I read this, so this is probably false since I barely remember where I read it, but somebody said that it wasn't even their tech.
Casey:
It was like quasi-Siri in that they licensed the tech from someone else and just put a UI in front of it and called it theirs.
Casey:
So I agree with you, John, that if it's not the people, then it should be IP, but supposedly the IP isn't theirs anyway.
Casey:
So what gives?
Casey:
I don't know.
Marco:
I don't know.
Marco:
Again, I think John's right.
Marco:
There has to be something else here that has not been reported.
Casey:
Well, and if it's the desperation of Yahoo, something that I've heard or I've read a lot about lately is how desperate Apple is.
Casey:
So how far is Apple from being in this position?
Casey:
And I know that's kind of a ridiculous and absurd thing to ask, but it's also kind of a legitimate thing to ask.
Casey:
I mean, is Apple really where the super incredible mega nerds want to be these days?
Marco:
That's a very good question.
Marco:
I've heard a lot of things, rumors and some things from people in Apple, that they have a lot of problems retaining good talent.
Marco:
Maybe getting good talent they still are okay with, but retaining good talent, they're having a big problem there.
John:
It makes sense that they have trouble retaining, because...
John:
Like the way Apple works is if you are a really smart, you know, great performer, lots of talent, can do lots of different things.
John:
You're not going to go to Apple and get to do what you want to do because the company does so few things like it's focused.
John:
Right.
John:
So you can help contribute to what may be a big deal.
John:
But you're not going to go, you know, I have this really great idea for this thing.
John:
And Apple's going to be like, no.
John:
They shoot down everyone's idea.
John:
Like, only very, very few ideas actually get implemented.
John:
So eventually, after you've worked on one or two things that Apple decided to do and you were important in contributing to them or whatever, you will inevitably say, well, you know what?
John:
But now I want to actually do the thing that I was thinking of that I think is cool.
John:
And there's no way for you to do that inside of Apple.
John:
So you inevitably have to leave.
John:
And it's not like...
John:
Yeah.
John:
I just want to go off and make letterpress or something.
John:
Apple's not interested in that, but maybe you are, and you can't do that within Apple.
John:
And so you're like, all right, well, I worked on this, I worked on that.
John:
They were great.
John:
It's really important work.
John:
Lots of people use it, but I just want to do my thing.
John:
So I think that's inevitable.
Marco:
I think also you can kind of get some idea that most of the people I know, and maybe this is just the people I've observed because it's who I follow on Twitter or whatever, but most of the people I know who have left Apple have gone to much smaller companies.
Marco:
Oftentimes they've gone to start a startup.
Marco:
And I think it's part of what you said, John.
Marco:
It's part of them wanting to do something on a much smaller scale where they can have a bigger role or make a product that Apple would never make.
Marco:
But
Marco:
I think part of it also is that Apple has created this entire environment, this entire ecosystem of small startups being able to succeed and one-person shops being able to succeed on the App Store.
Marco:
And their people being in charge of this stuff or working on the frameworks or working in this world or at least being surrounded by
Marco:
by other developers who are working in this world, that has to be very tempting for people who work inside of Apple to be looking at all these other people making probably way more money than they make at their job at Apple and doing really cool things and making products from scratch and having no boss.
Marco:
To watch that from the inside and not be able to participate, that has to be very tempting.
Marco:
And I bet that pulls a lot of people out of Apple.
Casey:
But isn't the converse also true in the sense that, let's say I was a middle-of-the-road, self-employed iOS developer, and I have a few apps or maybe just one app in the App Store that's popular, but it's barely self-sustaining.
Casey:
And then Apple says to me, hey, why don't you interview with us?
Casey:
I can't imagine I would be like, no, I really like being my own person.
Casey:
And it's hard for me to fathom what it's like to be self-employed because I've worked for the man my entire life.
Casey:
But I guess what I'm saying is if I was not a superstar and if I was just a regular Joe who was trying to do his own thing in the app store and Apple said, hey, we've seen what you do and we really like it and we'd like you to interview –
Casey:
I've got to imagine, I'd be thrilled at that opportunity.
Casey:
I would be so beside myself.
John:
They want you to move to California, though.
John:
How do you feel about it now?
Casey:
Well, and that's a very, very fair point.
John:
Because they don't do the telecommuting thing, really, and that's another limiting factor.
John:
You want to work for Apple, you've got to live in Apple Land, and living in Apple Land is expensive, and maybe that's not where your family is, and maybe that's not where you want to live.
Marco:
And if you do live out there, you have a lot of competition for that job.
Marco:
Or rather, people have a lot of competition for an employer.
Marco:
If you live out there already, then you can go work for any number of big tech companies plus an infinite number of small ones.
Casey:
And that's a really good point.
Casey:
It really honestly is.
Casey:
And I'm hypothesizing.
Casey:
I don't know what any of this is like.
Casey:
But I guess what I'm saying is as much as Apple is arguably bleeding talent, I can't imagine that it's that hard for them to find new talent.
Casey:
That being said, a revolving door is clearly not a sustainable approach.
Casey:
So I don't know.
Casey:
It's an odd thing to think about.
John:
I think it's not just the people who go there, are a superstar, do something awesome, like design the UI for the original iOS or the iPhone OS as it was then known, launch the original iPhone, maybe do one or two other projects and say, all right, well, now I feel like I have all the talents under my belt to do Brady's basically whatever I want, and I want to be the one in charge.
John:
You can only have so many chiefs.
John:
It's mostly got to be Indians, especially at a company like Apple.
John:
You only do a limited number of things.
John:
Only a limited number of people are in charge.
Marco:
Is this an H-1B reference?
John:
Native Americans, Marco.
Marco:
I don't know if we're allowed to call them that.
Casey:
Suddenly we've taken a turn.
John:
So, like, there's that feeling that you want to, like, I want to be the guy who calls the shots, right?
John:
And so those people go off and do that.
John:
But it's not just the people who are like, well, I came in at the bottom, I learned some stuff, and now I'm able to go off on my own.
John:
Because, like, you know, like you said, you can make more money.
John:
My friends are making these hit applications and making tons more money than I am.
John:
I could be proprietor of my own business.
John:
I could have...
John:
Unlimited income, limited only by my success, not by a review process and cost of living raises and bonuses and maybe stock options are unlucky.
John:
Think about Bertrand, Bertrand Serlet, who was one of the guys in charge, making presumably tons of money.
John:
He didn't leave Apple because he didn't get to be in charge of stuff.
John:
Well, I mean...
John:
He wasn't Steve Jobs, but he was like, you know, two or three rungs down from there.
John:
If anyone, you know, there's very few people who have that level of power.
John:
And he certainly wasn't, you know, oh, well, I'm so bitter that these people are making money in the app store.
John:
He just wanted to go and do something different.
John:
And no matter where you are, except maybe if you're at the very, very top of that pyramid, if you have an itch to go do something, you can't do it within Apple if it's not something that Apple wants to do.
John:
And so he left to do whatever his secret startup is right now.
John:
He didn't retire to sit on the beach and count his money and watch the waves come in.
John:
He had an intellectual itch and he wanted to do something.
John:
And so he left to do it.
John:
And that's inevitably going to happen in a company where you hire people who... Because that's what you want in your company.
John:
People who could be the Steve Jobs of their own company.
John:
But you want them to work for you.
John:
And you want to get them as long as you possibly can.
John:
And get what you can out of them.
John:
But I don't think Apple is bitter that they go off and do things on their own.
John:
If anything, it's like if we have an employee who couldn't leave Apple and go off and do better for themselves, maybe we didn't make the right hire.
John:
Like that's the you know, that's that's the calculus there.
John:
They want all people who could do better outside of Apple, but they want to keep them for as long as they can and, you know, get the best work out of them, I guess.
Marco:
I think it's interesting maybe to distinguish.
Marco:
We're talking about how Apple's having trouble getting talent, but that seems to be mostly at the lower levels of the company and the mid-levels of the company.
Marco:
At the upper levels of the company, they seem to have, for the most part, pretty strong loyalty and pretty long-running people there.
John:
Well, executives, I mean, can a middle manager go off and do their own thing and be as successful as they are as Apple?
John:
No, because at a certain point when you get high enough, like Bertrand is an exception because he was in the engineering organization, but there are people who are just managers.
John:
And if you're a longtime manager at Apple, you're going to be making lots of money.
John:
Maybe you don't care that you don't get to tell the company what the company gets to do.
John:
Like there's room for middle management everywhere.
John:
Those people aren't going to leave voluntarily.
Marco:
Yeah, I guess that's true.
Marco:
But if you look at other companies, I think Apple is pretty good at retaining the upper people.
Marco:
And so I guess the question is, the upper people, obviously, frequent changes there would probably be way more disruptive to the company than frequent changes at the lower levels of the company.
Yeah.
Marco:
Are frequent changes at the lower levels really something that they should be worried about?
Marco:
Or should they just keep trying to make the best stuff and keep retaining the upper people and just kind of hope that the lower people keep coming in faster than they're going out?
John:
I think they probably need to figure out some way to prolong the really smart people's stay by giving them some way to flex their independence and desire to do something.
John:
It's totally against Apple's MO to do the computer equivalent of concept cars or have something like Google Labs or 20% time.
John:
Those are just not in Apple's culture.
John:
But Apple's culture is so far in the other direction.
John:
If you can just give people some outlet within that structure to say,
John:
There is a slim chance, however slim, that you may be able to get us to do your crazy idea.
John:
Think of the original Xbox.
John:
I think it was Jay Allard and maybe one other person had the idea, you know what, Microsoft should do a gaming console.
John:
And they were not vice presidents when they came up with this idea.
John:
They were, you know...
John:
pretty much rank and file employees who'd been there for a while but were not not in a position to say microsoft should make a game console but they were able to take that idea and pitch it up up up the ladder and eventually convince microsoft to make a game console and they became a big part of that process not like say oh good we that's a great idea guys now go back and toil no they became you know
John:
big wigs in charge of that project.
John:
That can happen inside Microsoft, or at least happened once.
John:
There are plenty of people in lower positions in Apple whose ideas come to fruition and become a big type of thing, but I'm not sure they go with those ideas up the ladder.
John:
So if you could just give
John:
make some sort of forum within the company for these independent people to come up with something that it's possible to pitch its way up and to become the next big, you know, pillar on the stool.
John:
Even if that only happens like once every 10 years or something.
John:
I mean, I don't know.
John:
Like, none of us have ever worked for Apple.
John:
So we're all just speculating on the outside what it might be like.
John:
But...
John:
I think that type of like 20% time, however BS it is at Google these days and Google labs type things in the pre Google plus days, let's say before Google tried to become maniacally focused.
John:
That was a lot of the reason I think a lot of really smart people stayed at Google.
John:
Because whether anything actually came to fruition or not, there was the idea that it was a bunch of smart people doing lots of interesting things in all sorts of directions, and why would you leave to go anyplace else?
John:
Because here they give you a nice salary, they feed you, they take care of you, you have health insurance, it's a nice job, and you kind of sort of get to do whatever you want.
John:
Who knows that thing, whatever you want, could become the next Gmail, because that's where Gmail came from, right?
John:
Or the next Google reader before, you know.
John:
That environment within Google, the pre-Google Plus Google, I think that served as a magnet to pull people into Google and to keep people into Google.
John:
Maybe the wrong kind of people, maybe not the kind of people Apple wants, but Apple needs just a tiny little taste of that, a little bit more than they have now, and I think that would help them keep people for, say, six months longer.
Marco:
yeah hopefully longer than that but yeah i think that's that's wise i don't know casey what do you think
Casey:
I think I agree with everything you said.
Casey:
What's hard for me to reconcile is if you look at the big players in California, and let me hedge heavily by saying I'm an East Coast guy.
Casey:
I've only been to California a handful of times in my life.
Casey:
In fact, at least half of them were for WWDC.
Casey:
I don't understand what the culture and what the technology sector looks like out there.
Casey:
So I apologize for getting all the following wrong.
Casey:
Email Marco.
Casey:
But
Casey:
If you're a really bright engineer and you're really passionate about writing code, where are your options?
Casey:
I mean, you can go to Microsoft, but most people would perceive that as just corporate stooge land.
Casey:
You can go to Google, which means your entire purpose in life is to sell ads.
Casey:
You can go to Yahoo, which means you're the only bright star in a cloudy sky, which some people might like, but it's not my cup of tea.
Casey:
Or you can go to Apple.
Casey:
And at least Apple is devoted to pleasing customers as opposed to telling customers they're out to please them and actually putting their eyeballs for advertisements.
Casey:
Does that make sense?
Casey:
I don't see why anyone else would be compelling with the exception, as you guys mentioned, of startups.
Casey:
But I don't know.
Casey:
I guess I'm so risk adverse that that doesn't seem that compelling to me either.
John:
Well, that's one of the reasons that I think that senior executives stay as well is because especially if you're a senior executive, like it's the, you know, you want to sell sugar water for the rest of your life or come with me and change the world.
John:
Like those executives really feel like they can have the biggest impact on the world by being a regular good old middle manager in Apple than being a regular good old middle manager at Coca-Cola or GM or Procter & Gamble because they don't feel like they're –
John:
You know, like, they can go to parties.
John:
Oh, I work for Apple.
John:
Yes, I'm a very important person.
John:
You know, the iPod, you've heard of that?
John:
Yeah, that's the company that I work with.
John:
You know what I mean?
John:
Like, there's all sorts of angles to that, but there really is a chance.
John:
And same thing for engineers, to do something that you think will have an impact that used to be Microsoft, that was certainly Google and probably still is Google, because you could say you work for Google, and that, like, you know, I don't know what we call it, job satisfaction or...
John:
feeling like your job is important and can change the world and you're not just toiling away and i think apple is just as much a corporate stooge job as microsoft or any other place and it's a big corporation it's like it's it is what it is it doesn't it's not it's not crazily different than any other large corporation like say valve or something where it's totally outside the realm of expectations they have managers and employees and teams and there may be a couple of things that are different about them and certainly at the top levels the company behaves very differently in terms of focus and everything but to employees i don't know i don't
John:
I don't think it's that different.
Casey:
Maybe it's naive of me, but I feel like Microsoft's purpose in life, maybe up until recently, but Microsoft's purpose in life was to please other companies.
Casey:
And Yahoo's purpose in life is to buy cool things and ruin them.
Casey:
Google buys cool things and ruins them, too.
Casey:
That's true.
Casey:
And Google's purpose in life is to sell advertisements.
Casey:
And at least Apple's building cool stuff, right?
Casey:
I mean, if you're going to choose a corporate stooge job, and I think, John, you're right.
Casey:
Apple's more corporate stoogey than I care to admit.
Casey:
But if you're going to choose a corporate stooge job on the left coast, is Apple not the best option?
John:
It also depends on what kind of person you are.
John:
Here's the problem we were talking about with Apple and its services.
John:
Say you are someone who does something on the server side, data centers, infrastructure-type software.
John:
You don't want to go work for Apple because Apple has not shown that it values those people or that part of its business.
John:
It just wants it to work, doesn't want to hear about it.
John:
The smartest, best server-side people...
John:
They don't want to work at Apple because they want to be valued.
John:
If they go work at Google, they're practically gods.
John:
You get to work on GFS version 3 or Spanner or whatever these infrastructure things.
John:
Those are serious business.
John:
That's the whole company, right?
John:
But at Apple, you're just like, we don't want to hear you or know who you are or anything about you.
John:
All we ever hear is that you're screwing up and just make it like...
John:
The people who get the glory are I, maybe the iPhone interface, or I'm designing the next piece of hardware.
John:
I work on the operating system.
John:
Nobody's getting any glory or any fame or any recognition or putting anything in open source or contributing to anything.
John:
Who's working on server-side at Apple?
John:
Forget it.
John:
So Apple, I think, cannot hire those people.
John:
We're talking about like, oh, if you're a client-side programmer or if you're a designer, yeah.
John:
Designers want to go to Apple.
John:
Client-side native people want to go to Apple.
John:
But if you're a web developer or a server-side person, you don't want to go to Apple probably.
Casey:
That's not entirely true.
Casey:
I think that's mostly true.
Casey:
But if you happen to be one of the six people on the planet that knows how to do web objects, I think you can –
John:
Yeah, it's like COBOL.
John:
Yeah, they've gathered up the COBOL programmers.
Casey:
No, you're right.
Casey:
You're right.
Casey:
But I think that the six people that do web objects in the world and an acquaintance of a friend of a friend of a friend does web objects and actually lives nearby to where I live, and he works for Apple because – or at least that's my understanding.
Casey:
I could be totally wrong.
Casey:
Yeah.
Casey:
My point is if you do one of the things that Apple does that nobody else does like WebObjects, you can pave your own way.
John:
But I'm saying that's why Apple is having trouble hiring the people they need to make their server-side stuff better because hiring a bunch of WebObjects programmers is not going to help them make their stuff better, right?
John:
They want the people who are taking the jobs elsewhere who are going to come up with the next big thing or at least just bring Apple up to date with like 10 years ago tech.
John:
They're so far behind and so –
John:
out in the weeds on this they just want to get good server side people to do their stuff and it's and i bet like it's not just that maybe they can get the good server side people once the good server side people get there and they go like the first thing they want to do is like we got to get rid of this web objects crap what the hell are you guys doing and they'll find out like that the culture is like no we can't get rid of the web objects it runs you know the itunes store that sells 20 hojillion songs every three seconds and you can't break it and you know you're not going to rewrite it in something else just just help us get better but don't change anything
John:
Like that type of attitude, that is totally, you know, talk about corporate stooge jobs.
John:
Like that's the way it is.
John:
I mean, there are realities that have to be dealt with.
John:
You can't come in and say, no, no, no, no, no.
John:
Like the Apple store, that should not be written that way.
John:
You just got to get rid of it and replace it with something else.
John:
That's not a big, you know, what's the payoff?
John:
So we're going to risk destroying our entire, you know, multi-billion transaction business.
John:
And what's the benefit at the end?
John:
Oh, that we aren't on web topics?
John:
Oh, well, you have to see it'll give you a path forward and you'll be able to bubble.
John:
Like, it's so hard to sell those type of projects, right?
Casey:
Well, that's true.
John:
And so I think those people go there and then, like, realize that they're not going to be able to change anything and then leave and get a job at Facebook.
Casey:
And that's true until you have somebody like The Verge writing an article about how crummy iCloud is.
John:
That's not the server-side guy's fault.
Casey:
Is it not?
Marco:
No.
Marco:
No.
Marco:
We'll get to that in a minute.
Marco:
Before that, let me give our sponsor break here.
Marco:
This episode is once again sponsored by Squarespace.
Marco:
Squarespace is just an awesome way to make a website and have it hosted and designed and managed for you.
Marco:
It is fantastic.
Marco:
It's a website hosting platform.
Marco:
You can put up your blog.
Marco:
You can put up a store, a portfolio, a site for your business, a site for your music, whatever you want to do.
Marco:
You can put it up on Squarespace.
Marco:
Plans start at just $10 a month.
Marco:
And really, I mean, it could not be easier.
Marco:
They have a whole bunch of great templates designed by professional designers.
Marco:
Yeah.
Marco:
And if you want to jump in and customize all the CSS and HTML and JavaScript, you can do all that.
Marco:
Our site is hosted there, ATP.fm.
Marco:
You can check it out.
Marco:
That's totally a Squarespace site with minimal hacking involved.
Marco:
And if you don't want to mess with the hacking, you don't have to.
Marco:
You can just go there and sign up and move stuff around, drag and drop.
Marco:
Everything is hosted.
Marco:
It is just so low needs and awesome.
Marco:
I really can't overstate this enough.
Marco:
hosting a website on Squarespace is just so ridiculously easy.
Marco:
It's where I tell everybody in my life who asks me, oh, how do I make a site?
Marco:
Where should I host this?
Marco:
Could you help me with this?
Marco:
I say, yes, I can help you.
Marco:
I will tell you to go to Squarespace and that's it.
Marco:
Go there.
Marco:
That's it.
Marco:
And
Marco:
It's like telling people who want tech support, it's like telling them to just get a Mac.
Marco:
Because you know you can give them that directive and they won't come back to you calling you every five minutes with some problem and making you fix their computer.
Marco:
Squarespace is that for web hosting and web site construction.
Marco:
Trust me, it is awesome.
Marco:
Go check out Squarespace.
Marco:
You can use our coupon code ATP3 for Accidental Tech Podcast in the month of three.
Marco:
That's code ATP3.
Marco:
Use that code at checkout to save 10%.
Marco:
And again, plans are at $10 a month.
Marco:
You can even sell stuff.
Marco:
You can do commerce.
Marco:
I can't even fit everything they do into one ad break.
Marco:
Believe me, Squarespace is great.
Marco:
You can host any kind of website you want, a beautiful site, and you don't have to worry about hosting.
Marco:
You don't have to worry about designing everything from scratch.
Marco:
It's all done for you.
Marco:
It's fantastic.
Marco:
Go to squarespace.com, check it out today.
Marco:
And thanks to Squarespace for supporting us once again.
Marco:
So there's this article on The Verge called Why Does an iCloud Just Work?
Marco:
And it's getting a lot of attention.
Marco:
And I think this is worth a little bit of discussion here.
Marco:
And there was a great follow-up from Brent Simmons that we'll get to in a little bit.
Marco:
But, I mean, what do you think about this article?
Marco:
It basically cites a lot of users and developers basically all saying, like, we tried to build iCloud sync into our apps and it just didn't work and we had to cancel it.
Casey:
The problem I had with it was very few of the developers were named.
Casey:
And I don't blame them because if it were me, I wouldn't want to be named.
Casey:
I have tremendous respect for, I think, Pasco from Black Pixel was named.
Casey:
I think Justin Williams was named.
Casey:
And I have tremendous respect for those who were named.
Casey:
But I don't think the message was unfair or invalid.
Casey:
Everything I've ever heard from both prominent people whom I follow on Twitter, for example, and even friends who do this locally, all of them have said… You said boom too much.
Casey:
Yeah, I know.
Casey:
You saw that feedback, didn't you?
Casey:
Anyway, the people who I know that do this locally, everyone has universally said it's crap.
Casey:
It's in the same way that auto layout is either crap or so impossibly difficult to get right that it's effectively crap.
Casey:
It's all crap, I tell you.
John:
No, this is much worse than auto layout.
Casey:
It is.
Casey:
It really is.
Casey:
But I mean, so at what point is this wheel squeaky enough for Apple to really fix it?
Casey:
And can they fix it?
Casey:
I know, John, you've talked at length about how you're skeptical whether they can.
John:
Well, this is separate issues.
John:
That's why I said that the iCloud core data thing, and that's specifically what we're talking about here, is...
John:
It's not so much the server-side people.
John:
The server-side people have to answer where you have the server-side stuff being flaky or whatever.
John:
But as far as I can tell from listening to all the same developers and talking to some of them in person and reading all different articles in their blogs, it's a design problem.
John:
It's a...
John:
high-level, box-level design and also an API design problem.
John:
The high-level design is like, is there a way to have 17 different devices with a bunch of related objects stored in local databases and get them all to sync together without doing what Google does, which is like, okay, well, Google has your mail.
John:
Your email is on their servers.
John:
And that is the one...
John:
source of truth in the entire world and when you pull it up in your web browser you're not like synchronizing the state on your web browser but that thing is just like oh well i can there's one central source of truth everywhere and everyone synchronizes with that and all their actions like modified this is a bunch of local things to do modifications then they all try to synchronize with each other later sort of in a peer-to-peer type fashion um and i'm not sure that that conceptually and algorithmically they've worked out
John:
How that's supposed to work for arbitrary object models, because, you know, with core data, you can make up your own object model and you make your own relations between things.
John:
And, you know, like it's it's not it's not a fixed schema.
John:
I mean, it's it's not schemalist, but it's not like they don't know how your application works.
John:
So they're trying to make a general purpose system for any sort of, you know.
John:
tree of objects that you can modify in any sort of way and that later go to another thing that has its own tree of objects that's in a different state modify that one and then have the two reconcile themselves with each other and have that actually work like sometimes you don't even know what's supposed to happen uh
John:
So that's the first problem.
John:
The second problem is it looks like the API design that's on top of this conceptual thing doesn't give the developers nice ways to do the things they want because the problems are so complicated.
John:
Like one of the ones they put in the article is like, what if someone takes my app, starts doing stuff with it, essentially builds an object model for their data, and then they sign into iCloud?
John:
And their iCloud account, they had previously installed this application elsewhere, and they had a bunch of object data from there.
John:
How do I reconcile?
John:
Like, do I erase everything that they have and replace it with their iCloud version of this thing?
John:
Do I try to merge it to?
John:
What if they're not related at all?
John:
It is just a nightmarish type problem.
John:
And I think conceptually, ignore bugs, ignore server availability, ignore server speed, ignore visibility of anything.
John:
I just think conceptually, they don't have something that is nailed down that will work 100% of the time.
John:
And then layer on top of that...
John:
Oh, well, you know, there are bugs and there are APIs that there's no hook for me to say, hey, tell me when this thing changes.
John:
And sometimes it gets corrupted and it gets wedged and you can't tell what's wrong because I have no API to query.
John:
Is this thing available?
John:
Is it not available?
John:
Has new data come in?
John:
Has new data not come in?
John:
Like...
John:
It's just failure on top of failure on top of failure, and it's not just one thing.
John:
So that's why I think, like, get the best server-side people in the world.
John:
It's not going to save them from this, because they still have seven other layers of things that have gone wrong with this specifically.
John:
And I think the conceptually simpler ones, like the key value storage and document storage, because there's a solid design under there, whether it's like, well, last update wins, like in key value.
John:
I think key value is last update wins.
John:
And something a little more sophisticated for document, it's like a very simple conceptual model.
John:
Then they can put an implementation on top of that, which may or may not have a few bugs, but it's okay.
John:
And there's enough visibility into it and you can get stuff done.
John:
Like, I mean, we're all developers.
John:
You know what it's like when you start programming something and you didn't think it through conceptually to begin with?
John:
There's no amount of typing you can do after that to make it better.
John:
You have to just go, wait, wait, wait a second.
John:
What the hell am I doing here?
John:
This is never going to work right.
John:
I haven't even thought it through yet.
John:
I can't just start blindly typing and putting in weird cases and try to make this work.
John:
And that's the situation I think they're in with iCloud core data.
Marco:
Yeah, and I think from what I've heard and from what I've seen from other developers, I haven't done much with iCloud.
Marco:
I should say that up front.
Marco:
The only thing I've done with iCloud was a very basic feature of syncing your position and currently read article in the magazine, which works sometimes.
John:
What did you just say?
John:
Was that key value stuff?
Marco:
Yeah, I just used key value because it's just way easier.
Marco:
Literally, I'm just storing article positions in each article because that's small.
Marco:
And I'm storing, there's one key that just tells me what article you're currently reading.
Marco:
That's it.
Marco:
But the main concerns I've heard have been, yeah, what you said, the core data sync, which is I have this whole database of objects in my app.
Marco:
And when iCloud was unveiled, I believe Steve Jobs was doing this part of the presentation.
Marco:
He even said, like...
Marco:
And it works with the core data.
Marco:
You just sync it, and it just works.
Marco:
I think that got a huge applause.
Marco:
Because if it worked, it would be awesome, wouldn't it?
Marco:
Exactly.
Marco:
The whole audience was blown away.
Marco:
Like, really?
Marco:
Because that's a really hard problem.
Marco:
That's amazing.
John:
He should have said, no, not really.
Marco:
just kidding and so you know we work we were promised that this would work and so a lot of developers relied on that so the core data sync that i've always heard has been a complete disaster um but i think and the key value store is fine and everything documents um i don't know a lot of developers who've used the document model because originally everybody just did either key value or core data um if they could um
John:
Well, there are things to do with documents.
John:
And to be unfair to the server-side people, back in the iOS 5 days, almost nothing worked right.
John:
Key value is obviously the simplest.
John:
And document storage mostly worked but had some kind of annoying bugs and quirks, and that can be a little bit weird.
John:
So all these things were flaky to begin with, but it's just like the reason this is coming to a head now is because, all right, these things have had time to stew.
John:
iCloud didn't come out three months ago, right?
John:
iCloud is not brand spanking new.
John:
All these APIs, like we gave them like the one major version of iOS to mature, the one major version of Mac OSN to mature.
John:
And now that like key value storage and document storage seem to be following the typical path of Apple APIs and core data is not like...
John:
getting better.
Marco:
Well, the biggest problem, you know, I have heard that that core data is part is, you know, the most unreliable part of, of the iCloud sync stuff.
Marco:
But I think the much bigger problem, which you, you breeze past a little bit ago, uh, is that everything is tied to the Apple ID that's currently signed in and that people sign out of Apple IDs and into different Apple IDs on their devices, uh,
Marco:
fairly frequently.
Marco:
Everyone's not doing it every day, but there's a good number of people who do it regularly.
John:
And they have APIs for that.
John:
They have APIs for it.
John:
They're like, oh, and you're going to keep in mind that when you launch, you may not be in the same Apple ID as when your stuff was made, and you may get this callback that means they changed Apple IDs.
John:
And like...
John:
like they they're aware that this is going to happen but they like kind of shove it under the carpet of the program and say oh and you'll figure out what to do when that happens like what am i supposed to do like i you know so in some cases like all the pre-existing data gets deleted like that was in your local directory like you know and what if i hadn't synced that and like it's gone now like you're you don't have it's like it's like uh you know throwing an exception if you can't you know if the disk is full or something well you know i'll catch it i'll catch that exception what are you going to do about delete stuff
John:
right i mean like sometimes you can't there's no sane recovery or there's nothing smart for you to do that's what i talk about like the conceptually not like like oh well we have a callback for when they change things and and we'll automatically clean up all the old data and you're ready to go again i'm like but wait a second like from a user perspective like what if you want to do something different what do you want to tell people that this is happening that they're going to end up deleting all their local data and
John:
Like, I just don't think it's been thought through yet.
John:
I mean, and this is all, like, old data.
John:
Like, the frustration of the Verge article is, like, we talked to Apple and they don't tell us.
John:
Of course they're not going to tell you anything.
John:
That's their MO.
John:
They're just, like, total silence.
John:
And, like, either WWC, they're going to come out with, like, you know, the API equivalent of the Apology Mouse from Macworld New York 2000.
John:
You know, we're sorry for the puck.
John:
Look under your chair.
John:
Look under your chair.
John:
There's a sane database syncing, you know.
John:
Like, they'll come out.
John:
It's kind of...
John:
It's kind of, this is, it gives me some hope because like mobile me was a disaster and they had to change the name and you get iCloud, but they have had at least one instance where they had something that was a disaster and they came out with the much better, awesome version of it and didn't change the name.
John:
And that's file vault where file vault one was just a mess and file vault two kept the same name, but it was totally unrelated other than a name and that it did the same function and is awesome.
John:
So file vault two is awesome.
John:
File vault one was terrible.
John:
So if iCloud core data syncing,
John:
If this is considered just awful and then, like, something else comes out that's different and they say, here's this new thing, just forget about the old thing, they can still call it iCloud.
John:
Because iCloud is an umbrella term that already covers umpteen different things.
John:
And why not just keep changing out the scope?
John:
And they have the advantage of not having this user base.
John:
Like, wait, what about all the successful applications built on iCloud and core data syncing?
John:
They'll have to rewrite?
John:
Oh, there aren't any.
John:
Don't worry.
Yeah.
Marco:
And I think you're right, though.
Marco:
But conceptually, this is a problem.
Marco:
The biggest problem being usually that people who sign in and out of different Apple IDs, what is the app supposed to do about that?
Marco:
I don't think that's the kind of thing...
Marco:
that could necessarily be fixed with a revision to the API or a new server-side backend.
Marco:
Because it's like... Remember a year ago, there was a whole debate about the guy whose iPhone alarm went off in the symphony, and it was this whole thing.
Marco:
Well, what should the behavior of the alarm be with overriding the sound switch?
Marco:
And I wrote a big thing back then about it, and my theory was...
Marco:
this is a hard problem because you've told the phone, wake me up at this time no matter what.
Marco:
And you've also told the phone, don't make noise right now.
Marco:
And so you've given it these conflicting directives.
Marco:
That was the problem with HAL 9000 too.
Marco:
See, you've given it these conflicting directives and no matter what choice you make, it's going to anger some portion of the user base that's non-trivial.
Marco:
And so that's kind of a problem with the user at that point.
Marco:
Well, with this, with iCloud syncing,
Marco:
You've made this system where your data is tied to whatever Apple ID is signed in in all your apps.
Marco:
Your data is just tied to that.
Marco:
But a lot of people have different Apple IDs.
Marco:
A couple will share one Apple ID so they don't have to pay for apps twice to be on both of their phones.
Marco:
Some people will have a different Apple ID for being a developer versus being a consumer.
Marco:
There's lots of reasons why people will have different Apple IDs and
Marco:
And Apple does not make it easy to merge them or switch them or anything like that.
Marco:
So it's a very common thing.
Marco:
And, you know, if your app has its own sync platform, then it has some kind of concept of being logged in to that.
Marco:
And so if you change your Apple ID system-wide to go use a certain app or to do a certain thing, and then you launch, you know, my note-taking app, you know, whatever, HD Cloud Plus, then...
Marco:
then I don't lose that sync association from your Apple ID because I'm using my own custom sync thing that you've logged into.
Marco:
And if you actually go into my app and want to sync with a different thing, you have to go into my app and log out explicitly of that account.
Marco:
And presumably that stuff is all stored server-side.
Marco:
And then you can log in to something else.
Marco:
It's a deliberate user action.
Marco:
Whereas if you're using iCloud syncing...
Marco:
Users might not realize, in fact, they probably almost never do realize, that if they log out system-wide of iCloud, then the data in app XYZ is going to be blown away.
John:
And the worst part is that that data may be blown away, and that data may never have made it to any other devices.
John:
It may never have been synchronized, so it's actually gone.
John:
I don't know that the app has any way to tell that.
John:
well that's i mean some of these things you could fix with apis like say say the existing apis were all completely bug free and like and you got these callbacks and you had and you were given an opportunity to add new apis like oh we're about to change your apple id maybe they already have this and you have an opportunity to save this stuff off to the side or whatever you still end up with situations where like what if i do these three changes in this device do these four changes in that device that are conflicting these four changes in that device that are conflicting and they all happen more or less simultaneously and i turn these two on then turn those two off then turn the third one back on like
John:
To try to figure out what the state should allow, modifications to continue, what about when I turn those two back on?
John:
Reconciling these all without a single central source of truth like Gmail, where it's just everyone communicates up to the server and makes modifications there, allowing you to make local modifications and trying to resolve that into a replayable transaction law that results in some sort of consistent thing, you can make something that's like...
John:
provably like you it will it will have a deterministic consistent result but the odds that being result being what the users expected it to be are probably zero because the users will inevitably issue a series of conflicting instructions and when the thing synchronized no matter what the stuff picks
John:
It's sometimes it's not going to be what they wanted, because they gave conflicting instructions, there is actually no right answer.
John:
So that's what I'm saying, like, the model they're using for core data, you know, arbitrary object graph syncing is never even if it's 100% bug free is never going to look to users like the magical, hey, everything just works.
John:
Because they will issue conflicting commands with their actions on their individual devices, and when those devices synchronize, even assuming zero bugs and perfect performance, they're going to be sad that they're going to end up, quote-unquote, losing data.
John:
Even if you were to say, no, let me see, you didn't actually lose data, because here's how we reconcile things, and you can see these series of conflicting commands can only lead to one thing, and you can't have this and that, and you're like, well, but I wanted the other thing.
John:
Actually, what I really wanted was a merge of those two, but with me manually picking...
John:
It can't know that, you know, so that's that's never going to make people happy.
John:
And like, I'm not sure what the solution there is, except for maybe having I mean, you can't do what Google does.
John:
You can't have every single change to your application sending commands up to a server.
John:
you know i mean google has offline mode of gmail too but i think a like they the reason i work with gmail i think is because they have a defined data model that is not as complicated and you know it's like it's an email application but with messages and labels and stuff it's not arbitrarily structured uh interrelated uh data objects and objective c that you get to write yourself you know
Marco:
And this is a good segue to the Brent Simmons response article.
Marco:
Did you read this yet?
Marco:
It's called, Why Developers Shouldn't Use iCloud Sync Even If It Worked.
Marco:
I retweeted it.
Casey:
Oh.
Casey:
Yeah, I read it as well.
Casey:
And I was going to bring this up as well because – and forgive me for kind of interrupting your tangent.
Casey:
But one of the things that I find very interesting about iCloud is that Aaron and I share the same Apple Store ID so we can share the same apps and so on and so forth.
Casey:
We have different iCloud IDs.
Casey:
Yeah.
Casey:
And thus, if we had, say, a shared grocery list, we can't share a grocery list if that app is using iCloud in the background.
Casey:
And Brent talks a lot about this.
Casey:
iCloud is very personal and not very social.
Casey:
And I hate social because that's about as...
Casey:
as big a buzzword as brand.
Casey:
But nonetheless, I feel like there's some amount of truth to that.
Casey:
And Brent brings this up, and I presume, Marco, you're about to recap some of the other things he said.
Marco:
I quoted two things.
Marco:
That's one of them.
Casey:
Yeah, I mean, it's exactly true.
Casey:
And if I were to write, I've thought about writing a very, very simple shared list keeping app so that Aaron and I can share a grocery list or a packing list or a Home Depot or Lowe's list.
Casey:
But I can't use iCloud for that because we can't share it because we're on different iCloud IDs.
Casey:
What do you use?
John:
Do you use Google Docs for that?
Casey:
No, actually, we use Wunderlist, which I'm not a tremendous fan of, but it does the job.
John:
A lot of people I know use Google Docs for that, and we use Google Calendar to share our calendars.
Casey:
Oh, we do use Google Calendar to share calendars.
John:
And one of the reasons we do that is because –
John:
I don't think it's been thought of at this kind of deep level, but the reality is that we never worry about Google Documents staying in sync.
John:
We never worry about Google Calendar staying in sync with our various devices because we always know when we're making changes, we are directly manipulating the state of something on a server somewhere, and it's always in sync.
John:
It's never –
John:
It's never not in sync because it's not like we don't use any offline modes, right?
John:
The downside, of course, is that we can't actually make modifications to our calendar if we're offline.
John:
But thus far, that has not come up.
Marco:
It usually doesn't.
John:
That scenario is going to be less and less likely.
John:
So that conceptual simplicity of how does document sharing with a Google document work?
John:
Live in real time, always synchronized.
John:
That's how it works.
John:
And you just don't think about it.
John:
That model, it's very difficult to do well and bug-free and fast and all that stuff.
John:
But conceptually, it's understandable to people, and they come to trust it.
John:
Whereas no one, not even developers of the applications, can have any idea how things are working, even with zero bugs.
John:
There's a couple of things I've read about bugs.
John:
iCloud core data stuff, some of it unpublished as yet.
John:
Hopefully, it will be published at some point in the future somewhere.
John:
The worst part of any of these type of things is when you add on top of all the stuff we talked about the type of bugs where there's nothing you can do to help your user.
John:
There's nothing like Apple can do to help your user.
John:
Just like things get wedged in a way that even a developer can't be expected to figure out on their own, let alone an individual user.
John:
And that's what they were talking about in the Verge article is like a support time suck.
John:
Because sometimes things just get wedged and don't work.
John:
And there's no visibility of that.
John:
There's not even visibility to the developer unless you can let the developer SSH into your machine and start digging through supposedly hidden directories containing big binary blobs.
John:
and daemon processes that are hung that are not putting the binary blobs in the right place and just like it's the worst nightmare of trying to debug at least when you're debugging server-side stuff at least you have access to the server and you can see what's going on there this is like the worst of all possible words it's like every single person literally does have their own little server on their local machine their own little data store on their machine and you can't see any of that and it's talking to apple servers that you also can't see all of which have bugs none of which code you wrote and you don't even have the source code for it and good luck debugging that
Casey:
So, Marco, I'm sorry I interrupted you.
Casey:
You were going to bring up the social aspect, and you said you were going to bring up something else.
Marco:
Yeah, and the other thing is that Brent says, keep in mind that iCloud is Apple only.
Marco:
He says, you may think you'll never want an Android or browser-based version of your app, but are you sure?
Marco:
Really, really sure?
John:
Yeah, Marco, are you sure?
Marco:
Sounds familiar.
Marco:
Well, yeah, and I'm pretty sure about Android.
Marco:
But no, I think...
Marco:
This is a very good point that if you're in the iCloud platform business, if your app relies on that, then sure, that's fine if today you only have an iOS platform, but if you really invest heavily in that, you have to be really sure that you're only ever going to have an iOS platform.
Marco:
And
Marco:
I don't think that's a very safe assumption for a lot of things these days.
John:
The best part was when he brought up, what about a Mac app that's not sold through the Mac App Store?
John:
Because you can't use iCloud there either.
John:
Right.
John:
Exactly.
John:
We'd forgotten about that.
John:
We always forget about it.
John:
Remember when it was like, oh, well, they're putting iCloud only in the Mac App Store.
John:
That'll be like, that's to lure you into the Mac App Store.
John:
Now it's like, it's more like another repulsor.
John:
It's the opposite effect.
John:
Yes.
John:
It's not like saying, well, I really don't want to be in the Mac App Store, but only the Mac App Store apps get to use this awesome new iCloud API.
John:
I guess it is kind of true for key value storage and document storage.
John:
It's so incredible.
John:
If you choose iCloud, not only are you just choosing Apple's platform, but you're choosing also their sales channels irrevocably.
Marco:
Yeah, exactly.
Marco:
And so I think – and obviously on iOS, if you're making an iOS app, you're always stuck in there, and that's fine.
Marco:
But I just think it's unwise to limit yourself unnecessarily.
Marco:
It's one thing to say, I'm only going to have an iOS app right now.
Marco:
But it's a whole other thing to say, I will never have anything but an iOS and Mac App Store app.
Marco:
That's a very, very limiting thing.
John:
And Apple can always change this because these are policy decisions.
John:
They could say, hey, guess what?
John:
We have a web API with a JavaScript library.
John:
Now you can use iCloud APIs from your web app that you write yourself.
Marco:
That would change a lot.
Marco:
I mean, if Apple ever opened it up to server side or web side interaction, that would open it up tremendously.
Marco:
But I don't think they ever will.
John:
They don't understand the web.
Marco:
No.
Marco:
Why would we ever do that?
Marco:
That makes no sense.
Marco:
Right.
Marco:
There's no immediately obvious benefit to them to do that, and so I don't think they will.
Marco:
I think that would be a big giveaway.
Marco:
They want to lock iCloud down to their devices and their stores, and part of it's just for control and part of it's so they can make sure that nobody goes crazy and abuses it through their APIs and everything.
Marco:
Yeah.
Marco:
Whatever the reason, I don't think that's ever going to happen.
Marco:
Brent also points out that for most apps' needs for syncing, it really isn't that hard to write your own server and to run your own server, and it really isn't that expensive, and it really isn't that complicated.
Marco:
You can design server-side stuff...
Marco:
To make your life really easy in two key ways.
Marco:
You can make it really cheap to run in scale and low needs.
Marco:
And you can design the app so that if the server is not reachable, the app is still useful.
Marco:
And obviously, depending on what you're doing with the server, how useful it can be will vary.
Marco:
But with Instapaper, it was really easy for me to do this because Instapaper is made to be used offline.
Marco:
So if the server is not reachable, the app thinks it's offline.
Marco:
It still works.
Marco:
It works just fine.
Marco:
You just can't load new stuff into it, but it still works.
Marco:
Everything queues up, and once it gets a connection again, it works.
Marco:
If Instapaper's server goes down for an hour, which is a pretty major downtime for a web thing, I'll hear about it from a few people, but not nearly as many as you would think because everyone else is still just using the app just fine.
John:
There is a big advantage to these type of... What Apple wants to happen with these services does happen a lot.
John:
It's easy for you to talk about it because you have server-side development experience, but what if you're just a client-side guy?
John:
Maybe you just want someone to take care of that other stuff for you.
John:
Those type of APIs allow...
John:
developers who would otherwise not be able to make these type of products to make them or or would otherwise need more people you know some examples might be okay so lauren brichter genius programmer great app designer but he used game setter why because he doesn't want to write that crap and if it works kind of sort of didn't work when he launched his game but you know like if it eventually sort of works he doesn't have to do matchmaking he doesn't have to do accounts and stuff like that he gets to just write the game part you with newsstand uh i mean that's mostly monetary things because you want to get the money and everything it's not like you couldn't have done that but hey uh
John:
You know, you can make an application that does subscriptions, that does something that a native application wouldn't do by using Apple services, right?
John:
And then you went and did the web thing yourself anyway, because of course you can.
John:
But that's just an extension of the app store model where maybe you don't want to run a store.
John:
You don't want to figure out how to sell things to people and give them the downloads and host and do all this stuff.
John:
We'll take over that for you.
John:
And Apple wants to take over all those things and provide these infrastructural services.
John:
And that's all great when the service is...
John:
actually work and are things that people want done and i think icloud is is all those things except for the working part and maybe right up to the part where like if you were designing your own like if you're designing your own service to synchronize your stuff you may design something like key value storage and you might design something like icloud's documents in the clouds and you might design something like uh you know game center or whatever because those are functions you can imagine doing but would you
John:
undertake on your own to say, you know what?
John:
I'm going to provide arbitrary server-side synchronization of core data across multiple devices.
John:
I don't think an individual developer would bite that off.
John:
They would think of something simpler like the Simple Node server-side API.
John:
When third parties who created these services, they've looked more like...
John:
traditional more like modern web services and less like what iCloud core data thing with because they can't do that they can't have little demons running on everyone's machine synchronized they can't they can't make a demon process on ios that does all this stuff like they would be forced to do something that is listening on http endpoint that their applications talk to you know what i mean like they wouldn't be able to do all this crazy stuff that apple did and i think yeah apple just bit off more than it could chew in this case
Marco:
I mean, this is kind of a problem, as we discussed, I think, two episodes ago, or last episode, about iCloud's model to the users, that it is the certain simplification of hiding the file system and doing these things, but it's so limited.
Marco:
I mean, this is kind of like, it sounds like Apple bit off more than they can chew with a lot of parts of iCloud, not just like, oh, it doesn't work reliably, but like, this was a bad idea.
Casey:
Well, I don't know if it was a bad idea, but I just don't know if it's been executed well.
Casey:
And John, when you were talking a minute ago, I feel to some degree you're describing me in that I have iOS experience and I have server-side experience.
Casey:
But the thing is I have server-side experience in Microsoft technologies, which are expensive.
Casey:
And if I was to write, say, a grocery shopping list that I could share between multiple people like Aaron and myself, what are my options?
Casey:
I can't use iCloud because that's tied to a single iCloud ID.
Casey:
So what am I going to do?
Casey:
I could do like Perl and be like John, or I could do PHP and be like Marco.
Casey:
I could do Python and be terrible according to you two.
Casey:
I could do Ruby, which is also probably... Well, you know what I mean.
Marco:
I don't know Python, but if I was going to learn something else for the web backend stuff, I would learn Python.
Casey:
You can email Marco.
Casey:
But the point I'm driving at is, what do I do?
Casey:
And interestingly, and I think Brent talked about this in a different post, maybe I would go to Azure.
Casey:
And that doesn't necessitate using C Sharp.
Casey:
It doesn't necessitate using .NET.
Casey:
But from what I've gathered, having never played with this, Azure is a pretty decent way to get some sort of quick server-side or cloud database without too much effort with an iOS API.
Casey:
And that's just not a place.
Casey:
I don't think that's a position Apple wants themselves to be in.
Casey:
Maybe they don't care.
Casey:
I don't know.
Casey:
But that just doesn't seem right.
John:
You know what you might end up doing?
John:
And I've seen people do.
John:
Like, this is a low-tech solution to, like, client-side people who don't want to write a big server-side service, but they know they need one, and they're like, oh, I just like for the grocery list.
John:
Like, look, it's not rocket science.
Casey:
Oh, don't tell me Dropbox.
John:
Don't tell me Dropbox.
John:
Not Dropbox, but something like, what if I just, like...
John:
shove a JSON file up onto S3 and have the thing pull it down and reconcile it.
John:
Because it's just a grocery list.
John:
How many possible things could go wrong?
John:
Worst case scenario, I get the superset of a bunch of changes and there's some extra items that you don't want.
John:
I can deduplicate.
John:
When you have a confined problem domain, you can get away with just the...
John:
Most ridiculous, simple possible solution.
John:
Like, S3 would be enough.
John:
All I need is something other.
John:
Something not my device, something not that other device, but something in this third place that's always available.
John:
And I don't want to make it always available, and that's annoying, and that's really all I need is just a bucket that's shared that's always available, and I'll do everything else myself in client-side code because I can because it's a grocery list app.
John:
Like, that's what people end up doing.
John:
That's annoying.
John:
They would like to not be able to do that.
John:
If their needs are satisfied by key value storage, you're like, oh...
John:
Well, everyone's got iCloud, and I know everyone's going to have an Apple ID, and I'm storing, like, you know, like Marco's thing, like, your last red position, and, like, it's really easy to reconcile.
John:
And it's not critical.
John:
It's two bits of data.
John:
If I don't have it, I can throw it away, and it's, like, no big deal.
John:
Or, like, worst case, I can just pick the later one, assume that you read from top to bottom.
John:
Like...
John:
not having to do that and saying, I can just use iCloud key value storage.
John:
That just like makes people smile.
John:
Like, Hey, wait, I don't have to do any of that crap.
John:
I just want to store a number somewhere.
John:
And iCloud key value storage can do that for me.
John:
And you know, it's like, it's like P lists where when a Mac OS 10 came out and they had these property lists, people were using them for everything.
John:
But it's like, Oh, well, well, I didn't need to design some stupid, like I'm going to design a C structure.
John:
I'm going to serialize it with an innocent coder.
John:
And it's going to, no, I just need like the store, like lists of values.
John:
Like I'll just use a P list.
John:
And you know,
John:
p-list mania goes a little bit crazy and then you end up like trying to make a p-list into your entire database and that's bad but uh if you give developers a little tiny bit of cool infrastructure that makes them happy but if you keep ramping that up you say you know we're basically going to do everything for you and don't worry it'll work and it doesn't then you know people scale back and say you know what maybe i should go back to uploading json files to s3 because that that at least i i can have some guarantees about it working in a predictable way
Casey:
It's predictable.
Casey:
It's mostly reliable.
Casey:
And to some degree, it's a known quantity.
Casey:
I completely agree with you.
Marco:
Yeah.
Marco:
And again, if you have simple needs, you can write your own sync stuff.
Marco:
And granted, not everyone's going to get their sync stuff correct.
Marco:
But again, if it's a grocery list and you have to sync stuff, what's the worst that can happen?
Marco:
It's not that bad.
John:
And if it's not correct, you can fix it because you have all the source code and you control both ends.
John:
Exactly.
John:
That's the worst part is if it's going wrong and the demons running on your local Mac are wedged and are not synchronizing or notifying your application, it's like you don't control that code.
John:
You're not making it run.
John:
You don't have the source.
John:
You can file bugs into the black hole and just wait patiently for the next major version.
John:
But in the meantime, your customers just want their stuff to sync.
Marco:
And as Brent pointed out, too, and this is such a good article, and it's so short, you should read it before we just quote the whole thing.
Marco:
But doing the server-side stuff has really gotten so easy in the last five years as so many tools have come out to make it really easy, really cheap.
Marco:
You have to write so little custom code these days.
Marco:
There are great frameworks.
Marco:
There are great services.
Marco:
There are...
Marco:
There are companies that will automatically scale up and down everything.
Marco:
Granted, there's a lot of things that are more complex that will require custom work, but for the most part, for simple needs, for most app developers' needs, you don't need anything bigger than a Linode instance or paying by the cycle on something like Heroku or Azure or S3 or EC2 and the things that use EC2.
Marco:
For most developers' needs, one virtual server somewhere will cover it.
Marco:
And you can write something in whatever framework you find that is understandable to you.
Marco:
And as Brent says, I think this is a very good point.
Marco:
I'm just going to read this whole article.
Marco:
As Brent says, if you can learn Coco, you can learn this stuff.
Marco:
Coco is so obtuse in so many ways.
Marco:
To somebody who does iOS programming, web programming will seem easy by comparison.
John:
I would rephrase that part of his article.
John:
It's not so much that it's so much easier than it was before, or at least rephrase your summary of it.
John:
It's that...
John:
It used to be that for a given amount of effort, you could get a certain result.
John:
Now, if you put in that same amount of effort, your result will be so much better.
John:
The base level has risen so much.
John:
It's still going to be complicated.
John:
There's lots of stuff to learn and stuff like that.
John:
But previously, if you put in a week into getting your server-side stuff, you'd end up with something that looks like someone who had been doing server-side development for a week.
John:
But now, you have such an incredible leg up with all of these infrastructure and these frameworks.
John:
If you put in the week, your end result will be
John:
you are standing on the shoulders of giants who've created all this infrastructure for you.
John:
You're not staring at a blinking cursor on a bare, you know, Linux machine and saying, okay, now I guess I start writing a CGI script or something.
John:
Like, I mean, you're, you have such a leg up.
John:
So it is really complicated.
John:
And that's that I think why people stay away.
John:
I mean, when it's like anything else, if you're, you are a service side developer, you take a lot of stuff for granted, but a lot of clients that people are starting from a base of knowledge that doesn't really help them that much.
John:
But yeah,
John:
If they can follow a tutorial to get some sort of Rails thing up, or even like Node and just get some sort of Node instance up and put a little tiny snippet of code to echo some string back, and you can run that instance on a virtual machine that you can scale up.
John:
You are so far ahead of where expert server-side developers were in 1993 with your stupid little one-line Echo Node program, right?
John:
Like the things that thing can do, the scalability performance and reliability of that,
John:
are just worlds beyond expert-level knowledge from two decades ago.
John:
So that's what I think.
Marco:
Even one decade ago.
John:
That's where I think, like, you know, that's what he's getting at.
John:
It's like, even though you don't know anything about this, you will be able to get something up that has good performance, scalability, and reliability, even if you have almost no idea what you're doing, if you just put in a little bit of time.
John:
And that was not true many, many years ago.
John:
And also remains not true if you were on to have 500 million users, which is why Apple is screwed.
John:
But...
John:
You're not going to have 500 million users, and if you do, presumably you can hire some smart people to figure it out for you.
Marco:
Instapaper runs on about 10 servers because it does a lot of stuff for a lot of people, but the magazine runs on the cheapest VPS at Linode.
Marco:
It's $20 a month.
Marco:
The entire service runs on that.
Marco:
my blog, marker.org, it serves, you know, a good number of page hits these days.
Marco:
That runs on the cheapest VPS at Linode.
Marco:
Again, because it's like, the stuff that we can get today is so advanced and everything is so fast.
Marco:
Hardware is so cheap to rent and bandwidth is so cheap.
Marco:
Uh,
Marco:
I've never bought bandwidth separately from any of these things.
Marco:
With Instapaper, all the bandwidth is pooled from all the servers, and I've never exceeded that pool.
Marco:
Whatever each server comes with, it's all pooled together, and I've never needed to buy more than that.
Marco:
That's a pretty bandwidth-intensive app.
Marco:
You can do so much now with so little money
Marco:
And so relatively few servers.
Marco:
And yeah, if you're using one of these crazy hosted things, you don't even have to deal with the individual servers directly.
Marco:
You can just do so much.
Marco:
And the fact is, most iPhone app developers aren't going to need to do some crazy, ridiculous, complex thing during the life of their app.
John:
You should finish quoting, but I assume, going by memory here, was I don't have the article in front of me, the very bottom part about how, or maybe this was in someone else's commentary, Apple's thing about how they want to own and control all the important parts of their business.
John:
Read that part.
John:
Yeah.
Marco:
Well, anyway, I can't find the exact part, but he says, you know, he said, Tim Wood of the Omni Group tweeted the phrase, own the wheel.
Marco:
Here's the thing.
Marco:
This is Brent's words here.
Marco:
Here's the thing.
Marco:
half the mobile revolution is about designing and building apps for smartphones and tablets the other half is about writing the web services that power those apps how comfortable are you with outsourcing half of your app to another company
John:
Yeah, it was Gruber's commentary that I was remembering.
John:
It said, don't take Brent's word for it.
John:
Consider Tim Cook's doctrine.
John:
That's right.
John:
We believe that we need to own and control the primary technologies behind the products we make.
John:
I mean, it's just, you know, if you want to make a great product, you want to have certain things under your control.
John:
Obviously, you don't control everything.
John:
You don't control the App Store.
John:
You don't control Coco.
John:
You don't even have the...
John:
The source code for that in most cases, unless it's like, you know, something that's part of Darwin, like so many things are out of your control.
John:
And this is what's frustrating.
John:
I think, you know, good developers with iCloud is they're there.
John:
They've accepted the things that are outside their control, the platform, the store, the language, the API, the compiler, lots of things are outside their control.
John:
But they always felt like I can wrangle the things that are within my control to make sure my customers have a good experience.
John:
And this iCloud thing is like they're between a rock and a hard place because the customers think they want it and are demanding it.
John:
They want the sync features and they specifically ask for iCloud by name because it has good PR.
John:
Uh,
John:
And they can't make it work.
John:
And that's an uncomfortable situation to be in.
John:
Brent didn't have that problem with Glassboard because they controlled that side of it.
John:
And it was on them to make it work.
John:
And they could make it work because they controlled everything from top to bottom.
John:
They never were going to hit a barrier where they're like, this isn't behaving in a deterministic way.
John:
It's buggy and I can't fix the bugs.
John:
It's a blocker, right?
John:
They never had those blockers.
John:
If it wasn't working right, they would tweak their server-side software.
John:
And if you really want to control your destiny to the extent possible, like Brent's article said, why would you give up control over half of your application?
John:
Giving up control is one thing.
John:
The other thing is not having to worry about those details.
John:
So Loren gave up control of half of his application to Game Center.
John:
If that had not worked out for him...
John:
That would have been very bad.
John:
And actually, he had a lot of problems with that.
John:
I know, but eventually it sorted itself out.
John:
I mean, there were scaling problems because no one used Gabe Center before a letterpress, and it's buggy and weird, right?
John:
But he didn't want to write that stuff himself because that's not what interested him.
Marco:
I think he almost had to.
John:
That's the trade-off he made there.
John:
Maybe he regrets it.
John:
Maybe he went the second time, he would do the server-side part himself, right?
John:
But that uncomfortable situation where you're, you know,
John:
You're giving up control in exchange for, you hope, not having to do that.
John:
And if it comes out well, you're like, hey, look at all that work I saved.
John:
That was really smart.
John:
And, you know, I got featured on the App Store because I'm using Game Center.
John:
And there's other fringe benefits to using, you know, Apple's APIs, right?
John:
If it doesn't work out and you can't ship your application and you're rewriting it for the ninth time, then you're sad.
John:
And you're like, oh, I'm never going to let that happen again.
John:
From now on, I'm writing everything from scratch, like Lauren Brichter, who doesn't use UIKit.
Yeah.
Casey:
So to wrap this up, what's going to happen in June or whenever WWDC is with regard specifically to iCloud?
Casey:
I mean, is they going to have a new API?
Casey:
Are they going to say, oh, man, everything is finally fixed?
Casey:
And if so, is it going to be real or is it going to be a bunch of baloney?
Casey:
I mean, what do you guys think?
John:
WWDC is all about the new file system, Casey.
John:
Yeah.
John:
And don't forget the iWatch and the smart TV.
Casey:
No, no, no.
Casey:
John Syracuse will be so happy.
Casey:
Yeah.
Casey:
No, but seriously, I mean, do you guys think that they're going to make a big push for iCloud?
Casey:
Are they going to be repentant for it?
Casey:
Are they going to say, oh, no, really, for sure?
Casey:
I promise this time it's fixed.
John:
I don't know if they have enough time has elapsed for them to be able to... They know they need to do something.
John:
I don't know if enough time has passed for them to have actually done it.
John:
I don't know if they can come to WODC and say, here is the thing, and we have a solution.
John:
Is the solution fixing it?
John:
Is the solution scrapping and replacing it?
John:
Is the solution something in between?
John:
I don't think that enough time has passed for that to happen.
John:
All I think they can do when they show up there is hopefully...
John:
engage the developers, acknowledge the issues, and have something for them that improves their lives in some way, while also acknowledging that, like, because I don't think they're going to come out.
John:
It's not like a FileVault 2 thing.
John:
We're going to say, FileVault 1, forget that existed.
John:
There's another thing.
John:
It's awesome.
John:
It works great.
John:
You will forget FileVault 1 ever existed.
John:
And people go, oh, wow, that is awesome.
John:
All right.
John:
And then they just forget.
John:
You know, I don't think there's been enough time has passed for that, because...
John:
Maybe I'm pessimistic, but what was in the Verge story?
John:
I think they said they had four people working on the iCloud stuff or whatever.
John:
Apple has smaller teams than anyone thinks they have.
John:
I know how much work a handful of developers can get done in a year's time.
John:
I'm not optimistic about them coming down from the mountain with new stone tablets and saying, we have solved your problems.
John:
Not because they don't want to or are negligent, but just because not enough time has passed.
Marco:
I don't think that... My theory that I said earlier about iCloud is that I think there's problems in both the API implementations and problems with just the user conceptual model of iCloud and of where your data is and your apps, how it's tied to the Apple ID that's signed into the device.
Marco:
I think there are such conceptual problems there
Marco:
that I'm not expecting iCloud as it is named today to ever be fixed.
Marco:
I'm expecting it to happen more like MobileMe, which is like some next generation thing will come out in a few years to replace or upgrade iCloud.
Marco:
And it will work differently for the users, not just the developers.
Marco:
I think it'll have to be conceptually different for the user.
Marco:
But won't they keep the name, though?
John:
I don't think they'll do the name change.
Marco:
That's why I was talking about file vault.
John:
I think they will... Because it already is an umbrella term, and there are parts of iCloud that work okay.
John:
You don't have to scrap key value storage.
John:
You just don't.
John:
It's fine.
John:
It's all under the umbrella of iCloud.
John:
So when you say that iCloud is conceptually... There is no such thing as iCloud.
John:
Like...
John:
iCloud core data stuff is conceptually bankrupt and needs to perhaps be replaced or modified.
John:
And iCloud's conception of, hey, when you sign out, we dump all your data that was linked to it, like that whole connection between your Apple ID, your iCloud thing, and the data and applications, like that can be revised.
John:
And all that I think can happen over the course of several years without ever having to have a mobile meet iCloud type transition.
John:
I think they can keep the name because it is an umbrella term that really has no relation to
John:
Why is key value storage and documents in the cloud all under the umbrella of iCloud?
John:
No reason.
John:
They don't share the same servers.
John:
The backends might be written by entirely different teams, entirely different code.
John:
The front-end APIs, also entirely different teams.
John:
They could be entirely different languages for all we knew.
John:
They're all Objective-C, but one could be core foundation.
John:
They're as unrelated as anything else, except for the fact that they're both network services and marketing decided they're going to be under the umbrella of iCloud.
John:
So I think Apple has plenty of runway and room to totally change everything about iCloud while still calling it iCloud and just making it look like, oh, we're making it better.
Marco:
Yeah, but I think, though, they're going to have to do something that's changing the whole portion of iCloud that is app storage, like app storing their own data and having that sync somehow.
Marco:
They'll fix that when they do multiple users in iOS.
Marco:
Yeah, right.
Marco:
I just think that whole concept, as we talked about in another episode about the file storage thing not necessarily making a lot of sense or being too simple and not really addressing the problem domain well enough, I think the entire iCloud data model for apps...
Marco:
has that problem.
Marco:
The entire iCloud data model is too simple, too limited, doesn't really address the real-life problems and usage well enough for a lot of apps.
Marco:
And I think we're not going to see that get fixed with the product that we currently know today as iCloud or the section of it.
Marco:
What we will probably instead see is people will start following Brent's instructions of, we'll just see fewer and fewer apps relying on iCloud, especially from big developers who know better and have the resources to not use it.
Casey:
I tend to agree.
Casey:
And I feel like, just like the both of you said, key value storage, I think that'll carry on.
Casey:
I think documents in iCloud will probably carry on.
Casey:
I feel like core data sync in iCloud will go the way of garbage collection.
Casey:
And no matter how you look at it, the forecast for iCloud, it's cloudy.
Marco:
Oh, my God.
Marco:
We have to end the show now.
Casey:
I did that just for you guys.
Marco:
We are not allowed to keep talking after that.
Casey:
I knew that was terrible, but I knew that would shut you up.
Marco:
I was going to make an I-son pun before, but I restrained myself.
Casey:
See, that's because you're a professional.
Marco:
Yeah.
Marco:
We'll end with this awesome song by Jonathan Mann.
Casey:
How awesome was that?
Casey:
That was seriously fantastic.
Thank you.
Marco:
Now the show is over.
Marco:
They didn't even mean to begin.
Marco:
Cause it was accidental.
Marco:
Oh, it was accidental.
Marco:
John didn't do any research.
Marco:
Marco and Casey wouldn't let him.
Marco:
Cause it was accidental.
Marco:
And you can find the show notes at atp.fm.
Marco:
And if you're into Twitter...
Marco:
At C-A-S-E-Y-L-I-S-S So that's K-C-L-L-S-M-A-R-C-O-A-R-M-E-N-T-M-A-R-C-O-R-M-E-N-T-M-A-R-C-O-R-M-E-N-T-M-A-R-C-O-R-M-E-N-T-M-A-R-C-O-R-M-E-N-T-M-A-R-C-O-R-M-E-N-T-M-A-R-C-O-R-M-E-N-T-M-A-R-C-O-R-M-E-N-T-M-A-R-M-E-N-T-M-A-R-C-O-R-M-E-N
John:
Did you see his follow-up song?
John:
I like his second version even better.
Marco:
He made a second version?
Marco:
Yes.
John:
I said the song he made was nice, but it didn't seem right for the show.
John:
And he said, well, what would sound right for the show?
John:
I said, I don't know, bleeps and boops or something?
John:
And so he made one with bleeps and boops, which is also awesome.
Oh.
Marco:
The accidental tech podcast is done for the day.
Casey:
That's awesome.
Casey:
You'll have to send that around, because I did not see that.
Casey:
I had no idea.
Marco:
Well, I will have to paste one of them in, and we'll give him a good link in the show notes.
Marco:
And thanks to Jonathan Mann, the Song of Day guy on YouTube, for doing this.
Marco:
That's so awesome.
Casey:
I lost my junk when I saw that in the sense that I cannot believe that.
Casey:
In the good way, in the good way.
Casey:
In that I can't believe that somebody on the internet would care enough about us idiots, particularly me, to include me slash us in a song.
Casey:
I was beside myself excited.
John:
Repeat after me, Casey.
John:
I'm good enough.
John:
I'm smart enough.
John:
And gosh darn it, people like me.
John:
People like me.
Casey:
People aren't sick of us yet anyway, but eventually people will be sick of us.
John:
Then we'll have to do something.
Casey:
It'll take at least 100 episodes, don't you worry.
Casey:
Nobody's going to be sick of us.
John:
No one isn't already sick of us.
John:
I always wonder if, like, if, you know, so Marco and I, we had our podcast, right?
John:
Are we getting the union of the people, or are we getting the intersection for the people who can tolerate me and can tolerate Marco?
John:
You know what I mean?
John:
Like, are we, is the sum of our parts less than, you know?
Casey:
You know, I think you guys are confused.
Casey:
Really, I'm the big draw, and you two are just riding on my coattails.
John:
yeah yep that's it what your job is is to make all the people who hate both me and marco have someone likable to latch on to on the show because there are those people and you know so once you start once casey starts getting haters of his own then we'll then we'll have a problem it's only a matter of time and you can't do a podcast for for that long and not get he's very likable he's very likable that's true yeah he's not he's not obnoxious like we are so are you sure
Casey:
Have we met?
Casey:
Well, did you see somebody, was it earlier today, tweeted about how ugly we all are?
John:
Yeah, that was great.
John:
What am I going to argue?