I’ve been writing software professionally since 1996, although I started writing code many years earlier for fun. I’ve never been interested in getting professional qualifications or certifications in software development, I’ve always figured the best way to reach your potential is to work with people better than yourself (so you can learn how they work) and actually build and ship software to real people, then deal with the fallout that brings (the try, fail, improve, learn cycle I’ll get to later). A piece of paper is no substitute for experience.
However some of the most useful lessons I’ve learned have not been doing the work I’ve been paid to do, they’ve been learned working on software I give away for free.
I’ve been very fortunate that my freeware software John’s Background Switcher has been dramatically more popular than I could have imagined back in 2004 when I first created it – I stopped counting at the point when hundreds of thousands of people were using it. Fortunate not for the reasons you might think – it’s definitely not a case of “whoa! look how many users I have! I’m awesome!”. It’s been great because I’ve learned more about software development, shipping software and above all humility working on JBS than I ever have professionally.
Prior to JBS it was easy for me to forget that real people actually used the software I wrote. I would focus on writing the code for a feature, being as clever as I could be to impress my developer peers, completing it, then moving onto the next thing. I would pretend all that mattered was the thing I was currently working on – “leave me alone, I’m in the zone!”. I thought that users didn’t have a clue what they were talking about and if they complained then it was them who were in the wrong, it was “user error”. WHY DON’T THEY UNDERSTAND?!
The Techie User Phase
JBS was originally written for exactly one user – John Conners. I wanted a simple tool to periodically change my desktop wallpaper (and recover from my friend Ben setting my wallpaper to that of a monkey whenever I left my desk) – I was scratching my own itch. Then I released it for the world and… nobody cared at all. Later I added Flickr functionality and suddenly I had a bunch of people I’d never met, mostly techies like myself, using JBS.
They had suggestions of how to make JBS better. Since JBS didn’t do a great deal it was easy for these technically savvy people to pick up how it worked and the more ideas and suggestions they came up with, the more I added. Sometimes I’d break things, the users would tell me and I would fix them. It was great to be able to just do what I wanted without having layers of managers to persuade feature X should be in the next version. It was freedom!
Soon JBS supported several different picture sources, had lots of options to do things like exclude certain pictures, view the originals, change the way pictures were selected and so on. Things were great! Until it got popular and my ego took a battering.
New Users Aged 8 to 88
Thanks to word of mouth and some write ups on big technical sites, more and more people started trying out JBS. While early users were technically minded like myself, a lot of people with comparatively little computing ability were starting to try it out. And they were getting horribly confused.
In my haste to add functionality I’d stopped trying to keep JBS simple to use so when you first started it up it was by no means clear what JBS did, how to configure it or just what the hell was going on. So people would often email me with one line sentences complaining. I’d then have to reply and find out what the problem was and to me it would be incredibly obvious what they needed to do, but to them it may have well as been written in Klingon. However that was only scratching the surface. A great deal more people installed it, tried it, uninstalled it and I never knew anything about it.
I’m John Conners, What The Hell Do I Know?
Deny it all you like, but developers have egos. I’m no exception. You think you’re smart, you create things with your mind and hands and when you hit “Build” people should kneel before you in awe. But the reality is people just want to do their job, whatever that may be, and they don’t want things, like your software, getting in their way. If they want something that changes their desktop wallpaper, they just want it to do it and work the way they want without them having to think about it. End of story. The best software is the software you don’t even know you’re using – because the software itself isn’t the objective, it’s the task someone wants to accomplish (like writing a blog post like this) that matters. It took me a long time to realise this fact, but let’s rewind a bit.
I decided to add a feature so that if you uninstalled JBS it would show a web page that asked you if you’d like to tell me why you’re removing it. It was both a great idea and a tough pill to swallow. Because what happened is people actually told me why they were uninstalling JBS. And it turned out it was all my fault.
By this stage if JBS crashed it would send back a crash log to my FogBugz instance so I could figure out any bugs in JBS or any of the components it depends on and fix them. This taught me to write the simplest code possible. There’s a tendency for developers to try to show how clever they are by writing needlessly complex code and I was no exception. But overly complex code is likely more prone to bugs and when you come back and look at that code to figure out what went wrong the fact that you wrote it is no help, you look at it and think “why the hell did I write it like this and what is it doing?”. Lesson learned – write the simplest code possible so that when you later come back to fix it (everybody creates bugs) it would be easy to figure out what it was doing.
Uninstall feedback was a revelation. All of a sudden I was getting into the mind of the people who’d tried JBS, been confused by it, not been able to get it to do things it actually could do, then uninstalled in frustration. Some of the feedback would be, shall we say, tetchy. I quickly stopped taking it personally as when software doesn’t do what you want and gets in the way, it can be frustrating.
I actually changed the feedback page to say “Remember, I’m a real person called John and not some faceless corporation so be nice!” which snapped people out of being particularly mean and the feedback became a lot more useful. To those who say you should make software impersonal, you’re talking nonsense!
It didn’t take long before I could see patterns. What I thought was intuitive was clearly not. I could explain to those who left their email addresses how to do what they wanted (since JBS was loaded with features by now) and that helped them out individually. But the real problem was people running it for the first time and getting lost. I needed to rethink how I did things.
Try, Fail, Improve, Learn, Repeat
So I had a reasonably successful software product. I had tens of thousands of users. I had a large number of feature requests. And I had a lot of feedback telling me I needed to make it simpler for new users to use, but I didn’t want to sacrifice functionality. I decided to take a step back and do some planning. So I contacted a bunch of the most passionate JBS users (i.e. the ones who complained the most) to run some ideas past them in a bid to get into their heads, understand what they were expecting and see where that led me.
One of the main problems was that JBS had a whole bunch of different photo sources and it treated each one completely differently. It was not obvious for a new user what to do and even if they added some picture sets (some folders, Flickr sets, etc.) it still wasn’t clear what was actually happening. I’d originally built JBS to use local photos, then added Flickr, then a bunch more sources and had just bolted them on one after the other. People just wanted to choose some photos and get on with it, and no messing around!
So I started by doing the exact opposite of what I was used to. I started removing features.
I knew this would inevitably annoy some JBS users, they’d complain and might stop using it. But I suspected that if I did my job right it would alienate a few users but help a great many more. I had to go with the majority because much though I enjoyed answering emails and helping people out, it would be easier for all concerned if JBS was so easy to use that it required no help from me.
By now whenever someone emailed me I would ignore anything positive they’d say and focus on anything negative, always assuming that their problems were my fault – if you can’t use it it’s because I didn’t make it easy enough to use. This approach has the useful effect of disarming people because many would start by saying “I must be stupid because…” so me telling them they weren’t took that frustration away. I was now learning how to be a support person.
So I completely redesigned the user interface of JBS in consultation with the people who actually used it. I opened up early beta testing for anyone who was interested and would let them try it as I developed it, putting up builds every couple of days, seeing how my changes came across and letting them guide me how to go from there. I was quite happy to work on a feature for days only for it to fall on its face and end up deleting it completely – I took my ego out of the picture. I would try something, see how it worked and either remove it, change it or keep it depending on how it worked for real people. I would start from the position that I didn’t know best, I would let the JBS users tell me what they wanted and try to do it to provide the most benefit to the most people without compromising the simplicity I wanted it to have.
I also learned to start saying “no”. An idea can be a great idea, but if it made the software more difficult to use for 99% of users just to help 1% then I wouldn’t implement it. But rather than throw it away I’d see if there was another way to achieve what the person suggesting was after. Quite often there would be since as any sales person knows, people may know what they want, but might not know what they actually need, you just have to make them realise it and provide it. So I wouldn’t say “no”, I’d say “how about if I did this instead?”.
The Proof Of The Pudding
So after a hell of a lot of late nights and long weekends I released JBS 4.0 and an interesting thing happened. The feedback was initially very quiet. Which to me was perfect. As I had come to realise, good software doesn’t jump out and shout at you and make itself noticed. Good software should be practically invisible, quietly doing its thing and letting you get on with your primary tasks (which I assume is posting on Facebook, which JBS supports of course!). I took it as a great compliment that while user numbers kept increasing, the number of uninstalls and uninstall feedback dramatically reduced.
The JBS 3.6 User Interface
The JBS 4 First-Run Experience
The JBS 4 User Interface
Over time though I’ve received a flood of correspondence that makes all those countless hours of work for no financial gain more than worthwhile. People telling me how they hate their job but when they’re down they look at their desktop to see a montage of photos of holidays with their family, they smile and get on with their day. People who’ve installed JBS on their parents PCs pointed at their Flickr feed so they can keep up to date with what their grandchildren are doing. Even people who’ve lost a loved one but remember happy memories when they pop up on their screen. Touching people’s lives in a profound and positive way is rewarding in a way money can’t buy and thanks to all the lessons I learned above, I was able to make it happen.
A Summary In Neat Bullet Points?
Normally I’d write a bullet point list summarising the lessons I’ve learned from JBS so that anybody could use them but it doesn’t work that way. Remember how I said I never bothered with certifications and such like? It’s because there really is no substitute for experience. There’s no substitute for learning by screwing things up, figuring out where you went wrong and ensuring you try to do better next time. No substitute for seeing how much pain and frustration decisions you’ve made have caused normal people (and lots of them), then figuring out how to win them back, turn it around and make the software better. No flowchart you can build that determines when you implement a feature, or build something else that indirectly but more usefully solves a problem, or even when to remove a feature entirely because it’s the “right” thing to do, or when to completely change direction and try something completely different.
You have to learn by doing, and the best lessons are those born from failing, trying again and ultimately succeeding. Leave your ego at the door and learn lessons from everything you get wrong (pobody’s nerfect).
From doing this again and again and again I’m now much better at making judgment calls. Knowing what questions to ask to find out if a software release is going to be late before it actually is and what to do about it. Knowing when to push a release vs drop features. Recognising that instead of trawling through a bug / feature list and implementing them one at a time, when to take a step back and see if there’s something completely different you can do that renders chunks of those issues obsolete. When to look at the big picture and when to focus on the tiny details. I don’t always get it right, and frankly if I ever thought I did then I’d know I was deluding myself.
And if you write software for a living and work in the 99% of companies that are stuck in the dark ages of software development, just do what I did. Find something interesting and build it on your own time, even if it’s as trivial as a desktop wallpaper switcher. It taught me an incredible amount, and the funny thing is when you build something you’re passionate about, you magically seem to find extra time and energy to work on it.
Finally, the one piece of advice I would give is to use a tool like FogBugz – the best defect tracking / project management / source control / customer support system I’ve used. Without FogBugz I’d have been completely lost at sea both working on JBS and professionally. It’s the perfect example of what I aspire to build – software that is so good you don’t even think about using it – it just works.
And to think, JBS was all kicked off by my friend putting monkey pictures on my desktop when I left my machine unattended. Thanks Ben!
