The latency of software development, pre- and post-launch.

23 February 2007

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.

Future of Web Apps 2007

19 February 2007

A straight-up announcement post here: I’m going to be at Future of Web Apps in Kensington for the next two days. I’m reasonably identifiable (redhead, sideburns, goatee) and I’ll probably have a neck-badge that says “Developer” on it.

I think it’ll be even better than last year’s, in part because it’s spread over two days, and there are more gaps for socialising. So if you don’t see me in the hall, grab me outside it. I won’t be around on the Tuesday night due to prior commitments (The Long Blondes at the Astoria, hurrah) but will definitely be up for much in-pub ranting on the Wednesday. So: do say hello if you’re going to be there, and maybe we can bat some ideas around.

Links & notes for this month