Quando devemos parar de trabalhar e fazer ferramentas?

Como engenheiro de software, estamos sempre ansiosos por obter ferramentas eficazes para aumentar nossa produtividade. E em nosso trabalho diário, geralmente somos insatisfatórios com as ferramentas existentes e gostaríamos de ter maneiras melhores, como uma melhor configuração de script GDB, script Vim e algum script Python para automatizar as coisas chatas.

No entanto, é realmente uma troca, já que a fabricação de ferramentas também precisa de tempo e energia. Não oferece aumento de produtividade imediatamente. Portanto, como você julga se é hora de parar o trabalho e fazer algumas ferramentas para aliviar sua dor futura?

Eu "faço ferramentas" quando uma delas é verdadeira:

1. A tarefa está me irritando
2. O risco de erro humano na tarefa é muito grande

O "risco" para a 2ª opção não precisa ser enorme - o custo de criar uma ferramenta pequena é geralmente pequeno; portanto, se tudo o que você economiza é o risco de executar uma compilação de 10 minutos novamente uma vez por semana, geralmente pagar-se muito rápido.

Eu tento fazer as ferramentas o menor possível - apenas torne a tarefa um pouco mais fácil agora e talvez melhore novamente na próxima vez.

Isso significa que você só corrige a maior dor de cada vez e não cria correções para problemas que realmente não o machucam.

Com a experiência, descobri que apenas trabalhar duro no trabalho pesado geralmente é o mais eficiente em termos de tempo. Fazer uma ferramenta geralmente é tentador. Desisto de resistir quando:

• A ferramenta tem mais de um propósito. Um bom jogador de xadrez realizou duas coisas a cada jogada: bloquear uma peça do adversário e libertar um bispo. Um iniciante provavelmente precisaria de dois turnos para fazer isso. Da mesma forma, considero se a ferramenta faria apenas uma coisa, ou com um pequeno esforço extra, duas, por exemplo, ajudar a corrigir alguns arquivos de dados brutos e também criar dados de teste artificiais.
• Utilidade futura. Isso pode me poupar tempo para o trabalho desta semana, mas é provável que eu ou outra pessoa economize tempo em um novo projeto na próxima semana?
• É um bom momento para aprender um novo idioma, biblioteca, técnica de design ou qualquer outra coisa, e eu tenho tempo para fazê-lo. A ferramenta é um efeito colateral benéfico de se fazer algo educacional, usando o tempo já concedido para a educação.
• Quando estamos tendo sérios problemas para fazer as coisas funcionarem. Como pára-quedismo sem pára-quedas, você realmente deve reservar um tempo para fazer ou comprar um para-quedas. Se você não obtiver resultados experimentais significativos ou o novo aplicativo Web não funcionar, basta parar e criar ou comprar uma ferramenta para medir o que você não pode ver, conduzir componentes ou substituir parte do sistema. Quando o trabalho é totalmente interrompido, na necessidade de uma ferramenta, não me importo com uso futuro ou uso múltiplo. A necessidade pesa o suficiente.

Minha regra geral é que, quando tenho que fazer algo pela terceira vez, é hora de escrever um pequeno script para automatizá-lo ou repensar minha abordagem.

Não estou criando uma "ferramenta" completa neste momento, apenas um pequeno script (geralmente bash ou python; o perl também funcionaria ou até PHP) que automatiza o que eu fazia manualmente antes. É basicamente uma aplicação do princípio DRY (ou o princípio Fonte Única da Verdade, que é essencialmente a mesma coisa) - se você precisar alterar dois arquivos de origem em conjunto, deve haver alguma verdade comum que eles compartilhem, e que a verdade deve ser fatorada e armazenada em um local central. É ótimo se você pode resolver isso internamente refatorando, mas às vezes isso não é possível, e é aí que entram os scripts personalizados.

Posteriormente, o script pode ou não evoluir para uma ferramenta completa, mas geralmente começo com um script muito específico, com muitas coisas codificadas nele.

Eu odeio o trabalho pesado com paixão, mas também acredito fortemente que é um sinal de design ruim ou incorreto. Ser preguiçoso é uma qualidade importante em um programador, e é melhor que você se esforce ao máximo para evitar trabalho repetitivo.

Claro, às vezes o saldo é negativo - você passa três horas refatorando seu código ou escrevendo um script para economizar uma hora de trabalho repetitivo; mas, geralmente, o saldo é positivo, mais ainda se você considerar os custos que não são diretamente aparentes: falha humana (humanos são muito ruins em trabalhos repetitivos), base de código menor, melhor capacidade de manutenção devido à redundância reduzida, melhor auto-documentação, futuro mais rápido desenvolvimento, código mais limpo. Portanto, mesmo que o saldo pareça negativo agora, a base de código crescerá ainda mais e a ferramenta que você escreveu para gerar formulários da web para três objetos de dados ainda funcionará quando você tiver trinta objetos de dados. Na minha experiência, o equilíbrio é geralmente estimado em favor do trabalho pesado, provavelmente porque tarefas repetitivas são mais fáceis de estimar e, portanto, subestimadas, enquanto refatoração, automação e abstração são percebidos como menos previsíveis e mais perigosos e, portanto, superestimados. Geralmente, a automação não é tão difícil, afinal.

