Valorizar práticas ou praticar valores? A diferença parece sútil, mas é a distinção essencial nos dias de hoje, porque é a diferença entre o que interessa e o que não interessa no ramo do desenvolvimento de software

Pela tradição – tradicionalmente, historicamente – as empresas valorizam práticas. São criados, aglutinados, conjuntos de práticas a que chamam “metodologias”. As práticas são veneradas e chamadas de métodos (dai metodo+logia: compilação/estudo de métodos). Elas são absolutas e essenciais em si mesmas. O conjunto é a soma das partes, não o produto das partes. Ou seja, se A é X e B é Y, então A+B é X+Y. Sem truques, sem fatores de correlação. Sem sobreposição. Ou seja, irreal.  Disfarçadamente o modelo “fordiano” da fabricação em linha de montagem é trucidado, despedaçado e depois alguns pedaços remontados no melhor estilo frankeinstein para se criar uma metodologia. Por que há incompetência de quem manda para reconhecer práticas reais, úteis, para a área de software, práticas de outras áreas tentam ser encaixadas.

Hoje não se desenvolve software com uma metodologia da área de software, mas sim com conjuntos de práticas usurpadas de outras áreas como a mencionada linha de montagem e a engenharia civil. As pessoas simplesmente adoram comparar prédios e software. Não há sequer comparação possível. Acho que as pessoas esquecem – ou nunca aprenderam – porque se chama software. Software é o contrário de Hardware. É um conceito tão etéreo e abstrato que ele só pode ser definido por oposição e não tem um substantivo próprio (seu de fato).

Depois de tantas tentativas falhadas de híbridos mutantes de bonecos de trapos ambulantes chamados “metodologias de desenvolvimento” algumas coisas foram aprendidas. Lembre-se que este campo tem 50 anos. É muito mais novo que o artesanato (milênios), a indústria (séculos) ou a construção civil (desde sempre que o Homem é Homem).

O que aprendemos?

As pessoas querem software

Elas querem soluções. Elas não precisam de software. Então, como o software oferece soluções, elas passam a desejar software. E é isso que elas compram, a satisfação de um desejo. Então, é aí que está o erro … Erro? Quando uma pessoa assiste a um espetáculo, é porque precisa ou porque deseja? É na realidade uma mistura promíscua dos dois. Difícil de dizer quando é um ou outro. Isso é a primeira indicação da razão pela qual as metodologias tradicionais não funcionam. Cada espetáculo é único. Existem técnicas, regras, mecânicas, mas no fim não existe uma forma única de produzir um espetáculo… apenas um conjunto de melhores práticas.

Será mesmo que um espetáculo, uma arte, é um conjunto de práticas ? Ah! o espetáculo, a arte não são um conjunto de práticas. É um conjunto de sensações que satisfazem o desejo do espectador. A arte, em si, não é material, tal como o software. Cabe na cabeça de alguém que arte seja montada como um prédio? Passa pela cabeça de alguém que algo abstrato seja “montado” como algo físico seria? Bom, infelizmente passa .

Mas o “desenvolvimento” sim pode ter práticas, melhores práticas. Então, como um espetáculo de arte com metas concretas e práticas reais de produção, também um software (coisa abstrata) pode ser produzido usando práticas concretas.

Arte é produzida. Prédios são produzidos. Carros são produzidos. Software é produzido. Mas Arte não é fabricada, software não é fabricado. Carros e prédios sim. Esta diferença é tudo.

A Necessidade de Uma Metáfora

O problema é a necessidade de uma metáfora. Porque desenvolver software precisa ser comparado com desenvolver outra coisa? Este é o problema. A necessidade da metáfora. Porque sem a metáfora, você não consegue usurpar as práticas dessa outra área. Você precisa de uma metáfora, uma comparação com outro algo, para ver como esse algo se faz e usurpar as práticas de volta para o software. Genial? Mas não funciona. Está na própria essência da metáfora ser uma comparação provisória, limitada, um apelo à imaginação: nunca será real e nunca durará para sempre ou aplicável em todos os casos.

