A arte da guerra aplicada ao desenvolvimento de software

Se você trabalha na indústria de software, é provável que já tenha ouvido falar sobre o paradigma de design dividir e conquistar , que basicamente consiste em dividir recursivamente um problema em dois ou mais subproblemas ( divide ), até que estes se tornem simples o suficiente para serem resolvidos diretamente ( conquistar ).

O que você pode não saber é que esse paradigma se origina de uma antiga estratégia política (o nome é derivado do ditado latino divide et impera ) que sugere que é possível manter o controle sobre seus subordinados ou súditos incentivando a dissidência entre eles.

Essa estratégia foi usada por inúmeros políticos e líderes militares ao longo da história, como Júlio César (que a usou durante as Guerras da Gália para derrotar os gauleses militarmente fortes) e Napoleão (o especialista em artilharia francês dividiria as tropas inimigas para que nenhuma porção fosse mais forte do que suas próprias tropas e, em seguida, interromper suas comunicações, impedindo os esforços do inimigo para coordenar e executar ataques).

A Arte da Guerra: Princípios Antigos Aplicados ao Desenvolvimento

No entanto, a regra de dividir e conquistar não é a única estratégia política que pode ser aplicada ao desenvolvimento de software. Embora política e guerra tenham pouco a ver com desenvolvimento de software, assim como políticos e generais, os desenvolvedores devem liderar subordinados, coordenar esforços entre equipes, encontrar as melhores estratégias para resolver problemas e administrar recursos.

A Arte da Guerra é um antigo tratado militar escrito no século V aC e atribuído a Sun Tzu, um antigo estrategista militar chinês, cujas teorias tiveram uma profunda influência na filosofia oriental e ocidental.

Apesar de sua idade, o texto ainda está incluído no programa de muitas escolas militares no leste da Ásia e é listado como leitura recomendada em algumas academias militares no Ocidente. O texto está dividido em 13 capítulos, cada um dedicado a um aspecto diferente da guerra.

No entanto, além da guerra, os princípios e ensinamentos de Sun Tzu têm aplicações práticas na política, negócios, esportes e, acredite ou não, no desenvolvimento de software. Na verdade, você pode estar aplicando alguns desses princípios em sua rotina diária, mesmo sem saber suas origens.

Detalhado abaixo, você encontrará uma breve lista de táticas e dicas básicas explicadas na Arte da Guerra. Eles provavelmente podem ser aplicados ao seu trabalho na indústria de software ou em qualquer outra indústria.

O tempo é crucial em qualquer campanha

Capítulo II, parágrafo 2

Quando você se envolve em uma luta real, se a vitória demorar a chegar, as armas dos homens ficarão embotadas e seu ardor será amortecido.

Este princípio pode ser aplicado ao desenvolvimento de software, como regra descrevendo a relação entre a duração dos ciclos de desenvolvimento e a moral do desenvolvedor.

Se um grupo de desenvolvedores trabalha nos mesmos projetos por meses, sem objetivos claros ou fim à vista, eles podem ficar frustrados e sua produtividade pode diminuir.

O desenvolvimento de software é um esforço intelectual, então a motivação é o principal combustível para a produtividade. Trabalhar todos os dias sem perceber que seu trabalho está gerando resultados reais pode ser muito desmotivador.

Conforme indicado em algumas metodologias ágeis, o roteiro de desenvolvimento deve ser dividido em várias metas e marcos, que a equipe poderá alcançar em curtos prazos, e que lhes dará uma sensação de progresso e conquista.

Capítulo II, parágrafo 18

Na guerra, então, que seu grande objetivo seja a vitória, não longas campanhas.

Esta frase pode ser interpretada de duas maneiras:

Primeiro, pode ser visto como um precursor da filosofia UNIX: Escreva programas que fazem uma coisa e fazem bem . Ao desenvolver um software, você deve sempre ter em mente o objetivo principal do programa, o principal recurso que ele oferece ou o maior problema que ele resolve e garantir a implementação adequada.

