Os processos matam a paixão do desenvolvedor

VN:RO [1.9.11_1134]
sexta-feira, 13 d maio d 2011
Por Lucas "Sugis" Lago, Comp09. Siga no Twitter

Melhores práticas parecem boas quando analisadas isoladamente, mas elas podem sugar a vida dos desenvolvedores.

Outro dia, no almoço, eu tive uma pequena epifania. Eu também tinha um garfo de churrasco, mas isso é uma outra história. Em qualquer evento, algo veio a claridade que tinha me incomodado profundamente por algum tempo.

Nos últimos anos, a indústria de software se tornou cada vez mais focada no processo e métricas como uma forma de garatir códigos de “qualidade”. Se você seguisse todas as melhores práticas agora, você faria:

  • TDD completo, escrevendo seus testes antes de implementar o código.
  • Requerer uma porcentagem arbitrária de código checada antes de fazer um check-in.
  • Revisar o código completamente em todos os check-ins.
  • Usar ferramentas como o Coverity ou Sonar para gerar números de complexidade de códigos e requerer refatoração por parte dos desenvolvedores quando o código estiver demasiadamente complexo.

Adicionalmente, se sua companhia tem bebido Tang sabor Scrum, vocês também teria que gastar seus dias com:

  • Geração de cabeçalhos, histórias e tarefas.
  • Limpar as histórias antes de cada sprint.
  • Aturar seções de planejamento.
  • Controlar seu tempo para gerar gráficos para a gerência.

Resumindo, você estará usando boa parte do seu tempo com o processo, e cada vez menos tempo realmente programando a aplicação. Eu trabalhei em algus projetos onde os casos de testes duravam duas ou três vezes mais que programar o código em si, ou onde a necessidade de marretar os testes de unidades reduziram a legibilidade do código. Eu também vi exemplos de desenvolvedores tendo que enganar as ferramentas para atingir metas de quantidades de linhas e complexidade de códigos. A recursão subsequente faz com que isso seja progressivamente pior para o programador passional que escreve um código ótimo, mas o processo mata a paixão. Programadores desinteressados escrevem códigos ruins, códigos ruins fazem com que a gerência adicione mais processos na tentativa de “fazer” com que programadores escrevam bons códigos. E isso somente piora a moral.

Agora, eu certamente não estou advogando para uma abordagem velho-oeste onde nada é testado, e os desenvolvedores programam o que querem ignorando as agendas, etc. Mas a aplicação cega de processos de melhores práticasatravés de todo o desenvolvimento está tornando o que deveria ser um processo criativo em um relatório financeiro com gráficos com um toque de prisão. Enquanto cada um destes bambolês parece bom isoladamentes (exceto talvez o Scrum…), fazer os desenvolvedores passarem por todos eles vai desmoralizar até o mais apaixonado dos geeks.

Eu não tenho a bala mágica aqui, mas as companhias precisam começar a aceitar que existe uma diferença qualitativa entre os desenvolvedores. Fazer com que todos eles usem arados de mesmo peso para garantir que nenhum deles cometa erros é prejudicial para a moral e eficiencia como um todo. Agora, isso pode soar um pouco arrogante: “Eu sou um desenvolvedor experiente, eu não preciso de nenhum desses recém-criadas práticas para fazer bom código.” Mas, por exemplo, talvez desenvolvedores júniores (ou especializados) devessem escrever testes de unidades, deixando os desenvolvedores mais calejados livres para se concentrar na real implementação da aplicação. Talvez você não precise micro-gerenciar eles com seus updates diários do VersionOne para ter certeza que eles estão comprometidos com o sprint.

Talvez uma olhadinha no código seja preferível a um processo de revisão formal.

E um segredo, se voce está dizendo que voce está praticando desenvolvimento ágil, então pratique um desenvolvimento ágil!!! Um projeto onde você decidiu antes de iniciar o ciclo do produto as características que devem ter no produto, a data em que deve ser entregue, e os recursos necessários é um projeto cascata. Usar termos como “histórias” e “sprints” apenas inserem uma casca ágil quebradiça, e é loucura pensar qualquer coisa além disso. E francamente, isso é o que levou a toda a mentalidade Scrum/Burn Down Charts, porque as equipes de desenvolvimento não tema  flexibilidade para “entregar o que está pronto, quando estiver pronto.”

A não ser que os problemas que eu estou falando sejam atacados, eu temo que o ciclo negativo processo/paixão irá continuar a dragar desenvolvedores engajados em um pântano de reuniões e jogos de métricas.

