“Software vem sendo feito de forma artesanal.
Era mais ou menos isso que meu coorientador dizia nas aulas ou em outras conversas no qual ele reforçava o quanto o mercado de software era defasado. Eu achava ter entendido a dimensão dessa fala, mas cada dia me surpreendo o quanto essa ideia é viva no mercado, e achei justo discursar mais sobre isso.
É natural que alguém que não seja da área, veja o desenvolvimento de software como algo trivial. “É só criar essa interface”, “Não deve dar trabalho não”, “Faz ai, qualquer dúvida pode me perguntar”. São algumas das frases que estamos acostumados a ouvir. O problema maior começa quando os desenvolvedores também acreditam que pra satisfazer as necessidades dos seus clientes, basta simplesmente por a mão na massa.
Um dia essa foi a única forma de desenvolver software. Conforme explica Sommerville, os sistemas de software não eram grandes e complexos, portanto não demandavam as técnicas e métodos que surgiram a partir da chamada crise do software. Quando o hardware começou a permitir o que até então parecia inviável, o mercado sentiu uma pressão que resultou nos inúmeros métodos de desenvolvimento que conhecemos hoje, alguns dos quais enchem as bocas dos marketeiros que vendem a ideia do desenvolvimento perfeito de software.
O que ninguém esperava, é que muitos desses métodos seriam usados de forma tão deformada, escondendo com encanto um desenvolvimento artesanal, sob o pretexto de um compensador processo comunicativo, colaborativo e adaptativo, um autêntico mito da bala de prata do desenvolvimento de software. Eu não sou o primeiro a dizer isso, o ousado artigo Agile is Dead reporta uma onda de discurssão nesse sentido.
O que tenho observado, é que a confiança demasiada nos valores ágeis gera uma certa negligência nas atividades centrais do desenvolvimento de software, como por exemplo, análise e levantamento de requisitos, desenho de software e testes. Tem uma boa razão pra isso. Por exemplo, é mais fácil acusar falha de comunicação do que perceber que o problema de não estar correspondendo as expectativas do cliente é por uma falha ou descaso total com os requisitos de software.
“Ok, mas qual o contrário disso?
Por motivos óbvios, prédios, aviões ou mesmo eletrodomésticos, não são feitos sem um trabalho de engenharia. Sem engenharia esses projetos não seriam confiáveis, teriam uma qualidade inferior com preços e prazos superiores, a história tem inúmeras provas da falta ou falha de engenharia. Com software não é diferente.
Não existe outra saída, projetos de qualidade exigem Engenharia, a acadêmia e os gigantes do mercado já sabem disso. Outras empresas nadam a deriva a procura de produzir software barato, com filosofias ou métodos “inovadores”. O que para pequenos projetos pode dar certo, ao passo que se aumenta a complexidade, pode se tornar um pesadelo.