Ideas From Another Field
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.
Join the DZone community and get the full member experience.Join For Free
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.
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:
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.
Published at DZone with permission of Mahboob Hussain , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.