On Being the Right Size

"...a large change in size inevitably carries with it a change of form..."

On March 1926, John Burdon Sanderson Haldane published his essay titled “On Being the Right Size”; in it, Haldane discusses several aspects of animal anatomical systems and functions as essentially linked to and influenced by animal’s size.

For example, assuming a human person being, say, about ten times taller than an ordinary grown-up, will imply that the bones’ cross-section will grow about x100, but that person’s weight will be x1000: Every square centimeter of his bones will have to carry tenfold the weight, hence—such person’s skeletal system will not be able to support such a huge body; it will break.
From another perspective, that of keeping body warmth, being ten times smaller than the usual person will necessitate a food-supply proportional to the much-reduced surface (rather than weight); such a person (?) will have to dedicate most of the time to finding food and eating it…
These reasons, by the way, quite undermine a plausibly physical existence of neither Lilliputians nor Brobdingnagians¹.

Source

Haldane includes also for organ sizes, such as the eyes and the brain.

And a question rises while reading through the nice examples:
What if we start ‘small’, and create a ‘prototype’ of an elephant, delivering first its cousin, the rock hyrax?
Can the small hyrax be scaled up?

“Sup, cuz…?” (Source)

Gartner defines Scalability as—

…the measure of a system’s ability to increase or decrease in performance and cost in response to changes in application and system processing demands…

This definition is practically applicable to any domain, as its associated concerns.

Often, when considering Scalability from performance perspective, I present some engineering examples. One favorite [of mine] is the Super Bowl's 'Big Flush' myth, which draws attention to the question of utilities’ planning for sudden surges, their cost and function.
Another example [a real one!] is the route of Israel’s Highway 20 through Ayalon river: The railway was lowered to pass through it. In winter of 1991-1992 the river had flooded the route². Designers claimed than, that the route was well-planned, and such a flooding occurs once in a century; sure enough, it was flooded again on the next winter, and three time after that (true to today).

In Information Systems context, Scalability is much about assuring the system may be able to sustain increase of [at least] three parameters:

• Volume (and integrity) of data transferred and processed

• Number (and complexity, and resilience) of handled transactions

• Evolving and modified processing requirements

All these should be possible with no (or—as little as) usage impact, or—in the worse case—redesign.

This implies, that Scalability should be accounted for with early design stages, and should also be included with testing as soon as functional components are being validated.

Some criteria require special attention, as they imply additional setting and maintenance effort, for example—

• Concurrency or distributed computing [as horizontal scaling] may be not ‘hard’ to define or realize, but might be a bit challenging in testing.

• Vertical scaling (e.g.—with additional memory or processors) should be possible.
  This is much enhanced by virtualized environments, which might raise a concern: Through development, product teams might find it quite easy and convenient to upscale their environment, but—

  • Will the customer be able to sustain the costs of similar configurations?

  • Not less important: Is upscaling really necessary?
    Can design be improved to contain growth and avoiding this scaling?

  • What are the risks of an upscaled system?

• Network characteristics are also of interest; any traffic analysis [and testing] should be able to address both ‘network agnostic’ processes and the impact of network issues on availability and performance.

• Performance tests should be enhanced to include for [at least] Load, Stress, and Soak cases, which oppugn system’s data integrity, process continuity, and service availability.

• Another aspect, which often escapes design and development, would be the cost of resources and associated maintenance or scalability expenditures: This includes both the ‘price’ of meeting growing demands and the possible ‘penalty’ on service failures…

Indeed, above spell some lucubration for designers and testers, as predicting future trends or changes in the absence of proper preliminary analysis is [almost] impossible³. Such hardships were, after all, one of the Agile Manifesto drivers…

The message of this short post⁴ is, that scalability is a system design risk: Failing to understand the system’s evolutionary path, expected growth patterns, or preparing for such, will—essentially—lead to either collapsing hyraxes or starving, neurotic elephants…

Whereas design for scalability is hard—testing is… [head scratched…]⁵…well…

• Validation, assuring that the “…system meets the needs of the customer and other identified stakeholders…” is, obviously, an issue, as those needs are not easily definable upfront⁶.

• Verification, evaluating “…whether or not …[the] system complies with a […] requirement, specification, or imposed condition…” is also baffling, for similar reasons⁷…

“…an elephant turning somersaults or a hippopotamus jumping a hedge…” (👆🏻)

1. My deepest thanks to my great teacher, Victor Sela, who took us through the details in his physics and mathematics lessons, by the essay his wife, Lea, taught us in her respective class.
A teacher for life.

2. Standing on the hill, where the old railway station was, one could see a little circle down below, in the water.
It was the locomotive’s funnel.

3. Most designers, developers, testers, product managers, stakeholders, and essentially—anyone involved or interested in a system—do not [usually] have any prophecy skills.

4. More detailed posts will follow; do drop your comments and suggestions.

5. Below V&V definitions are by PMI’s PMBOK.

6. Zoom downloads went up from 7.86M on 4Q19 to 116.14M on 1Q20, to 331.32M in 2Q20.
Not sure Zoom’s customers or other identified stakeholders could have suspected COVID…

7. The problem with unwritten rules is, that you don’t know where to go and how to erase them…