Don’t build an app, build a business

The BBC News article App Store ‘full of zombies’ as it celebrates fifth birthday comes as no surprise to anybody who has much experience with developing apps – most of them make very little impact at all.

Even Apple’s own spin on its app store stats sounded a warning bell, when Tim Cook revealed this stat during the WWDC keynote:

If 7% of apps don’t get downloaded at least once a month, there must be much higher figures for apps which don’t get downloaded at least once a week, once a day or once an hour. And an app that isn’t getting downloaded regularly isn’t making anybody much money.

I thought it was well established now that the App Store gold rush is long over, but it’s worth repeating the message so that more people don’t end up wasting their time. You will not make yourself rich by making an app now. You will not even make yourself a living. You will barely make some beer money, if you’re lucky. It is an insanely competitive environment and the easy wins were a long time ago.

If your plan is “I want to make an app”, go back to the beginning and start again. What do you actually want to achieve? You don’t need to make the world a better place, but you do need to provide something of value to some people. Come up with a proper aim and see what flows from there – starting at “apps” is thinking backwards.

Apps are cheap and disposable. They're sold in a similar way, and for similar prices, to songs on iTunes. It certainly takes a lot of skill to create a best-selling song, but the best musicians don't pin all their hopes on one song making it big. And many musicians fail, but that doesn't stop thousands from trying – there's a lot of glamour at the top of showbiz.

I suppose there's a lot of glamour in being at the top of the App Store rankings too.

But don't be distracted by shiny things that are far away from you. Be realistic about the risks. Concentrate on how you can provide value and be useful, instead of hoping for a hit.

The secret of good documentation is empathy

Writing documentation is hard, but that’s no reason to skimp on it if you want to run a successful software project. It’s certainly one of my least favourite activities, and usually one I put off right until the last minute, but the existence of good documentation is often the deciding factor whenever I’m assessing whether to use some software.

I have become accustomed to most documentation being pretty crappy though – so much so, that sometimes I forget to even look for it. I’ve been learning the JavaScript library Knockout this week, and I’d looked a few things up on Stack Overflow before realising that Knockout’s own documentation is excellent.

What I like about it is:

  • it’s written to help me out, as a new user who knows nothing about Knockout
  • it explains why I would want to use it in the first place
  • it guides me through the key concepts, with examples
  • it doesn’t shy away from the “advanced” stuff, but it flags it up appropriately – so if you’re more of a JavaScript novice, you know which parts you can safely skip, but if you want to know more detail about what it’s doing, all the info you need is there
  • there is a clear progression through the documentation – pages are relatively free of links, which keeps you on the right path, but if you want to jump in and look something up it’s easy to do so

It’s just the right amount of detail – not too little, not too much, and you can read the whole thing in quite a short amount of time and feel like you have a good understanding of what Knockout is and how to use it.

While I think of it, the documentation for Bootstrap is another example which manages to get this kind of digestible tutorial-but-also-reference thing right.

As much as I love PhoneGap, I wish their documentation was as good as this. Frequently, it’s not kept up to date, which can lead to a lot of hair tearing even when trying to follow something as simple as the guides for setting up your first project. How many users have been put off using PhoneGap at all because of this?

I think all that’s needed is a little empathy. Remember that a new user doesn’t know anything about the software – and their first question is “why the hell should I bother using this in the first place?”

Answer that, and then think about what they’ll need to know next. Simple stuff really. But apparently, easy to forget. Why?

Nobody will tell you how badly you’re screwing up the experience of the first time user.

New users won’t give you feedback. They’ll move on elsewhere – maybe to some competing software, or maybe they’ll just give up on the whole idea of what they were trying to do anyway. They’ll think it’s their fault. They must have set up their computer wrong, or they’re too stupid to understand this, or this software isn’t really for them anyway.

I did experience some “road bumps” with Knockout even though its documentation is great. Fortunately, these only occurred after I was quite far through reading it, so I persisted instead of giving up. Did I just miss something by skimming over it? Maybe – after all, most people skim when reading on the internet, and I’m no exception. Maybe I’d just failed to grasp something which was never explicitly stated, and that functionality could have worked in a number of ways.

Having solved my issue, nobody is ever going to get to hear about what it was, or how I solved it. Other users may have the same problem, and will have to figure it out themselves too. The maintainer of the documentation will never know – there is no channel for me to say “I didn’t understand A, until I realised B”. There will be no bug report for an issue which may be unique to me and my brain.

Preventing your software from descending into an abyss of complexity

Nice article by Kris Gale on the hidden costs of complexity in software:

Among the most dangerously unconsidered costs is what I’ve been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer.

I used to work on a huge financial software product, written in VB6. Legend had it that this was the largest VB6 program ever built – hundreds of different components. And it was painfully slow to work on. The whole application desperately needed refactoring, yet despite there being a team of 20 developers working on it, development had basically completely ground to a halt. We were all busy, of course – plenty of bug fixes and minor feature requests – but it never felt that the application was noticeably getting better.

There had been an attempt to move the application into the world of .NET, but all that had achieved was creating a hybrid VB6 and C# application that added yet more layers of code. Nothing was ever removed, or stripped back, or simplified – just more and more code added to the pile.

It meant that it took a long time to add any new functionality, as you had to dig through all of the layers, and inevitably changing anything would cause something to break, often in a subtle way in a completely different part of the application.

I used to enjoy coming home from work and hacking on Quest for a few hours, because it felt like I had suddenly become 1000x more productive, and could add new features and fix bugs almost scarily quickly.

Now that Quest is (for the moment) my full-time job, and with its codebase having grown quite considerably over the years, I have to be careful not to bring the same problems upon myself. All software tends to stagnate over time – I’m reasonably happy with how my own architecture is holding up, but even then I often find I’m slowed down by having to ensure that it always remains compatible with games created for older versions, and that any changes I make to how it works apply across both the desktop and web editions.

In some ways, it would be nice to strip things back a bit – perhaps making it a web-only product, instead of there being a Windows desktop version too. The existence of the desktop version seems a bit “legacy” now, but there still a genuine need for it – schools don’t yet always have reliable or fast internet connections for example.

The challenge, then, is to ensure that any complexity that exists is there for a good reason, and to keep an eye open for where things can be simplified. It’s very easy to ask “how can this software do more?” – perhaps we should also sometimes ask “how can this software do less?”