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.

Life is not a conveyor belt

I think a major failing of the education system is that it gives kids an expectation that life is a series of levels. All you have to do is succeed at the current level, and then you’ll be moved along to the next one.

In the UK, school is divided up into “Key Stages”, with two or three school years per Key Stage. It’s a similar structure to a game like Sonic the Hedgehog – complete all the levels in a stage, and face Doctor Robotnik, in the form of a timed exam.

I’m not saying I have a better idea for structuring mass education – there are a lot of children that all need to go through school (while their parents are busy doing other things to earn money). Perhaps inevitably the system must share features with the factory, the farm or the army boot camp.

But what kind of mindset can this create? I’ve met people who seem to retain an idea that life is a sequence of stages that you go through, even though they have long left school. After graduating from university, they measure their success by how far they have progressed through what they perceive as the necessary next levels – in employment, work your way up the career ladder. In your spare time, get married, buy a house, have children.

I tell them my thoughts on marriage, for example. “Oh, you won’t feel like that when you get to my age”, they say. “Not when you get to my stage in life” – like I simply haven’t scored enough points yet, but maybe there is hope for me some day. “Now, look at this lovely kitchen we’re having installed.”

Once you’ve achieved all these levels, presumably you will find happiness. Eventually, you can retire, and later, when you’re too ill to feed yourself, you will be looked after by your children and grandchildren, and the equity released from your house. You can die happy, knowing that you got through the last 80 or so years without fucking anything up too much. Well done you.

Not everybody is like this, and I’m not quite there yet with my model for how all of society should be living. But this does seem like a rather boring way of life, indicating an absence of imagination. More worryingly, there is an implicit trust in this view, that the lifestyles of our parents and grandparents, cultivated in the 200 or so years since the industrial revolution, are somehow correct and permanent. This is the way things are. This is the way things should be. This is the way things will always be. This is how you succeed in life.

If you just fit in, follow instructions, act like everybody else and don’t ask questions, you will be fine.

But although it may be comforting to believe that our way of life is pretty stable, we humans have a pretty poor track record keeping anything constant for any length of time at all. Blindness and assumptions lead to all kinds of groupthink and bubbles.

I would love for all of those years of school to teach kids these lessons instead: Don’t follow orders, don’t blindly copy what others are doing, and always keep your wits about you.

Difficult to test these things under exam conditions though.

Once again, some interesting comments on this over at Hacker News

How I live and how I work

I live differently to everybody else I know.

Other people go out to work. They earn money. They spend it. On houses, cars, children, gadgets, holidays. All kinds of things.

Sometimes they complain about work. Sometimes they complain about how expensive things are.

I don’t complain about either of those things.

I sit at home all day, creating software. I haven’t worked out how to make much money from it yet. But I’m getting there.

And yet, I seem to have plenty of money. Enough for me to live on for a few more months anyway, without having to worry just yet.

I haven’t won the lottery. I spent about six months last year doing some contract work, to earn of bit of money before coming back to doing my own thing again. But that contract wasn’t especially highly paid – pretty average, maybe a little on the low side when I compare it to other contracts that I’ve seen advertised, and the rates that other developers  I’ve spoken to have charged.

I suppose I lead quite a frugal lifestyle. If I look back 10 years, the lifestyle I had a student isn’t actually very much different to the kind of life I lead now. When I started working, I didn’t start spending.

Maybe it’s because when I started working, I had some student debts to pay off. Not the UK Student Loan – that’s paid off very gradually out of your pay packet – but some nice big credit card bills. I paid those off with a graduate loan from the bank, which then took me about three years to pay off.

So I was working but I couldn’t really afford to change my lifestyle, so I didn’t. Then when the debts were paid off, why change anything? I simply started saving.

Over time, those savings built up. I could have done quite a lot of things with the money. I could have put down a deposit to buy a house, sooner or later anyway. I could have bought a big shiny car. I could have saved a bit less, and developed a taste for expensive shirts or exotic foreign holidays. Or I could have started a family.

But I’m not interested in any of those things. Instead, the money allows me to buy the most valuable things in the world. Time and Freedom.

Some people save up for their retirement to start enjoying life. They put up with years of hardship, waiting for the light at the end of the tunnel.

I don’t believe in retirement. Not just because the economic situation at the moment means it’s likely that for many of us, even if we save up, retirement will be continually postponed until we are too old to really enjoy it. But more importantly, if you can set up your life so that you enjoy work, so that your work is your life, and your life is your work, then you never need to stop.

You can enjoy your life right now. You just need to spend less money on shit that you don’t need.

There are some great comments on this article at HackerNews

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?”