Eachan's Space

Last week I posted about the basics of building megaprise software and the six principles I believe should be reflected in every product you deliver [if you're in this category].  For organizations like ours a good to describe each of these principles is a really simplified agile user story; it’s a format people are already intimate with, practiced at delivering against and I personally like the fact that the basic clauses (as a… I want to… so that… as proven by…) force a habit of thinking about the business value of an idea rather than just raw requirement.

So how would a user story for scalability look?  Let’s start with:

As the CTO, I want to look out onto an infinitely scalable set of products that can be grown cost effectively with customer demand, So that system capacity never restricts business growth.

Hmmm – how do we cater for the “as proven by” clause?  When developing a feature from a user story this is one of the most important clauses as it is the primary reference you use to know if you’ve done a good job or not – but how can you tell if you’ve done a good job of scalability?  The hard data (design, performance thresholds and capacity) will be different in every system, feature and project so how about taking the principle a little further with some questions you can ask yourself – essentially thinking exercises you can use to judge how well you’ve reflected the principle of scalability in every feature you roll.

That would give us:

As the CTO, I want to look out onto an infinitely scalable set of products that can be grown cost effectively with customer demand, So that system capacity never restricts business growth, As proven by appropriate and justifiable answers to the scalability questions.

Note the keywords here; appropriate and justifiable.  You’ve got to keep in mind that there might not be business value in making every single feature you roll infinitely scalable – what if it is a temporary feature used only for a fixed time like a migration tool or a site aimed to take advantage of a single event like an election or sports championship?  In these cases you’ll probably have a fixed demand for capacity and a finite lifetime all known in advance.  Keep it appropriate.  A good practice to help make sure you always think of the most appropriate solution is to practice explaining it to yourself.  If you can’t convince yourself you’ve catered for it then you’ll never convince me and you will most certainly never convince your customers.  Keep it justifiable.

What do you challenge yourself with?  What questions do you need to answer?  A good start would be:

• How will I scale this again and again?
• What is the marginal cost of increasing capacity?
• Will it scale cost effectively?
• Does it perform adequately?
• What will happen if it gets hit 1000 times per second instead of 10?
• What will be the effect on shared data/infrastructure if its usage doubles?
• How do we measure usage and remaining capacity?
• Can I do this in fewer hits?
• Can I do this with less memory?
• Can my feature deliver its functionality in fewer cycles?

Think about these things as you code and you’ll be well on your way to making highly scalable software.