The impact of a blocking paradigm vs non-blocking Reactive software.
A Forbes survey indicates that too much corporate money is evaporating into the Cloud, to the tune of 30-35%. Some consider the expense of tuning software for efficiency a serious drag on productivity—a price too high. How can developers produce efficient software without taking extreme hits on productivity?
Admittedly, developing software that is among the most efficient is not a mainstream concern. This is not for good reasons, which include lack of knowledge, complacency, and dismissing the need for self and business improvement by addressing those limiting characteristics. Many simply don’t see or acknowledge the costs of inefficiency.
Unfortunately not an overwhelming number of software developers are business minded. The tech-only developers often think that business-oriented people should be more technical. This is unrealistic. Although every good software developer is capable of possessing a measure of business mindedness, and even business savvy, not all business people are capable of becoming good software developers. Yet, rather than embracing business thought, tech-only developers consider their increasing technical prowess as the means to keep themselves employed. This is in conflict with their own interests, however, if their current job disappears due to the business facing costs that greatly impact net revenues. More to the point, gaining technical prowess in software efficiency is a means of delivering solutions that are less costly and thereby take aim at threats to business profit.
Come on tech people, you’ve got this. Be business people, too! It’s more you than you think, and making a business a success is fun and rewarding!
It may be difficult, however, for some to justify what appears to be novel approaches, practices, and techniques. Unless it is currently mainstream, there isn’t much motivation to seriously investigate with the intent of adoption. Those disinclined or reluctant to take risks will likely consider the unfamiliar to be too risky to their future success. Others will avoid what requires them to move out of their comfort zone. It requires thought leaders to reshape and motivate the thinking of the overall industry.
But why might developers see a different, yet more efficient approach, as dangerous and even threatening? Those who refrain from the use of the most efficient architectures, programming, and related tools, are generally concerned about the learning curve being too steep, and that they’d be risking failure with the unfamiliar. After all, they didn’t learn much about such techniques in school, if anything at all, and they haven’t read or heard much about it in the industry news.
Although a learning curve is indeed required, it’s not as steep as most think. Yet, that is not actually the point at all.
In actuality if we were required to learn software development techniques to achieve runtime efficiency because the industry were to move in mass in that direction, we could no longer be employed in challenging work if we didn’t learn the techniques. Sure, we could probably find work in maintaining the inefficient code that we have known for years and that has kept us in our safe zone. Yet, we should not expect much more.
Imagine what it will be like when not developing software for maximum efficiency is like knowing COBOL in the 1980s, but not seeing the need to learn groundbreaking, newer and promising techniques, such as object-oriented development. Imagine those who used a waterfall process for a decade or two, and when hearing about agile, thought it sounded like chaos and that it could never lead to success. In both cases there were and are casualties of their (in)decision.
Although developers can now make good money maintaining incredibly messy, decades-old, COBOL code, this is due to the enormous shortage of COBOL developers. Why? Because few over the past many years have seen any future in it. Would you choose to work in COBOL even if the money is good? Probably not, otherwise there would not be such a shortage of COBOL developers. The programmers who wrote all that code probably have grandchildren, or even great-grandchildren, or are no longer with us at all. That’s why the companies ingrained in COBOL systems must sooner or later find replacements for those systems. There are now virtual banks innovating in order to replace those archaic banks all together, and to be acquired by the ones who can admit the inevitable.
While some remaining developers may feel entirely comfortable with waterfall software processes, what is the likelihood of getting a future job if they don’t know or are unwilling to learn some form of agile? Even though many have dragged agile astray from its roots, those retaining the balance of simplicity of use are successful. The likelihood of big upfront design having a resurgence in the industry approaches zero.
At some point in the near future, the same kind of eventuality will be faced by developers who don’t know or are unwilling to learn Reactive software development.
So, when developers actually face that point of reckoning, what will they do? They will just learn Reactive, because their relevance as a developer will depend on it. Even so, it is certain that their learning would not end with the rudimentary. Like the recent wave of “I am an expert with Kafka,” and “I am an expert with Kubernetes,” suddenly the very developers who resisted and rejected Reactive will feel the dire need to declare themselves experts with it. It would lead to an explosion of those claiming to have the corner on software efficiencies with Reactive architecture and programming.
Think, however, of the advantages of learning Reactive now. Claims of knowledge and experience would have real substance. Knowledge will actually put the current learners—hopefully you—in that situation when Reactive is at its highest point of demand.
A cognitive bias kicks in when people need a justifiable reason to save mental energy. When you find yourself being afflicted by mental laziness, attack it though determined, goal-based learning.
Being unwilling to learn Reactive software development now, due to its “learning curve,” rather than learning when it becomes urgent to do so, is an example of a cognitive bias. In essence a cognitive bias kicks in when people need a justifiable reason to save themselves from expending mental energy.
Saving ourselves mental energy often occurs when we encounter something new or face a problem that we prefer not to think about. In fact, we will actually choose a more familiar, yet complex, way of doing something over choosing simplicity. That’s generally because making things that are as simple as possible requires more thought than pursuing complexity because it is familiar and the result of automatic thought. Fight those normal human inclinations with a determination to work past the pain to reach the gain—new and valuable knowledge.
To reinforce that the Reactive learning curve is not too steep, those who have already embraced Kafka and other messaging and streaming tools have taken a first step toward Reactive.
This is so in all kinds of human situations. A person will not change some poor eating habits because it takes thought and determination. Thus, most in that situation would simply stick with what is familiar and even be drawn to new food offerings with similar characteristics. This is even the case when a simple diet that is composed of the right foods is far more healthy for them. In many cases change doesn’t occur until a person learns that they will die sooner than a normal life expectancy unless they change to a healthy diet. Think about the trouble and risk that would be avoided if such a person adopted healthy eating in their younger years because of being mindful of their future.
How does unhealthy vs healthy diet overlap with Reactive? Building software with familiar tools that offer a thread-blocking paradigm is ultimately bad for the health of software as it pertains to scale and related costs. It is relatively simple to change that, but the thinking of the software developers addicted to a blocking paradigm will see it as too much thought and change. It will likely require someone in a leadership role to enforce change because the costs of inefficiency are unjustifiable. The eventual demise of inefficient systems may lead to necessary change, or to the death of business operations remaining heavily vested in them.
The fact is that computer software design is, as of the year 2020, 17+ years behind the design of modern microprocessors. It’s literally an upside-down comparison. If you were to return to this document a year from now, it will certainly be 18+ years behind, because thought leaders in this area cannot possibly move the dial far enough in the right direction in only 12 months. It’s going to require a sea change in industry mentality driven by true software futurist-leaders to enlighten the millions of less mature ones. You can be one such futurist software leader.
Note that this is not a prediction. It’s simply a matter of what is required to cause enormous change. Even so, it’s not entirely up to software leaders. When business leaders realize that their money and that of investors is being unnecessarily consumed—possibly even squandered—because developers are complacent with changing toward efficiency, this will surly result in an irresistible drive toward change. Be the software leader that introduces your organization to the future of business-driven computing at scale.
A few years ago it was common to hear that CIOs didn’t care about the cost of the Cloud. They just wanted to unburden themselves from the complexity and monetary costs of datacenter and on-premise computing. Yet, a few years down the road, those same CIOs who didn’t care about cost are now rethinking that decision. They have realized that the Cloud can be or has even proven to be far more costly than was previously understood.
Returning to the Forbes survey mentioned at the outset, consider the cost of a cloud-based enterprise being 30-35% higher than necessary. The result is that too much corporate money is evaporating into the Cloud. It’s reported as being mostly due to sloppiness. What if executives learned that part of digital transformations could lower those costs not only by 35%, but a far greater percentage of their current overall costs, by running more efficient software systems?
If the problem was not considered urgent even with these discoveries, that is likely to change relatively soon if it has not already begun. Over-spend on the Cloud is even more disturbing now in the new era of COVID-19. Every Dollar, Euro, Pound, Franc, Krone, Shekel, Yen, Dirham, Dinar, Yuan, Rupee, Real, Rand, and Peso being spent is a glaring source of budget impact. The excesses must be addressed, and software leaders must spearhead the efforts through information and education.
Think of the benefits to the health of the computing industry. If you, after all the above, are still on the fence on this argument, suspend disbelief for just a moment. Place yourself in the position of being very concerned about computing health, because software is not only eating the world, the way it is designed and deployed is eating your business profits. Now, you learn that by adopting Reactive as a primary means of software architecture and development, there are real, extended, fiscal benefits.
- Reactive makes full use of hardware CPU power, resulting in the most efficient software
- Efficiency reduces the shear amount of hardware required to run the software
- The reduction in required hardware reduces monetary expenses
- The reduction in monetary expenses increases net revenues
- The reduction in required hardware reduces the environmental impact of software
- The reduction on environmental impact of software increases quality of life
Although Reactive is not currently a household word for executives and software development practitioners, every business founder, board member, executive, and investor understands that reducing expenses leads to gains. Not to be forgotten is that software efficiency is a first-order environmental concern. If you lead in the direction of Reactive, your efforts will not go unrecognized or unappreciated. You will be the face of the inefficiency resistance and a pioneering change agent toward global software efficiency.
