I've talked many times about the productivity benefits from automation. In this episode, I talk about the knowledge sharing benefits we get from automation - something you could describe as a side-effect. I discuss how, to be effective, any new software developer needs to learn not just the technical tools and practices, but also the domain - the environment in which the software will operate. I then look at how automation practices like Continuous Integration, Deployment & Delivery, Infrastructure-as-Code and Automated Testing can help provide that knowledge.
Or listen at:
Published: Wed, 29 Jun 2022 18:47:32 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.
Automation in software development is excellent - it helps us to improve our productivity. But setting up automation and maintaining it comes at a cost - so, how do we justify the ROI on it?
Well, predominately for me, you can justify it generally just based on the productivity increases you get from using that automation. However, in the last couple of episodes, I've looked at some additional benefits that you receive, almost as side-effects, that can help you with that return on investment case.
I've looked at the Security side-effect - how by automation you're automatically getting better levels of security and can really help you produce a much safer product. And in the last episode, I looked at Auditability - the ability to use automation to get better logs and non-repudiation to help you with any audit process you need to go through.
In this episode, I want to look at how automation can help us with the Knowledge Sharing aspect.
Within software development, there's a lot of opportunities to automate. However, in this episode I'm going to reference Automated Testing, Continuous Integration, Delivery & Deployment and Infrastructure-as-Code, so I just want to give you a quick recap on those subjects.
Automated Testing.
Testing our software is critical. If we don't test it as part of our development process, then our users will do that testing. Do you really want your prized customers having to work through buggy software? That's not going to do you or your company's reputation any good. But testing can be a time consuming activity. So by investing time in automating that testing, we make it practical to run often, potentially, even continually. This provides us a safety-net to move quickly, as we can tell rapidly if we have inadvertently broken something. I talk more about automated testing in episode 14.
Continuous Integration, Delivery & Deployment.
We need to build our software for it to be useful. Historically, we may have done this on a local developer's machine, often resulting in the "it works on my machine response".
Continuous integration provides us with dedicated service to build. It provides a consistent, clean result and not subject to the vagaries of individual people's set up. And it's also an excellent place to run an automated test.
Continuous Deployment takes that built software and allows us to deploy to our service at the push of a button. We automate the manual actions needed to download, install and configure our software, avoiding many of the mistakes that come from the manual approach - and it allows us to do it quicker. Changing something that was potentially an overnight or even a weekend event to being a trivial activity that can be done multiple times per day. It also provides us a further place to run automated tests against our production release, allowing for quickly highlighting any release failures and allowing for rapid rollback.
Continuous Delivery takes that a step further and reduces the need to press the button by automating away all of the approval activities. All of the things that led up to us being allowed to press the button under Continuous Deployment, Continuous Delivery allows us to entrust to the system that everything has been done. It avoids the manual mistakes of either missing steps or not even knowing how to progress. Again, it's repeatable. Again, it's time saving. Again, it allows you to cut down on the time it takes to get the investment that we've made into our development work into production where we can see the benefits.
I talk about continuous integration, deployment and delivery in episodes 19 to 21.
Infrastructure-as-Code.
This allows us to document our infrastructure a software code. It allows us to build out our servers, network storage, etc. as instructions that can be automated. Traditionally, building our infrastructure would be time consuming, laborious, specialised and an error prone activity. And prior to the Cloud, it was also often expensive and could have considerable lead times.
With Infrastructures-as-Code and the Cloud, we can now produce these set ups for us to run our software quicker, cheaper and with less errors. I talk more about infrastructure as code in episode 135.
So let's move on to the main content of the episode, the side-effect of Knowledge Sharing through automation.
There's a lot to learn for a software developer, both technical and domain.
When I talk about the technical, these are the tools and practises we use. Over half of software developers have less than five years experience. Our industry is exceptionally young and constantly changing. It is one, that I feel, you need to be constantly learning just to keep up. The technical landscape for software development can seem to change overnight. From a technical perspective, many of today's software practises, processes and knowledge will be obscure in five years time. I've seen long running projects that start on the bleeding edge of technology, only to draw to a conclusion years later with whispers of now it being legacy because it is now three or four generations behind the new bleeding edge.
And the domain is the environment in which the software being developed will operate. And this will likely be different for every organisation that a software developer will go into. While organisations within an industry vertical are likely to use some of the same terminology, it is common that even in similar organisations or even departments within an organisation will have different terms, descriptions and processes for how they operate.
And this all needs to be understood by the developer to be effective when applying their knowledge of the software development tools and the processes to an organisation's problem.
And this is where automation can help to share that knowledge.
Continuous Integration, Delivery & Deployment and Infrastructure-as-Code can go a long way in helping to understand the technical tools and practises in use. In many cases, the developer doesn't even need to know how these activities work under the hood. They just need to press the button to use them. And should they need to look under the hood, then that automated process provides a living, breathing documentation of the actual process.
I've certainly taken advantage of such systems on client sites to quickly grasp the technical setup of some fairly complex systems.
The Automated Testing helps us to understand the software in the business context - the domain - by utilising the various types of Automated Testing - we don't just understand the software at the micro level, we can understand it at the macro level.
We gain an understanding of the micro, the building blocks, through things like unit testing. Unit testing helps us to test the smallest components within our system. Think about it as testing just a seatbelt within a car assembly.
We then gain an understanding at the next level by seeing how those building blocks interact with each other through things like integration testing. Now this might be where we would be testing our seatbelt when attached to the seat structure.
And then we gain an understanding at the macro level by seeing how the resulting systems provide business benefits through things like acceptance testing and Behaviour Driven Development (BDD). For our seat belt, we would see that when it's attached to the entire car and used in crash testing - we're seeing the benefits that the customer will get in the event of a crash.
You may be asking, why are we not just using documentation? Couldn't we achieve the same knowledge sharing through documentation?
Well, yes, but I don't believe it to be as effective or to produce the same return.
By automating, we are effectively getting double benefit. Not only are we gaining a level of documentation, we are gaining all of the benefits that come with automation - something that I discussed in depth in episode 122: The State of DevOps 2021 - What it says about documentation.
I also find that when we document through automation, it is up to date and relevant. A Word document on a server can quickly become stale and out-of-date. While automation needs to be kept relevant - otherwise it stops working.
In this episode, I've talked about the Knowledge Sharing side-effect of automation.
Onboarding new software developers can be one of our most expensive and time consuming activities. We want to be getting those developers productive as quickly as possible, and automation helps in two ways.
Firstly, it reduces the amount needed to learn - if automated, it's a button press away rather than having to learn an archaic sequence of actions.
Secondly, it provides a level of living, breathing documentation to both the technical implementation and the domain knowledge of how it is used within the organisation.
Again, similar to the Security and the Auditability side-effects, I do think the Knowledge Sharing side-effect is often overlooked. I think it provides a great justification for increased automation throughout your organisation.
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.