My most trusty digital workhorses

While I wouldn't necessarily call myself a gadget geek, I have amassed a not unimpressive amount of gear over the years and seen most of it fade into obsolescence.

Take the Psion 5 organizer. It was gorgeous. You could actually type on it with eight fingers and it fits in your jacket pocket. Just watching it slide open is techno-rapture. If I hadn't dropped it eight years ago and cracked the touch-screen (everything else still works) and if it had had USB, I might still use it to this day. There isn't a single device on the market today that gets the same mileage from standard AA batteries (because of its monochrome LDC display), the same portability, the instantaneous boot, the same comfortable keyboard. Nothing.

As for PCs, my carbon footprint is a very hefty size:

1992: 386 laptop with a whopping 20 Mb disk
1994: 486-DX266 PC
1997: Pentium I 120Mhz laptop
1999: Pentium II PC
2000: second-hand IBM Thinkpad
2003: IMac 17"
2006: Macbook
2008: My Linux PC for daily use.

Everything else, except for the Macbook, I have either sold, scrapped, given away or painted yellow and used as a stage prop. No machine has managed to keep up with the state of the art in software land, or with Steve Jobs' master plan. How many of today's websites will run on Internet Explorer 3? Who would want to use a 256-colour 640x480 monitor? The first portable music players sported a laughable 32 Mb of built-in memory. Your batteries would outlive your playlist many times over. I never owned one of them, though.

There are however two ancient digital workhorses that have stood me in good stead for over two decades. I have never bothered to replace them. I don't need to, because they do everything I want them to. More importantly, I don't have to replace them, because of incompatible firmware upgrades, new connector jacks, file formats or standard wars.

Free as in free from frustration

How many small open source projects have a dedicated testing team, comparable in size to the available development horsepower? How many have a dedicated usability professional, or even integrate usability standards throughout the development process?

If you have limited time to spend on something you will not get paid for, you will pick the fun stuff. In the workplace fun, cool and kudos are not the sine qua non before programmers will do any work. Your paycheque is your motivation, as Alfred Hitchcock once said to an actor.

I attended a seminar once about Spring MVC, listening to two over-enthusiastic developers telling me how their platform was so much better than the 1356 Java web frameworks vying for my attention. First question from the audience: "When are you guys going to bring the documentation up to date?". I rest my case.

Although no documentation is often better than bad documentation I could possibly live without documentation, provided the software is so intuitive it doesn't need a manual. I can hear your ironic chuckles already.

I was dabbling with music notation software on Linux, installing the latest version of MuseScore.
It's an impressive piece of work, but it kept crashing. It's been around for a while, and yet it still manages to crash randomly. I was running the stable release, and yet it kept crashing on me. The crashes were inexplicable and completely non-reproduceable. One single keystroke was enough to let everything vanish.

I bet it doesn't crash that often on the developers' machines. I reckon there's a lot of satisfied users who don't uninstall the app out of sheer frustration. Why don't I file a bug report and help the developers fix this? Well, I consider some bugs too trivial to report and others - like this one - too glaring. I'm using the latest version of Ubuntu, installing it using the standard Synaptic package manager. As far as I'm concerned the problem is not my problem. Sure, there's likely some pesky bit of configuration to do with sound drivers, but statistically I have only forty more years left on this earth, and my time is too precious to bother.

Mac OS comes with Garageband. It has only a subset of all the nifty features that MuseScore offers. It's made for the amateur home studio, i.e. for me. It's so intuitive it doesn't need a manual. It's certainly not free, neither in freedom or in beer, but it came installed with the OS, so at least it feels free.

Best of all, it hasn't crashed on me yet.

Eat your own dogfood part 3: JDBC4Me

I've done it. After almost ten years of fruitless hacking at ambitious architectures that didn't really do anything, I have finally uploaded a first version of a working piece of open source software: JDBC4Me. I won't expound on how it will radically alter our conception of data or how it wil effect a dramatic paradigm shift in database access. It won't.

It's nothing earth-shattering. For the non-programmers: it helps you retrieve, insert and update data from a program from and into a database in a more user-friendly way. It does nothing new, but it does it in a way I found lacking in other tools. If you're not a Java programmer who's reasonably well-versed in JDBC you probably have no use for it whatsoever. That's perfectly fine.

