I am, by nature, a very ambitious person, but the most important lesson I’ve learned in my four years as an indie iOS developer is to measure that ambition agaist reality. Then push just a bit further. And that lesson only cost me $100k — I call it my MBA in hardknocks.
Thankfully, App Cubby was able to sustain two failed projects that each cost upwards of $50k, but not many indie developers can get away with those kinds of mistakes. And many a would-be indie developer has been crushed by getting themselves too far upside down before realizing they bit off more than they could chew.
I wish there was some sort of 5 point list I could write to convey these lessons, but it’s just not that easy to sum up. It takes years and lots of both successful and failed projects to get a good sense of realism when looking at the scope of a project.
For someone who has never shipped software, scope estimates are generally off by at least 10x. Developers laugh at these sorts of estimates. At a party someone comes up with “The Next Angry Birds™” and estimates it’ll take a two weeks and $5k to complete. Good luck with that.
Then there are well intentioned developers who just haven’t shipped enough projects, or big enough projects, to have had a few go horribly awry. Their estimates are generally off by 4x to 10x. They often think they’re good at estimating scope, but inevitably kill features and skimp on polish. That’s not great estimating, it’s just shipping crap.
This happens a lot in the contract development space. Client accepts the low bid, but expects Apple level polish. Heated emails are exchanged and the project ends in disaster, or everyone decides to just look the other way and ship a subpar 1.0.
It’s also evident in all the half started projects gathering dust in developers’ “Personal Projects” folders. They have a great idea and think they can knock out a quick app in their spare time. They don’t, and eventually abandon the project or ship a subpar 1.0. There’s also the delusional belief that these abandoned projects will be quickly finished whenever time permits. Time doesn’t permit, that’s not how time works. And even if time is made, the project is still at least 4x further from completion than estimated.
Then there are the grizzled veterans who have done their best to learn from past successes and failures. They may still be off by up to 4x, but have learned when to stop throwing good money after bad or how how to appropriately slash scope while still shipping a solid 1.0. These are the people I want on my team.
The timer app I shipped last week was an experiment in a lot of ways. Not the least of which was a test of my own ability to get a quick project out the door on time and within budget. I failed. But I failed better.
My initial plan for the app was to test the waters in the shallow end of the App Store pool. I was going to outsource the whole project and even started interviewing Eastern European artists and coders. I estimated the project at 2 weeks and $2k. Now that Timer has shipped, I know this would not have ended well. It would have taken at least twice as long, cost twice as much, and been half as polished as Timer. I don’t say that to denigrate the talent of Eastern European contractors, I was actually very impressed with the folks I started interviewing. It’s just that outsourcing is a completely different process — one that I doubt would be particularly compatible with my usual iterative, team approach to development.
Instead of outsourcing, I decided to hire my good friend and coconspirator Justin Youens to code, and work with a new aquantance — and ridiculously talented artist — William Szilveszter. My new estimate for the project was one week and $5k.
Turns out simplicy is complex. I’ve heard that a million times and thought I really understood it, but was once again surprised at how complex a “simple little timer app” could be. After a few day’s work and roughly $2k invested we had a functional app that many developers would have called 1.0, but “functional” wasn’t the goal. There are already hundreds of half-finished, poorly concieved timers in the App Store.
After some great input from Justin, Will, and trusted beta testers, along with some iteration on a few of the core interactions, the app ended up taking two weeks and $7k. Just 1.4x my revamped estimate and 3.5x my lowball estimate. Not bad, not bad at all. And I’m incredibly proud of the result.
That’s the best I’ve ever done at estimating scope. Project VJ is the worst I’ve ever done. [WikiPro was a close 2nd.]
Back in the Spring of 2009 I had this great idea for an interactive music app. A series of 2D/3D scenes that would react in real time to music as well as user input. That idea became Project VJ, a project I worked on for the better part of a year. After hundreds of hours of my time and $50k in expenses, we had a decent prototype. It was a gut-wrenching decision, but in April 2010 I shelved the project, realizing that it would take at least another year and a lot more money to ship.
The code is now crufty and many of the concepts are no longer novel, so I’ve decided to take it off the shelf, dust it off a bit, and show how far we got. I keep telling myself I’ll finish it one day, but given the above discussion, I realize that’s a bit dilusional. I could finish it, given the right financial and/or development partner, but it’s not doing me any good sitting on the shelf. So here it is.
This is the artist’s rendering we started with:
Here are a couple demo videos of the prototype recorded in 2010:
The sad truth is that quite a few people who read this post are going to think “I could build something like that in a weekend”. Like that? Yes. A polished 1.0 on the level of other great apps on iOS? Not on your life.
Ultimately ambition is a great thing — I constantly strive to ship the best possible apps, and often succeed — but ambition not measured against reality is a recipe for distaster. Or something insanely great. It really depends on how much flexibilty one has in chasing that ambition beyond reality. One of the most ambitious things I’m currently working on is to put myself in a position where reality is a lesser constraint. That’s where the magic happens.