Apple's iTunes Remote app was developed by one person - report
Apple's iTunes Remote application for the iPhone has not been updated in over 8 months because the software was written by just one person, and he is currently busy with other projects, according to a new report which describes Apple as "a huge startup."
Sachin Agarwal, co-founder and CEO of Posterous, wrote on his blog this week that he believe's a great deal of Apple's success comes from the fact that the company puts together small teams of highly qualified people to work on projects. He said he knows the Apple Remote application, available for free on the App Store, is made by one person because the single developer is a good friend of his.
"Apple doesn't build large teams to work on every product they make," he wrote. "Instead, they hire very few, but very intelligent people who can work on different projects and move around as needed."
He continued: "One day you might be working on the Remote app, and the next day you might get pulled on to another project that needs your help."
The Apple Remote (iTunes link) was last updated in November of 2009, to fix bugs associated with Apple TV 3.0 and iTunes 9. It has not been given support for iOS 4, including multitasking, or the retina display of the iPhone 4.
Agarwal said that engineers who work on Mac OS X and iOS often switch back and forth between the two projects to help something get pushed out the door in time for its scheduled release. And employees on the Final Cut Pro team often help out with other pro applications.
"Great startups have small teams that can build quickly and pivot when needed," he said. "When working at a startup, you don't own just one part of the application: you have to be able to work on whatever needs your attention that day."
Apple's startup mentality, even though it is one of the largest companies in the U.S., is no secret. Chief Executive Steve Jobs even referred to his company as the "biggest startup on the planet" in an interview in June.
A few former Apple employees recently offered a peek inside the company's corporate culture revealing that, like most companies, Apple has its share of red tape that can frustrate employees. But the issues go away and projects take on a "startup level urgency" when something is given the attention of Jobs.
Sachin Agarwal, co-founder and CEO of Posterous, wrote on his blog this week that he believe's a great deal of Apple's success comes from the fact that the company puts together small teams of highly qualified people to work on projects. He said he knows the Apple Remote application, available for free on the App Store, is made by one person because the single developer is a good friend of his.
"Apple doesn't build large teams to work on every product they make," he wrote. "Instead, they hire very few, but very intelligent people who can work on different projects and move around as needed."
He continued: "One day you might be working on the Remote app, and the next day you might get pulled on to another project that needs your help."
The Apple Remote (iTunes link) was last updated in November of 2009, to fix bugs associated with Apple TV 3.0 and iTunes 9. It has not been given support for iOS 4, including multitasking, or the retina display of the iPhone 4.
Agarwal said that engineers who work on Mac OS X and iOS often switch back and forth between the two projects to help something get pushed out the door in time for its scheduled release. And employees on the Final Cut Pro team often help out with other pro applications.
"Great startups have small teams that can build quickly and pivot when needed," he said. "When working at a startup, you don't own just one part of the application: you have to be able to work on whatever needs your attention that day."
Apple's startup mentality, even though it is one of the largest companies in the U.S., is no secret. Chief Executive Steve Jobs even referred to his company as the "biggest startup on the planet" in an interview in June.
A few former Apple employees recently offered a peek inside the company's corporate culture revealing that, like most companies, Apple has its share of red tape that can frustrate employees. But the issues go away and projects take on a "startup level urgency" when something is given the attention of Jobs.
Comments
But if people pivot around so easily, couldn't they get someone other than the app's creator to tweak it for iOS4? Not supposed to be that hard...
Just sayin'...
I hope this 'one' developer is working on 'the next big thing' as a direct replacement/upgrade to Apple Remote. There are many users out here, like me, that would hate to see this application languish.
First they tried a big team with huge budget and it failed, and a manager got the boot. Then a new manager tried to outsource it and it failed again, and he got transferred off to another department and never seen again. Then finally they tried the "small elite group" (5 guys!) approach and it worked.
I think the first two approaches *could* have worked if the problem was well understood, or had been done before. But when it's something no one *quite* knows what they want, or where to go, the third approach is best. Apple probably mostly does that kind of project.
Small teams always work best though. Even on big projects you would split stuff up so people can take ownership of a section.
Doesn't explain it not being updated though. Did he loose the code or is it just so bad nobody else understands it?
What, exactly, would you do with multitasking support in an App such as Remote?
What functional benefit would actually come from upgrading it to make full use of retina display?
Maybe other improvements could be proposed for the Remote App: A previous poster's idea of being able to link it into lyrics, bios, and other background information sounds compelling.
But multitasking...
Of all the things that could be done with the Remote App, why does this article call out multitasking and retina display?
What, exactly, would you do with multitasking support in an App such as Remote?
What functional benefit would actually come from upgrading it to make full use of retina display?
Maybe other improvements could be proposed for the Remote App: A previous poster's idea of being able to link it into lyrics, bios, and other background information sounds compelling.
But multitasking...
I think the author's point is not that these two updates are so critical to this particular app, but that most other apps are being updated in this fashion and the fact that it hasn't happened for Remote is indicative that it has been put on the back burner for at least the time being.
for something like SQL server MS has a core design team that codes the new version. these are the most talented guys and with more experience. they code the new features. after release the code goes to the Tier 2 team that finds and fixes the bugs as customers report them. the core people are designing the next product. after a few years people who work in Tier 2 move to the core design team if they are accepted.
this way existing products get timely updates and you can hire new programmers to train them
i think Apple did something like this for iPhone 4. it was in development before the 3GS came out and the same team is probably working on the next redesign while the lower level people will design the next one or two versions with small changes
These three updates would just update the app for iOS4, so, I agree with the author.
Of all the things that could be done with the Remote App, why does this article call out multitasking and retina display?
What, exactly, would you do with multitasking support in an App such as Remote?
What functional benefit would actually come from upgrading it to make full use of retina display?
Maybe other improvements could be proposed for the Remote App: A previous poster's idea of being able to link it into lyrics, bios, and other background information sounds compelling.
But multitasking...
Multitasking would be sweet. Everytime you start the app it needs to establish a connection to your iTunes from scratch. If it could just refresh that connection it would be much more responsive.
That could come in really handy when I'm sitting out on the patio and some NWA comes on while I'm grilling out with my parents over or something...
Thank You Writer of Remote App, Thank You
Will spare all of you the sordid details, but let's just say this ...
As a Mobile Disc Jockey - with Remote, a Wireless Mic, iPhone, and a little WiFi ?
Now am SERIOUSLY "Mobile" (well, least for a few 100 feet, not bad)
.
This App is THE best thing that's happened for me and My Show/Shtick since SoundJam and mp3's on that old Wall Street PowerBook.
My deepest Regards and Appreciation
Thank You Again Apple Remote App Writer(s)
.
Oh, and should that be "whomever" ? ....
.
they should have a two tier design philosophy that Microsoft uses for their successful products other than OS's. the Vista/7 design team was something like 15000 people which is why the end product was the way it was.
for something like SQL server MS has a core design team that codes the new version. these are the most talented guys and with more experience. they code the new features. after release the code goes to the Tier 2 team that finds and fixes the bugs as customers report them. the core people are designing the next product. after a few years people who work in Tier 2 move to the core design team if they are accepted.
this way existing products get timely updates and you can hire new programmers to train them
i think Apple did something like this for iPhone 4. it was in development before the 3GS came out and the same team is probably working on the next redesign while the lower level people will design the next one or two versions with small changes
Yes, thats the way most large companies work, unfortunately, when things get passed off to the Tier 2 (or test team) they can muck things up because they cannot possible know everything the Teir 1 team intended.
This is one of many reasons items like Vista was probably muck up a bit.
Although the teir 1 team would hate it, they need to stay on for testing through production asm much as possible.
However, I think Apple knows that the teir 1 team can only 'innovate' so much, thats why they look for new/fresh engineering talent/leaders (not usually done in alot of industries, eg aerospace) and new aquisitions(key here is how do they integrate them). Small companies keep having break throughs where microsoft etc have more trouble doing so.
I worked at a company (not Apple) where they had a very difficult software project.
First they tried a big team with huge budget and it failed, and a manager got the boot. Then a new manager tried to outsource it and it failed again, and he got transferred off to another department and never seen again. Then finally they tried the "small elite group" (5 guys!) approach and it worked....
...Small teams always work best though. Even on big projects you would split stuff up so people can take ownership of a section...
For me, the best part of getting insight into the workings of a company like Apple is the insight into what they do to succeed. If small (nimble) teams lead to such successes on a short time table, then glad to know it so I can do my best (and inherently more feeble) attempt to replicate the approach.
No surprise here. Apple is very understaffed for the size of the company. They have always expanded heir headcount very carefully.
they should have a two tier design philosophy that Microsoft uses for their successful products other than OS's. the Vista/7 design team was something like 15000 people which is why the end product was the way it was...
There are lots of studies and theories on the "optimal team size".
One of the most concise is the "2PT" theory-- a team where the team size is no larger than 2 pizzas can feed.
http://www.shmula.com/155/software-d...e-and-dynamics
Another, more scientific explanation:
Intra-project communication becomes more and more challenging with increasing team sizes. When team size increase so does the number of different communication channels. Every team member can communicate with every other team member. Mathematically it looks like this:
c = n(n-1)/2
c = communication channels
n = team size
http://intellijens.se/2006/08/what-i...team-size.html
You can see that the communication channels (and interaction difficulty) increase dramatically as members are added to the team.
Many people consider 5-7 to be the optimal team size:
http://www.infoq.com/news/2009/04/ag...imal-team-size
Anecdotaly, I've been on, and led various-size teams in business (Bell & Howell, Lockheed, IBM, Apple, my own company).
The best teams were the ones where you could walk up to another team member and say something like:
"Bob, I am gonna' need to change the...". Before you can finish your sentence/thought, the other person says: "yeah, yesterday, I fixed it so you could..."
The worst teams were the ones where the team leader says something like:
"We're gonna' have a meeting to discuss the status of the project. Before we do, we should get together as a sub-group in a pre-meeting, meeting and decide..."
Those words: "pre-meeting, meeting" indicate that the project is on life-support!
For me, 5 is the optimal team size. You "know" what everyone else is doing and their progress towards completion-- very little time is spent (wasted) in status meetings. If part of the project lags, the others, naturally, assume whatever duties/tasks, necessary, to bring it back on schedule.
For other insights relating to inspiration and completing projects (or not), I suggest the following (all good reads):
The Mythical Man-Month
The Soul of a New Machine
Parkinson's Law
Acres of Diamonds
.
There are lots of studies and theories on the "optimal team size".
Great post and thanks for the additional reading suggestions too.
There are lots of studies and theories on the "optimal team size".
One of the most concise is the "2PT" theory-- a team where the team size is no larger than 2 pizzas can feed.
http://www.shmula.com/155/software-d...e-and-dynamics
Another, more scientific explanation:
Intra-project communication becomes more and more challenging with increasing team sizes. When team size increase so does the number of different communication channels. Every team member can communicate with every other team member. Mathematically it looks like this:
c = n(n-1)/2
c = communication channels
n = team size
http://intellijens.se/2006/08/what-i...team-size.html
You can see that the communication channels (and interaction difficulty) increase dramatically as members are added to the team.
Many people consider 5-7 to be the optimal team size:
http://www.infoq.com/news/2009/04/ag...imal-team-size
Anecdotaly, I've been on, and led various-size teams in business (Bell & Howell, Lockheed, IBM, Apple, my own company).
The best teams were the ones where you could walk up to another team member and say something like:
"Bob, I am gonna' need to change the...". Before you can finish your sentence/thought, the other person says: "yeah, yesterday, I fixed it so you could..."
The worst teams were the ones where the team leader says something like:
"We're gonna' have a meeting to discuss the status of the project. Before we do, we should get together as a sub-group in a pre-meeting, meeting and decide..."
Those words: "pre-meeting, meeting" indicate that the project is on life-support!
For me, 5 is the optimal team size. You "know" what everyone else is doing and their progress towards completion-- very little time is spent (wasted) in status meetings. If part of the project lags, the others, naturally, assume whatever duties/tasks, necessary, to bring it back on schedule.
For other insights relating to inspiration and completing projects (or not), I suggest the following (all good reads):
The Mythical Man-Month
The Soul of a New Machine
Parkinson's Law
Acres of Diamonds
.
after Vista came out i read a blog posting from one of the devs. he coded the start menu or whatever the new name is called. he said that from the time he submitted a version of his code to the time it made it to a real test build was around 6 weeks. during that time it went up to higher and higher levels of test builds to be tested for compatibility with other code
the 2PT theory is probably right. anything larger you get bogged down answering countless email turf battles, conference calls, etc.