Innovation in Software

Many years ago I ran FreeBSD on pretty much every system I touched. I loved it. The lack of political polarisation that touches the GNU/Linux community combined with the power of Unix under the hood sucked me in.

I even, almost infamously, had a rant about another operating system I now use daily. I was a zealot. I am ashamed of my attitude in that email – my only excuse is that I was still quite young, a rather naive and opinionated 26 year old.

Today, I use exclusively OS X, and occasionally boot up a virtual Windows instance to test code on MS code. I have a terminal open nearly all the time and often dive down to the Unix goodness, but more often than not the bulk of my work is in the browser, text editor, IDE or Mail app.

Why then, I was asked the other day, do I not just ditch Apple and get a Linux (or even BSD), machine to work with? The bulk of my work (except for iPhone application development) would continue as before.

My answer is very simple: carpenters don’t build lathes.

To explain, let’s first go back to that rant I had about OS X. About a month later, I ordered my first Apple laptop – an iBook G4 – and was very happy with it. What happened in that month?

I realised when shopping around, I needed to check out the chipsets used for WiFi in each laptop because FreeBSD wireless support was pretty hit-and-miss back then. I also needed to understand the graphics chip-set because I’d need to compile X if I wanted to run a graphical desktop environment. I then realised I’d need to assess pretty much every feature in terms of hardware compatibility to make a purchasing decision. And then, on receipt of my new laptop I would have to spend a few hours doing all the compiling and fixing, and I would then need to do this work every few months as part of an upgrade cycle.

Yes, I’d get the power and flexibility of my own tailored operating system environment, but isn’t that a lot of work?

I recalled a few months previously a friend was playing with his new smart phone. It was running Symbian and he seemed to be doing lots of prodding and poking with it. Enquiring what he was doing, he said he was “doing some maintenance” to keep it in working order. Hang on, was he effectively sysadmin’ing his phone? “Yes, I suppose”, came the reply. When you have to do systems administration work on your phone, your phone is no longer a tool to assist with your work, it is an object of work in itself.

It was this insight when thinking about my operating system choices that directed me to OS X: I wanted the power of Unix, sure, but I wanted it to just work. I wanted to be able to get on with my work, the laptop and operating system as tools rather than objects of work themselves.

This small insight has made my life a great deal easier, and still dictates not using any other operating system. Some of my peers see it as weakness (even more point to my original rant above), but I see it as spending my time doing the things I love.

And it’s also an insight I think that as developers we forget: are we developing tools that assist with objectives, or tools that are objects of work themselves. Are we building interfaces and suggesting business logic that means our customers spend time managing the behaviour to fit around them? If so, why?

In the last few weeks I’ve seen some really interesting “reductions” in functionality that aim to make tools more directly useful, rather than requiring some administration.

Take for example, the role of authentication. You need to “contain” all of your customer’s “stuff” in a way that is linked to their “account”. So we have user registration, user profiles, account activations, password resets, etc. Seems like a lot of stuff. Are we sure we need it?

Take for example, Posterous. Their home page explains it all:

All you need to do is email stuff to post@posterous.com and you’re up and running. No signup, no captchas, no password strength indicators unless you want to add them. You’re a person capturing stuff – why do you need to admin yet another web application?

BootStrap UK (which is worthy of an article in its own right as a concept), needs accounts but has a simpler registration system: just follow @bootstrapuk on Twitter and they’ll follow you and direct message you a password. Done.

There are other examples out there as well, sometimes using software to help break out “lathe obsession” elsewhere in society. One iPhone app I’ve seen reviewed gets the banking system to work around the customer, rather than demand the customer head into a branch to suit the banking system. Brilliant.

We often spend too much time trying to work out how a customers will need to behave around our application, rather than how we need to get out of the way and let our customers use what we produce in order to do their thing. In every customer we need to start seeing the carpenter more, and assume they – perhaps unlike many of us developers – don’t like tinkering with lathes for its own sake.