O problema de relativizar as coisas é quando se perde a referência absoluta. Melhorar nem sempre é sinônimo de estar bem, menos pior não é igual a estar bom. Em desenvolvimento, isso é um conceito extremamente importante. Isso impacta diretamente na qualidade do produto que foi desenvolvido.
Como tudo o que é importante, obviamente, isso é muito renegado.
Sistemas Complexos
Muitas coisas tem que acontecer de maneira coordenada para que um novo sistema seja concebido. É preciso que muitas tecnologias sejam combinadas, muito conhecimento gerado e muita informação processada para que se obtenha um novo produto. Pegue uma geladeira: é preciso conhecimento de termodinâmica e mecânica para montar a estrutura dela. Precisa-se saber de eletromecânica, para que o compressor seja entendido e usado corretamente. De eletrônica, para controlar tudo isso. Precisa-se entender até de decoração: geladeiras integram o ambiente.
Eu não vou entrar nos detalhes de que cada peça destas deve ter todo um conhecimento por trás. É claro que não gastarei o espaço do post com uma especificação ultra completa de uma geladeira. Vou atentar para o aspecto de quem faz isso, como de costume.
Eu digo a todo desenvolvedor: “coloque uma coisa na sua cabeça, o trabalho em desenvolvimento é social”
Eu digo a todo desenvolvedor: “coloque uma coisa na sua cabeça, o trabalho em desenvolvimento é social”. Tudo bem, é uma atividade “técnico-social”: um grupo de pessoas com determinados conhecimentos se juntam para fazer algo e receberem, depois de um tempo, um pagamento por isso. Eu não canso de repetir isso. É um mito, uma lenda e um caminho certo para projetos de prazo estourado quando um desenvolvedor acha que, sozinho, vai conceber algo genial. E é aí que começa o problema…
Sendo uma atividade social, desenvolvimento não pode ser feito sem interação entre pessoas. Quando pessoas interagem, pessoas comparam. E quando comparam, muita coisa pode acontecer.
Versus
Primeiro eu não entendia. Quando comecei a entender, passei a protagonizar. Quando cansei de disso, passei a observar. Até que cansei de ver, quando virei gerente, os times de hardware, lógica programável, microcontroladores e software embarcado (do driver à web, passando pelo banco de dados) discutindo qual parte do projeto estava pior. Já vi isso dentro de uma mesma equipe.
Não vou entrar nos méritos da validade destas discussões pois se forem feitas de maneira correta, elas são muito válidas (cross developer reviews são muito úteis). Saber aproveitar criticas é uma arte muito mais nobre que saber criticar e quem me conhece sabe que eu sempre fui de bater pesado, mas ao mesmo tempo nunca negligenciei que alguma coisa que eu fiz estava ruim quando, chamado a atenção, eu constatei isso.
O problema destas discussões são quando as críticas são usadas como mecanismo de defesa, não da qualidade técnica do sistema ou devido ao estilo de implementação adotado. Isso se manifesta da pior maneira possível: o sujeito não admite que errou. Ou pior ainda, sabe que está fazendo um pacto de mediocridade. Eu comento sobre isso no Autodesenvolvimento.
Vaidade Técnica
Além de ter descrito sobre o triste pacto de mediocridade no Autodesenvolvimento, também lá comento sobre a Vaidade Técnica. Ela só atrapalha. Eu sempre tive orgulho do meu trabalho, algo que muita gente confundia com presunção ou vaidade técnica. Não era isso. Por quê? Porque eu sei o exato dia em que minha vaidade técnica caiu por terra…
Certa vez, eu havia concebido um esquemático de hardware e submetido o mesmo para leiaute. O leiautista havia trocado alguns pinos de um buffer, para facilitar o roteamento da placa. Eu tive que mexer naquilo e não conferi. Errei. Quando voltou, eu revisei sem notar que ele tinha revisado o que eu havia revisado e errei de novo. Não perdemos os protótipos, mas o desenvolvedor do software foi genial e conseguiu contornar: mas só fez isso porque eu não saí jogando a culpa em todo mundo, ou seja, humildemente admiti meu erro e pedi ajuda.
Errar é humano. Me tornei do tipo crítico, depois de errar duas vezes, ao ponto de ficar desconfiado das coisas que eu mesmo fazia. Caí no erro do lado oposto: passei a querer mudar tudo sempre. Foi importante eu aprender que durante a concepção de um sistema, eu estava constantemente aprendendo e sempre que revisitei algum trabalho, tive a duras penas, que aprender a resistir o impulso de fazer tudo de novo.
Esta postura (saber que estou sempre aprendendo) passou a complementar a primeira, de assumir meus erros. Mas porque coloco essas coisas? Coloco porque boa parte da discussão que acontece entre equipes de desenvolvimento acontece quando uma equipe vê caminhos para não se responsabilizar por um trabalho mal feito. Em cima disso, um outro colega faz um outro trabalho, considerado de pior qualidade.
A soma de coisas ruins chega a um produto ruim.
Produto Porcaria
Costumo dizer que se um produto é uma porcaria, é porcaria resultante da postura e da qualidade do trabalho social dos seus desenvolvedores. Existem desenvolvedores (e talvez até algumas empresas) que não se importam em lançar no mercado produtos porcaria. Há inúmeras razões que usam para isso. Nunca considerei estas assertivas como válidas.
Conceber um produto com qualidade é muito independente do tipo de tecnologia envolvida. Já vi produtos porcaria usando tecnologia de ponta e já vi produtos excelentes (alguns até geniais) usando nada mais que micros de 8bits. De maneira semelhante, a utilidade de um produto independe da qualidade de sua concepção.
Todas as etapas de desenvolvimento de um produto devem ser cumpridas de maneira que se considere “bom” ou “bem feito”. Muitas vezes comenta-se em tratados mais filosóficos que a jornada é mais importante que o destino… Talvez um análogo para desenvolvimento seja que a execução é mais importante que o produto final.
O que definitivamente é o fim é usar, como argumento, de que um produto “está menos ruim que antes”.
Nivelar por Baixo
Um produto bem executado, bem desenvolvido, é algo que depende de coordenação. Depende de interação. De nada adianta criticar o trabalho de um colega sabendo que a sua parte no trabalho está ruim, pois no final, a discussão pode até ter sido ganha, mas e o que mais se ganhou com isso?
Este tipo de pensamento entranha na cabeça do desenvolvedor com o passar do tempo. Não estamos vacinados contra os vícios que adquirimos. Para quem quiser entender porque hábitos são importantes, recomendo ler terapia comportamental. Em um resumo simpliesta, em que os psiquiatras vão me excomungar, claro, quer dizer que nosso pensamento influencia nosso comportamento e nosso comportamento influencia nosso pensamento.
Agora pense quantas vezes, ao longo da carreira, um desenvolvedor que utilize o balizamento “o meu está menos pior, portanto, estou bem” não está comparando o seu rendimento com o integrante do time de pior performance. A isto damos o nome de “nivelar por baixo”.
A vaidade técnica pode levar o desenvolvedor a criar o péssimo costume de nivelar por baixo. Ao nivelar por baixo, tende-se a produzir sistemas com qualidade decrescente, levando a cada vez mais discussões desnecessárias para defender o indefensável, que é uma implementação ruim.
É só fazer direito
Eu comentei anteriormente que estamos em constante aprendizado quando desenvolvemos um sistema. Portanto, o conceito de “ótimo” está em constante deslocamento. É complicado saber então quando estamos fazendo um produto bom? Dá para saber quando estamos fazendo direito?
Não é complicado! Dá para saber sim!
Contudo, não é fácil, apesar de simples. Para fazer um produto bom, basta fazer o melhor que se possa imaginar, com o conhecimento que se tem e com os recursos que se tem. Basta buscar colaborar com a equipe. Entender os pontos de vista dos colegas, estar aberto a sugestões.
O principal, neste caso, é estar com a consciência tranquila. Buscar fazer melhor deve ser um costume, não uma ação. Um desenvolvedor deve buscar nivelamento por cima, deve buscar evoluir, em todos os aspectos: técnico, profissional e pessoal.
