%w(Akita On Rails) * 2.0Sua referência de Ruby on Rails e Agilidade

Durante o Encontro de TI que teve esse sábado, tive a chance de trocar idéias com o Guilherme Chapiewski. Caímos no assunto de Net Negative Producing Programmer (NNPP). Eu li sobre esse termo pela primeira vez no artigo do Jay Fields. Depois dele outros bloggers exploraram mais o assunto como o Kris Kemper. Tem também um paper do G. Gordon Schulmeyer explorando em mais detalhes ainda. De qualquer forma, o resumo da ópera é o seguinte:

“Retirar um elemento tecnicamente ruim de uma equipe pode ser mais produtivo do que adicionar um elemento melhor capacitado.”

Ou seja, descobriu que você tem um programador ruim: demita-o, o mais rápido possível! Não há outra solução. Muitos gerentes consideram que programadores ruins ou medíocres, na pior das hipóteses, são apenas mais lentos do que os programadores bons. Mas essa é uma concepção absurdamente errada: um único programador ruim causa prejuízos irreparáveis a um projeto, ou seja, ele não é apenas lento, ele literalmente dá marcha a ré na equipe. O resultado nem sempre é óbvio. A maioria deles é um acumulador de Dívidas Técnicas. Ou seja, a mantenabilidade e extensibilidade são profundamente comprometidas.

Uma coisa é fato: é muito difícil descobrir um programador ruim, principalmente se você, o gerente, não é um programador também. Pior: você precisa ser um bom programador para conseguir descobrir o ruim. Numa equipe razoavelmente balanceada, com programadores pelo menos pouco acima da média e apenas um ou dois elementos ruins, fica mais fácil separar o joio do trigo: a própria equipe vai começar a expurgar a maçã podre de seu meio (se forem espertos). Isso é uma faca de dois gumes, porque agora se você, no papel do programador, acha que seu colega é o ruim, quem garante que os outros não acham que você é quem é o ruim? Se você é um programador, é bom que você garanta o seu. Eu costumo separar “codificadores” de “desenvolvedores”. Ambos são programadores, mas o primeiro grupo é aquele tipo que bate o cartão na entrada, faz apenas o que mandam, vai embora no mesmo horário todo dia e não se preocupa com mais nada. O segundo grupo são os verdadeiros artistas, os que entendem que software é arte e que, como tal, exige dedicação, estudo constante, simplesmente não existe limites de horário comercial. Como eu costumo exemplificar: é a diferença do pintor de paredes para um Da Vinci.

Um gerente precisa ter muita consciência disso: toda equipe de desenvolvimento de software precisa de Líderes Técnicos Sênior. Dica: procure nas comunidades Open Source, você terá melhores chances de encontrar os melhores programadores lá. Não procure em instituições de ensino e, principalmente, desconfie de qualquer programador que mostre primeiro os certificados que tem. Gostei do que o Kris Kemper mencionou no seu blog de como a ThoughtWorks faz para contratar: o candidato passa por uma bateria de testes. Não basta apenas uma ou duas entrevistas: ele precisa passar por vários sêniors da empresa, precisa demonstrar código que será revisado por outros sêniors, ou seja, precisa realmente merecer estar lá. Precisa demonstrar experiência (seguindo Malcolm Gladwell, em Outliers, eu diria que só se deve contratar programadores pertos de atingir as 10 mil horas de experiência, a menos para cargos com tarefas menos importantes), precisa demonstrar desembaraço e excelente capacidade de comunicação, precisa mostrar código, e código bem feito, código que não passaria vergonha na frente de um Martin Fowler.

Agora, eu já vi situações muito ruins, onde uma equipe inteira tem apenas NNPPs. Nesses casos, não há o que fazer: dissolva a equipe inteira. Tome muito cuidado para não cair na tentação do Custo Perdido. Muitos pensam assim: “mas eu já investi tanto tempo e recursos nessa equipe, seria um desperdício jogar tudo isso fora.” Nada disso, ruim é mantê-los criando mais e mais dívida técnica que depois é você quem terá que arcar. Custa mais barato dissolver a equipe, formar uma nova melhor e recomeçar o projeto do zero se for preciso. Você vai parar por 6 meses, mas pelo menos não vai falir daqui 2 anos.

