[Off-Topic] Net Negative Producing Programmer
Durante o Encontro de TI que teve nesse sábado, tive a chance de trocar ideias 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. Outros bloggers exploraram o assunto também, como o Kris Kemper. Tem ainda um paper do G. Gordon Schulmeyer que desce mais fundo no tema.
O resumo da ópera, nas palavras do próprio Schulmeyer, é o seguinte:
“Retirar um elemento tecnicamente ruim de uma equipe pode ser mais produtivo do que adicionar um elemento melhor capacitado.”
Descobriu que você tem um programador ruim? Demita-o, o mais rápido possível. Não há outra solução. Muitos gerentes acham que programadores ruins ou medíocres, na pior das hipóteses, são apenas mais lentos do que os bons. Essa concepção está absurdamente errada: um único programador ruim causa prejuízos irreparáveis a um projeto e literalmente dá marcha a ré na equipe.
O estrago nem sempre é óbvio. A maioria é acumuladora de Dívida Técnica (obs 2012: este artigo fala mais de problemas técnicos de software, mas generalize para problemas em geral, como moral baixa da equipe, clientes insatisfeitos, etc). Mantenabilidade e extensibilidade ficam profundamente comprometidas.
Uma coisa é fato: é muito difícil descobrir um programador ruim, principalmente se você, o gerente, não é programador também. Pior: você precisa ser um bom programador para reconhecer o ruim. Numa equipe razoavelmente balanceada, com programadores pelo menos um pouco acima da média e só um ou dois elementos ruins, a própria equipe separa o joio do trigo e expurga a maçã podre do seu meio (se for esperta).
Isso é uma faca de dois gumes. Se você, na pele do programador, acha que o seu colega é o ruim, quem garante que os outros não acham que o ruim é você? Se você é programador, garanta o seu.
Eu costumo separar “codificadores” de “desenvolvedores”. Ambos são programadores, mas o primeiro grupo 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 é formado por verdadeiros artistas, gente que entende que software é arte e que, como tal, exige dedicação e estudo constante, sem limite 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, suas chances de encontrar os melhores programadores são maiores 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 contou no blog dele sobre como a ThoughtWorks contrata: o candidato passa por uma bateria de testes. Não bastam uma ou duas entrevistas: ele precisa passar por vários sêniors da empresa e demonstrar código que será revisado por outros sêniors. 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, ao 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. (obs 2012: esse modelo não é ruim, mas hoje eu penso que é melhor de outra forma, assunto para outro post)
Agora, eu já vi situações muito ruins, em que a equipe inteira é feita de 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. Sai 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 versus resultado de longo prazo. Isso é uma constante em todas as empresas por onde passei: o gerente adora o programador cowboy, aquele sujeito que resolve todos os problemas que jogam para ele. Todos os cowboys são adeptos do POG, 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 fazem POG diariamente.
Por isso, se você é gerente, suspeite de resultados mágicos, comportamentos inesperados do software, erros constantes corrigidos instantaneamente. Sabe aquele comportamento? Hoje estourou um problema, você manda um e-mail para a equipe, ela responde uma hora depois 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”: um pintor de paredes insano que se acha Van Gogh. É o tipo mais perigoso, porque o pintor de parede conhece as próprias limitações e nunca diria que pinta quadros, mas o cowboy acredita de verdade 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. A ficha ainda não caiu: o mérito atribuído ao cowboy é gerado pelos problemas que ele mesmo criou. Se você é desse tipo de gerente e agora 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 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? Tem algum software cujo código-fonte só existe 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, o ganho efetivo é de 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. Além de mais rápido, ele faz código de qualidade, o que torna fácil a manutenção, a extensão e 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? Desdenha da Propriedade Coletiva de Código e prefere manter alguns códigos escondidos? Acha que teste é algo opcional, que dá para fazer depois? Pior: defende o uso de práticas ou tecnologias sem saber explicar, tecnicamente, por que está usando? Tudo isso é sintoma. Um deles já é motivo mais do que suficiente para deixar os papéis da demissão preparados e começar a entrevistar novos candidatos.
Aliás, parece que estou brincando quando falo em “demitir”, mas estou falando sério. Outra coisa muito importante para uma empresa é a rotatividade das pessoas. Quando as mesmas pessoas ficam juntas por anos, elas se acostumam umas com as outras e passam a fazer vistas grossas com mais frequência, derrubando drasticamente a qualidade do serviço. Uma meta que deveria ser adotada: renovar de 10% a 20% do pessoal todo ano. Mantenha os verdadeiros desenvolvedores e demita os NNPPs, a menos, claro, que você tenha dinheiro para jogar fora.
Update 30/03: Esqueci de mencionar mais algumas coisas, respondendo também a alguns comentários. Como eu já havia falado na minha apresentação do Matando a Média, o mercado como um todo baliza 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 é também uma provocação. Dadas as leis brasileiras que protegem o profissional ruim, na prática 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 confundam isso com uma crítica aos novatos, júniores e recém-formados. 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 e 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 o chamado Catch-22 do co-piloto. Algumas décadas atrás muitos aviões caíram porque o piloto tomava decisões erradas e o co-piloto, mesmo sabendo disso, ficava calado por causa da hierarquia: alguém de ranking menor não deve contrariar alguém de ranking maior. O mundo da aviação evoluiu e hoje existe um procedimento chamado PACE (Probing, Alerting, Challenging, and Emergency Warning). Se o co-piloto sabe que o piloto está errado, existe um procedimento para ele avaliar a situação, alertar o piloto, desafiá-lo se ele não entender e, persistindo o erro, o co-piloto deve avisar a torre de comando e tomar o controle da aeronave. Essa mudança de cultura na cabine ajudou a diminuir drasticamente os acidentes aéreos.
Um bom programador deve dizer não a um chefe que está empurrando a equipe para o precipício. Se a empresa pune esse tipo de iniciativa, essa empresa não é boa para você. Deixe de lado a criancice de bypassar o chefe e fazer fofoca para o chefe do chefe: encare o sujeito homem a homem e discuta o problema com realismo. 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 explorar um pouco mais o conceito de “Cowboy”, porque ele pode ser mal interpretado. Novamente: o novato ganhando experiência e o sênior aprendendo coisas novas não são cowboys. Esses são os que merecem investimento. O problema são os Lemmings, os suicidas: o cara é ruim, todos sabem que é ruim, todos avisam que ele está indo em direção a um precipício, mas o desgraçado colocou na cabeça que não pode mudar, 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: produtividade negativa, prejuízo certo. Depois de avisar uma vez, duas vezes, não adianta mais: tem que mandar embora, porque aí é ele ou você.