Availability is a Feature

Normally we class availability as a non-functional requirement of the systems we build but I’m starting to think that’s a mistake because often when we get to project scheduling it’s forgotten. We allocate time, budget and resource to make sure we’re feature complete, that this button or that tick box is visible or that we can gather credit card details but rarely do we treat availability similarly.

Unlike a functional requirement which has some form of physical manifestation availability tends to be invisible dotted around the system in all sorts of different places from architecture and code to hardware. In contrast real features are a logical sequence of inter-linked pieces of code and design that are naturally traceable from entry to exit point. No entry point means the feature is not complete and this can be trivially determined prior to deployment. The first time we know availability isn’t “feature complete” is when our deployed website is down.

Worse, with every single feature or subsystem we add and the corresponding increase in load and size of dependency graph there’s an increased chance that we compromise availability. This can make for some serious growing pains where we add more features, attract more customers and thus more load all the time paying no attention to availability until it’s too late.

Consider the wiring in a house, we add a garage which needs lighting, maybe heating and a motor-powered door. Then we build an extension for guests, more lighting, heating and wall sockets. Eventually, something gives, maybe it’s a piece of wiring that should’ve been replaced or a bad junction but the net effect is to risk burning out all the wiring in the house. Replacing all the wiring would’ve been hard enough without the extensions but now the house is twice as big and the wiring is four times more complex. Worse, we cannot do a piecemeal upgrade instead we must replace all the wiring at once and until it’s done we can’t have all the heating on or we can’t cook at the same time as using the garage.

Like the wiring, availability needs constant and sometimes significant attention and putting the work off can lead to significant cost down the line. Similar arguments apply to other non-functional aspects of our systems such as scalability (it’s no good adding features that attract more customers if the system won’t cope with the additional load).

In light of the above, I believe it might be better to classify availability as a feature if not the feature. After all if the system is not available, none of the cool features we’ve implemented are worth anything because they can’t be accessed. It might also be a catalyst for discussion (especially amongst non-technical staff) of availability’s costs and benefits as compared to those of other features leading to improved strategic thinking.

Relevant Links:

Technorati Tags: , , ,

2 Comments

  1. Ok I couldn’t help but comment. I view a feature and availability as a classic chicken and egg problem, but I think the feature always wins. This profoundly bugs me, because I work on availability, but I’ve rationalized it to this: Availability can still sell at a ‘good enough’ where good enough can be astonishingly bad. Features though, don’t seem to have that luxury. On some level it has to offer something good enough to sell. My son plays all kinds of online games with his friends that validates this in my mind time and time again.

    The first guy that I had that taught me how to develop still resonates with me … “Make it work, make it maintainable, make it reliable, make it fast. Repeat.”

  2. Hi John,

    “Ok I couldn’t help but comment. I view a feature and availability as a classic chicken and egg problem…..”

    I think that “make it work, make it maintainable” is acceptable when you start off but particularly in the case of websites I think this bias changes over time. Once you have a bunch of paying users you want to keep them – availability can have a significant impact on this as has been documented in respect of MySpace.

    I’d like to explore this more so let’s consider this example – once I have a database with all the features I require, how much do I value reliability and availability? Do these things become more or less important as the amount of data (value) in the database grows? Do these things become more or less important as I gain more dependencies on the database?

Comments are closed.