How fast is your turnaround time?

There's currently a question been posted on AskSlashdot which asks How fast is your turnaround time?:

...Overall, we manage to get a 'bullet-proof' patch in about 4-5 weeks (from coding->QA->Build/Packaging->shipment), which I consider not so bad. But the other day, we got an urgent request from our support team to come up with a decent fix in 48 hours. I think they're a tiny bit unrealistic. So I wanted to get feedback from my peers: are we doing that bad?...

Esendex's core product is an online service, which means our customers don't need to install anything. So realistically I'm not in a position to comment on this particular matter. We don't need to go through a packaging stage, and we can be pretty confident that we won't have installation issues as we own all the server hardware the system runs on.

But looking at the timescales involved here puts a few things into perspective. If one of our releases introduces a critical error (by which I mean that people can't use our service anymore), then the entire business rests on getting that error fixed. In these cases (thankfully they are few and far between) 48 hours is just too long. In fact much too long.

If we're in a position where we have customers not able to send messages then our SLAs make us contractually obliged to fix the problem within 4 hours. I remember being alerted to one such error a few years ago at 2am on a Sunday morning. By 5am that day the system was patched and fully operational again.

A quick turnaround stems from the design methodology you are using. With XP we learn to expect change, so we make sure that we don't code ourselves into a corner. This makes new requirements easy to add, but it has the side effect of making most bugs easier to fix as well.

Of course, there's always going to be the possibility that your design is so flawed that it's impossible to fix a certain bug. In these cases backing out of an update is sometimes the only feasible option.

All non-trivial software contains errors. If there's one truism about software development, that's it. The important differentiating factor is the severity of those errors. A truly business critical severe error needs to be fixed as fast as possible, and if it means late nights then so be it.

As professional developers we're paid to release working software, and if that software doesn't do its job then we haven't done our job.