Traduzido daqui.

VN:F [1.9.11_1134]
Rating: 1.0/5 (1 vote cast)
Os processos matam a paixão do desenvolvedor, 1.0 out of 5 based on 1 rating
Related Posts with Thumbnails

6 Comentários para “Os processos matam a paixão do desenvolvedor”

  1. Paulo

    Cara, teu texto tá com muito anglicanismo, um monte de expressões traduzidas direto do inglês (‘bala mágica’, ‘advogando para’, ‘em qualquer evento’) que, francamente, não funcionam bem em português, e o texto ainda soa pedante; ou então parece saído direto do google translate. O nome disso é expressão idiomática por um motivo: funciona bem naquele idioma.

    Sobre o excesso de processos matar a criatividade, eu acho uma questão bem delicada mesmo. Parece que no final das contas o que importa de verdade é a qualidade dos desenvolvedores e a sinergia que se consegue extrair da equipe, o processo sendo uma coisa secundária, mas ainda assim muito importante; basta considerar a diferença entre um processo em cascata e um processo ágil: a velocidade de obtenção dos primeiros resultados, a maleabilidade no escopo do projeto, são características definidas principalmente pelo processo seguido.

    Fora isso, concordo com você que o excesso de ferramentas de métricas e controles nunca vão fazer um desenvolvedor desinteressado produzir trabalho melhor; mais provável desmotivar quem já estava trabalhando com motivação e produzindo código de qualidade.

    Um ponto que eu achei interessante é a idéia de colocar juniores pra acrescentar testes e implementar features menores no começo, taí uma prática que pode bem ter as suas vantagens.

    VA:F [1.9.11_1134]
    Rating: 0 (from 0 votes)
    #500
    • Até concordo com o excesso de anglicanismos.. realmente foi por um pouco de incompetencia do tradutor aqui…

      Vai um pouco da pressa de publicar o negócio, e de estar fazendo em paralelo com outras coisas…

      Juro solenemente revisar o texto eventualmente! =)

      VN:F [1.9.11_1134]
      Rating: +1 (from 1 vote)
      #501
      • Paulo

        ah, o texto foi traduzido mesmo, eu passei batido o link ali embaixo. Po menos mal, eu achei que vc escrevia assim habitualmente, me senti obrigado a comentar! hehehe!

        VA:F [1.9.11_1134]
        Rating: -1 (from 1 vote)
        #502
        • Sim o texto foi traduzido…

          Infelizmente no processo de tradução eh foda matar os anglicanismos…

          Quanto ao ponto de usar pessoas menos experientes para tarefas menores no início, seria realmente muito mais eficiente do que fazer toneladas de revisão de códigos complexos escritos por pessoas sem prática… =)

          VN:F [1.9.11_1134]
          Rating: 0 (from 0 votes)
          #503
  2. Leandro

    Lucas achei bacana o texto que você colocou ai, porem o titulo esta dizendo ao contrario, pois você “fala” que não deve ser feito isoladamente, no entanto o texto é claramente uma analise isolada do ponto de vista de um desenvolvedor.
    Porem acredito que os processos deixa algumas coisas mais engessadas, mais sem duvida nenhuma o resultado final, é um produto de mais qualidade, os processos existe para evitar o retrabalho, e para garantir que la na frente um erro não precise voltar la pra traz na primeira etapa, ou seja, se a cada etapa o processo pontuar os erros ocorridos, evita muita coisa la na frente.
    Infelizmente hoje as empresas tem que pensar em um todo e não somente em um setor.
    Att,

    VA:F [1.9.11_1134]
    Rating: 0 (from 0 votes)
    #571
  3. Mario

    Interessante o ponto de vista citado, mas o que tenho vivido é que os processos existem para ajudar o desenvolvedor a conseguir um melhor resultado no final, quando se trabalha com grandes aplicações e grandes equipes isto é fundamental para auxiliar na comunicação e garantir que não se esqueçam de detalhes importantes. Claro que o processo deve fazer sentido e se adequar a realidade do projeto e da equipe. Mas lembre-se aquele fix em 5 minutos feito no ultimo momento pode gerar muita dor de cabeça a todos depois que for feito deployment em produção, se não tiver sido adequadamente testado e revisto.

    VA:F [1.9.11_1134]
    Rating: 0 (from 0 votes)
    #589

Deixe um Comentário

Spam Protection by WP-SpamFree

Get Adobe Flash playerPlugin by wpburn.com wordpress themes