An American systems scientist, Peter Senge, said that.
He could have been talking about developers who think liquid software (i.e., continuous updates) is still conceptual, something that’s not ready for prime time. They may say, “Oh, that would be really swell, but I don’t think it’s possible.” The thing is, though, it’s already being done. It’s not future think, it’s now!
But I get it. Software development isn’t easy. Creating and sustaining a product takes lots of dedication and focus. When systems are already in place, it can be daunting to consider supplanting those with new ways of developing, fixing, and improving software. Lots of developers don’t feel they have the time or energy to learn about what’s out there…somewhere…now.
Still, sooner than you might imagine, liquid software will become the norm. It’s inevitable – for a whole host of reasons that are less important than self-interest, self-preservation, and good old bottom line money-making.
Why not gain, without pain?
Is it not true that almost every time the software industry goes through changes in processes, constraints, and the essential ways we work, it’s been a frustrating struggle? Of course it is. Why? Because there are rarely templates, best practices, or well-established techniques that are part of the average developer’s toolkit.
What if I told you that a significant objective of the liquid software revolution that’s already begun is to solve this problem? What if I said that liquid software is introducing automated systems and standardizations into the development environment that will result in enormous efficiencies designed to eliminate these burdens?
Have I caught your attention?
Wouldn’t it be better if boring, repetitive, and thankless tasks were handled securely and reliably by machines? And wouldn’t that translate into more work hours and brain power that developers could dedicate toward the generation of greater innovations? And wouldn’t that give companies making the transition to liquid software a competitive advantage?
Would any end-users be opposed to receiving seamless, transparent updates with zero downtime? Would enterprise users not like bugs eliminated and new features delivered as quickly as possible? Wouldn’t all of this be a selling point? Wouldn’t that mean more bucks in the bank for those who take the first steps toward liquid software now, instead of running like crazy to play catch-up later?
It’s a fact: Machine control improves software development
Still not convinced?
Then let’s talk about continuous integration (CI) and a CI server like Jenkins. Before Jenkins, there were all manner of end processes that had to be manually executed. Companies used to set aside one to two months for entire teams to do nothing but pre-release integration. Then, new systems were created and, very rapidly, CI was in common use. Those who made the switch know from direct experience that the new way is better. The ones playing catch-up today are those who didn’t think they had the time or energy to devote to learning about and transitioning to CI and continuous deployment (CD). They are now paying a price for lagging behind.
Today, any software firm worth its salt has machines that are already controlling numerous activities and offering solid protection for and reliable feedback from the systems to which they are attached in a real CI/CD environment. Does this describe the circumstances in your software development shop? If it does, when did you get on the CI/CD train? Were you an early adopter or did you hold back? If you held back, what were your reasons? Do you acknowledge that you’re better off with CI/CD than without?
If you came late to CI/CD, were your reasons for not adopting those systems and practices the same reasons you have now for not pursuing liquid software?
We’ve made a great leap forward with CI/CD and we’re experiencing the tangible benefits of that leap. Why wouldn’t the same hold true for liquid software? Major industry players such as Google, Netflix, and Amazon are already profiting from the benefits of moving to liquid software, like the capability for continuous updates.
It doesn’t need to be a great leap for mankind, just start with that first step
If you’re intrigued, let me encourage you further: Achieving continuous updates is not as difficult as you might think. Accept that it’s possible, not just for big firms, but for software development organizations of any size. Take a few, small steps forward (just as you once may have done with CI/CD) to identify the specific impacts that liquid software will have on your software processes, software environment, framework, code, tests, and so on. Your objective, of course, is to produce positive outcomes. So, start there. Don’t ask, “How do I implement liquid software in my company?” or “What will it cost?” Ask, “How will liquid software specifically help my firm to achieve greater productivity, security, service, and creativity?”
Then go to the next level. Explore continuous updating for your stateless services. Look at how you could continuously update your REST API, and how you could apply continuous updates to your data, data access, and data persistence layers. For each, add the constraint of zero downtime and a high availability environment.
Next, consider the things you’re doing now that make it impossible for you to have continuous updates in place. Look at what you’re doing when updating persistence or data layers. Probably you’re needing to shut everything down, perhaps on a quarterly basis. Wouldn’t you prefer to execute these updates continuously and without downtime?
If the answers you get inspire you to go further, remember that getting from where you are now to a liquid software future is a process that will take place in parallel with existing processes. This is typically done on the side, modifying your infrastructure, frameworks, and deployment model, as well as the final runtime and runtime environment. But nothing stops while the transition is occurring.
And a final thought: Leapfrogging. The cell phone is a pre-eminent example of this phenomena. In many developing countries, average citizens never went through the phase of wired telephony and then the transition to mobile. They jumped (or leapfrogged) over the earlier technology to the modern one. In software development, we’re seeing this with greenfield projects that are using state-of-the-art DevOps technology and design for what are called cloud-native applications. Equally, those who can afford to do so, such as big banks and large industries, are creating side projects (essentially just small, startup enterprises) to address specific issues. These are not adopting old practices, even if those practices are still in use at the parent firms. They’re leapfrogging into new technologies, such as liquid software.
Maybe it’s time to ask your software development innovator if continuous updates are right for you!
