In episode 83, I had a long chat with Trevor Ewen about how he provides software service to non-technical clients. If you've not listened to it, it was an excellent interview full of wonderful insights. So much so that I want to pull a number of topics from that podcast and look at them in more depth. In this episode, I want to look at the regular software releases.
Or listen at:
Published: Wed, 19 May 2021 17:51:56 GMT
Links
Transcript
Hello and welcome back to The Better ROI from Software Development podcast.
In episode 83, I had a long chat with Trevor Ewen about how he provides software services to non-technical clients. If you've not listened to it, it was an excellent interview, full of wonderful insights. So much so that I wanted to pull a number of topics from that podcast and look at them in more depth.
In this episode, I want to look at regular software releases.
In the interview, Trevor talked about how he had instigated quarterly reviews.
In those quarterly reviews, his team would review the software in the platforms they provided to their customers. They would check to make sure everything was correct and up to date, including things like security patches.
Trevor saw this as an excellent way of making sure that the software was correct and safe by having those security patches applied on a regular cadence.
For me, regular security patching can be one of the most effective defences you have when it comes to cybersecurity. It's a highly recommended practise by all experts in the field.
Take, for example, your laptop. Your laptop would almost certainly be getting regular updates, which include not just functionality updates, but also security updates. Microsoft is well known for this and releasing them on a Tuesday - you have what is now known as Microsoft Patch Tuesday.
With the Internet being such a prevalent means of communicating updates, it's almost common practise now for all software to be receiving updates on a regular cadence.
However, updating that software when you're developing internally somehow seems to be forgotten.
We often consider our security efforts the work we do up front, not the work that we do on an ongoing basis.
We largely consider it one and done, that's it.
We don't need to think about it anymore once we've released that software out to our teams, out to our clients - we don't need to think any further about it.
And this couldn't be further from the truth.
A lot of today's software is built on other software. Its built on software that we imported, whether it be libraries, frameworks or any other type of product.
Think about it as a skyscraper; Your team's development is sitting on top of many, many other layers. If those layers aren't solid, if the foundations of the skyscraper aren't solid, if the lower floors aren't solid, if your own team's work isn't solid, then that skyscraper will not survive.
You may be thinking that if you've done the work when you built the software originally, you don't need to do it again. You don't need to review those libraries, those platforms. You don't need to review those lower floors, that foundation that you built upon. However, that's not true. It's common for many libraries, many platforms, many operating systems to identify security holes or bugs, vulnerabilities within their systems that could potentially lead to you having a breach.
And it isn't uncommon for those to be systems that have been out in the marketplace for a very, very long time.
As I'm recording this, it's been recently announced that Dell have a bug within their update driver software software that they've put onto every single laptop and server, I believe, for roughly about the last 12 years, or at least most of them.
The problem with this software would actually allow a third party to execute software and programs on your machine without your knowledge.
This is quite critical as a software fault, quite critical as a security vulnerability. And yet that has been found to be in software that has been in use for over 12 years. I'll include a link to the article that talks about that vulnerability.
And isn't isolated to that. The same is true of so many pieces of software, as more people look at it, investigate it - more ways, found are how to potentially exploit it and find security vulnerabilities.
So much so that once a vulnerability is found, once even a patch is put out into the marketplace, there's a race to see who can exploit that patch before teams have had a chance to apply to all their machines. Before they've applied it to all their software. This is why it's critical to get into a regular cadence of being able to deliver on a regular basis. Being able to update, put these fixes in and release your software in a regular way.
The other benefit that comes from regular releasing, is a confidence that you can release when you need to.
If you haven't released a piece of software for one year, two years, five years, ten years - what level of confidence can you have if you have an emergency and you need to be able to release that software if a security fix or a business change is required?
How confident can you be that you can release it?
Do you you even know how to release it?
That you're not going to cripple your business by attempting to make that release without fully understanding how to do it and be confident in it?
I've certainly worked in organisations and with teams where a release is seen as a scary event. I talk about this in earlier episodes where people find it such a difficult, cumbersome task that they end up batching more and more and more and more - to the point where it actually becomes almost impossible to release - because of the amount of stuff that's been batched up over a long period of time.
You get to a point where the release has to be done in the middle of the night. Or it needs to be done at a weekend. Or we need to take this down, we need to affect a client, we need to turn off our website over a weekend, and we need to have everybody in because it's such a big, risky job and we need to be on top of it.
That is an incredibly dangerous place to be as an organisation. It hugely limits the flexibility and the agility of the business to adapt to changes in the market, in the security posture of your software or just where you need to be as a business.
If the Covid-19 pandemic teaches us nothing else, the unexpected does happen, and we need to be able to be in a position where we can be agile enough to adapt our organisations and our working practises to cope.
Let me repeat; you must have a means of being able to do regular safe releases for your business to maintain the level of agility and flexibility it needs in that software, for your business to survive in the modern day.
Now, if you are an organisation that is scared to release your software on a regular basis, you may be thinking that's very well and good, but the effort, the work it takes us to do a release each time is mammoth - how can you possibly suggest it's a good for our business or even possible for our business to release on a much higher cadence?
Simply put: automated, automated, automated.
I've talked about this in previous episodes.
I've talked about the ideas of Continuous Integration, Continuous Delivery, Continuous Deployment in Episode 19, 20 and 21. Anything your staff are doing to get that software from the developers hands into the production environment: automated it.
Whether that be the building of the software to make sure it's correct, whether it's the testing of the software, whether it's the deployment onto the servers: automate, automate, automate.
The more that you can automate, the more confidence you have in it being a robust process and not a manual checklist which people can forget or skip bits or misunderstand 3:00 in the morning.
It's a robust process that is repeatable each and every time.
It also removes so much time and effort in the actual process itself.
I've got systems I can finish coding now and have in production in five minutes time.
I make my change locally. I've tested it locally. Great, it works on my laptop.
I save that. I push that up to Source Control. Source Control takes it through to Continuous Integration which builds it - making sure that it builds remote. It's not just working on my machine.
It then packages it through Continuous Delivery, runs it through tests, making sure the software does what it should - to make sure it's avoiding regression.
Then automatically deploys the software into production environment and runs further tests to make sure they operates as we expect it to.
All of this is through automation.
Automation is a key to being able to do this on a regular, repeatable, reliable cadence.
Automation is a key to helping you with your internal productivity and then helping you with things like your business agility and flexibility.
Obviously, this automation is not free of charge. There has to be work done to set it up. There's plenty of software systems and platforms out there which don't cost the Earth. Some of them are actually free, but you still need to set them up.
So there is a cost involved even if the price tag says zero.
So you have to factor that cost in to the cost of your product. Again, this is a cost that should be factored in.
Back in Episode three, when I introduced thinking about software development as a product rather than the project - where when we're thinking about is a project, we think about just the creation cost - when we're thinking about as a product, we also need to think about the ongoing maintenance and even the eventual decommissioning.
The costs it takes to set up that automation suddenly make much more sense.
If you're looking at those costs on a project basis, which is only interested in the initial set up, it may feel that extra work to set up that automation, to set up those automated tests, that automatic build, automated deployment may seem a lot of overhead for just getting your product built and ready to go.
When however you start thinking about it in the product mindset and the longer lifetime of that product, suddenly you've changed the equation.
As far as return on investment goes, that investment you're putting into the automation suddenly becomes much more obvious and gives you a much greater payback when you start thinking about the life of a product.
The investment you put in to automate the testing, the build, the deployment suddenly pays back much better if you're thinking about, well, how often you're going to need to release this software in the next year, two years, three years, until, in fact, you expect the product to be decommissioned.
Now that maybe 20 years time. Think how much of a payback you're getting on that early investment that you're putting in to make sure that you can be confident that you can safely, reliably and quickly release that software at any time you want. Be confident that you can maintain your business agility and flexibility.
The project thinking has a tendency to force us into thinking about the "what do we need right now?"
Thus, the project thinking again will probably tell us putting effort into those tasks are poor return on ROI.
This is why we need to be so careful to avoid going down that project mindset and always be thinking about it in product terms.
In this episode, I've talked about regular software releases and the importance of being able to have confidence that you can release safely, quickly and with reliability time and time again.
It helps your business be able to rely on it for the agility and flexibility your business needs, whether that's because you need to make a change to the business direction, you need to update the software, or you need to implement that highly critical security patch, having that capability is so crucial to your business.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.