Get updates to your emailSubscribe
“I took a course in speed waiting. Now I can wait an hour in only ten minutes.”—Stephen Wright
A lot of my conversations with software practitioners lately have focused on ways to make changes to their software faster. It doesn't matter if they work for big banks or small startups—it seems like everyone is trying to figure out how to increase their speed of change. It's becoming pretty clear that, in 2016, everyone wants to be fast. So, what does fast mean?
Well, here are three examples: Etsy, the online marketplace makes 50 deployments per day. Fred George, an expert consultant on software development processes describes deployment to production every 3.5 minutes as the normal pace for his projects. Jon Jenkins from Amazon talks about managing changes to their production environment every 11.6 seconds.
I'd say that’s pretty fast.
Wanting to release faster reflects the market's demand for more business agility. Businesses are under increasing pressure to build better customer experiences than their competitors, which requires lots of change and lots of innovation. To stay ahead of the rest of the market, you must be able to make those changes faster and cheaper.
Today, the goal is to create technology systems that incorporate change “as a feature”. In practice, this means recuing the time it takes to turn business ideas into deployed code. To put it another way, speeding up your release time increases your system's adaptability and gives you more business agility.
More and more of the software architects and technology leaders I speak with acknowledge that their systems need to become more changeable and that their primary goal is to make software that is more amenable to change. If it's your job to design or maintain a distributed application, you're probably spending a lot of time figuring out how to do that.
There are lots of ways to increase your speed: use better tools, improve your software development practices, change your solution architecture and even change your organization. DevOps, agile, microservices, continuous development and containerization are all becoming popular because of their potential value in making changes cheaper and faster.
But, that's a big scope to worry about and it can be difficult to figure out where to start. One basic but powerful way to improve your release speed is to start by simply getting better at making changes. That means incorporating lots of practice today, before you introduce all of the other stuff.
With the right support, instituting a requirement to release early and release often can become the driver for all of the processes, tools and architecture to evolve. It doesn't matter what you change, just increase the rate at which you change it and give your teams the autonomy and freedom to incorporate the things they need to make those changes easier and cheaper.
Speed gets a lot of attention because it is becoming so important but it’s vital to remember that speed is only one factor. The fact is that, when it comes to software development at most organizations, speed needs to be governed. Focusing solely on speed is a great way of introducing bugs, reliability issues and outages.
In a lot of companies, that could lead to a loss of customers and revenue—both of which have a chance of leading to a loss of employment for the person who decided that speed-at-all-costs was the right decision. But many traditional organizations are already grounded in a safety-first perspective, so a pure focus on speed can be a good correction.
If you aren't already doing it, start thinking about how to get faster. You don't necessarily have to be the fastest development team on earth but if you can speed up and make your releases cheaper and easier than your competitors can, your business will have a chance to really prosper in the application economy.
Ronnie Mitra is an expert in enterprise development and integration who leads the CA Technologies API Architecture and Design Practice across Europe. In this role, Ronnie helps companies leverage their burgeoning API potential. Before joining CA, he worked at IBM where he held the worldwide leadership role for WebSphere connectivity products.