Bicatu

“Nova metodologia de desenvolvimento promete revolucionar a forma como desenvolvemos software”

“A nova versão do Ruby on Rails/C#/Java/node.js introduz funcionalidades que permitirão desenvolver mais rapidamente código”

Estes são dois exemplos de frases que encontro na mídia especializada quando o assunto é desenvolvimento.

Ao mesmo tempo o que encontro são reclamações de que os softwares que adquirimos (ou fabricamos) possuem de uma a três das características abaixo:

1. Acima do prazo
2. Acima do orçamento
3. Não satisfaz às necessidades do usuário

Como alguém que possivelmente já desempenhou todos os papéis da cadeia de produção de software, de Cliente a tester passando por analista,  desenvolvedor e gerente de projeto tal realidade sempre me surpreendeu.

Enquanto Eu não acredite que exista (ou venha existir) a “bala de prata” para software, ou seja, a solução/linguagem/framework/metodologia que atenda a todos os tipos e peculiaridades do software, me assustam os dados que tratam que cerca de 90% do software produzido sofre dos três problemas citados anteriormente.

Em busca de um “por quê” venho estudando nos últimos anos os diversos aspectos envolvidos na produção de software.  Afinal se encontrarmos a causa fica mais fácil encontrar a solução, certo?

Apesar de considerar que ainda há muito espaço para avanços minha conclusão é que, infelizmente, estamos tratando de um problema sem solução. Ao citar isso quero dizer que a despeito de alguma solução verdadeiramente revolucionária (ou mágica) o melhor que podemos fazer é conter o caos que é inerente ao processo e mitigar o impacto dos três problemas venham causar.

Quando converso com um amigo que não é da área técnica Eu sempre escuto que ele não entende como podemos ter tantos problemas nessa área.  Eu tento explicar que apesar de estar englobada em uma área de ciências exatas o desenvolvimento de software já deixou de ser (se é que algum dia verdadeiramente foi) uma área determinística.

Idealmente deveríamos poder, passados 50 anos desde o aparecimento da computação chegar numa fórmula que nos permitisse dizer o que queremos que o software faça e termos uma resposta precisa sobre quanto tempo e quantos recursos ele necessitará.

Donald Knuth, professor de Stanford, escolheu para o título de seus livros o estranho nome de “The Art of Computer Programming”.   O que é estranho é que o termo arte, associado normalmente a criação, foi aplicado a algo que na sua definição não deveria necessitar de nenhuma criatividade.  Dado um problema existe um conjunto finito de soluções para resolvê-lo. Ou não?

Para explicar que motivos me levam a tomar esta decisão é preciso voltar um pouco no tempo e entender o caminho que percorremos até a realidade atual.

Com excessão dos primeiros computadores e seus respectivos programas que eram extremamente limitados, o desenvolvimento de software consistia em você pegar um problema do dia-a-dia, como uma folha de pagamento que precisava ser calculada manualmente, e modelava este problema usando alguma linguagem de desenvolvimento.

E aí se encontram as principais características que são as origens dos problemas:

a) Definição do problema/solução

Mesmo passados muitos anos ainda não temos uma maneira de especificar o problema e a solução de maneira a eliminar a ambiguidade ou possibilidade de interpretação diversa como existem em outras áreas.  Assim sendo uma mesma especificação de software tem uma margem que permite a interpretação diferenciada.

b) Complexidade x Abstração

A maioria dos problemas é suficientemente complexo quando se olha de perto.  Excessões, validações, cenários são variados e a combinação de variáveis é suficientemente grande para tornar o desenvolvimento impossível.

Para contornar essa realidade usamos em nosso dia-a-dia abstrações que visam simplificar o que estamos tentando entender ou resolver em termos mais contidos.  Infelizmente como efeito colateral das abstrações também escondemos detalhes relevantes a solução.

Com isso criamos soluções que funcionam em certas condições mas não em todas.

O que temos feito a esse respeito?

Em minha opinião nada que efetivamente produza resultados.  Basta acompanhar que o ritmo de linguagens e frameworks só aumenta em vez de diminuir.   Ou seja, continuamos a aumentar o caos já que com a quantidade de linguagens, plataformas existentes quem pode realmente se considerar um especialista?

O Java está na versão 7.0 e ainda contem problemas de compatibilidade e funcionamento que existem desde seu lançamento há mais de 15 anos.

Nos preocupamos em “avançar”, criando novas camadas de abstração sobre as que já existiam em vez de se concentrar em resolver problemas.

É por isso que não creio que vejamos uma real melhoria no quadro enquanto a realidade por trás dos problemas não for colocada como prioridade pela indústria.