Outra coisa que todo gerente sempre erra: resultado imediato vs. resultado de longo prazo. Isso é uma constante em todas as empresas que já passei: o gerente adora o programador cowboy, aquele sujeito que resolve todos os problemas que ele joga. Todos os cowboys são adeptos do POG, ou a “Programação Orientada a Gambiarra”. Seria engraçado se não fosse trágico: isso não só existe, como é praticamente a norma na maioria das equipes de software. Eu arriscaria dizer que pelo menos 4 em cada 5 programadores faz POG diariamente.

Por isso, se você é Gerente, suspeite de resultados mágicos, comportamentos inesperados do software, erros constantes que são corrigidos instantaneamente. Sabe aquele comportamento? Hoje estourou um problema, você manda um e-mail para a equipe, ela responde na hora seguinte dizendo “agora está tudo ok”. E isso se repete todos os dias. É um sinal fortíssimo de POG. Programadores cowboy são “codificadores” que acham que são “desenvolvedores”, ou seja, um pintor de paredes insano que acha que é Van Gogh. Esse é o tipo mais perigoso porque o pintor de parede sabe das suas limitações e nunca vai dizer que é um pintor de quadros, mas o cowboy não, ele realmente acredita que é o Van Gogh! E o pior, paradoxalmente, os gerentes os adoram porque eles resolvem todos os problemas!

Agora vem a parte chocante: os gerentes adoram os cowboys porque eles resolvem todos os problemas que eles mesmos criaram! Ou seja, ainda não caiu a ficha que o mérito todo atribuído ao cowboy é gerado pelos problemas que ele mesmo criou! Se você é desse tipo de gerente e se agora você entendeu que tem cowboys, demita-os também. Existe até aquele dilema: “mas eu não posso mandar ele embora, só ele sabe como o sistema funciona!” Exatamente, esse é um motivo até ainda mais forte para mandá-lo embora: ele é, literalmente, um grande Single Point of Failure (SPOF). Desenvolvedores de verdade não escondem as coisas, não mascaram resultados, não enrolam o processo. Quer um sintoma? Você tem algum software cujo código-fonte reside apenas na máquina do seu programador? Cuidado: você acabou de encontrar um cowboy.

Outro motivador: quando você troca um programador ruim por outro realmente bom, não está trocando 6 por meia dúzia, está efetivamente trocando 1 por 10, como já dizia o bom e velho Frederick Brooks em The Mythical Man Month. Há 30 anos já sabemos que um bom programador pode ser 10 vezes melhor (não apenas mais rápido, mas um programador que faz código de qualidade, o que torna fácil sua manutenção, sua extensão e inclusive o repasse de conhecimento a outros programadores).

E nos dias de hoje, existem vários sintomas que denunciam cowboys que devem ser demitidos: seu programador torce o nariz quando se menciona Pair Programming ? Ele desdenha Propriedade Coletiva de Código e prefere manter alguns códigos ainda escondidos? Ele acha que teste é algo opcional e que pode fazer depois? Pior, ele defende o uso de práticas ou tecnologias sem saber explicar, tecnicamente, por que está usando? Tudo isso é sintoma. Se seu programador tem pelo menos 1 deles, já é motivo mais do que suficiente para deixar os papéis da demissão preparados e a começar a entrevistar novos candidatos.

Aliás, parece que estou brincando quando falo em “demitir”, mas estou falando sério. Outra coisa que é muito importante para uma empresa é a rotatividade das pessoas. Quando as mesmas pessoas ficam juntas por períodos muito longos de tempo (anos), eles se acostumam uns com os outros e passam a fazer vistas grossas com mais frequência, drasticamente derrubando a qualidade do serviço. Uma meta que deveria ser adotada anualmente é de renovar, uns 10% a 20% do pessoal todo ano! Mantenha os verdadeiros desenvolvedores, mas demita os NNPPs, a menos, claro, que você tenha dinheiro para jogar fora.

