In Part 1 of this post, we imagined the world through the lens of an average person in 1920s versus the turn of the century. We talked about the acceleration of technology adoption, the exponential pace of change, and how companies have to create bespoke solutions to more quickly to achieve business outcomes and increase adaptability. Of course, bespoke solutions are hard to create due to time and cost pressures.
We left off by imagining a future five years from now and asking whether automation is a potential answer to building bespoke solutions more effectively. In Part 2 of this post, I will explore automation and its growing role in the software engineering industry. I will highlight a mindset shift on the horizon, one that may result in a future when the majority of software construction is not done by humans, but by software itself.
Automation Everywhere
It is a fascinating exercise to think of the world five years from now, especially in an environment when automation has moved past simple, low-skill tasks. It is not inconceivable that we will see:
- Arial drones delivering packages to our doorsteps
- Increased adoption of self-driving vehicles
- Robots in select retail and grocery centers handling service and checkout
These scenarios are highly likely and have been on our radars for some time. But it begs the question: if we can automate more and more human activities, can we automate software engineering?
For an industry so tied to technology advancement, software engineering continues to be a surprisingly manual and labor-intensive process. It has not changed much since its inception; it is largely a hand-crafted exercise in designing and coding algorithms. While the languages, tooling and frameworks have improved dramatically over time, so has the complexity of the applications required, resulting in limited improvements in speed and cost to completion. The problem is that the basic process of building software has not changed.
The implications are tremendous and create a huge opportunity to disrupt the software engineering industry. We have the confluence of two factors — first, organizations need to build bespoke software very quickly to adapt to the rapid pace of change (what we discussed in Part 1). Secondly, the size of the software engineering market creates a huge incentive to solve the speed and cost problem — globally, the market size is $168 billion and growing annually by over 20%.
A Mindset Shift
Given the massive market size and the confluence of trends, we have an opportunity to create a mindset shift in how we construct software, but we cannot think incrementally. What is holding us back? People in the software industry have been conditioned equate software engineering with writing code, so their natural desire is to want tools to help them accomplish this activity faster. It reminds me of the famous quote attributed to Henry Ford regarding the advent of automobiles (rumor has it he never actually said this, but we’ll go with it for effect):
“If I had asked people what they wanted, they would have said faster horses…”
To solve the speed and cost problem, we have to think differently and ask ourselves if automation can change how we approach the process of software engineering. It might surprise some that we are already moving in that direction. Consider the following observations:
- DeepCoder — An AI solution developed by Microsoft and the University of Cambridge that auto-generates code based on github repos and a basic set of requirements
- From Watson to DeepMind and beyond — AI-powered machines can now beat humans in chess, Go and Jeopardy
- Test Automation — 78% of companies use automation for functional or regression testing, so quality assurance has already become increasingly automated
These are examples are interesting, but we have not yet hit the tipping point. Something is missing. We need a bridge between today’s manual custom software engineering process and a future when code is mostly auto-generated from AI and data. But is that a bridge too far?
Enter Low Code
Absolutely not. We have the bridge right in front of us and available to walk across, consisting of a mature class of platforms ready to support a mindset shift: low code. Low code platforms allow developers to visually create custom software with code that gets auto-generated and auto-deployed. Instead of the two extremes — manual hand-crafting of source code or waiting until AI can fully generate its own code — low code platforms let us define what we want a custom solution to do, and the platforms handle the rest automatically.
(NOTE: They’re called low-code platforms because most allow engineers to hand-code things that the platforms might not be able to do — hence, low-code)
Given their potential to change the game, it is surprising low code platforms are not more well-known (the category could use a better name). Here again, this is an example of the software automation train leaving the station. Would it be surprising to know that the low-code market is set to grow from $13.2bn in 2020 to $45bn in 2021, a healthy 28% growth clip?
There are multiple established platforms in the market, from Microsoft’s PowerApps to sophisticated platforms like Salesforce (yes, that Salesforce) and Mendix. The simpler solutions are geared toward what the low code industry terms “citizen developers,” or non-technical business-people who can build a simple application on their own.
While citizen developer tools are useful, they are not the paradigm-shifting bridge and usually send shivers down the spines of IT departments who fret about shadow IT groups. Rather, enterprise platforms have the potential to accelerate what a team of software engineers can accomplish. For my money, the best platform is OutSystems, which both Forrester and Gartner rate as a top low code offering in their respective research. It is an elegant, easy-to-use platform meant for enterprises to build and deploy highly customized solutions that can scale to millions of users. Whether it is OutSystems or one of the other enterprise platform players, the industry now has a viable option to solve the speed and cost issues associated with bespoke software solutions.
Wait, What?
Unsurprisingly, there is natural skepticism from people in my industry about low code platforms, generally falling into two basic arguments. The first is something I hear from software engineers, and their argument is based on developer interest, coloring the use of low code platforms as something short of actual programming. Their point usually ends with something like, “I’m a software developer because I want to write code.”
When I hear this, it sounds a lot like someone saying they want faster horses. I often remind my colleagues of the importance of the mindset shift. No, we are not software coders, we are problem solvers, and if we can solve problems more quickly with automation, then we have a new automobile that might just take us to more interesting places.
The other argument takes issue with the whole notion of a machine being able to craft code with the same quality as a good software engineer. These skeptics understand how difficult it is to build high quality, extensible, maintainable software, and they believe the best a machine can do is generate bloated, overwritten code that would be impossible to maintain.
This is a fair point — it is doubtful that low code platforms today could generate more maintainable code than a strong software engineer. But in certain instances, do these platforms really need to? Engineers point to elegant code as easier to maintain, but with a low-code application, you do not have to maintain the code. You maintain the solution. And that is what we want, an environment where software engineers focus on the business outcomes over the source code. Shouldn’t they care more about why a business feature isn’t working rather than why something won’t compile?
We must also remember that over time, it is likely that machines will be able to construct software as elegantly as humans. After beating humans at Jeopardy, Go, poker and chess, is it really that hard to conceive a time in the not-too distant future where AI-enabled machines can match the prowess of a strong software engineer?
Conclusion
Despite my interest in software automation, it definitely has a place. Not every type of software will benefit from low code platforms. If I am Facebook, I’m not looking to replace my web and mobile consumer apps with a low code solution — too many unique requirements, users and scaling challenges. Data and back-end services are likely not good use cases for low code either. But for the vast majority of an organization’s internal or consumer facing software apps, where the requirements are neither unique or overly complex, a solution that offers the speed and cost benefits of software automation seems like a wonderful bridge to cross.
