Muletas de papel

Há organizações que se esforçam bastante para ter um processo de desenvolvimento de software determinístico e completamente detalhado. O modo mais comum de realizar isso é confeccionar algum tipo de documento eletrônico (um site interno ou algo parecido) especificando todos os procedimentos que os funcionários precisam seguir, que formulários precisam preencher, com quem devem falar e em que momento espera-se que realizem cada uma das atividades. Em muitos desses lugares o Processo é tratado como um verdadeiro tesouro, o recurso mais importante da empresa, por razões um tanto quanto “pragmáticas”. Pelo menos é o que os responsáveis pelo Processo dizem. Ninguém que pretende ser profissionalmente respeitável vai falar que faz algo por intuição ou crendice.

O Processo teoricamente permite que a empresa aproveite as novas contratações com um mínimo de tempo de treinamento e entrosamento. Com um Processo elaborado, quando um novato chega ele só precisa consultar as escrituras, seguir as ordens, conseguir os mais novos modelos de documentos e preencher as lacunas. A idéia é que, se toda a equipe fizer isso e tiver bastante sorte, no fim das contas vão produzir software útil, interessante e barato.

Mas obviamente isto não costuma passar de uma idéia bem intencionada.

Documentos detalhando tudo o que qualquer funcionário possa um dia precisar fazem todo o sentido para organizações em que novatos inexperientes são maioria. Eles podem começar a produzir mais rapidamente do que se esperássemos o tempo necessário para que se adaptassem e evoluíssem. Eles não precisam perder tempo absorvendo a cultura da empresa, porque a cultura oficial já está escrita e devidamente catalogada. Novatos inexperientes também costumam ficar mais exigentes quando começam a se tornar um pouco menos inexperientes. Um processo bem documentado permite trocá-los por sangue novo quando começam a pedir aumentos e benefícios.

O problema com os processos detalhados e rígidos aparece quando a organização quer ter um relacionamento saudável e de respeito com os funcionários, incentivando e premiando o aprendizado ao invés de puní-lo. O Processo serve como aquelas rodinhas para quem está aprendendo a andar de bicicleta. Elas ajudam a não cair, mas nenhum campeão olímpico cogita usá-las. Depois que as pessoas aperfeiçoam suas habilidades e tornam-se capazes de andar sozinhas, aquela parafernália toda só atrapalha. Como já são experientes, sabem instintivamente o que é importante e podem adaptar o processo padrão conforme necessário sob demanda. Eles conseguem eliminar gargalos e otimizar procedimentos sem muita burocracia e muitas vezes sem nem perceber que estão fazendo isso. Gargalos atrapalham o desenrolar dos trabalhos e costumam ser flagrantemente visíveis, as pessoas eliminam alguns deles todos os dias simplesmente porque as incomodam.

Infelizmente fazer isso fica infinitamente mais difícil na presença do Processo, por causa das diversas lacunas a serem preenchidas e dos procedimentos a serem seguidos. Como tudo precisa ser muito bem pensado, definido e aprovado, não sobra espaço para coisas bobas como instinto e melhoria inconsciente. O triste resultado de todo este esforço de formalização é ver pessoas que poderiam se programadores brilhantes se limitando a domar a burocracia. Não adianta se concentrar em ter o formato dos documentos padronizado se o conteúdo não tem valor. Do mesmo modo, não é possível adaptar o formato a um conteúdo de valor se ele é definido previamente e gravado em pedra por alguma entidade externa à equipe. Planos são úteis somente na medida em que ajudam o planejamento, afinal o importante é realizar a atividade, não produzir o documento seguindo à risca o modelo padrão. O importante é o planejamento, não o plano. A atividade, não o sub-produto.

Os lindos modelos, diagramas coloridos e documentos reluzentes servem como muletas de papel feitas para ajudar quem está mal das pernas. Se pensarmos bem, não há nada mais natural para quem não quer confiar no talento das pessoas. Mas para quem quer andar com desenvoltura e desviar dos obstáculos do caminho, muletas só servem para atrapalhar.

Mais sobre aquele programador Java que você não quer

Houve muitos comentários interessantes aqui sobre meu último texto e alguns deles falavam em algo chamado “lógica de programação”. Um dos leitores comentou que muita gente se limita a aprender uma nova sintaxe, mas continua usando a mesma lógica para programar (*). Ou seja, continua a pensar do mesmo jeito.

Não há sentido em aprender uma nova linguagem assim.

Não existe “a” lógica de programação, apenas “uma” lógica de programação. Quando escrevi o texto anterior era nisso que eu estava pensando, mas precisei de outras pessoas para me abrir os olhos. O importante é que cada linguagem tem uma forma diferente de interpretar a máquina, uma nova filosofia. O que você vai querer aprender é isso, não a sintaxe simplesmente.

Não há grandes ganhos em aprender C# se você já sabe Java, porque o modelo de pensamento das duas é basicamente o mesmo (e conseguir um exemplo foi bem difícil, já que até mesmo neste caso ainda há o que se aproveitar). Mas a lógica para programar é bem diferente se você usar Haskell no lugar de C. Para quem está acostumado com linguagens em que efeitos colaterais são a regra e não a exceção, aprender Haskell dói. É a dor do cérebro ajustando-se a uma linha de pensamento diferente.

