Why IT and Software Delivery Service Cycles Are Getting So Much Faster
I had the opportunity to attend Amazon’s AWS re:Invent conference this year. The number of new services they launched was amazing. And in November, Microsoft held the virtual conference called Connect(). They, too, announced plenty of new initiatives. But what does this have to do with delivery service cycles? Well, as I watched what Amazon and Microsoft have done, I realized that their end goal is to alleviate the pain companies have when developing and deploying new software. They’re letting everyone focus on what’s really important: delivering value to customers.
The existence of tools and services is one of the reasons why delivery speed is so fast these days, but it’s not just that. When you let others take care of the things that aren’t your primary business, you can easily innovate and deliver faster. For example, if you need to do a big migration to the cloud but you don’t have enough experience to do it, it’s better if you hire a contractor to help you. This doesn’t mean you aren’t capable of doing it–or even learning how to do it. But it may cost you, both financially and reputation-wise. It’s way more affordable–and more face-saving–in the long term to lean on someone else’s shoulder.
That’s how our industry is behaving now. There have been so many improvements regarding cultures and disciplines, tools and services, practices and the vast number of resources you can find out there that speed is resulting naturally. It’s letting organizations take software delivery time from months to minutes. So let’s explore some of the things that are making this speed possible.
Changes in Culture That Have Resulted in New Disciplines
One of the first software development methodologies I encountered was the waterfall approach. At the time, I liked the idea that there was an order and well-defined processes to follow. But when I joined a company where they heavily used this model, I was disappointed. I’d get so excited to work on new assignments, but then they’d take ages to deliver, thanks to the bureaucratic processes involved. It was clear that we needed a change in the process. Everyone needed to be involved. After working in waterfall fashion for some time, I was introduced to Scrum. Everything was different. For example, I noticed that with this model we could be paying more attention to creating working software than having extensive documentation.
When we switched to Scrum, we were deploying something new to production every two weeks. In the past, we’d deliver a simple change in a month, if we were lucky. Testing is another example of improvements that came with Scrum. Teams became more confident in what they were working on because something or someone was always verifying they were delivering what was expected. And testing opens the door to refactoring and to always be improving the code. That’s contrary to what usually happens: the older the code, the more difficult it is to make a change.
Now we have test-driven development (TDD), short cycles of development, all sorts of different tests (like unit, acceptance, and integration tests), pair programming, ownership from everyone, continuous integration, continuous delivery, SOLID principles, and even crazy things like chaos engineering. We’re still learning how to apply all of these principles and disciplines, but it’s good to know they’re there. We should take what makes our delivery service cycles faster and discard what doesn’t.
More Tools and Services That Let You Focus On Your Business
There’s one main reason you’re seeing tools and services being launched so frequently: those companies or communities are trying to make your life easier and more productive. Proof of that is all the serverless waves you may have been seeing recently. It’s a simple and fast way to get started. From prototyping to validating a concept to creating something new, you don’t need to worry about provisioning a server to host your application. And you just pay for what you use. Cloud providers are launching these types of tools with the sole purpose of helping you to become more productive. If there’s something you need that a cloud provider doesn’t offer, there might be a company already offering a software-as-a-service (SaaS) solution for that. Twilio or Auth0 are just two companies that specialize in this.
Also, for any tech stack that you choose, there’s likely to be a powerful IDE available. There are so many IDEs right now that are making people more productive. Features like live unit testing from Visual Studio or pair programming from Visual Studio Live Share or Cloud9 are good examples of productivity-boosters. Those features are appealing because you can receive feedback instantly, and this certainly improves your speed of development.
Another important tool is Jenkins, which helps in the field of deployments and code integration. You can have at your fingertips the possibility to deploy a new change to a live environment in minutes. Of course, that’s only after the change has passed a set of tests successfully and after the team knows it isn’t making the application worse, overriding anything, or causing any downtime. While these benefits aren’t 100% attributable to Jenkins, the tool is absolutely helping to achieve them.
Better Practices That Enable Ease of Change
When you hear that there are some organizations delivering software changes in minutes, your first impression might be that their system must not be that complicated — or that they’re nuts! But in reality, these organizations are leveraging automation. This is by far the more important practice that’s helping everyone to go faster. The rise of DevOps as a movement reinforces this practice of relying on automation more and more each day. Many practices in this area will help you to deliver with confidence: practices like configuration management, continuous integration, automated testing, infrastructure as code, immutable infrastructure, release strategies, and more.
But architecture also plays a big role here. You’ll need to keep it in mind that things will change. Technology will evolve. We can choose to evolve with it, or, if we wait too long, we’ll be forced to evolve with it. Functionality will change, too. This happens all the time. And if you don’t act wisely, you’ll accumulate technical debt. That technical debt, in the end, can force you to start over. That’s costly.
Instead, what’s happening right now is the emergence of new patterns that let us be less afraid of change. There are practices like implementing domain-driven design (DDD), using design patterns, building microservice architectures, making use of containers, and taking the serverless approach, just to mention a few. Of these examples, containers are the most acclaimed right now. Everybody is talking about containers and with good reason. Organizations are increasingly adopting them, thanks to the portability and packaging that this technology offers. Containers enable more collaboration between teams and reduce the time taken for deployments — and even for rollbacks. In some way, they enable you to go faster by forcing you to document each change, even at the infrastructure level. This makes everyone aware of what’s being pushed, and potential problems practically identify themselves. Plus, it’s easy to change something; if it’s easy to change, you can deliver fast.
Focus On What Your Customers Value Most
We’re living in wonderful times. It amazes me how good our industry is becoming at delivering useful things to the world and how collaborative we are right now. We’re not only focusing on delivering fast. We’re also paying more attention to what customers value most.
We’ve learned from our mistakes. We’re creating tools that make our lives easier and more enjoyable. New practices are becoming the default, thanks to the results they’re giving in return.
It’s true that things are changing fast, but the good thing is that you can easily tell when something is becoming relevant and useful if it stands out from the rest. You might be practicing some of the things I mentioned here. If you’re not, at least consider trying some of them.
Originally published at https://aspetraining.com/resources/blog/why-software-delivery-is-faster.
