This is part of the series on the Axioms of Software Development. If you haven’t read the previous axioms - you can see them here.
It’s my aim that by helping you understand these axioms, I can help you resolve problems associated with coordinating developers, time and resources and ensuring your software project is successful.
10. Automation Builds Productivity
While I’ve listed this as an axiom of software development, really, this is true of all industries. Anything you can properly automate will result in less errors and higher productivity.
In order to do this, you first need to understand a fundamental of automation. You can not automate something that has not been standardised to be done the same way each time or done in accordance with a strict set of rules.
A mistake I have seen made many times is attempting to automate a process that still has numerous edge cases, hours are spent on getting the automation done just to realise that there are occasions where the process needs to be different requiring decisions to be made in order to proceed.
But once you have a process that happens the same way every time according to a set of rules, then this is ripe for automation and you should automate it as soon as practically possible. In a software development world, automation can be achieved in many places, from task management, building, testing, deployment, and even to monitoring and scaling. We’ll go over a few of these here to give you some ideas on where you can automate your processes.
Automate your Tests
Picture what happens when your developer creates a new feature. It makes total sense to you.
You look at the feature on staging and it looks good. So you approve it to go to production.
But, when you go to deploy it, your automated test process comes back with an alert saying, ‘We just found an error on the 6 ft requirement for the basketball team members.’ Your automated testing process stops the deployment process. You are very lucky that the automation process caught that error before it went live. You are left with a choice of either fixing the error or fixing the test to push the code live.
Automate your Deployments
When you deploy code to your production environment on an application that is going to have continuing work, you don’t want someone manually copying files onto a server. You equally don’t want someone running a 10-step manual process.
You want to automate that as much as you can.
A big reason to automate is that it makes deployments easier. And it creates the functionality to roll back deployments, if you happen to push an error into production.
Rolling Back Your Production Environment
Another scenario you might encounter is having a feature pushed to production that everyone is happy with. But later finding one subset of users report that the new feature breaks the part of the system they use - and now they are blocked. With automation, you can just roll that back and put the old version live, quickly and easily.
I unknowingly created this exact issue. Because I’m both a software developer and the project manager of my own software projects, it’s pretty easy for me to write what’s called “founder’s code.” Essentially, that’s sub-par code which I think is good enough to just push live. (I don’t do it as much now as I used to.)
One day I did an update, and believe it or not, I was updating the copyright year in the footer so it shows the current year. That is pretty obvious. But of course, I was being smart! I didn’t want to just edit the year in the text, I wanted it to automatically update so I wouldn’t have to fix it every year. So, I wrote some “founder’s code” that automatically sets the current year as the copyright year and I pushed it live. And I promptly went out for dinner around 7pm, without taking my mobile phone.
I got home a couple hours later and I had at least 10 messages from different clients, complaining about the application. My email inbox was flooded. All sorts of things.
As it turned out, I had pushed a syntax error into production that only came up in a certain way and it caused the application to crash.
Luckily, our entire process was automated using our OpsCare Service, which monitors all our applications 24/7. When my OpsCare team saw that I had pushed something into production right before the site went down, they first tried to contact me and, after failing to reach me, they just pressed a button and the whole thing rolled back to a previous version and the whole system came back up again.
The total downtime was perhaps 10 minutes, instead of 3-4 hours, which was the time I was out at dinner.
Summary
This is where automation builds a lot of productivity. It also means developers are not as afraid to push new features into production because they know that the system will help them to make sure it works when it goes live.
Are These Axioms Helping You?
I hope you are getting value from these axioms. Please send me through your feedback and thoughts.
