Almost three years ago Microsoft’s Satya Nadella famously coined that “every business will be a software business”. Today, the $500 billion global software market is on track to double to $1 trillion by 2030.
J.P. Morgan is on record as having 40,000 software engineers (more than Alphabet) in their most recent filing. Every major enterprise company is racing to hire engineers in order to out-develop their competition. The big problem is that traditional software development is slow, fragmented and wasteful.
For example, each week the average software engineer will spend 4 hours waiting for tests to complete, 3.5 hours waiting for builds, and 3 hours on environment management — more than a quarter of their work week not actually creating anything of value. When you consider that engineers are often the highest paid people in organisations it’s clearly a big problem. However, things are changing.
One of the leading development platforms, CircleCI, made the bet that AI and automation would be the key to speeding up software innovation and freeing up engineers to do important work. In the last year the company introduced a number of automation and machine learning enhancements that reduced the amount of time that engineers wait around by 50%. It’s one of the many reasons that more than 300,000 developers including those at Facebook, Spotify, GoPro, InstaCart and many others have turned to CircleCI to move faster.
Leading the company is Jim Rose — a six-time founder with past investment from Google Ventures, Foundation Capital, and Marc Andreessen. Since joining CircleCI a little more than four years ago, Rose has increased revenue by more than 450% and grown the company into a truly exciting entity.
Interested in learning more about automating software development and speeding up innovation, Information Age spoke to Rose on the subject.
What is the current state of the software market?
At the moment, there are still lots of companies and individuals who are doing different processes manually. When you think about the process of digital transformation, it’s really about trying to foster a software development team.
One is trying to get software out of on-premise data centres and get them into cloud-native environments, where you can get access to compute on an instantaneous basis.
The second is that software, traditionally or in many cases, has been seen as a guideline or an adjunct to primary business. Now you’re having all sorts of businesses from banks to car manufacturers to retailers all realising that software is core to what they do. And so they need to figure out what they own and they have to consolidate their assets and integrate them as a standard.
Once companies have this instantaneous access to compute and they have structures in place that developers can work in, what’s sitting in between today is usually some kind of mishmash of different platforms and processes.
In most cases you have very long waterfall software release processes that have lots of manual steps and then they have lots of manual scripts. In some cases for more advanced shops, they might have the first generation of automation solutions in place but as teams are speeding up, those are starting to break.
And now that’s what we’re coming into and helping companies navigate. As their software teams are speeding up, they’re building more software and as they’re trying to do it faster; in order to be both responsive to opportunities in the market but also be responsive to potential negative changes as well. Businesses just need to completely rethink how all of those pieces are put together.
Is this speed you refer to the main hurdle in software development?
Companies and development teams are trying to speed up as the market is speeding up. They’re trying to figure out how can they work quickly so that they can address opportunities.
The only way to get there is to really automate all the steps that don’t necessarily need human intervention, because instead of doing it over the course of minutes, hours and days, you can do it in seconds.
As teams are speeding up, and as software is your primary storefront to your customer, you have to make sure that the quality levels are high; you have to make sure that it doesn’t crash or that you don’t have security vulnerabilities, for example.
So, when you think about agile, it is about trying to become more nimble, both from a quality perspective as well as from a speed perspective.
In the US it’s all about speed but in going faster, integrating smaller chunks and being able to release software on a more consistent basis, your software just inherently gets better. All of those fears around having to deploy go away when you do it five, eight, 15 times a week, and in some cases we have customers who do it 100 times a day.
Deployment becomes a non-issue.
On the quality side, one of the big issues for software development in the past is that if you only release once a quarter, you have a really hard time making sure that all the changes you introduce into your application actually work together. Oftentimes you see companies do a big bang release and then after they do a big bang release, they spend the next 60, 90 days trying to fix all the things that regressed and broke. In this method, your software cycle slows down, but also the quality of the application itself suffers.
From an agile perspective that’s what people are trying to address.
How can an organisation change to accommodate, support and foster software development teams?
There are a few different ways.
One is that developers are hard to hire and so you want to make sure that all the time spent from a development perspective is dedicated to building out your special software, whatever that happens to be; if you’re a bank, building a great banking application, if you’re an e-commerce app, building a really great e-commerce app. I think one of the big areas that people have underinvested in is that software developers historically built things. That’s what they do, they build software. So the development cycle has been underinvested from a third party app perspective.
There are just things like, for example, testing automation and continuous delivery infrastructure that teams shouldn’t have to build on their own. You’re much better off acquiring it from someone else who specialises in that area so you can focus on the thing that you’re good at. It would be like telling somebody that they need to build a coffee maker and giving them a bunch of copper pipes, some solder and some valves. You would never do that. But historically, development has been treated that way. So definitely putting the right tools and platforms in place is really critical, all the way up and down the stack, from the data centre all the way up to the planning tools.
I think the second part is that in a traditional waterfall model, software development usually plays the role of catcher, so the application gets defined much earlier in the process and then by the time the development team gets it, there’s been a number of decisions made that may or may not actually work and may or not be feasible or easy to do.
There’s this notion of shift left, which is trying to push development further and further up the planning cycle so that the concerns or the needs of the development team get considered both in the construction of the application as well as in its delivery. And then when you think about it from an operational perspective, it means you really have to think through how an application is operated much earlier in the life cycle as well. For example, if you’re trying to build cloud-native apps, you have to architect them in a very particular way which means that you need to make that decision and need to be part of that process much earlier.
When teams are adopting more software-first, agile processes, you end up with a triangulation of concerns. You’ve got the folks and the business owners and the product managers who own why you’re building something. You have the technical architects and the software developers really talking about how you build it. And then you have the operators, the ones that are responsible for actually running it, figuring out what you actually run at the end of that entire process. So everyone needs to be involved. And that can be a hard transition for some companies.
How can AI and automation spur and improve software innovation?
With automation you can automate tasks that are both predetermined, as well as self-learning. An example of that might be if every time you try and release a piece of software you have to do a third party test against some other third party payments system. In the past with those tasks, you would have to hire would hire up a QA team that would essentially try and process transactions and do it all manually, which is incredibly slow. It’s also incredibly fraught with just error and complication.
These are perfect examples of tasks that should be fully automated in your test suite — all of these things that you know you are going to do over and over again, you should automate those tasks to make them deterministic and predictable. And then ultimately quick.
There are opportunities to take those repetitive tasks that any minute spent by a developer doing those things over and over again is a waste of time and, quite frankly, a waste of money.
So when you look at AI and software that is being built, instead of thinking about pushing predictive deterministic software, what you’re doing is pushing a model. And the model is a sandbox of pre-conceived notions of how something might work and then as people are going through it, and as tests are being run, the model is changing and evolving as it’s learning more about how things are either working or not working. That puts an incredible amount of pressure on the testing system.
When you think about some of the AI missteps when you have situations where there’s unconscious bias built into the AI, where the AI kind of runs amok and starts blocking people out of certain applications, or shuts things down, those are all situations where from a testing perspective that are challenging.
It’s becoming more and more complicated, but it’s also becoming much, much faster and more responsive. So you’re only going to see the inclusion of AI and machine learning in software development to continue to increase. But, now you need to have all the necessary frameworks in place to be able to test for all of those changes.
