Intro
What with Easter and a certain wedding here in the UK we’ve had a lot of Bank Holidays lately, so I had the opportunity to escape to my parents’ home in the Gloucestershire countryside for about 10 days. I decided I wanted to make the most of the time to develop an iPhone app that I’ve been thinking about recently. Last night at 11pm I submitted a binary of that app to Apple for approval – it’s called “PrayerMate” and it’s designed to help you organise your prayer life. In this post I want to write up some of my experiences and what I’ve learnt from it all.
Before I go any further, I should explain that I have a very poor track record of actually shipping anything. It’s taken me many years to catch on to the huge chasm that exists between “knowing Objective-C” and “raking in the profits from a successful app that is actually available for purchase on the app store and that people enjoy using and want to recommend to their friends”. You’d have thought it would be obvious that those two things are not the same, and yet I think a lot of us probably fall into the trap of thinking that “I theoretically know what would be involved in making something” is conceptually identical to having actually gone ahead and done it.
Recognising this about myself up front, I realised I was going to have to take special measures to make sure that this didn’t end up as yet another half-baked piece of code festering on my hard drive because finishing it off proved too much like hard work. Which leads to my first point: planning
The Planning Stage
Long before the holiday began I tried to plan out what I would and wouldn’t do during those 10 days. The product I had in mind was really well suited to a short development sprint, since the Minimum Viable Product was extremely simple, yet the scope for adding extra features over the long haul is vast. I made myself a list of all of the features I could think of, and was absolutely ruthless about what would make the cut for version 1.0. And I mean ruthless – initially I hadn’t even planned to allow people to delete prayer points once they’d added them to the database. This paid off in spades later in the development process, when it quickly became apparent that even the simplest feature has acres of hidden complexity lurking beneath the surface. Admittedly I ended up adding one or two of those features that I initially rejected later on, once I felt confident that they wouldn’t make shipwreck of the whole enterprise, and that whilst perhaps not essential they were nonetheless pretty important.
Having made my list of features, it broke down nicely into about four key areas, so I made myself a schedule for how I would use the 10 days. It worked out like so:
| Thursday 21st (travelling): | UI Design |
| Friday 22nd (Good Friday): | Basic navigation |
| Saturday 23rd: | Manage categories |
| Sunday 24th (Easter): | DAY OFF |
| Monday 25th: | Manage subjects |
| Tuesday 26th: | Prayer mode |
| Wednesday 27th: | In-app payment upgrade |
| Thursday 28th: | Testing, bug-fixing |
| Friday 29th (Royal Wedding): | Icon design, screenshots, writing blurb |
I made sure I knew which days were going to be taken up with other stuff like Royal Wedding celebrations and so on, and deliberately scheduled a lighter workload for them. You’ll also notice I planned to have a full day off on Easter Sunday, the benefits of which I’ll talk about later on.
With hindsight, making this schedule was probably one of the most important factors in my success. I’ve spoken previously of the crippling effect of uncertainty in my life, and having this schedule meant that I always knew what I was supposed to be working on at any given point in time. It helped that it was more or less realistic – the first few days I finished nice and early and was then able to take the evening off to spend time with my parents, and one or two days I was still coding away at 10:30pm trying to get something finished when I’d much rather have been heading to bed – but by and large I was able to stick to that schedule right until the end, and it was a huge help.
Clearing the Stones
I deliberately didn’t start on the project in earnest before heading to my parents’, but for the week or so leading up to it I did try to clear the ground a bit so that I could get off to a running start. I knew that I wanted to base the project off one of the samples that Apple provides, so I made sure that was compiling and running properly on my iPod Touch. Perhaps that all sounds a bit meaningless and insignificant, but it had been a significant mental barrier to my starting earlier – I’d formerly tried to get that particular sample running and had broken it with some changes I’d made and didn’t really understand why it wasn’t working properly. I wan’t to make sure my first day of my sprint wasn’t going to be wasted faffing about stuff that I didn’t really care about.
Designing the User Interface
Again, because of the crippling effect of uncertainty, I knew that an important first step was going to be to mock up the user interface. If I didn’t know what I was supposed to be coding then there was no way on earth I was going to succeed in getting on with it. So whilst I was on the train from London Paddington to Kemble I fired up Balsamiq Mockups on my MacBook and worked out what the workflow was going to be. Nothing very fancy or very complicated – but I would have spent the rest of the week floundering if I hadn’t done this first.
Coding a Fake App
Over the next few days I then had to get on with the coding. The first day I created all of my view controllers, populating all of the tables with hardcoded data and allowing the user to navigate between it all. This worked out really well over the rest of the week – it meant that it felt like a working app right from the start, and every little bit of code I added could be seen in action as soon as it was written. It was basically a case of eliminating friction later in the week – there was none of the hassle, however small, of creating new classes and so on, because it was all there ready and waiting on day one.
Where Would I Be Without Stack Overflow?
I have to say, I would have been utterly lost without Stack Overflow. I must have used it about half a dozen times a day – it seemed like every time I Googled a problem I was having, somebody had already asked a question about it on Stack Overflow and there was already a bunch of awesome answers explaining how to solve the problem. In a few rare cases where a question didn’t already exist, I got some excellent answers promptly. Kudos to Jeff Atwood and the rest of the team involved in developing such an awesome site and community – in my experience it really works.
The Value of a Day Off
As I mentioned previously, I planned right from the start to have a complete day off on Easter Sunday, and get away from the computer as far as possible. Partly that’s because I think that’s the way God’s designed us – he set the pattern of working hard for six days and then having a day off himself, and who are we to work harder than God? But my experience bears out the wisdom of that. Quite apart from feeling more refreshed off the back of it, it meant that by Monday morning I was chomping at the bit to get back to work – I literally couldn’t wait to get on with it. Speaking for myself, if I work flat out without a break I’m rarely doing my best work, and usually end up wasting so much time that I would have been better off taking a day off anyway, so I don’t think you lose anything by trying to be a hero.
In a similar vein, I also made a point of going for a walk for about an hour every afternoon. I got through a lot of 5by5 podcasts during the week! The one day I failed to do that, my eyes were throbbing by the end of the day and I seriously regretted it. I should have listened to my mother – there’s no substitute for eating well and getting good exercise!
The “It’s Mostly Done Phase”
I found that by far and away the hardest phase of development was that penultimate day I scheduled in – “testing and bug-fixing”. I quickly realised that this is were 90% of my failed projects come to die. The product feels finished, although admittedly I had a list of about a dozen little niggles that needed fixing before I could launch. And, of course, being me, there was about a dozen other little niggles that I kind of knew about but hadn’t bothered to write down on my list.
This is where the schedule really broke down. Suddenly I was back in the land of uncertainty – which of those things should I tackle next? How am I going to solve that really hard-sounding one? Aghgh! It only makes matters worse that so many of them seem quite simple – all the more reason not to bother tackling them, since “I can always do that later, it’ll only take a minute”.
In the end I just had to bite the bullet, choose the hardest problem and crack on with it. I often find that once you actually start on something, it’s not nearly as bad as you think. Beginning is often the most difficult step.
Kicking It Out The Door
Once the holiday was over, I put the app to bed for a week whilst I got on with real life. I did show it to a few friends during that time and got a bit of user feedback, but I didn’t do any coding at all. I decided that if I was going to get this thing finished, I just needed to set myself a deadline and say that I was going to submit it to Apple no matter how many little niggles remained unfixed. Yesterday was clear in my diary, so I decided I’d just have to get as much done as I could and then live with the consequences for the rest. That turns out to be a really helpful motivator!
Even so, it amazed me how much courage it seemed to take to go ahead and submit the app. “How can I be sure if I’ve done enough testing?” “What if they find some really obvious bug right off the bat?” Well, you know what – it’s free to submit it, and you can always resubmit it later if they find something! It was a tremendous relief to finally get the thing submitted (even if it did require a complete reinstall of Xcode to overcome an annoying Java error – thanks again Stack Overflow!) and now I just have to work frantically on all of the marketing material whilst I wait to hear the result.
Conclusion
Overall, I’m so glad I decided to get on and make PrayerMate. I feel like I learnt loads about myself and why I find things hard and what I can do to help myself. And hopefully I’ve made a useful app that people will get some genuine benefit from as well. Here are my top five lessons:
- Clarify what you’re supposed to be doing at any given moment as much as possible
- Never believe the lie that something is “almost finished” until it is actually finished
- A very simple app that is finished is a lot more useful to people than a “fully featured” app that isn’t available for purchase
- Know when to stop working as well as when to get on with it
- You can get an awful lot done without the commitments on your time of “normal life”!
Be sure to watch out for PrayerMate in an App Store near you in the coming weeks!
