Ideas From Another Field

The microservices field gains some insight from other fields of study in this
collection of ideas that have influenced software architecture and development
methodology.

Applying concepts from one field or a book in another field has been a common
pattern in modern technological development. The spirit of antifragile, a recently
coined word, has found its way in the implementation of microservices. In the quest
to make software programs antifragile, the way forward is to build intelligence
into them. A couple of other examples are: i) The law of diminishing returns from
economics which applied to parallel computing becomes Amdahl's Law. ii) I surmise
that the Agile board in the Scrum methodology is the application of the Hawthorne
Effect. Cross-pollination of ideas is one of the mechanisms of innovation. And, as
we found out recently, learning transfer is the way Elon Musk follows to become
such a prolific technocrat and businessman.

My essay ends here.

The following part is just a series of quotes that I have stringed together; the
quotes and my brief notes elaborate the summary given in the paragraph above. So if
you are interested in the details, read on.

Image title

It was a very interesting moment for me when I bumped into antifragility while I
was reading up on microservices. In his book Antifragile: Things That Gain From
Disorder, Nassim Taleb defined his concept as: "Antifragility is beyond resilience
or robustness. The resilient resists shocks and stays the same; the antifragile
gets better. This property is behind everything that has changed with time."

Adrian Cockcroft elaborated on this definition while applying it to micoservices.

"The point of antifragility is that you always want a bit of stress in your system
to make it stronger" (source).

At Netflix, they built a Simian Army that actually tests systems running in
production. One of them is Chaos Monkey. As the Netflix blog states, Chaos Monkey
is "a tool that randomly disables our production instances to make sure we can
survive this common type of failure without any customer impact. The name comes
from the idea of unleashing a wild monkey with a weapon in your data center (or
cloud region) to randomly shoot down instances and chew through cables - all the
while we continue serving our customers without interruption. By running Chaos
Monkey in the middle of a business day, in a carefully monitored environment with
engineers standing by to address any problems, we can still learn the lessons about
the weaknesses of our system, and build automatic recovery mechanisms to deal with
them. So next time an instance fails at 3 am on a Sunday, we won't even notice."

Bilgrin Ibryam compares and contrasts antifragile system from fragile systems and
suggests things that need to be in place in order to build antifragile software: "A
fragile system is difficult to modify, and cannot cope with a changing environment.
Even if it provides some value when used in a stable non-changing environment, when
faced with further stress and change, it quickly turns into a liability. Many
organizations have applications (mainframes for example) which are impossible to
change, very expensive to maintain, but still running on high cost as they are very
critical to the business. An antifragile system is created with change in mind and
it feeds from stress and change. It is much harder to create such a system (it is
not a software system but a social-technical system) but once it is in place, it
drives the business based on change, and even creates the change. But once you put
an appropriate organizational structure, the right tools and culture in place, then
you can start gaining from change. Then you can afford having Friday Hackathons,
then you can start exploring open source projects and start contributing to them,
then you can start open sourcing your internal projects and benefit from a
community, and generally be the change itself. And why not the Netflix or the
Amazon of tomorrow."

Extending this idea further, Vivek Juneja posits about the future: "The future is
to allow the applications to be able to decide for themselves in dealing with
failure, chaos, and uncertainty. This requires us to build intelligence back into
the system that is ever growing and continually learning about its surrounding.
That will make systems to be self-aware and truly anti-fragile."

This method of injecting ideas from other fields can be seen in Amdahl's Law. In
economics, the law of diminishing returns states that "in all productive processes,
adding more of one factor of production, while holding all others constant, will at
some point yield lower incremental per-unit returns."

When applied to parallel computing, the law of diminishing returns becomes Amdahl's
Law: "Amdahl's law is a formula used to find the maximum improvement possible by
improving a particular part of a system. In parallel computing, Amdahl's law is
mainly used to predict the theoretical maximum speedup for program processing using
multiple processors. It is named after Gene Amdahl, a computer architect from IBM
and the Amdahl Corporation. This term is also known as Amdahl's argument."

To explain the law in other words: "The incremental improvement in speedup gained
by an additional improvement in the performance of just a portion of the
computation diminishes as improvements are added. An important corollary of
Amdahl's Law is that if an enhancement is only usable for a fraction of a task, we
can't speed up the task by more than the reciprocal of 1 minus that fraction"
(source: Computer Architecture: A Quantitative Approach by John Hennesy & David
Patterson).

More specifically, this law "is used to predict the theoretical maximum speed-up of
program processing using multiple processors."
The formula is:

Image title

Here's another example. I surmise that the Agile Card in Scrum is a way of
implementing the Hawthorne Effect, which is: "The Hawthorne experiments were
originally designed by the National Research Council to study the effect of shop-
floor lighting on worker productivity at a telephone parts factory in Hawthorne.
However, the researchers were perplexed to find that productivity improved not just
when the lighting was improved, but also when the lighting was diminished.
Productivity improved whenever changes were made in other variables such as working
hours and rest breaks. The researchers concluded that the workers' productivity was
not being affected by the changes in working conditions, but rather by the fact
that someone was concerned enough about their working conditions to conduct an
experiment on it."

The basis of all human emotions is insecurity. Feeling important is the first
defense against insecurity. Now whether the sense of importance comes from within
or outside, the impact of someone noticing our work goes a long way to add to the
feeling of being important. In the field of agile software development, and in
particular in Scrum, an important tool is used: the Agile board which is shown
below:
In my view, the Agile board is an example of applying the Hawthorne Effect in
software development.

This pattern of applying ideas and concepts from one field in another, which can be
termed cross-pollination, is one of the ways to innovate. In his book The Ten Faces
of Innovation, Tom Kelley discusses various personas that innovate. One of them is
the Cross-Pollinator.

He describes: "The Cross-Pollinator draws associations and connections between

seemingly unrelated ideas or concepts to break new ground. Cross-pollinators can
create something new and better through the unexpected juxtaposition of seemingly
unrelated ideas or concepts. They often innovate by discovering a clever solution
in one context or industry, then translating it successfully to another. For
example, it was a Cross-Pollinator who transplanted the idea of a piano keyboard
from the musical world to create early manual typewriters in the business world,
which of course evolved step by step into the electronic keyboards we all use
today.
Orville and Wilbur Wright cross-pollinated materials and mechanisms from the
emerging bicycle industry to build their first powered aircraft" (source: The Ten
Faces of Innovation, by Tom Kelley with Jonathan Littman).

Elon Musk's entire knowledge acquisition methodology is a form of cross-

pollination, called learning transfer. Entrepreneur & author Michael Simmons
describes: "Starting from his early teenage years, Musk would read through two
books per day in various disciplines according to his brother, Kimbal Musk. To put
that context, if you read one book a month, Musk would read 60 times as many books
as you. Musk is also good at a very specific type of learning that most others
aren't even aware of - learning transfer. Learning transfer is taking what we learn
in one context and applying it to another. It can be taking a kernel of what we
learn in school or in a book and applying it to the "real world." It can also be
taking what we learn in one industry and applying it to another."

So, the next time you come across a seminar on cognitive psychology or a book on
marine biology, it would be worthwhile to attend the seminar or read the book.