This article is more than 1 year old
Software development slow because 'Most of our ideas suck'
Continuous delivery, make way for continuous experimentation
If you want a vision of the future of software creation, imagine a boot process spinning up a server, forever.
Speaking at Continuous Lifecycle London* on Wednesday, Mike Roberts, co-founder of consultancy Symphonia Cloud, employed less Orwellian terminology for tomorrow: continuous experimentation.
Perhaps you've heard of continuous delivery, the trending software engineering practice that aims to accelerate development cycles while making them simultaneously speedy and boring.
Continuous experimentation takes that a step further by reducing development cycles to weeks, days or even hours while making the data derived into fuel for further innovation.
Agile development exposed as techie superstitionREAD MORE
"There's no point in having continuous experimentation if we're not continuously learning," Roberts said.
Over the past 20 years, he explained, "the lead time for delivering software has come down significantly. It used to take years. Now it's more like weeks. We have the opportunity to bring this lead time down further to days or hours."
Echoing arguments made earlier in the day by conference presenter Linda Rising, Roberts urged businesses to reorganize their IT operations around technology and management processes that enable the rapid testing of ideas.
"Most of our ideas suck," he said, attributing the quote to software consultant Jeff Patton (though any cynic, unbidden, will say as much).
"But some of them are amazing," he added. "If we can try enough of these ideas out, we can play a numbers game. We can find that ideas that will really help our customers."
Enterprises, Roberts insisted, have to start thinking about how they can embrace experimentation as their core way of working, something many startups have done.
That's not an easy task. Roberts enumerated a number of obstacles that bar the way to reaching the dream state of frictionless, perpetual innovation.
There are technical challenges: minimizing incidental complexity; reducing infrastructure costs and commitments to new systems; avoiding the technical tar pit formed by a fragmented ecosystem.
Roberts favors serverless technology for overcoming these issues and contends it has as much value for accelerating development as it does for reducing expenses.
"If you're only using serverless for the cost savings, I think you're missing a big trick," he said.
There are organizational and cultural challenges, too: Minimizing the time from code completion to code deployment; nurturing a culture of learning; and spreading ownership of product innovation across teams.
"When we treat engineers as just code robots, we're not really releasing their full potential," he said.
And there are safety challenges: making it safe to fail; ensuring budgets don't get busted along the way; and protecting data and security.
"Safe experimentation is not a contradiction," he said. "Science labs do that all the time." ®
*The conference was co-sponsored by Situation Publishing and Heise Medien