One of the biggest pitfalls in building software is trying to be all things to all people. The choice of what to leave it out is often harder than what to put in.
JDBC4Me does one thing, and I think does it reasonably well for a sub 1.0 release. It has documentation and lots of unit tests. While writing these tests I discovered and fixed scores of obvious and some pretty nasty bugs. I deliberately tested against only three database products and their most common Java drivers: Oracle10, MySQL5 and Derby10. Use anything else, and the tool will default to settings that may or may not work. I'm quite happy to include Microsoft SQL server and PostGreSQL, but only when I have time to test them properly. If there's one thing I discovered in working with databases in Java, it's that vendor-neutrality in generic tools is overrated. Hibernate and other ORM tools are keen to lure you into this trap and pretend that changing vendors is as simple as updating a configuration file, but the soldiers in the trenches know better.

Here's another thing I learned. The more you zoom in on a programming challenge, the hairier it gets. You start off thinking that all driver vendors conform neatly to the JDBC standard, especially a multi-billion dollar empire like Oracle. Yeah, right. I actually discovered that Oracle had the worst standard compliance of all, and I was unlucky enough to base the first version of my code on Derby, which had the best compliance (not surprising, as Derby is written in Java). I made assumptions that the driver could provide certain metadata, which it didn't in Oracle, so my well-intentioned vendor-neutral code quickly had to go and I found myself writing an Oracle10Proxy, a Derby10Proxy and a Mysql5Proxy. It hurts my eye, it flies in the face of everything JDBC stands for, but it's the only way to make sure that each database performs as it is supposed to perform.

Having lots of features to please lots of users counts for nothing if the features you need are poorly implemented. A housing site that covers 20% of all properties in a country is less useful than one that has 80% in a single town, if that happens to be the town I want to live in.

Next time I'll share an experience of using other people's open source software. I'll try to be friendly and forgiving, BUT IT KEPT CRASHING ON ME.
"Yeah, but it has many more features than [...]"
- BUT IT KEEPS CRASHING!!
"You can write your own macros..."
- BUT IT KEEPS CRASHING!!
"It's free"
- BUT IT KEEPS CRASHING!!

Eat your own dog food - part two

The problem with Yourstreet, I reckoned, was that in essence it was a business venture backed by a website, more than just a web application. It was a typical chicken and egg/necessary critical mass quandary: nobody is going to join if not enough people are already using it. It would have taken a serious investment is sales and marketing. We didn't really want to run a software company: we just wanted to code. But...

• Rule one: there's a lot more to programming than just writing code.
• Rule two: there's a lot more to software development than just programming.
• Rule three: there's a lot more to running a software company than development.

Any programmer should be rudely awoken by rule one when she gets involved in any non-trivial application. Violations of this rule are responsible for more than half of all curious perversions on Daily What the Fuck. Good programming is about being considerate for your co-workers, not showing off your skills just for the hell of it, and basically treating your work as if the next guy to maintain it is a homicidal maniac who knows your address. Writing code that works is one thing. Writing code that other coders can read and improve is a necessary feature of good programming.

Software development involves business cases, requirements, project briefs, planning meetings, progress reports, release schedules, deployment diagrams, service level agreements. Well, you get the point. Especially in smaller projects you can't avoid becoming involved in one or more of these chores that have very little to do with coding, or even programming.

All of the above still has to do with building and maintaining the product. Elsewhere in the building they're hiring new staff, replacing lightbulbs (and planning the resources for it), answering the phone. O yes, and finding people who might want to give you money in exchange for yourstreet.org. Rule three is about creating Joel's development abstraction layer.

I don't want to run a software company, I really don't. Not even one with a casual dress code and gorgeous female developers who like classical music. That's why our Scotland partnership broke up -- that, and my marriage, but this being a software blog I won't elaborate. I moved back to the Netherlands and started work for a company in Rotterdam.

Meanwhile I had all this Perl code and too much time on my hands in the evenings. So I decided to reafactor yourstreet into something that didn't require a sales force to reach critical mass and was something that I could see myself using. I started building a web-based CMS/file synchronization/version-management apparatus. Started it, and abandoned it.

Don't even think for one moment that a team of one (or two) developers can out-perform a team of 500. If you want to write successful software on your own, you have to keep it small, smaller, smallest. More about that next time.