Coming clean on software ‘scalability’

3 categories to lead you to more explicit assumptions

We hear the term scalability thrown around in different contexts, shutting down many interrogations about why software developers are making the decisions that non-techies can’t possibly comprehend. Surely everyone should appreciate the need to be able to meet increased demands. Growth is what business is after and future-proofing for growth appeals to the aspirations of the defensive as well as to the hopeful.

Unfortunately what it actually means is not particularly clear, even to the software engineers using it. Some may argue that the vagueness of the term calls for eliminating it entirely from your vocabulary. The goal of good technical design and implementation should cover scalability and thus it can be assumed, no?

Well, what it requires can be very different given the context and constraints. Instead, we should refer to specific qualities our software should exhibit over time. How do we identify these qualities? As a start, it would help to be more specific about the type of scalability being considered.

I separate it into 3 categories:

• Operational Scalability — relating to the ability of your infrastructure and technology to be able to accommodate changing operating conditions;
• Functional Scalability — relating to the cost of adding, changing and maintaining product functionality over time; and
• Development Scalability — relating to the effectiveness of increasing the number of people developing the software.

So, are we sufficiently considering these up front? Will the solutions we design meet our real needs, or could we be providing for a future need that won’t ever be? It is hard to say what good looks like when all involved have different perspectives when technology is always changing, and no two environments are ever quite alike. The proof of the pudding is in the eating.

To gain confidence in the design of our solutions, we can take the practical approach and build prototypes — performing tests and running trials. We can also learn from the collective experience and draw on the knowledge of experts, studying the principles and practices that have been shown to work.

Either way, good solutions only become bad when the initial parameters of the design no longer fit. Being explicit about your assumptions can be hard, and stakeholders often prefer blissful ignorance to shared responsibility. Hell, it may mean that we all have to admit that there are things we don’t know. Determining the trade-offs may be so overwhelming that it leads to analysis paralysis. Sometimes it pays to start the work, optimising for scalability later. As long as everyone broadly knows what they are signed up for, they can happily enjoy when their bets pay off.