The First Rule of Automation
Automation really is the talk of the future. The general zeitgeist is that automation will slowly take over the world and make an increasing number of jobs obsolete. The trend is definitely moving in that direction with the cheap availability of technology, and easy access to tools that allow for data analysis and artificial intelligence. In this landscape, software engineering starts to take on a mythos wherein so many people see it as a magic wand to be able to automate everything. While software engineering is definitely needed for automating the unskilled (and potentially skilled tasks), we will still need skilled workers for the future.
While there are several different details that can be addressed as far as the future of automation, what is possible, and what is not possible, etc, the purpose here is not to talk about all of these. More the purpose of this article is to understand the first step in automating any process before even thinking about touching any code. This is also assuming you have determined what you want to automate. The reality, is that you need to fully understand the problem and how you want each situation to be addressed.
The first step in automating your project is to fully understand the problem and how you want your program to respond to each situation. Too many times, someone will set out on an automation project without understanding what exactly the problem is, then get bogged down in all the details on how to build something instead of understanding what exactly they’re building. If you don’t understand exactly what you’re building, the code you write is not going to be formulated near as well. Just writing code without a clear understanding of the problem often leaves you picking technologies, libraries, frameworks, and designs that don’t fit the problem near as well as if you were to fully understand the problem. You can definitely follow best practices in the industry to ensure your system is more extensible, resistant to defects, and everything else, but you’re missing out on creating designs that capture what exactly you’re looking to do.
Automation is only as good as you understand the problem. A more difficult problem may require the use of experts. For example, if you’re trying to automate the work (or some amount of the work) an accountant does every day, I would daresay that you probably won’t know a whole lot on what exactly you are or should be automating without talking to at least one (and preferably a couple) of good accountants who have been in the frontlines of the industry for a long time and have had a chance to see and work through many of the problems in that field. This input is crucial to solving the problem.
Having the desire to write code and automate some task or process is a great first start to be. The process of automating a manual task is technical and full of problems to be solved, something that software engineers thoroughly enjoy. However, being able to write code (even really well designed code) alone is not enough to automate most o the tasks out there. There are definitely opportunities to automate small and simple tasks, though typically you can find code and tools already written for this (and this can be a good place to start getting your feet wet with writing your own automation), but most of the interesting things left to be automated require an in-depth analysis of the problem at hand. Don’t let this scare you but to motivate you to really understand the problem you’re trying to solve so that you can write well-designed coding solutions for the problems you’re looking to automate.