Pensieri di un lunatico minore

Managing application availability

Applications fail. It’s a truism of the technology world, but how an organization deals with application failures, and the priority they place on stability, is a good indicator of the underlying quality of the code and developers involved. Take this recent posting from the OmniGroup gang:

For many years now we’ve had an integrated crash reporting system. This has helped improve the stability of our applications immensely (often report now start out with “Wow, this is the first crash I’ve seen…”). But, it hasn’t always been clear (especially in the alpha or beta timeframe) how well we were doing on overall stability. We could guess by counting the number of crash reports vs. an estimate of the number of active users, but that wasn’t very convincing.

[...] we can now chart the total number of hours OmniFocus has been running vs. the total number of crashes (reported or not!). As the pool of people testing OmniFocus goes up, or some testers go idle, or some user with large number of crashes isn’t reporting them, we don’t have to wonder as much how that affects our average crash rate.

So now, they can track average hours between issues for all their users. Right now, they’re over 8,000 hours¹ (333 days), and their target is to go a full year. Given there’s a patch at least once a quarter that requires a reboot, that effectively means that it’s unlikely anyone will ever deal with a crash of their application.

¹ Note, they’re not saying each user has a crash each 8,000 hours, but that for 8,000 hours of aggregate use, they’ll have one crash occur. Slightly different, but the only way to do this with a sample set this size.