Como sabem eu venho de uma formação acadêmica em ciências naturais – em física – onde as coisas têm que fazer sentido real mesmo quando trabalhamos com coisas tão abstratas quanto uma função de onda da física quântica.  Pese embora a grande onda mitológica que rodeia a fisica quântica ela não é baseada em magia ou achismo, ela é baseada numa estrutura matemática. Quando descobri a minha vocação para a criação de software tive que rapidamente me por a par do que estava acontecendo neste mundo. E aqui, de um jeito prático e não acadêmico. Durante os meus primeiros trabalhos com software não existia exatamente um método a seguir, existia um fluxo de demanda. Mas esses primeiros exemplos me mostraram que não era possível fazer software assumindo que é algo mecânico e reativo.  Tendo formação acadêmica me voltei para os livros – o que é dizer muito, porque nunca antes lhes tinha dado muito valor, mas quando entramos num campo diferente daquele que fomos educados e no qual sabemos intuitivamente navegar, é bom ter referências. A razão para isso é que não poderia cair nos mesmos mitos que as pessoas já no ramo tinham caído, da mesma forma que o ingênuo – coloque aqui uma profissão – cai no mito da mecânica quântica “mágica”. Eu nunca fui de idolatrar autores, ou memorizar livros, ou saber (re)citar passagens. A experiência me mostrou que quem entende os conceitos não precisa dessas coisas, mas li bastante para me tornar um programador java, tirar minha certificação, mas o que mais me atrapalhava era não existir um método para criar software. Em java, temos os principios de OO para seguir como os principios SOLID. Em física, temos o método científico como base e várias práticas de laboratório que nos guiam. Entretanto, em gerenciamento de projetos de software me impressionava que tal coisa não existisse.

Fiz questão de fazer um curso não programático na finada Sun exatamente para descobrir esse outro lado. No curso que era guiado principalmente pelo Processo Unificado (Unified Process, UP) era levantada a lebre de um tal de XP. Eu tinha tido contato com o XP ainda quando fazia meu estágio em física. Afinal a física prática passa pelo processamento de sinal, e este passa por usar computadores.  Com o passar do tempo as práticas que observava na realidade não batiam com o que os livros diziam e o insucesso de vários projetos me fez entender que para entrar no mundo do software antes de saber programar é preciso saber escolher entre filosofias de desenvolvimento.  O Rational UP da  Rational Rose, depois IBM no tempo do CASE lançou o mote. A ideia era ter ferramentas onde especificar o software, apertar um botão e simplesmente teriamos um software funcionando. Não resulta. Ferramentas ainda são burras e precisam de alguém que as saiba usar.  Alguém muito esperto consegue vender esta ideia imbecil de que software pode gerar software automaticamente. Ainda hoje existem tentativas de enganar os pacóvios com esta artimanha. Repare que o engano advém de quem compra e não de quem vende. É quem compra que é muito desonesto, tapado, analfabeto ou burro para não entender a enganação.

Apenas pessoas sabem fazer software e existe uma razão muito simples para isso: fazer software é um processo criativo. Criativo aqui significa tanto ser um processo onde se cria algo, como um processo em que se precisa ter imaginação. E as máquinas não têm isso ainda.

Então por que é tão difícil fazer software? Fazer software não é dificil. O que é difícil é fazer software que alguém compre e atenda a uma demanda, a uma necessidade. Para qualquer produto comercial existem duas formas de demanda. Ou quem quer comprar, compra o produto já pronto que o produtor já criou antecipadamente (retail sell – venda a varejo) ou o interessado chega junto ao produtor e pede que seja feito um produto com certas características (tailored sell – venda sob medida). Na primeira categorias podemos encontrar muitos produtos como pão, fruta, vinho, carros, casas – e inclusive software – e no segundo podemos encontrar produtos como roupa (de alfaiataria), carros (Rolls Royce), aviões e também software. Qual é a diferença? Volume.  A primeira categoria ganha em vender barato e muito. A segunda em vender caro e pouco. Ambos têm o seu quinhão de mercado. Atenhamo-nos apenas ao software feito sob medida (sob demanda – on demand, como também é chamado) para o resto da conversa.

