Close enough for a side project - how to know when things are good enough

Once upon a time, before I became a web developer, I worked doing sound and light for events. Like web development, the hours tend to be long, and the work tends to attract anti-social oddballs. Unlike web development, you deal with rock stars. Like most professions, it’s full of jargon and in-jokes. One of the phrases in common usage in that industry was “close enough for rock and roll”. Depending on who you were talking to, it might have been jazz rather than rock and roll, but you get the idea. It isn’t too far away from the notion previously popularised by Voltaire: “Perfect is the enemy of good”.

Another formulation of the same idea was expressed slightly more succinctly (and less politely) on the T-shirt shown in the photo attached to this blog post. It was designed by and for my old student union stage crew. While the T-shirt encapsulates a lot of the attitude of the team, it would be a mistake to imagine that we were sloppy. As I’ve written before, we were unpaid, but we certainly weren’t amateurs. That volunteer crew probably had as high a level of professionalism as any team I’ve been a part of. The point was that we cared about the right things, and there comes a point where you have to accept that things are as good as they are realistically going to get.

There’s a point where it just isn’t worth putting in more effort before launch. You’ve done as much as you can, and you’re proving the law of diminishing returns, or the Pareto principle. Besides, if you carry on fixing things, you’ll end up delaying your launch. If you’re getting ready to put on a show, there's a point where you have to open the doors, whether or not things are 100% ready. There are people outside who have bought tickets. They don’t want to wait while you mess about with your final preparations. They’re here to see the show, and their idea of perfection is very likely to be different from yours.

In events, these people are (somewhat dismissively) called ‘punters’, and they don’t notice the same things that you do. Unless they’re in the business themselves, their perception of the event is likely to be very different to yours. Working on stage crew, I’ve cobbled things together with gaffa tape and crossed my fingers, and the show has turned out fantastically well. As a musician, I’ve done shows that I thought were riddled with mistakes, and people in the audience told me it was the best gig they’d seen us play. Punters don’t go to gigs for technically competent sound or lighting, or flawless performances - they go because they want to have a good time. Things are never as shiny backstage as they are front of house.

Similarly, as a developer, I’ve built sites that have won awards, although the code made me cringe. From a technical point of view, you may not be proud of the code or the architecture underlying a website, but that’s not what people are here for. They are visiting your website for the content, or some of the interactivity that it provides. Most sites are not perfect, but they don’t need to be.

There are certain areas where you should never cut corners. In events, that’s things like rigging lights from the ceiling - you have to make sure that they won’t fall on anyone’s head. In development, it’s in security - you have to make sure that people’s data is safe. If there’s a chance people might get hurt, there’s no excuse for sloppiness. But in most areas of most projects, you’re never going to get things perfect - you need to know what’s good enough.

I’ve been working on my own current side project (the redesign and Drupal 8 upgrade of an art gallery listings site) for a while now, in between the day job and family life. Just before Christmas, I still had quite a few tasks left on my board, but having read an article by Ben Roux, I knew that I needed to get the thing live, sooner rather than later. This is the great thing about side projects - there's something marvellously liberating being able to just make that decision for myself, without consultation with clients or stakeholders.

The great thing about putting your work out there on the web is that publishing improvements is trivial. I’ve defined my minimum viable redesign, so I can iterate and improve after launch, even though some of the functionality from the old Drupal 6 version isn’t ready. I could keep polishing and polishing, but it’s better to put it out there, and fix things later. Besides, I’m pretty confident that the new design is better than the old one, in spite of a few rough edges. Chances are, I’m the only person who will pick up on most of the problems with the site.

On the other hand, this means that nothing is ever finished. One of the things I loved about working in events was that there was a clear beginning, middle and end. We would start with an empty room and a full truck. We would unpack the truck, and fill the room with gear. Then we would put on a show. After the show, we’d pack up the gear and put it back into the truck. Then the truck would drive to the next venue, and we could (usually) go home with the satisfaction of a job well done.

With web development, it’s more like endlessly pushing a boulder up a hill. After putting a site live, there’s no great moment of triumph. If we take the analogy of a concert, it’s more like opening the doors and letting the punters in. Unless it’s a short-lived marketing site, the only time you ever take a website down and pack everything away is if the business has failed. There are always things to improve. I could keep adding features, or tweaking the design, or improving performance forever. But what value would it add? Besides, it’s a side project, and I’ve got other things to do.

All tags