I've talked many times about the productivity benefits from automation. In this episode, I talk about the higher value benefits we get from automation - something you could describe as a side-effect. Automation gives us productivity - but not just to do more, but to do better. Automation gives us the opportunity to elevate the work carried out by our teams - ultimately leading to better, cheaper, more reliable, more secure software. I look at common automation techniques and how they helps to free up our teams:
Or listen at:
Published: Wed, 06 Jul 2022 14:45:16 GMT
Links
- Episode 14 - Software Testing
- Episode 19 - Continuous Integration
- Episode 20 - Continuous Delivery
- Episode 21 - Continuous Deployment
- Episode 135 - Infrastructure-as-Code
Transcript
Hello and welcome back to The Better ROI from Software Development Podcast.
Over the last few episodes, I've been looking at some additional benefits we get from automation within our software development process.
Automation does come at a cost. It takes money and time to set up and maintain. But I believe the benefits well outweigh those costs. Both in terms of productivity, the Security side-effects, the Auditability side-effects, and the Knowledge Sharing side-effects that I've talked about over the last few episodes.
But I wanted to take a little bit more of a look at the productivity side. While productivity can mean more work, we can also look to use it to produce higher value work - we can elevate the work.
We can use that additional productivity to allow our teams the time to produce better quality, cheaper, safer and more reliable software. And that is the subject of today's episode.
Within software development, there are many opportunities to automate. Anything that is being done repeatedly is a candidate. Sometimes we refer to developers being "lazy" - they would rather automate than repeat the same activity - well, that developer laziness is a good thing, and I've touched on this briefly in prior episodes and I want to expand on it here.
At the simplest level, if we are automating the dull, repetitive activities, we have more time available for our team to be working on higher value activities.
Let's look at this per activity. We'll look at:.
- Automated Testing
- Continuous Integration, Deployment and Delivery.
- And Infrastructure-as-Code.
Automated testing.
Automating our testing can seem an obvious step, but we can get pushback based on the expertise needed to build it.
If we think about our testing, we would want to test and retest at various stages during the lifetime of our software. Historically, it was common for any change to our software to go through a whole raft of checks to ensure that our change had not broken existing functionality - regression testing to ensure our software had not regressed.
This could have been hundreds of manual checks, ranging from critical path to obscure problems that might have occurred once five years ago. They would all be on the testing pack and would be checked every time we had a change to our software. Often these manual tests could take days or weeks, not just to run, but to schedule and resource.
And as it was such an intensive, expensive activity, it encouraged batching, which would increase risk and how long it took to actually see any return on our software development investment.
And because of the amount of manual effort required to perform the test, we would use low skilled and cheaper staff to follow those tests robotically. Which can then lead to pushback when we suggest using expensive developers to automate something that we can just throw a cheap resource at.
However, as with many things in software development, our testing is evolving at a considerable pace. The role of the software tester has moved beyond following a plan by rote, and using their skills to really improve the quality of the resulting software.
They are providing the "what-if" questions to our software. They are pushing at the boundaries. They are considering the seemingly obscure things that can happen to our software when it goes into production.
To paraphrase a well-known software testing proverb;
Our software development team develops a software for a robot barman.
We then test that a customer can walk in to the barman and order:
- a beer
- two beers
- a round of beers
- two wines and a beer
- some bar snacks
We test for weeks with thousands of combinations of drinks and snacks - all works and we are happy - we party, we celebrate and we ship Barman Version 1.0.
On its first day of use, a real customer walks in and asks to use the bathroom - and the barman blows up.
This is the higher value testing we should be using our software testers for.
Let's move on to Continuous Integration, Deployment and Delivery.
Continuous Integration enables us to build our software in a repeatable, reliable manner. Continuous Deployment enables us to deploy that software at the push of a button. Continuous Delivery removes the need to push that button, automating all the relevant checks. The three, along with automated testing, provides the cornerstone of being able to make multiple deployments per day.
But how does it help us to elevate the work of the software developer?
Part of it is simply by removing the time that was previously dedicated to that activities. But another part is a reduction on cognitive load.
Neuroscience tells us that there's only so much the human mind can effectively hold at one time. Thus, the less our software developers have to think about, the better they are to deal with the most important and expensive problems to our organisation.
Even removing the simplest of activities from the software developer provides additional horsepower for that extra hard work. Albert Einstein is reported to have worn the same outfit daily to save on the time and energy deciding what to wear. The same has been said of Steve Jobs and Mark Zuckerberg.
Having our software developers not have to think about how to achieve repeatable tasks, like the build and deployment of the software, allows them greater cognitive space to think.
As an aside, this is the same argument for not multitasking. Having multiple tasks for a software developer, or any knowledge worker, is bad for productivity as so much cognitive load is taken up switching between the tasks. Regardless of what you might believe, multitasking is never a good idea - but I come back to this more in a future episode.
Finally, let's talk about Infrastructure-as-Code.
Infrastructure-as-Code allows us to document our server, network, storage, etc. all the things that we need to run our software on. It allows us to document in code the steps that we would have previously had an I.T. operations engineer, or team, carry out manually.
By using Infrastructure-as-Code, we get the benefits that I've talked about in the previous episodes:
- productivity - much quicker than doing manually
- Secure - we reduce the manual interactions
- Auditable - we have revisions and can review that code
- Knowledge Sharing - we can learn how it's been put together, and as it's code under version control, how and why it is evolved over time.
By freeing up the I.T. operations engineer, again, we have the opportunity to elevate their work. We are freeing them up to look at better ways of working. Maybe they can find cheaper ways of running the software. Maybe they can find ways of making it more reliable. Maybe they can find ways of making it more secure.
Again, with all IT disciplines, what is bleeding edge last week could be superseded this week.
In this episode, I've looked at a number of common technical practises that can help in automation of our software development process and in doing so allows us to elevate the work our teams carry out.
Yes, automation can allow us to be more productive. But that isn't just to do more. It can be to do better. It can be to produce higher quality work.
Simply doing more may produce a good ROI, but there comes a point that the market demands higher quality rather than higher quantity.
However you look at it, automation is incredibly valuable. It provides us great ROI for productivity - us being able to do more - however, over the course of the last few episodes, I hope I've helped you to see that there is more that can be gained from automation, be it greater Security, greater Auditability, greater Learning, and of course, the opportunity to allow our teams to elevate their work, thus elevating the resulting software.
Thank you for taking the time to listen to this episode and I look forward to speaking to you again next week.