Historicamente, sempre que uma metáfora foi usada, duas coisas foram verdade: primeiro, funciona por acaso, não por mérito; segundo, prova que o assunto não está entendido em si mesmo. Um exemplo, a medicina. Começou como charlatanismo de venda da banha da cobra, virou “conjunto de práticas” metafóricas (do tipo sangrar quando está com febre porque a febre é o sangue fervendo, ou por panos frios, para diminuir a “fervura”), depois veio a renascença, e a medicina foi reintreptada à luz do humanismo e da ciencia, e depois virou … bom, continua sendo um conjunto de práticas, mas agora não metafóricas, baseadas em experiências concretas. Ainda não se chegou no nível dedutivo da física ou da química.

Desenvolver software está, no dias de hoje, no nível de sagrar alguém… os desenvolvedores e os clientes, claro. Dizem que deveria ser ciência. Nunca será. É baseado em ciência, como a medicina, com seus aparelhos de tomografia, raios-X e ultrasons… ferramentas… mas não deduções dos “porquês”.

Praticando Valores

Por que tudo isto não muda? Porque como estamos na fase de “conjunto de práticas” é isso que se procura sem analisar as razões e as experiências. A Renascença trouxe à medicina a luz que faltava: raciocinar e colocar o ser humano na frente. Ou seja, a Renascença trouxe valores para as práticas. As boas, as más, as em estudo, etc… abandonam-se as más e ficam as boas: seleção natural.

O que precisamos então é praticar valores. Salvar vidas é um valor, existem várias receitas como se faz, mas o que se ensina e pratica é algo maior, mais genérico, mais…. humano. Mas quais valores? À partida é difícil de dizer precisamos exemplos, precisamos experiências, casos reais.

Felizmente sempre tem alguém correndo na frente do paradigma, procurando o próximo. Estes exploradores descobriram coisas interessantes que podem ser compiladas em certos valores. E desses valores, avaliar as melhores práticas que atendem a eles.

Da mesma forma que o Juramento de Hipócrates antecede a medicina moderna, também a maioria dos valores necessários ao desenvolvimento de software antecede o próprio conceito de software. O juramento existe porque uma propriedade muito básica de toda a medicina existe – independentemente de como definirmos medicina e que práticas ela tem: toda a medicina começa sendo uma relação de confiança entre duas pessoas: o paciente e o médico. O cliente e profissional.

Confiança.  Este é o valor primário da medicina. O paciente confia no médico. O juramento é exatamente a “certeza” que o médico honra essa confiança e se compromete a não violá-la. Comprometimento. Outro valor. Esta relação de valores é tão forte que ela é base de lei em muitos países e culturas. Isto significa que ela existe no nível mais elevado possível: o nível humano.

A mesma coisa é necessária em desenvolvimento de software. Mas desenvolver software é uma atividade conjunta. Este fato simples – precisamos de uma equipa de pessoas – traduz-se na necessidade de valores que sejam aplicáveis entre os membros da equipa e entre eles e o interessado.

Atualmente existem algumas vertentes de desenvolvimento que tentam produzir software praticando valores.

Estas vertentes – genericamente chamadas ágeis – concordam que valores precisam ser praticados. Como tal eles precisam ser identificados. Nem sempre os mesmos são identificados, então vou pegar alguns como exemplo:

Comprometimento – não violar a confiança dos outros ou os compromissos assumidos. Este é essencial a qualquer atividade humana, comercial ou não.

Foco – faça o que se comprometeu com todo o esmero possível. Não inclua falhas ou pontos fracos, não se distraia.

Abertura – mostre o que fez, a todos. Não esconda nada. Não utilize ou forme segredos. Peça ajuda. Não tenha medo de pedir e de sugerir.

Respeito –  dialogue com os outros de igual para igual como seres humanos e não numa hierarquia artificial. Não menospreze e não subestime ninguém. Experiência se aprende, mas genialidade se utiliza.

Coragem – É necessário ter coragem para se comprometer , agir, demonstrar e esperar respeito. É necessária coragem para dar pedir ajuda e assumir erros. Coisas vão dar errado, e você será o responsável. Aceite isso mesmo antes de acontecer. Aceite isso para que não aconteça. Tenha a coragem de impedir que aconteça.

As metodologias ágeis continuam sendo conjuntos de práticas, mas agora, práticas devotadas a praticar valores. As práticas não mais são suficientes em si mesmas. Elas precisam do aval, da inspiração, de um ou mais valores.

São os valores que ditaram o que desenvolver software significa. Não um conjunto falho de metáforas. Deste valores podemos distinguir entre práticas boas e más, e descartar as más, da mesma forma que hoje a sangria  é uma aberração da história da medicina.