Monday mornings at work there is a buzz about the weekend, especially the outcome of sporting events. Someone is usually strutting around on a high because their team won, or ribbing someone because their team lost. This social interaction is what PlayUp have captured in their flag ship application PlayUp Live, along with live scores, fixtures and more. You should click this link now and check it out.
The journey over the last six months to get the iOS version out (support for other mobile platforms is coming) has been quite a challenge and this post is about those challenges and key take-outs you wont want to miss if you are developing an iOS app that connects to a back end. PlayUp is really exciting and it will grow to be as big as a Twitter or a Facebook, so Im expecting a few more challenges and growing pains and it will be worth it. While this isn’t a job advertisement feel free to contact me if you think this sort of challenge is for you (james dot ladd at iplayup.com).
These are my personal top #5 take-outs from working on the project
#1 Small Team
The number one #1 learning from working on the project is to keep the team small, with two people on the UI and two people the backend integration with the server. The server side is not factored into this count as this is quite variable, however the typical code base size for an iPhone app suggests 4 - 6 developers maximum.
#2 Shared Vision
The team should share a consistent vision of the product they are building. Multiple competing visions or changes in the vision can derail the project significantly. There is a reasonably common held belief that a key person leaving a project can kill it, and this is even more so if that person is the vision holder. A vision holder who is strongly focused and driven to reach that vision with good communication skills is a must.
#3 One Application
The back end of an iPhone application is as important as the front-end, and involving both teams in understanding the requirements of the other is essential. Both parts are crucial to the overall success of the product and directly effect the schedule and outcomes. A shared design and understanding of the architecture is key.
#4 Fast Feedback
The cycle time on building a feature and showing the relevant stakeholders effects the schedule and this loop should be as small as humanly possible. Getting the app onto the stakeholders device is nice and in some cases essential but it takes longer. Getting the stakeholders to be ok with a ‘first-draft’ that isn’t pixel perfect is another way to reduce cycle time to get feedback quickly, so is not writing tests for this ‘first-draft’. However, there are some cases where writing tests in the ‘first-draft’ will allow you to make changes faster later on. You know your app and will have to decide on your own balance.
Depending on your application you may need to use off the shelf libraries, and these libraries need to be thoroughly evaluated. Take the time to do this because in the heat of battle is probably not the best time to find out it was not the most robust choice.