Second Order Effects

15 January 2009

Seth Godin recently wrote about the end of newsprint, and how he frankly didn’t care. I think he’s correct about some aspects of journalism, but to talk about newspapers without talking about actual physical newspapers is crazy.

What will we miss?

All the second-order effects. We’ll miss the daily conversation with the guy on the newstand. We’ll miss the cuttings that our parents and grandparents send us in the post. We’ll miss seeing other articles in our peripheral vision as we read – complete articles with photographs and boxouts, not just headlines – as opposed to the ads that surround the online edition. We’ll miss scrawling notes in the margin. We’ll miss leaving them lying around the flat for our flatmates to read. We’ll not have anything to wipe our shoes on.

I say this as someone who’s happy reading from a computer screen, if not from an e-reader. The second-order effects of newspaper journalism being transmitted in physical newspapers are just as compelling a reason for their existence as the intended outcome.

This reminded me of something else that’s been on my mind, relating to another newspaper; this time, one my friends made.

Russell and Ben’s lovely paper is receiving a slowly escalating amount of attention. I’m glad, because it’s really good, and because there’s a (passable) piece of writing by me and lots of (very good) writing by many of my friends in there.

But I’m curious – and perhaps a bit concerned – as to what others might take away from it.

The most important thing about this isn’t “hey, they printed stuff off the internet“. The most important stuff is all the craft, all the second-order effects it has; the details Ben writes about in his excellent post on designing and making the thing; the tangibility it gives to work we’ve done that our non-technical friends (and especially relatives) might never see; the ease of distribution amongst small, hand-to-hand circles it affords; the way you design for (small) mass production rather than one-offs; the reminder that small-scale print is affordable and doable.

Let’s not forget the importance of the immediate first-order effect: this is a beautiful thing, lovely to hold, great to read, fun to show others. In and of itself, it’s delightful (in every sense of the word).

Russell and Ben are, I think, somewhat correct in their closing comment, that “2009 feels like a year for printing and making real stuff in the real world. Its going to be exciting“, but that’s something to consider with caution: making real stuff, printing real things alone, isn’t going to be enough; you’ve got to have the thought, the details, the affordance of second-order effects as well.

I’m excited, for many reasons, as to what 2009 might hold; I hope there’ll be, for me at least, a sizeable amount of making spread across all manner of media – words, things, screens. And, especially, the things that can’t make up their mind which they are. I’m not fussy, and I still think there are lots of interesting problems on screens to solve.

Whatever I’m doing, though, I’m going to try and remember that it’s not just about the idea, not just about the hey-look-a-thing-ness of it all; it’s about the execution, and the detail, and the thought – and embodying that thought in the final product.

To go back to Seth Godin: that’s what newspapers, real, physical, printed newspapers always did. They had affordance out their earholes, and that’s what we loved them for.

I think I’ve found my (slightly corrupted) mantra for 2009:

think twice, cut once.

  • "An almost-real-time, behind-the-scenes look at the assigning, writing, editing, and designing of a Wired feature."
  • "Brands are built…out of culture…out of meanings from culture. In the Volvo campaign, the meaning was safety and symbol for this safety was a little girl. Pretty standard. But this book is interested in new ways to source meaning. Let's look at new, emerging brand tactics." More excellent posts from Grant.
  • "The current browsers, including Firefox, just can’t cut it. JavaScript isn’t fast enough (thereby limiting the UX), browsers are single threaded and they aren’t stable enough. If Google want to challenge Microsoft (or anyone else for that matter) in the desktop space they needed a better platform… Google’s solution is I think much neater – build an open source browser that supports multithreading, fast JavaScript execution and stuff Google Gears into the back end so it works offline." Now that's a good explanation.

In a recent post about offshoring development work, Ryan Carson explains that the way you know when you’ve outgrown a freelance developer is this:

Getting bugs fixed and new features implemented starts taking fricken’ forever.

There’s some interesting discussion on the post – about eastern-European wage rates, about freelancing, etcetera – but there was one elephant in the room that nobody really mentioned, and I really think it’s necessary. And that’s this:

once your application is live, everything will take longer.

Whilst you’re in the build process, you can turn on a dime; you can commit new code at a moment’s notice, change the direction of the codebase or even the application, churn out features at a remarkable rate. And, when something doesn’t work (despite having passed the test suite… which you do have, right?), you patch it and move on. It’s a doozy.

Once you’re live, everything changes. You’ve got an active audience using the site – you might even have paying customers. You can’t afford for a single thing to go wrong. New features are no longer about build it, run the tests, check it in, deploy. Your testing on the development box has to be more fastidious. The integration between new functionality and the existing needs to be really well thought through. The design needs to be seamless with that which exists already. And, if it goes live and there’s still one of those totally unforseen bugs… you need to be ready to roll back at a moment’s notice, and put the feature on hold until it’s ready.

This is not new. Some teams are lucky enough to make many deploys daily; most can muster up daily fixes; some might go to weekly. But the effort that a feature requires post-launch is far more than it does pre-launch.

So it’s inevitable – freelancers or no – that the pace of development is going to fall off a bit post-launch. Hopefully, only a bit – but it’s not going to be the same rate unless you’re extremely lucky. You’ve also got to keep your users in mind, and break them into new functionality slowly.

It’s a hard transition, going from the development site to live. To you, as an owner, a developer, it feels like the same product – so the change in pace is a bit frustrating. And it’s important to keep the pace as fast as possible. Some fixes are critical, and need to go out the door the instant they’re done; others can wait a little longer – a day or two, if necessary – for release. It’s a rare, focused, hugely talented team that can splurge out new features like a machinegun.

Now, I’m sure that the problem is compounded by avoiding maintenance contracts (and so having to re-contract and re-hire) and having developers whose time is precious. But it’s always important to bear in mind that the latency of any web software development shoots up post-launch. So if it does: don’t immediately reach for the outsource button. Take stock, have some patience, and see what the product needs – how often it needs to be released, how often it needs to be improved. And then you can make that call a little better informed.

The other golden rule, incidentally, is never deploy on Friday. I hope the reasoning behind that is obvious.