Em tudo o que é feito sob medida, e também num software, precisamos saber como o cliente deseja que seja o resultado final. Afinal o resultado final servirá a ele e apenas a ele. Tal como um casaco ou um terno que serve apenas a uma pessoa. Pode até ser que sirva para outros, mas nunca sem ajustes. Precisamos então saber quais são os requisitos. Requisito é um conceito muito importante neste tipo de produto, porque é à medida dele que será feito o produto final.

Um outro fator na equação é como será feito o produto. A tecnologia que será usada para realizar o produto afeta o preço, a qualidade, a durabilidade, e até o aspecto e usabilidade do produto.  Existem tecidos específicos para certos tipos de roupa e circunstâncias específicas. Existem razões técnicas de porque o mesmo casaco precisa ser de algodão em umas regiões e de lã em outras.  Se formos fazer um produto que nunca ninguém fez antes ou poucos tentaram e tenhamos que experimentar diferentes tecnologias será diferente daquele que utiliza uma tecnologia já muito entendida e aperfeiçoada.

Pondo estas duas forças num gráfico obtemos um cenários mais ou menos como o mostrado na figura a seguir.

Na zona verde estão os produtos menos complexos, os mais complexos na zona vermelha. Repare que o software é algo complexo.

Muita gente – gente demais, na minha opinião – adora comparar “fazer software” com “fazer casas, carros e aviões”. Não, essas coisas não são nem de longe tão complexas. Por quê? Porque os requisitos são muito bem conhecidos e a tecnologia também. Não há surpresas – tijolo é tijolo e metal é metal. Não há mudança de ideia no último momento. Não há uma tecnologia que surgiu no último momento e tornou tudo obsoleto.  Um pouco mais semelhante seria um carro costumizado ou um avião costumizado como Air Force One. Mais próximo ainda seria um vestido de noiva. A tecnologia é muito simples e conhecida, mas os requisitos são muito voláteis. É por isso que existem costureiros de grife cobrando caro por essas coisas. Do outro lado, temos as vacinas, aqui os requisitos são simples – evitar a doença , mas a tecnologia tem que ser criada. E algumas , como a da AIDS não tiveram sucesso até hoje.  A vacina é um exemplo muito mais próximo da complexidade de fazer um software com tecnologias novas (muitos projetos de vacinas falham, como falham os projetos de software). E talvez por isso as equipes tendam a usar tecnologias velhas. Dá-lhes uma margem maior de segurança emocional (se bem que uma plataforma de aplicação velha é um empecilho em si mesmo).  Armas de energia com o phaser do Star Trek ainda são uma ilusão, mas as armas  taser estão bem perto, e cada vez mais perto de uma arma de energia. Aqui, o requisto continua simples – desabilitar o adversário, mas a tecnologia é simplesmente desconhecida. Um exemplo de algo bem complexo de criar seria uma verdadeira  TARDIS , pois não apenas ela é um ser vivo que viaja no tempo e no espaço, como é maior por dentro do que por fora. Um desafio ao raciocínio humano mais fundamental, o que dizer ao raciocínio de engenharia.

Ao fazer software é raro que tenhamos requisitos bem conhecidos, e normalmente as empresas se encarregam de estragar a outra variável não tendo uma tecnologia padrão para desenvolver o software, o que significa que a cada projeto temos que começar de novo aprendendo novas tecnologias e refazendo funcionalidades que já tinhamos antes. Isto torna a produção de software inerentemente complexa. Não somos nós que a fazemos complexa, ela é complexa por natureza. O que podemos fazer é torná-la mais ou menos complexa, mas nunca apenas complicada ou  simples. Normalmente a tornamos mais complexa do que natural.