E há o risco de fazê-lo tarde demais: é fácil refatorar três novas classes de objetos de dados e criar um script que gere formulários da Web para elas. Depois de fazer isso, é fácil adicionar mais 27 classes que Também trabalhe com seu script. Mas é quase impossível escrever esse script quando você atinge um ponto em que existem 30 classes de objetos de dados, cada uma com formulários da Web manuscritos e sem consistência entre elas (também conhecida como "crescimento orgânico"). Manter essas 30 classes com seus formulários é um pesadelo de codificação repetitiva e substituição semi-manual de pesquisa. A alteração de aspectos comuns leva trinta vezes o tempo necessário, mas a escrita de um script para resolver o problema, o que seria um acaso para o almoço quando o projeto começou, agora é um projeto assustador de duas semanas, com a terrível perspectiva de um mês de duração, que consiste em corrigir bugs, educar os usuários e possivelmente até desistir e reverter para o projeto. base de código antiga. Ironicamente, escrever a bagunça de 30 classes demorou muito mais do que a solução limpa teria, porque você poderia estar usando o script conveniente o tempo todo. Na minha experiência, automatizar o trabalho repetitivo tarde demais é um dos principais problemas em grandes projetos de software de longa duração. porque você poderia estar usando o roteiro conveniente o tempo todo. Na minha experiência, automatizar o trabalho repetitivo tarde demais é um dos principais problemas em grandes projetos de software de longa duração. porque você poderia estar usando o roteiro conveniente o tempo todo. Na minha experiência, automatizar o trabalho repetitivo tarde demais é um dos principais problemas em grandes projetos de software de longa duração.

Acabei de me lembrar disso:

O problema com isso, é claro, é que, na situação da vida real, você não pode medir facilmente esses dados para selecionar a célula certa na tabela. E, como foi mencionado em outras respostas, existem outras variáveis ​​(o risco de erro, a tarefa é muito chata para fazer isso uma única vez, ...) que você precisa adicionar à equação.

Portanto, minha resposta é que realmente depende da situação e você não pode esperar obter uma resposta "correta" para todas as situações. Afinal, a vida seria chata se tivéssemos livros de receitas para tudo.

Este é um grande problema na minha experiência. A criação de ferramentas geralmente é deixada para um desenvolvedor motivado que para de trabalhar para criar a ferramenta. Isso geralmente interfere no desenvolvimento, mesmo que ele forneça valor. A criação de ferramentas precisa ser vista como uma parte integrada do "Processo" de desenvolvimento.

Lembro-me de assistir a revisões de código em que erros de cabeçalho resultariam no agendamento de outra revisão. Muitos destes poderiam ter sido detectados por uma ferramenta. por exemplo, contagem incorreta de sloc, falta de requisitos, erros de formatação. Minha ferramenta escrita em perl gerou o cabeçalho do código entregue e validou os requisitos de um banco de dados Oracle. Como não fazia parte do nosso "Processo", no curto prazo, a ferramenta foi vista como um atraso na entrega.

Toda a equipe precisa parar periodicamente e ver onde há esforços manuais que podem ser automatizados pela criação da ferramenta.

Todas as outras respostas são boas, mas eu acrescentaria mais um motivo pelo qual é valioso gastar tempo para criar pequenas ferramentas (e personalizar seu .vimrc, .emacs etc.):

Às vezes, você fica criativo ou motivado "preso em um barranco" e, fazendo alguma coisa, qualquer coisa, "faz com que os sucos fluam" novamente (para misturar metáforas). Idealmente, isso seria algo que impulsionaria o projeto de forma produtiva, mas se for um pouco tangencial e que o inspire, também será bom.

Você pode não estar olhando para uma tela em branco, mas simplesmente tendo problemas para ver o progresso que está fazendo em uma grande tarefa. Nessa situação, marcar algo tangível pode impedir que você sinta que não está chegando a lugar algum.

Uma variação disso é quando você fica pensando em algo que deve estar em segundo plano - apenas tomar um momento e fazê-lo fará com que você se perca da mente e liberte você para colocar toda a sua energia na tarefa principal novamente.

Depende do que você considera fazer uma ferramenta. Indiscutivelmente, eu faço várias delas de maneira que outros desenvolvedores considerariam frívolas ... Porque eu as faço para quase tudo, exceto os comandos mais básicos do sistema de arquivos.

Eu uso duas razões para apoiar isso.

• É uma extensão do princípio DRY. Se queremos repetir algo, o esforço manual é o uso menos eficaz de recursos humanos.
• É uma maneira eficaz de registrar o que fiz, por isso, se eu construí alguma coisa, talvez eu (ou outra pessoa) queira consultar como o fiz semanas ou meses mais tarde e mantém o registro do trabalho com o projeto.

Ocasionalmente, crescem em ferramentas maiores e ganham funções interativas, mas, se não o fizerem, ainda terão valor como registro.