Eu tenho alguns livros sobre qualidade de software na minha pequena biblioteca. Eles são ótimos para curar insônia. Sobre CMM, eu até consegui avançar no Managing the Software Process (Watts Humphrey); eu devo ter lido a metade dele. Sobre ITIL, não consigo passar da primeira página.
Então, descobri sobre um momento interessante da história da ciência. No início do século XX, havia um grupo de matemáticos e filósofos desesperados para colocar ordem na lógica e na matemática. Monstros tinham sido levantados por gente inconseqüente como
Georg Cantor e
Ludwig Boltzmann. Havia a necessidade de colocar ordem no mundo e provar que a ciência e o universo andam como sistemas mecânicos: perfeitamente previsíveis e descritos a partir de regras simples.
Para tentar colocar ordem e certeza na matemática, Alfred Whitehead e Bertrand Russel publicaram, entre 1910 e 1913, três volumes do
Principia Mathematica. Na página 379, eles provam que 1+1=2, tal era a preocupação com a correção e o formalismo. Os manuais de ITIL não são muito melhores e assim como ele, são
Kryptonita para o entusiasmo.
Em 1931,
Kurt Gödel publicou e apresentou o
Teorema da Incompletude. Em poucas palavras, ele demonstrou que haveria sempre fatos que a matemática não poderia provar nem verdadeiros nem falsos, num sistema minimamente complexo. O incrível é que a informática também tem o seu Gödel e ele é Fred Brooks, que escreveu que não há solução mágica para o desenvolvimento de software em seu clássico
The Mythical Man-Month.
Os formalistas fizeram de conta que não viram; eles queriam automatizar a descoberta de verdades matemáticas e acelerar a ciência. E as empresas continuam fazendo de conta que o processo vai resolver seus problemas de qualidade, quando o problema é humano.
Claro, os processos ajudam num sentido bastante restrito de qualidade. Eles ajudam a fazer com consistência aquilo que a empresa já sabe fazer. Parece burocrático e é. Mas o processo não ajuda a fazer aquilo que a empresa ainda não domina. E o incrível sobre a informática é que sempre se está fazendo algo novo ou usando uma teconologia nova. Pouca gente passa mais de 5 anos fazendo a mesma coisa. E aqueles que o fazem, como programadores COBOL num banco, acabam naturalmente achando um processo, se não houver alguma formalização.
Os proponentes dos processos, como aqueles matemáticos, costumam estar tão enamorados de seus teoremas, que não prestam atenção ao que os rodeia. Ele têm a solução e as empresas são imaturas. Não é por nada que sempre encontram resistência.
Pois a maior parte das empresas não precisa de nada muito sofisticado. Quem tem equipes pequenas não precisa de muita burocracia e grande parte dos projetos são pequenos. É preciso apenas um bom gerente e bom senso. Watts Humphrey escreveu seu livro no contexto de projetos de bilhões de dólares. Quando se tem uma equipe de 10 pessoas, a qualidade delas é muito mais importante que a qualidade do processo.
Mas o maior problema com o CMM é que ele propõe um processo ideal, longe da realidade de uma tecnologia ou prática concreta. O arquiteto
Christopher Alexander (cujo trabalho inspirou o movimento de
Padrões de Projeto) escreveu sobre o grande movimento no século vinte de separar o processo de projetar do processo de construir. Desconfio que essa tendência da engenharia foi induzida pelo trabalho daqueles matemáticos e filósofos formalistas. É comum escutar que o CMM mostra "o que fazer, não como fazer".
Correndo o risco de não ser levado a sério (quem se importa?), vou lançar mão de uma pérola de sabedoria, proferida pelo grande filósofo Ozzy Osbourne:
"The shooting's easy when you've got the right gun."
Ou seja, aplicar uma tecnologia adequada de uma maneira inteligente é fundamental para o sucesso de um projeto de software.
Como podemos insistir com um processo que ignora isso?
Em 1956, a IBM lançou um HD de 5MB chamado 305 RAMAC. Ele usava bytes de 7 bits com 1 bit adicional de paridade. Era alugado por US$3,200 mensais, que hoje seriam US$24,978 ou quase R$50 mil.