Aceitar este princípio básico – “princípio zero”, poderíamos chamá-lo – é fundamental para conseguir fazer software. Isto era verdade a 50 anos atrás, e com a velocidade com a tecnologia evolui,  é muito mais verdade hoje. Não é por acaso que nasceram coisas como o Java e o .NET para quebrar um pouco desse escalar de tecnologia que constantemente nos exigia mudar de ferramentas para fazer software. As plataformas virtuais nos trouxeram uma âncora que nos ajuda a diminuir a complexidade. Mas a âncora não durará por muito tempo e novas âncoras precisarão ser desenvolvidas.

Entendendo que fazer software é algo complexo, as pessoas esperam que a forma de gerenciar a produção do software tenha que ser igualmente complexa. E este é outro paradigma difícil de quebrar:  o complexo pode ser gerenciado com o simples.  O truque é mantermos os olhos nos objetivos. E são estes que têm que estar claros desde o dia um, e refinados todos os dias. Como já disse Dwight D. Eisenhower “O plano não é nada, planejar é tudo”. Ou seja, a complexidade é tratada facilmente se o plano não for fixo e evoluir conforme as circunstâncias. Mas veja, o plano muda e é descartável, mas não os objetivos  (e se você tem algum sentido de ética, nem todos os caminhos são aceitáveis).  Algumas pessoas entendem esta frase assim: “não faça planos”. É errado. A mensagem é “Faça planos, e continue fazendo planos. Não pare de fazer  planos até chegar no objetivo”. A cada plano temos um mapa do caminho para os próximos tempos  ( horas, dias, semanas, meses, anos… não interessa), quando replanejarmos teremos um plano que vai um pouco mais à frente e assim continuamente. A mal intrepretação deste simples conceito leva a aberrações como a recusa de criar uma plataforma de aplicação coerente e coesa ou simplesmente achar que é possível levantar requisitos “on-the-fly” na medida que o projeto progride.

A complexidade do software demanda o processo criativo contínuo, e isso exige a atuação de pessoas em todos os pontos desse processo. Todo o resto são ferramentas.
Será que o processo unificado (UP) ou qualquer outro processo criado antes de 1990 se baseia nestes princípios? Quero crer que não. Todos os processos clássicos se baseiam num mecanismo Stage-Gate como o usado para construir carros e aviões (!). Este tipo de processo simplesmente não funciona quando a principal energia é a criatividade,  e é por isso que muitos de projetos de software falham.  Em qualquer outro ramo de atividade, tantos projetos falharem é inadmissível. Em software, fazemos de conta que não é verdade.

O que não é admissível é que seja possível viver construindo software sem ter um processo-base para tal.  Práticas de laboratório até temos algumas (vide práticas de XP ) e temos alguns candidatos a processos de gerenciamento realista de software como Scrum. Mas ainda aguardamos o santo graal do processo de software.  O Processo Unificado não é bom o suficiente porque ele é muito semelhante a um processo Stage-Gate  e é corrompido muito facilmente se transformado num processo que tradiconalmente é usado em empresas produtoras de software. Um processo criado “in-house”, híbrido e muito parecido com um Frankeistein , um monstro fabricado de partes de outrém.

A promessa de um processo padrão moderno, confiável, honesto, que tome em consideração a complexidade, os requisitos, as tecnologias, e as pessoas ainda está por vir.  A minha aposta é que será algo muito semelhante a uma fusão de Scrum com XP e diretivas do manifesto de software craftsmaship que apela a um certo padrão de qualidade e orgulho no trabalho que fazemos – que por exemplos os alfaiates têm – que nós,  produtores de software, ainda não temos.

Software é simplesmente complexo, e é por isso que gostamos de o fazer. Aceitemos de uma vez por todas a sua complexidade natural e façamos-o com o respeito que merece.