The Importance of Automation
Automation makes a world of difference in how effective you are as a developer. I’ve worked in a few places now, and I can tell a huge difference between the type of developer that focuses on development alone versus the developer that focuses on a lot more…
The ‘Normal’ Development Process
The ‘Normal’ Steps
- Get requirements
- Plan out the architecture (maybe)
- Write some or all of the code
- Compile (if necessary) and test. (Multiple loops of writing code and testing for those that develop in a smarter way without waiting until the end to test everything)
You Just THOUGHT It Was Finished…
Once all the manual testing finishes and the code works as expected, it gets checked into source control. End of story, everybody lives happily-ever-after, right?
If you are lucky, a bug turns up a day or two after the source code was committed to source control. The more likely case is that weeks pass before that bug shows up. So what happens then?
- Manually reproduce the issue
- Write code to fix it
- Manually verify the issue is gone
- Commit to source control
So… end of story, everybody lives happily-ever-after, right?
Congratulations, now you have two problems. This pattern repeats, over and over. Eventually, it is time to ship code and you cannot wait any longer. Even worse, every time a new problem occurs, the same process is used to fix those bugs. What is going to change? How are you going to make everything better?
AH! We can rewrite all the code! It is obvious those previous people writing the code did not know what they were doing. They were obviously idiots. So you re-architect the whole thing. It’s a masterpiece. So… end of story, everybody lives happily-ever-after, right?
On a more personal note, I hate this approach. A lot of the developers I’ve worked with still work with tools/methods that were popular in the 90’s. This is one of the big problems with developers that do not keep up with current trends. You end up working in a much less efficient way due to not keeping your skills up to date. For those who are not familiar with better methods, it is the norm. They believe it is an inevitable part of development.
It does not have to be that way. In addition, it drives those of us who know better approaches to go crazy (and causes potential to lose your good developers!). It is usually difficult to teach people new ways of doing things. At times, these developers are not willing to learn something new. On one side of the spectrum, it is a bit uncomfortable. On the other side of the spectrum, you are stuck in an environment where your code works relatively well, and you spend most of your time working on other people’s bugs/bad design. And don’t get me started on deadlines pushed by management that cause some to take shortcuts…
I think you get the point by now. Unfortunately, despite our best efforts or design, bugs do crop up. We need a smarter way to stop the whole develop -> manually test -> bug turns up a lot later -> develop -> manually test -> etc. process. This is where automation can make a huge difference.
Automation Makes Us More Efficient Developers
Suppose that rather than manually testing everything every time a change is made, there is a set of automated tests that run within seconds that test most of the functionality. Such a concept exists called unit tests. Let’s see how the cycle goes with bugs now.
- Write an automated test to capture the issue (versus manually reproducing the issue). This means the test should fail.
- Write code to fix the failing test.
- Integrate the code (it’s a good practice to also manually verify the fix worked).
- Commit to source control.
So what happens now? Perhaps your changes cause another bug, but if that automated test is run automatically every time a code commit occurs, that same bug will not occur again (if you don’t ignore a failing test). So rather than create new bugs every time, the code becomes more and more stable as more and more automated tests get run every time a code change is made.
Running those automated tests after a code commit can happen automatically (as well as email alerts when the code fails those tests). This is called continuous integration. Tools such as Jenkins, TeamCity, and GitCI can help automate that testing. Yay! We’ve stopped the cycle of insanity (the code -> manual test -> check-in code cycle) and now have an actual process that will stop many bugs occurring over time (versus what we could call the ‘hope’ method).
If you need to deploy your code to a different machine, you can potentially use something like Docker or a VM. Why would you do this? If you completely duplicate the environment, you are eliminating almost all chances of potential bugs cropping up from environment issues. I can’t tell you how many times I or someone on a team I am working on has been bitten by a different version of Python, Linux, or something similar. If you can develop in the same environment as what gets deployed, you minimize the risk of some issue occurring in deployment. Just one less thing to have to worry about.
Want to Learn More?
Posts in this blog will look at these different types of automation and more. Learning these things can make you a much more efficient developer. You can be a developer that others depend on to get things done (I have heard this from my co-workers several times). Others will know your software will just work most of the time without having to track down very many issues. In short, you will be a reliable developer that others enjoy working with.