Building World Class Software at uptime

Friday, May 16, 2008

Gordon Ramsay and programmers' egos

If you've never watched Ramsay's Kitchen Nightmares (the British version, not the Fox travesty), you should. Gordon Ramsay visits troubled restaurants and tries to turn them around - sometimes succeeding, sometimes not.

As you watch the episodes, you start to see a few common themes:
  • Chefs cooking for an imagined audience that doesn't really exist
  • Overcomplicated food
  • Egos getting in the way of a quality product
All of this can be translated pretty easily into software:
  • Programmers adding features that make the product harder to use
  • Software that is so over-designed that it has lost its flexibility
  • Beloved design patterns that don't apply to the task at hand.
Today we're getting ready to release up.time 5. I started here at uptime when it was back at version 3, and quickly realised that my first priority had to be simplifying the code base. As the product had evolved over the years, techniques that people had thought were really cool at the time were just getting in the way; if they had used the direct, obvious methods, it would have been much easier to change them with the product's needs. A few months and a lot of hair-tearing later, we'd managed to simplify most of the main areas, and by now, though I say it myself, the code base is really quite good.

Ramsay's advice for pretty much all the restaurants he visits is this: Stick to simple dishes with good, fresh ingredients. He applies this rule to small "hole in the wall" places right up to French restaurants with Michelin stars. And the software equivalent of this looks something like:
  • Keep the design obvious so that it can change later on;
  • Focus on end-user features ("ingredients"), not programming techniques.
That is: if you're building a whizzy new database library before there's an easy way for customers to get your product up and running, there's something wrong - and that something is that your ego is getting in the way. Don't let it happen to you!

Labels: ,




Friday, May 9, 2008

Monitor This!

In case you were wondering what the inside of one of these looks like:

There are pictures over at Royal Pingdom. Very tasty.

Labels:




Saturday, April 12, 2008

Perl is here to stay

It's ugly, it's dated, and only its mother could love it, but Perl isn't going away. Actually, I have a soft spot for the language; it's the fastest and easiest way to do a lot of small jobs on the command line, and the library support is great.

Labels:




Java 6 update 10

The upcoming Java 6 update 10 isn't just a point release - it adds a lot of new features:
  • More modular JRE downloads: if you don't need the entire JRE feature set in your app, you can break it down to just the pieces you need.
  • A new Look&Feel module called Nimbus. Unlike Metal, it looks nice.
  • Much, much better startup performance, which has been my longest standing complaint about the platform.
More analysis at Ajaxian.

Finally, a release to get excited about!

Labels:




Tuesday, April 1, 2008

If there are epigrams, there must be meta-epigrams

In 1982, Alan Perlis distilled what he had learned from a lifetime of programming into 130 pithy quotes. TWENTY FIVE YEARS AGO. And most of them are still relevant.

Some of the best:
  • Syntactic sugar causes cancer of the semi-colon.
  • It is easier to write an incorrect program than understand a correct one.
  • If you have a procedure with 10 parameters, you probably missed some.
  • If a listener nods his head when you're explaining your program, wake him up.
  • Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers.
  • There are two ways to write error-free programs; only the third one works.
  • In English every word can be verbed. Would that it were so in our programming languages.
  • Making something variable is easy. Controlling duration of constancy is the trick.
  • If there are epigrams, there must be meta-epigrams.



Friday, March 28, 2008

How to undelete files on Linux

Carlo Wood explains how to undelete files on Linux ext3 file systems. The really cool thing is not that you can do it, but that Carlo decided not to believe the received wisdom that it was impossible, and went and figured out how to do it anyway.

One of my mantras is "I don't mind you complaining that it can't be done, as long as you don't bother the people who are doing it".

Labels:




SLA Inversion

So you’ve launched your new enterprise web site, and you’re so confident with your fully redundant web architecture that you figure you can provide a five-nines SLA - 99.999% uptime, or 5 minutes downtime a year. After all, what can possibly go wrong?

Welcome to SLA inversion, where a 99.999% available web service depends on a 95% available DNS server. Or a 98% available Internet connection. If your users can’t do work, it doesn’t matter why - they don’t care that your web application is still able to process transactions; they don’t appreciate the difference between application failure and DNS failure.

As it happens, this topic is close to my heart: I run a few cancer support mailing lists, and one day I decided to switch the domain name hosting provider. What I didn’t realise was that the new registrar wouldn’t let me edit the zone file until the domain transfer had completed, and that left me dead in the water for several hours: requests to the web site were going to the registrar’s default page. No matter that the web site and mailing lists were just fine; the point was that nobody could reach them.

Whenever you’re monitoring for a service level agreement, you need to follow a few important rules.

  1. Measure as close as you possibly can to what end users will see. That generally means running synthetic transactions at a minimum: HTTP for web applications and test emails for email services.
  2. Take time to think through all the services your users rely on, and make sure they’re monitored, implicitly or explicitly. For example, are there routers outside your control on the path between you and your users? If so, find out what SLA, if any, is in effect. You can’t provide a better target than the weakest link in the chain.
  3. If there is a weak link controlled by your customer, make sure it’s explicit in the SLA contract.

Service level agreements are all about avoiding nasty surprises: taking a bit of time up front to think through how you might be caught off guard will benefit you, and more importantly, your users.

Labels: