A fabricação de objetos físicos é amplamente compreendida, principalmente porque a mesma coisa está sendo produzida repetidamente. Se você está produzindo widgets, o processo é ordenado, repetível e possivelmente até mesmo aperfeiçoável. Você pode encontrar e melhorar o pior gargalo repetidamente até que todo o processo seja altamente eficiente.
Construir pontes e casas é menos repetível, mas em ambos os casos o processo foi desenvolvido ao longo de muitas décadas, até mesmo séculos. Há poucas surpresas. Mas construir software? Isso é outra história. Cada projeto, grande ou pequeno, é único e nunca foi feito antes. Há inúmeras maneiras de resolver um determinado problema e pessoas inteligentes discordam sobre qual é a melhor maneira. Talvez nem haja uma única melhor maneira. Muitas vezes, uma maneira melhor só se revela depois que você faz o projeto pela primeira vez. Depois que você escolhe um caminho, sempre haverá um número desconhecido de incógnitas desconhecidas. (Viu o que eu fiz ali?)
Claro, desenvolvemos algumas práticas recomendadas ao longo dos anos e alguns padrões surgiram, mas os desenvolvedores podem até divergir sobre como esses padrões podem ser implementados.
Em outras palavras, geralmente há uma maneira bem clara de criar widgets, mas há um número aparentemente infinito de maneiras de criar um projeto de software, o que torna problemática a noção de "melhor maneira".
Bola de cristal em um buraco negro
E isso, é claro, faz com que descobrir quanto tempo um projeto de software levará seja muito, muito difícil. Mesmo depois de anos tentando, ninguém parece ter encontrado uma maneira confiável de fazê-lo. Muitas pessoas — eu inclusive — consideram isso praticamente impossível.
Agora, a frase "praticamente impossível" não é algo que um empresário quer ouvir. Se você está produzindo e vendendo software, seus clientes não querem ouvir você dizer: "Sabe aquele software que você nos pediu para construir? Bem, não temos certeza de quando ele estará pronto. Ainda estamos descobrindo a maneira certa de construí-lo. Tentamos uma maneira, e não deu certo, mas poderíamos ter descoberto uma maneira melhor como resultado. Mas como não temos certeza absoluta de como faremos isso, não podemos dizer quando ele estará pronto e funcionando."
Agora, embora a confissão hipotética acima seja a verdade, poucas lojas de desenvolvimento de software admitirão isso para o cliente, muito menos para si mesmas. Elas podem nem perceber que é verdade.
A indústria de software fez (e continua fazendo) grandes esforços para resolver esse problema, e muitos gerentes de marketing de produtos para ferramentas de processo de software dirão que o resolveram. (Acredite, eles não resolveram.) Muitos textos de marketing foram escritos e muitas promessas foram feitas, mas o fato é: ninguém sabe quando esse projeto de software será concluído.
Como o software é tão maleável
Como o software é tão maleável e capaz de entregar novos recursos, os clientes tomam decisões de compra em parte com base nos recursos atuais, mas frequentemente com base na "próxima grande novidade". Como resultado, o lado comercial promove, e frequentemente até vende, recursos que ainda não existem. Naturalmente, os clientes querem saber quando esses recursos chegarão. E, naturalmente, as empresas de software prometem entregar recursos dentro de um determinado prazo.
Muitas vezes, essas promessas são difíceis de cumprir. As equipes de desenvolvimento de software adorariam poder dizer ao pessoal de negócios precisamente quando as coisas chegarão, mas, como observado acima, elas não podem. (Elas podem dizer e agir como se soubessem, mas não sabem...) Elas são frequentemente pressionadas a dar uma data. Muito esforço é feito para prever essa data, mas essas estimativas estão quase sempre erradas. Às vezes, elas estão espetacularmente erradas.
O banco de duas pernas e três pernas
Então, o que uma equipe de desenvolvimento deve fazer? Existem mostradores que podem ser girados. O primeiro mostrador que todos giram é trabalhar mais horas. Isso pode funcionar. No entanto, pressionar uma equipe geralmente resulta em mais atalhos e mais erros, aumentando a dívida técnica, mas não necessariamente produzindo uma entrega no prazo. Os gerentes são tentados a adicionar mais pessoas para aumentar as horas trabalhadas, mas então a Lei de Brooks entra em ação e as coisas pioram.
Alterar o conjunto de recursos entregues é outra solução comum. Outro caminho é sacrificar a qualidade, seja reduzindo a correção de bugs ou diminuindo a eficácia da interface do usuário. Finalmente, pode-se mover o cronograma, mas isso irrita os clientes pagantes.
Portanto, temos o famoso banco de três pernas de "qualidade, cronograma ou recursos — escolha dois!" O negócio odeia sacrificar cronograma e, às vezes, se recusa terminantemente a fazê-lo. Os clientes, cujos sentimentos são terrivelmente importantes, não gostam de mudar datas e geralmente abominam reduzir recursos.
Isso deixa a qualidade na tábua de corte, e sejamos honestos, esse é geralmente o caminho tomado. Ninguém gosta de um aplicativo com falhas, mas é fácil e tentador esconder a má qualidade por trás de recursos aparentemente funcionais. É muito rotineiro para os clientes receberem a entrega de "software funcional" e só descobrirem a falta de qualidade depois do fato. A equipe de software então corrige os bugs e entrega um "lançamento pontual" que melhora a qualidade. Esta é, na verdade, uma maneira muito astuta de alterar o cronograma — colocar o tempo de correção de bugs depois do tempo de entrega.
E essa maneira "inteligente" de resolver o problema é normalmente a escolhida. A equipe de desenvolvimento consegue (supostamente) atingir a data, os recursos prometidos ao cliente são entregues e todos ficam felizes. Até que executem o software.
Não estamos fazendo gadgets e engenhocas. No final, alguém tem que comer o sanduíche de cocô, e geralmente acabam sendo os desenvolvedores de software e a equipe de QA. E é por isso que você obtém software com bugs.
