Recentemente li um post do Guilherme Chapiewski sobre Automatização, e isso me lembrou que o Neal Ford escreveu um capítulo inteiro sobre automação (ou automatização) em seu último livro, “The Productive Programmer“.
Para ele, existem quatro “Princípios de Produtividade do Programador” (ele também relata que esse é o nome mais pretencioso que conseguiu achar).
Os princípios são: aceleração, foco, automação e canonicidade (alguém lembrou de ubiquitous language?); e cada um deles é tratado em um capítulo dedicado na primeira parte do livro. A leitura é bastante dinâmica e basicamente concentra dicas para serem adotadas / adaptadas ao dia-a-dia do programador e de sua equipe.
O ponto de Neal Ford é que os programadores não utilizam seus computadores com tanta eficiência hoje como se fazia antigamente:
I’ve been developing software for many years (cue the maudlin “Back in my day, we had kerosene-powered computers…”). During that time, I’ve observed an interesting phenomenon: developers are getting less efficient, not more. Back in ancient times (a couple of decades in computer time), running a computer was a difficult job, much less programming the thing. You had to be a really clever developer to get anything useful from the beastly machine. This crucible forged Really Smart Guys who developed all sorts of efficient ways to interact with the intractable computers of their age.
Slowly, due to the hard work of programmers, computers became easier to use. This innovation was really to stop users from complaining so much. The Really Smart Guys congratulated themselves (as all programmers do when they can get a user to pipe down). Then a funny thing happened: a whole generation of developers came along who no longer needed clever tricks and devious intelligence to get computers to do what they wanted. The developers, like the end users, basked in the easier-to-use computers. So, what’s wrong with that? After all, productivity is a good thing, right?
It depends. What is productive for a user (nice graphical user interface, mice, pull-down menus, etc.) can actually be a hindrance to someone trying to get the best performance from a computer. “Easy to use” and “efficient” overlap infrequently. Developers who grew up using graphical user interfaces (OK, I’ll just go ahead and say it: Windows) don’t know many of the cool, efficient tricks of the trade of the Really Smart Guys of yesteryear. Developers today are not running their computers, they are walking them. I’m going to try to fix that.
[...]
Computers are designed to perform simple, repetitive tasks over and over really fast. Yet an odd thing is happening: people are performing simple, repetitive tasks by hand on computers. And the computers get together late at night and make fun of their users. How did this happen?
Na seção 4.13 do livro ele apresenta uma justificativa para a automação de tarefas que é uma argumentação bem interessante:
When you deploy your application, it takes only three steps: run the “create tables” script on the database, copy the application files to your web server, and update the configuration files for the changes you’ve made to the routing for your application. Simple, easy steps. You have to do this every couple of days. So, what’s the big deal? It takes only about 15 minutes. What if your project lasts eight months? You will have to go through this ritual 64 times (actually, the pace will pick up as you near the finish line and have to deploy it a lot more often). Add it up: 64 times performing this chore x 15 minutes = 960 minutes = 16 hours = 2 work days. Two full work days to do the same thing over and over! And this doesn’t take into account the number of times you accidentally forget to do one of the steps, which costs more time in debugging and repairing. If it takes you less than two days to automate the whole process, then it’s a no-brainer because you get pure time savings back. But what if it takes three days to automate it—is it still worth it?
I have encountered some system administrators who write bash scripts for every task they perform. They do this for two reasons. First, if you do it once, you’re almost certainly going to do it again. Bash commands are very terse by design, and it sometimes takes a few minutes even for an experienced developer to get it right. But if you ever have to do that task again, the saved commands save you time. Second, keeping all the nontrivial command-line stuff around in scripts creates living documentation of what you did, and perhaps why you performed some task. Saving everything you do is extreme, but storage is very cheap—much cheaper than the time it takes to recreate something. Perhaps you can compromise: don’t save every single thing you do, but the second time you find yourself doing something, automate it. Chances are excellent that if you do it twice, you’ll end up doing it 100 times.
[...]
You will see lots of chores in your projects that you would like to automate away. You have to ask yourself the following questions (and be honest with your answers):
- Will it save time in the long run?
- Is it prone to errors (because of lots of complex steps) that will rob time if done incorrectly?
- Does this task destroy my focus? (Almost any task takes you away from your locus of attention, making it harder to get back to your focused state.)
- What is the hazard of doing it wrong?
The last question is important because it addresses risk. I was once on a project with people who, for historical reasons, didn’t want to create separate output directories for their code and the tests. To run the tests, we needed to create three different test suites, one for each kind of test (unit, functional, and integration). The project manager suggested that we just create the test suite by hand. But we decided to take the time to automate its creation via reflection instead. Updating the test suite by hand is error prone; it is too easy for a developer to write tests and then forget to update the test suite, meaning that his work will never get executed. We deemed the hazard of not automating as too great.
One of the things that will probably worry your project manager when you want to automate some task is that it will spiral out of control. We all have the experience of thinking that we can get something done in two hours only to have it quickly turn into four days. The best way to mitigate this risk is to timebox your efforts: allocate an exact amount of time for exploration and fact gathering. At the end of the timebox, re-evaluate objectively whether completely pursuing this task is feasible. Timeboxed development is about learning enough to make realistic judgments. At the end of a timebox, you may decide to use another one to find out more. I know that the clever automation task is more interesting than your project work, but be realistic. Your boss deserves real estimates.
Falando em automação, uma ótima ferramenta para isso é o Capistrano. O custo da automação de tarefas pode trazer benefícios imprevisíveis. É como se fosse um investimento e um seguro ao mesmo tempo.
Pense nisso… e faça as máquinas trabalharem enquanto você pode se dedicar a fazê-las produzir ainda mais. Ainda sobra tempo para realizar tarefas mais interessantes!