Wednesday 3 November 2010

Relax: write some selfish software

I recently decided to improve my organisation a bit, and there's no better way to start such a project than by procrastinating — by designing and writing that absolutely essential piece of perfectly tailored software that will implement your system, while the situation you'd hoped to apply it to devolves even further into chaos. Just before git init, though, I stopped and thought.

For the ten years or so that I've been capable of writing code worth sharing, I've never given a second thought to making anything I've written available under an open source licence. Zealots have gushed about the benefits sharing brings to the community and to the quality of the resulting software, and I've largely agreed.

While I've had my fair share of minor patches accepted (and rejected) upstream, no standalone project I've ever written has got very far nor found any audience to speak of; I generally stay up 20 hours of 24 for a fortnight hacking away, then I lose interest. I thought about why that was, and came to the conclusion it's mostly because I prematurely pander to my non-existent audience — and that's hard work. My phantom customers sit on my shoulder while I code, and in my mind they're impossible to please. Before I know it I'm writing preference panes and portable self-documenting file formats and littering the code with FIXMEs for all the things I want some imaginary co-maintainer to forgive me for (and filling a bugtracker with them too). As a handful of potential users contacts me, I'm so eager for actual users that I agree to implement the features they ask for, even though they want things I don't, then get bored implementing them and stop.

I decided to try this one the opposite way: a deliberately selfish program that would do exactly what I'd want it to do, so would need no preferences; that would only ever store my data, eliminating the need to worry about file formats and field names; that would run only on my platforms and devices, and so have no portability concerns; that would have absolutely no test cases because the only one it would need would be "works for me?"; and whose code I could litter with disgusting hacks.

It went really well. It's simple software anyway, but it was up and running in a fraction of the time it usually takes and I still have the energy for the inevitable first re-write. Some wise sage once wrote: "Plan to throw one away. You will anyway." With all previous such projects I think I've given up at exactly the point where you realise you have to re-write, but you're so worn out you can't be bothered any more.

That isn't to say I won't open-source this or future code. There are definitely too many bits of personal organiser software out there already, for instance — ones that aren't tailored inflexibly to a single pedant's whims — but as it's free to share, I might as well.

Unless your aim is specifically to release a popular piece of open-source software or you have lots of free time to add features for others, ignore "release early, release often". Concentrate on creating something that does a good job of addressing your variety of your problem. When it comes to releasing it to the world, just write a few paragraphs about the true state of play and git push it somewhere public. Even then, maintain staunch indifference about whether it gets used by anyone but you.

No comments:

Post a Comment