Nem precisamos ir tão longe assim para observarmos a dor. Acontece até mesmo quando se passa de C para C++ (por causa das noções de orientação a objetos) e de Python para Io (por causa da orientação a objetos sem classes). A causa disso tudo é a necessidade de absorver uma lógica diferente. Pensar que existe uma única lógica de programação só vai piorar as coisas. Novas linguagens demoram tanto para se disseminar também porque as pessoas acham que já dominam “lógica de programação” há muito tempo e que só precisam se adaptar a uma sintaxe nova. Elas não querem aceitar a dor.

A moral dessa história já foi escrita por Alan Perlis e citada pelo grande Peter Norvig há muito tempo: “Uma linguagem que não afeta seu modo de pensar sobre programação, não é digna de ser estudada.” A conclusão direta disso é que o que devemos procurar em uma linguagem é um novo modo de pensar, não uma sintaxe nova para o antigo.

* Estas não foram as palavras exatas dele, mas acho que é uma interpretação válida

Você não vai querer um programador Java

Muito menos um programador C#, Delphi ou Visual Basic. Para falar a verdade, o que você quer não é nem mesmo um programador Python, Ruby ou Lua.

Este texto também não é um elogio aos programadores Haskell. Você também não vai querer um desses.

Se você tem um problema para ser resolvido com algum programa de computador, o que você precisa é de um programador. Simples assim.

Ninguém precisa da especialização em nenhuma linguagem ou plataforma específica para começo de conversa, mas para programar computadores com certeza você vai precisar de um programador. A verdade é que ele vai precisar de muitas outras habilidades além de proficiência com um compilador, mas se você contratar alguém que não sabe programar, terá uma bela enrascada em mãos. Não importa quantos analisadores de problemas e desenhadores de retângulos sua equipe tiver, se eles não puderem conseguir que um computador faça alguma coisa, seu projeto vai ser um fiasco na certa. A não ser — é claro — que os retângulos possam ser transformados de algum modo em instruções detalhadas executáveis por um computador.

Mas nesse caso você teria programadores. Só aconteceria deles programarem com retângulos, mas ainda assim seriam programadores.

Conhecer uma única linguagem de programação não é um empecilho somente porque muito provavelmente ela não vai mais ser a melhor ferramenta para o trabalho daqui a três ou quatro anos, mas porque mostra uma incapacidade (ou falta de vontade) para aprender. O que nenhum cliente deveria querer são programadores altamente especializados a ponto de conhecer uma única linguagem de programação. Ao invés de um programador especialista na plataforma da moda de hoje, o que você precisa é de um que seja capaz de aprender as de amanhã. O que um bom programador mais precisa, como qualquer bom profissional, não é apenas saber usar as ferramentas do presente, mas ter capacidade de aprender as do futuro.

Não se deixe enganar também por programadores de retângulos, mesmo que eles gostem de ser chamados de modeladores, arquitetos ou de qualquer outro nome que esteja na moda na época. Linguagens visuais também são apenas linguagens. São linguagens que, por serem gráficas, podem parecer independentes de linguagem, mas não deixam de ser linguagens. Não importa que o programador desenhe ao invés de escrever, se ele quis se limitar a desenhar, deve ser porque não quer nem se dar ao trabalho de aprender a escrever.

Especialização em excesso além de tudo cria ilhas muito concentradas de conhecimento. Por algum motivo inexplicável, muitos programadores especializados acham que jogam em times adversários, que estão em trincheiras diferentes e que tudo é uma grande guerra. Se quiser experimentar isso, tente publicar uma notícia que simplesmente cite Ruby (nem precisa ser o tema principal) em um fórum Java e observe o que acontece. O triste é que eles acabam isolando a si mesmos dentro de uma comunidade pequena e perdem de aprender o que as pessoas de fora poderiam ensinar.

Blogday 2007

O José Oliveira indicou este blog (junto com outros quatro) em um texto publicado como parte da iniciativa BlogDay 2007. Ele não especificou se isto é algum tipo de meme, mas tem todas as características de um. Parece que estou meio atrasado, já que o tal dia foi na última sexta-feira (dia 31), mas vou usar isto como desculpa para indicar cinco blogs que acompanho de qualquer modo (em nenhuma ordem em particular):

Motor curiosidade — Novo blog do Marcos Pereira sobre desenvolvimento de software e essa vida de programador. Promete ser extremamente interessante, a julgar pela qualidade dos dois primeiros textos e pelos textos dele no blog antigo.

Coding Horror — Talvez um dos blogs mais discutidos no pequeno círculo dos programadores. Jeff Atwood costuma abordar com acidez e bom humor assuntos relacionados a tecnologia que vão desde a relevância dos jardins gradeados na internet até como montar uma máquina silenciosa.

Danilo Sato — Para quem quer estar por dentro das últimas novidades em matéria de agilidade e sempre de olho no mundo acadêmico. Danilo costuma freqüentar conferências ágeis (e também algumas não tão ágeis assim) e relata as experiências neste blog, junto com muitos pensamentos úteis.

Thinking Parallel — Mesmo para quem acha que este barulho todo sobre paralelização é só mais uma onda, não custa nada acompanhar o blog do Michael Suess. Apesar dele ser um pós-doutorando, seus textos passam longe do academiquês e costumam ser dos mais digeríveis sobre o assunto.

{ | one, step, back | } — Jim Weirich não é tão conhecido (e forçadamente controverso) quanto David Hansson, mas é uma das figuras mais relevantes quando o assunto é Ruby. Se você programa em Ruby, mesmo que ainda não tenha ouvido falar no cara, já deve ter usado rake ou builder, duas ferramentas criadas por ele.