Update 30/03: Esqueci de mencionar mais algumas coisas. Respondendo até a algumas coisas nos comentários. Como eu já havia falado na minha apresentação do Matando a Média o mercado como um todo balisa todo mundo por baixo. Por isso um bom programador, mesmo sendo até 10 vezes melhor que um ruim, nunca ganha 10 vezes mais. Às vezes a diferença mal chega a 10%, o que realmente é triste. Claro que quando eu digo “demita”, é sério, mas é uma provocação. Dadas as leis brasileiras que protegem o profissional ruim, isso realmente fica difícil. Portanto, o pragmático seria: demita sempre que puder e, mais importante, contrate com muito esmero. É sempre melhor demorar mais e contratar alguém realmente bom do que assumir que alguém pode ter “potencial” apenas por credencial.

Uma coisa importante: Não estou falando contra os novatos, júniores e recém-formados, não confundam. Existem muitos garotos com muito potencial, especialmente aqueles que sabem que estão em início de carreira e querem aprender, se esforçam para aprender, mudam de rota quando recebem feedback, sabem pelo menos começar a argumentar suas posições. Um cowboy pode ser tanto um recém-formado quanto alguém com 20 anos de carreira, não importa. Os bons júniores devem ser bem cuidados e receber o coaching adequado para que não peguem o caminho dos cowboys.

Outra coisa: “quero ser um bom programador, mas meu chefe me pressiona para entregar tudo antes, inclusive incentiva a fazer POG.” Bom, vamos lá: em aviação existe uma coisa chamada Catch-22. Algumas décadas atrás muitos aviões caíram porque o piloto tomava decisões erradas e o co-piloto, mesmo sabendo disso, precisava ficar calado por causa da hierarquia (alguém de ranking menor não deve contrariar alguém de ranking maior). Em sabendo disso o mundo da aviação evoluiu e agora existe um procedimento chamado PACE (Probing, Alerting, Challenging, and Emergency Warning). Ou seja, se o co-piloto sabe que o piloto está errado, existe um procedimento para ele avaliar a situação, alertar o piloto, se ele não entender desafiá-lo e se ele ainda não entender, o co-piloto deve avisar a torre de comando e tomar o controle da aeronave. Isso diminuiu drasticamente os acidentes aéreos. Um bom programador deve dizer NÃO a um chefe que está empurrando a equipe precipício abaixo. Se a empresa pune esse tipo de iniciativa, então essa empresa não é boa para você. Não estou falando da criancice de bypassar o chefe e fazer fofoca ao chefe do chefe, mas sim de encará-lo homem a homem e discutir o problema realisticamente. Veja um trecho do documento do PACE :

For the actual announcement of change of command on the flight deck, the Co-pilot could use a phrase such as “Captain (Jones), I must take over control of the airplane. (Jerry), take your hands off the controls. NOW!” This use of a personal first name or a nickname can very effective to break the perceptual narrowing of the Captain. A third crew member, if present, can use terminology such as, “Captain (Jones), you must give control of the airplane to (Barry) immediately.”

Update: 31/03 Acho que vale a pena eu explorar um pouco mais o conceito de “Cowboy” já que parece que ele pode ser mal interpretado. Novamente, Cowboy não é o novato ganhando experiência, ou mesmo o sênior aprendendo coisas novas. Esses são os que se deve investir. O problema são os Lemmings, os suicidas, aqueles que são ruins, todos sabem que são ruins, todos avisam que estão indo em direção a um precipício mas o desgraçado colocou na cabeça que ou não pode mudar, ou não quer mudar ou não sabe como mudar e por isso não vai mudar. Esse é o cara que continua indo precipício abaixo e arrasta todos ao redor junto com ele. É exatamente o NNPP: um cara de produtividade negativa, que causa prejuízos. Esse tipo, depois de avisar uma vez, duas vezes, não adianta mais, tem que mandar embora, porque aí é ou ele ou você.