Eight guys, four weeks, one dream
A software coop
At our local Cocoaheads chapter, we started dreaming in December… What if we pooled our resources and multiple talents to create a software “co-op”? Shared resources, low buy-in, extra exposure and marketing…
Over the holidays, Cocoaminded was born. We have a domain, so we must exist, right?
Early January, Mark had an idea. What if we all worked together on a small iPhone app to promote our other apps, and learn something in the process?
Introducing Tweety10
Mark’s idea was to expand on his HockeyTweet to create an Olympic-themed Twitter client. It would have a live newsfeed (from Twitter, of course!), medal count and schedule. It would use web services to serve the data
And just like that, we decided to start what became Tweety10.
The first 80%
We all got together on Sunday, January 10th at The Code Factory and brought our laptops. Mark even brought his 24″ display. At 9:30, we had a kickoff meeting where we decided that at 5:00, no matter what, we would all go home. And we would decide if the app was in a good enough shape to continue working on it, with the goal of submitting within two weeks to the App Store.
I was nominated as Project Manager, which means that I was responsible for the big picture, so to speak. Given my past experience, here is what I had planned:
- Each feature of the application, for example the News view, the Medals view, etc… was written on a 3×5 index card. Features would be then assigned, and divided into subfeatures as necessary. For the News view, you had the actual view, the Controller (UITableViewController, in this case) and the model, along with the web service. We wrote those subfeatures on cards
The idea was, whatever was on a card should represent about an hour’s worth of work. If it took more than an hour, you made a new card. When you were done, you asked for a new card. - Version control with Mercurial.
I suggested Mercurial (hg) early on because it is fast, simple and distributed. It also has a fairly quick learning curve, meaning I would not have to spend a lot of time explaining it to everyone.
Mercurial had a couple of small glitches that were due to my unpreparedness, but overall it was very satisfactory. - We would use BitBucket.org to store our common code repository.
BitBucket has a free, private repository (and unlimited public repositories). It was extremely simple to create the private project and add the other seven developers as writers to the project. You can also assign read-only access if you want: it is simple and quick, much like Mercurial itself. - Starting from the skeleton application (a variant of the Tab Bar Application Xcode template), we would add source code and resources as needed, and push to the common repository as often as possible. Continuous integration was the word.
I spent my day making cards, troubleshooting issues, helping out with code problems and generally having a blast integrating all of the code into a build system on my own computer. It was exhilarating to keep feeding six smart people with enough information to keep them busy, while at the same time making sure that they are not stuck on a problem or bored and going off-spec. The index cards were a hit, and BitBucket performed admirably.
At the end of the day, we decided we had an app, and it was worth continuing towards our goal of putting an app in the App Store.
The other 80%
Since we would not work in the same area anymore, I immediately transcribed all the cards on a Wiki page in BitBucket. This allowed us to put our name next to a virtual card and claim it. We could add cards, and mark them as complete when the work was done.
We started using Skype’s Chat feature to create a private chat amongst all of us. The great thing was, you did not have to stay logged-in like you would for IRC. If you disconnected from the chat, as soon as you re-connected Skype updated your chat window and you could see all of the conversation that you had missed. This is a great feature.
Although it was not formal, it was very helpful to meet two to three hours every week for NSCoder Nights. It was a great way to gauge progress and help each other out with all the little things that stop us from time to time.
We finalized our artwork and installed localizations, keeping abreast of changes in localizable files as much as possible (this late, the changes were far between).
Real artists ship… then get rejected
We submitted to the app store a week before the Olympics were due to start, and after three days got rejected because we used the word “Olympics” in our keywords. Oops! I wonder how people who live on the Olympic peninsula feel… We removed the keyword, re-submitted and after another four days of waiting…
Tweety10 is available on the App Store. It’s free, give it a try!
Post-mortem
Having a real, in-person kick-off day for the project helped tremendously. This would not have happened otherwise. Most of our subsequent interactions were online via email, Skype or BitBucket and if we had not smoothed out the communication channels beforehand, the friction would have been too great.
Mercurial is a great version-control system. Once we got past the initial hurdles of merging (hg does not come with a built-in merge tool, you have to set it up) and pushing (Mercurial Keyring Extension is a must).
BitBucket, with its one free private project, was an awesome instrument in communication via code and issues. You get an email when an issue is created or updated, and you can resolve issues by pushing a change containing text like “Fixes #23”.
Finally, I was delighted to see that as a group, we worked really well together. I hope we all gained some valuable knowledge and experience with this project; I certainly did.
This was really a case of the whole being larger than the sum of its parts! I hope you will enjoy the app and the 2010 Winter Olympics in Vancouver, Canada.