I was planning to use my keys left for something different today, but found myself in an associative storm of tweets, possible conference sessions to be proposed and some situated software I’ve been working on for a few years, intermittently.
Marc Evers pointed me at Clay Shirky’s Situated Software around the time it came out in 2004. I stumbled across David R. MacIver’s independent reinvention today. Both good, and similar in spirit. Waiting for number three, and we have a pattern.
Situated Sofware resonates with me, because, even though I prefer to use software already written - I’m more of a power user than a developer in that sense - there are surprisingly plenty of opportunities to make software for yourself, or small (a few hundred?) groups of users. I have to remind myself (and sometimes the users do) about the things, or sometimes the indirect effects, that are good about it. Because there is always plenty of things that are bad about software, your own or others’. Feeling bad about your software does not make it better.
David talks about not necessarily loving the code, but loving the problem it solves. Clay’s piece references Richard Gabriels’ classic Worse is Better, but links to a worse site than the original. Oh the irony. I looked it up, and Worse is Better is self-referential. Worse is Better as an amusing history of the author arguing in favour and against (using a pseudonym) his own opinion.
Further reading
I also was reminded of Andy Palmer’s’ mantra Strong opinions, weakly held. Eloquently collected by Chris Matts’ who’d rather be wrong than right.
The chapter on Battle of Wesnoth in The architecture of open source applications is a great example of explicitly designing for worse is better, in part. It features an extension language that ‘real programmers’ feel is worse, but levels the playing field for ‘regular users’ to create extensions.
Subscribe to our RSS feed