Às vezes, você pode se inspirar e pensar em um recurso muito legal para adicionar, mas não se esqueça de que os aplicativos que têm muitos recursos usados ​​com pouca frequência têm um nome depreciativo: bloatware .

Em segundo lugar, a declaração também pode ser considerada como precursora de um dos princípios de desenvolvimento de software enxuto: Entregue o mais rápido possível .

Quanto mais cedo você entregar o software sem grandes defeitos, mais cedo você receberá feedback do cliente e poderá incorporar as alterações na próxima iteração.

Se, por outro lado, você entregar um software que não funciona, você perderá um feedback valioso, porque os clientes não terão a chance de testá-lo adequadamente. Isso tornará o próximo estágio de desenvolvimento mais difícil ou impossível em situações em que sua próxima iteração depende do feedback do cliente.

Sem liderança, sem resultados

Capítulo III, parágrafo 11

Agora o general é o baluarte do Estado; se o baluarte estiver completo em todos os pontos, o Estado será forte; se o baluarte for defeituoso, o Estado será fraco.

Esta citação descreve a importância do papel do gerente em uma equipe de desenvolvimento: o sucesso de um projeto depende da força de todas as pessoas envolvidas, e o gerente é o baluarte do projeto. A responsabilidade começa no topo.

Embora os desenvolvedores frequentemente trabalhem sozinhos (cada um sentado atrás de um computador, com comunicação limitada com colegas de trabalho), isso não significa que eles não precisem de uma boa liderança. Os gerentes de projeto são responsáveis ​​por manter a equipe no caminho certo, garantindo uma comunicação eficaz e resolução de disputas, e os líderes, obviamente, definem as prioridades do projeto (entre outras tarefas), portanto, seu papel não deve ser subestimado. Nem a responsabilidade deles se algo der errado. Imagine o que aconteceria com um líder militar cuja unidade não cumprisse seu dever no campo de batalha?

Uma equipe pode produzir um ótimo software mesmo que tenha algumas maçãs podres nas posições de desenvolvimento, mas isso é improvável de acontecer se o gerente de projeto for a maçã podre , não importa quantos desenvolvedores rockstar a equipe tenha.

Capítulo VI, parágrafo 28

Não repita as táticas que lhe renderam uma vitória, mas deixe seus métodos serem regulados pela infinita variedade de circunstâncias.

Às vezes, ao iniciar um projeto, é tentador usar o mesmo conjunto de tecnologias que usamos em projetos anteriormente bem-sucedidos (a mesma linguagem de programação, as mesmas bibliotecas, o mesmo servidor etc.). No entanto, a menos que os requisitos dos novos projetos sejam exatamente os mesmos dos anteriores, essa pode ser a abordagem errada.

Na programação, como na maioria dos domínios, a panacéia (um suposto remédio capaz de curar todas as doenças) não existe. Não existe uma combinação única de tecnologias que você possa usar para resolver todos os problemas; cada tecnologia tem suas vantagens e desvantagens.

É claro que aprender uma nova linguagem de programação ou usar uma API desconhecida pode ser caro inicialmente, mas a longo prazo, a qualidade do software será superior e você se tornará um desenvolvedor melhor.

Capítulo XIII, parágrafo 27

Portanto, é apenas o governante esclarecido e o general sábio que usarão a mais alta inteligência do exército para fins de espionagem e, assim, alcançarão grandes resultados. Os espiões são o elemento mais importante na guerra, porque deles depende a capacidade de movimento de um exército.

Essa frase pode ser interpretada como a importância do uso de ferramentas de monitoramento e bibliotecas de log durante a fase de manutenção.

Embora às vezes os clientes não pensem assim, o desenvolvimento não termina quando você obtém uma versão estável e totalmente testada. O software está sempre evoluindo, seja corrigindo bugs, adicionando novos recursos ou melhorando a eficiência.

