Em 14 de Outubro de 2012, Felix Baumgartner, um paraquedista austríaco, concluiu o objetivo do projeto Red Bull Stratos e realizou um salto de 39 mil metros, sendo o salto mais alto de todos os tempos, partindo nada mais nada menos que da estratosfera no qual ele chegou através de um balão especialmente preparado para tal feito. E este não foi o único cuidado, pois para se conquistar tal feito, ele passou por uma preparação minunciosa, tomando assim vários cuidados como por exemplo empregando telemetrias adequada e altamente calibradas, fazer Felix respirar oxigênio puro para eliminar o nitrogênio de seus sangue, que poderia se expandir em alturas elevadas e com isto ameaçar sua saúde.
O staff do projeto contava com especialistas altamente qualificados e entre eles estava Joe Kittinger na categoria de consultor especial, detentor do recorde anterior que havia sido estabelecido em 1960. Vendo um documentário sobre o tal feito, houve algo que Joe comentou que me chamou muito a atenção:
“Teve muita gente falando sobre como as ondas de choque da barreira de som poderiam partí-lo ao meio” o que deixou Joe muito triste e frustrado, pois “aqueles que insistiam em afirmar estas coisas, não consultaram a equipe Stratos para saber os cuidados que eles estavam tomando, não eram especialistas no assunto e não possuíam nenhuma fundamentação e realizavam tais afirmações apenas porque eles podiam”.
Bom, Joe deveria estar mais acostumado com esta situação pois esta é um das constantes da humanidade. Independente das motivações, *parece* que ser leviano é regra e não exceção. Além disto há a “recursividade dos sem noção“, onde sem argumentos racionais o imprudente critica o insensato que acredita e potencializa os delírios do leviano. E há quem afirme que o segredo do sucesso é saber conviver com tudo isto, convencer e ser articulado para sobreviver.
Mas sou muito solidário ao Joe, eu entendo totalmente o desconforto dele.
Num dos muitos contextos que posso citar, é muito comum vermos discussões em foruns e listas baseadas em artigos equivocados ou baseado em pesquisas de caráter duvidoso, algumas vezes as imprecisões logo vem a tona pela análise de seus integrantes, mas sempre há (quando não são maioria) os simpatizantes dos levianos por razões simples, tanto o autor quanto seus simpatizantes estão falando aquilo que eles desejam que seja verdade e não a realidade ou simplesmente são analistas imprudentes.
A algum tempo, me foi solicitado uma consultoria de performance, security testing e verificação de SIMRAV compliace de um sistema, sendo-se que o SIMRAV tem um workflow, processos, protocolos e mensageria padrão. No primeiro contato com os desenvolvedores, me foi comentado que possivelmente eu não encontraria muita coisa, pois o Scrum Master do projeto havia orientado todo o processo de TDD (Test Driven Development), todos os módulos possuíam testes unitários, funcionais, de integração e que a arquitetura era excepcional, etc, etc, etc… E quanto a capacidade de processamento ele realmente era impecável, mas além de ter segurança tendendo a zero, ele havia falhas conceituais, que eu achei impressionante.
Quando fiz a introdução da apresentação do meu parecer, chegaram a me perguntar se eu tinha certeza do que eu estava falando, chegaram a insinuar (na brincadeira) que eu estava sendo leviano e que tal apresentação era para conquistar mais horas de consultoria, da forma que foi feito confesso que me senti ofendido. Mas relevei, e já imaginando por isto, em minha apresentação dissequei alguns bits, datagramas, assim como fluxos incorretos e as páginas dos manuais que evidenciava as falhas. Nem preciso dizer que os diretores técnico e de produto, assim como os gerentes de produto, desenvolvimento e segurança não ficaram nada felizes, mas ali não encontrei ninguém na equipe que dominasse de SIMRAV. E então fiquei pensando, como poderia? Para um sistema tão específico não possuir alguém que dominasse as regras de negócio? Na hora lembrei de uma das máximas do livro Code Complete do Steve McConnell:
“Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.”
E neste caso, para desenvolver melhor, era necessário de um especialista nas regras de negócio. Pois técnicas eles possuíam de sobra. E o mais surpreendente foi ouvir do diretor que num outro sistema eles haviam cometido a mesma falha.
Acidentes acontecem, ninguém é perfeito, todos estão propensos ao erro e o alvo de minha crítica é ao cerne de cada uma das iniciativas. É a insistência e a recorrência que classifica o indivíduo.
Namastê!