E não há melhor fonte de informação para saber quais mudanças fazer do que ter espiões monitorando o software em ambientes de produção, verificando quais recursos são mais utilizados, os erros mais comuns e as operações mais demoradas.

Relatórios de erros, entradas de log e dados de uso são fundamentais para detectar bugs, identificar gargalos e outros problemas, pois nem sempre é possível reproduzir as mesmas condições em ambientes de teste controlados.

Trabalho em equipe e motivação

Capítulo X, parágrafo 24

Aquele que avança sem buscar fama, Que retrocede sem escapar da culpa, Aquele cujo único objetivo é proteger seu povo e servir a seu senhor, O homem é uma jóia do Reino.

Basicamente, esta é a antiga versão chinesa de “não há eu na equipe” . É mais importante trabalhar em conjunto com os outros do que buscar o ganho pessoal.

O desenvolvimento de software é uma atividade complexa que exige que os desenvolvedores trabalhem efetivamente em equipe. Um bom desenvolvedor não é aquele que corrige mais bugs, implementa mais recursos ou termina tarefas antes do previsto; um bom desenvolvedor é aquele que ajuda a equipe a atingir seus objetivos.

Reivindicar crédito por tudo que você fez, não reconhecer seus erros ou culpar os outros por eles, ou se chamar de ninja do código pode enganar alguns gerentes inexperientes e pode até conseguir um aumento, mas você se tornará um membro contraproducente de sua equipe.

Capítulo VII, parágrafo 21

Pondere e pondere antes de fazer um movimento.

Essa frase indica a importância das reuniões de desenvolvimento de equipes, como as propostas pelas metodologias ágeis.

Ao trabalhar em equipe, é importante discutir quaisquer mudanças importantes antes de implementá-las. Não importa se você é o líder da equipe, ou se você é a pessoa com mais experiência no assunto, você deve sempre conversar, ou pelo menos informar, o restante da equipe.

Lembre-se de que outros desenvolvedores podem fornecer informações sobre partes desconhecidas do software. Isso significa que eles podem começar a implementar as mudanças mais rápido do que o esperado, porque podem estar totalmente cientes dos efeitos dessas mudanças.

Capítulo X, parágrafo 25

Considere seus soldados como seus filhos, e eles o seguirão até os vales mais profundos; olhe para eles como seus próprios filhos amados, e eles estarão ao seu lado até a morte.

Essa citação indica a importância da motivação, um princípio de gestão que às vezes é esquecido por gestores e líderes de equipe. Desenvolvedores motivados escreverão código melhor, trabalharão mais rápido, cometerão menos erros e estarão mais dispostos a dedicar horas extras.

A motivação deve ser gerada pelos gestores, interessando-se genuinamente por seus subordinados, ouvindo-os, preocupando-se com seu equilíbrio entre vida profissional e pessoal, construindo ambientes de trabalho positivos e cuidando de suas trajetórias de carreira.

Além disso, você não deve confundir motivação com remuneração. Estudos recentes demonstram que o dinheiro não motiva a maioria dos trabalhadores, o dinheiro é principalmente bom para atrair e reter funcionários, mas não para deixá-los felizes com seus empregos. Portanto, aumentos e promoções não devem ser vistos como ferramentas motivacionais.

Pensando fora da caixa

Capítulo V, parágrafo 7, 8 e 9

Não há mais de cinco notas musicais, mas as combinações dessas cinco dão origem a mais melodias do que jamais se pode ouvir.

Não há mais de cinco cores primárias, mas em combinação elas produzem mais matizes do que jamais se viu.

Não há mais de cinco sabores cardinais, mas as combinações deles produzem mais sabores do que jamais podem ser experimentados.

Uma das coisas boas da programação é que as possibilidades são infinitas; você pode desenvolver basicamente onde quiser (pelo menos, desde que não seja um problema NP-completo).

Aplicativos móveis, sites, jogos, aplicativos de desktop… se você sabe programar, todos eles estão ao seu alcance.

Capítulo III, parágrafo 1

Na arte prática da guerra, o melhor de tudo é tomar o país do inimigo inteiro e intacto; despedaçá-lo e destruí-lo não é tão bom. Assim, também, é melhor capturar um exército inteiro do que destruí-lo, capturar um regimento, um destacamento ou uma companhia inteira do que destruí-los.

Ao trabalhar em um projeto com uma grande base de código, é comum encontrar módulos ou seções de código que foram implementados com más práticas ou usando bibliotecas obsoletas. Embora possa ser tentador apagar (ou destruir) esse código, pode não ser a melhor ideia por vários motivos:

• O código legado não é necessariamente ruim, às vezes é um código bom que foi escrito quando outras metodologias e tecnologias foram consideradas o caminho a seguir. No entanto, só porque é antigo não significa que não está funcionando.

• Você pode perder tempo corrigindo o código que ainda funciona em vez de se concentrar na correção de outras partes mais críticas do código.

• A menos que você tenha certeza do que está fazendo, substituir uma seção de código que funciona significa que você corre o risco de introduzir novos erros ou bugs.

Isso não significa que a frase “Se não está quebrado, não conserte” seja uma boa estratégia, mas que todo projeto tem prioridades, objetivos e restrições de tempo. Portanto, se você encontrar um código que possa ser melhorado, discuta-o com o restante da equipe ou com o gerente de projeto para descobrir quando otimizá-lo.

Capítulo VIII, parágrafo 3

Há estradas que não devem ser seguidas, exércitos que não devem ser atacados, cidades que não devem ser sitiadas, posições que não devem ser contestadas, ordens do soberano que não devem ser obedecidas.

Mesmo que não o diga diretamente, poderíamos interpretar esse princípio como um alerta para evitar antipadrões.

Embora o uso de um antipadrão possa resolver um problema de curto prazo, lembre-se de que, a longo prazo, será contraproducente. Portanto, não importa quanto tempo você economize, quantos bugs você corrija ou quão conveniente seja para você, evite-os.

Ainda assim, há momentos em que você pode ficar tentado a usar um antipadrão para resolver uma tarefa urgente, prometendo a si mesmo que implementará uma correção adequada quando tiver mais tempo, mas lembre-se de uma das leis de Murphy: todas as correções rápidas se tornam mudanças permanentes.

Conclusão

Embora desenvolver software seja diferente de comandar soldados na guerra ou liderar um país, tudo isso deve resolver problemas que exigem trabalho em equipe, boa liderança, eficiência e soluções de longo prazo.

No entanto, a Arte da Guerra não é o único livro que contém princípios que podem ser aplicados ao desenvolvimento de software. O Príncipe , de Nicolau Maquiavel, é um exemplo.

Na verdade, aqui está uma lista de citações de Maquiavel que ainda são relevantes. Tente adivinhar quais são os princípios correspondentes no mundo do desenvolvimento de software.

1. O leão não pode se proteger das armadilhas e a raposa não pode se defender dos lobos. É preciso, portanto, ser uma raposa para reconhecer as armadilhas e um leão para assustar os lobos.
2. Nunca tente ganhar pela força o que pode ser ganho pelo engano.
3. Nunca algo grande foi alcançado sem perigo.
4. Quem deseja o sucesso constante deve mudar sua conduta com os tempos.
5. Os homens em geral julgam mais pelas aparências do que pela realidade. Todos os homens têm olhos, mas poucos têm o dom da penetração.
6. Aquele que deseja ser obedecido deve saber mandar.
7. A sabedoria consiste em saber distinguir a natureza do problema e em escolher o mal menor.
8. Não há como evitar a guerra; ela só pode ser adiada em benefício de seu inimigo.
9. A natureza cria poucos homens corajosos; indústria e formação faz muitos.