Caso você seja programador (ou apenas curioso) e ainda não tenha topado com este post no Quora (originalmente publicado como How do I explain to non-programmers how complex, time-consuming, and error-prone software development is?) sugiro que você pare o que estiver fazendo e vá dar algumas boas gargalhadas. Bom, talvez se você não entenda nada de programação, vai ser mais um choque de realidade do que uma história engraçada.
De qualquer modo, traduzimos, livremente, neste post algumas das respostas mais criativas para a pergunta acima! Atenção: Pequenas adaptações dos textos em inglês para o português foram feitas, não apenas para facilitar a tradução, mas também para melhor se adequar à nossa realidade brasileira (afinal, por que falar em adicionar leite ao chá quando ninguém bebe chá com leite por aqui? – você logo vai entender do que estou falando).
“A cerimônia do chá” por Channing Walton.
Peça para a pessoa interessada em saber como funciona o trabalho de um programador descrever os passos necessários para fazer uma xícara de chá. Provavelmente ela dirá algo como:
- Coloque água para ferver;
- Coloque o chá em uma caneca;
- Quando a água ferver, despeje-a na caneca;
- Espere por 5 minutos;
- Beba.
Agora sim a diversão começa. Você precisa começar a fazer as seguintes perguntas:
Água fervente?
- De onde vem a água?
- Onde está a chaleira?
- Como você coloca a água na chaleira?
- Como você sabe a quantidade certa de água a colocar na chaleira?
- E se não houver água / chaleira / eletricidade / gás?
Coloque o chá em uma caneca?
- Onde está a caneca, e se não houver uma? Devíamos ter pensado nisso antes de ferver a água?
- Onde está o chá e qual tipo de chá será utilizado? Deveríamos ter perguntado primeiro, talvez não deveríamos ter começado isso se não tivermos o chá, certo?
Derramando água fervente?
- Você tem certeza de que a água ferveu?
- Como você se certifica de que a caneca foi corretamente preenchida?
- E se durante a preparação do chá a caneca vazar?
E assim por diante. Você pode continuar por horas. Quem perguntou ficará entediado e, provavelmente dirá “sim, mas esse nível de detalhes é bobo”. Nesse momento, você pode sorrir e dizer “exatamente”.
P.S.: Depois de tudo, diga que, na verdade, o cliente realmente queria um café expresso duplo e não uma cerimônia de chá japonesa. Mas certamente você deveria saber disso, não estava óbvio nos requisitos?
“A ponte que ninguém quer cruzar” por Daniel Caspers
Aqui está uma receita curta, caso você precise ser objetivo.
Diga-lhes que é como construir uma ponte, mas com os olhos vendados. Precisa ser assim porque a engenharia de software não é diretamente tangível. Tudo o que fazemos precisa de alguma forma de abstração ou representação alternativa para ser compreendido, de modo que a analogia base abrange a engenharia complexa e a caótica falta de visibilidade durante todo o processo. Em seguida, adicione os ingredientes abaixo a gosto, conforme o seu humor para ilustrar o quão complexo, demorado e difícil o processo pode ser:
Complexo
- Um engenheiro quer construir a ponte com um novo material, porque parece legal testar o novo material. Existe uma grande força comprovada, apesar de ele desconhecer suas possíveis fraquezas (sobre novos frameworks);
- O engenheiro constrói a ponte para, só então descobrir que ninguém quer atravessar a ponte de qualquer maneira (sobre um projeto sem validação de mercado);
Demorado
- Sua ponte extrapolou o orçamento e você sequer está no meio de sua execução (sobre escopos mal definidos);
- Você acaba de passar 6 dias tentando descobrir por que a metade da ponte está torta e inacessível pela equipe (sobre não ter a menor ideia do que pode ter acontecido);
- Você passa metade do tempo dirigindo sobre a ponte com muitos carros, enfrentando ventos fortes porque você não quer se tornar a Ponte Hercílio Luz de Florianópolis (atualmente desativada);
Suscetível a erros
- Alguém decidiu soltar os apoios de concreto no rio antes da hora. Como não houve planejamento os apoios desviaram o caminho e foram irremediavelmente perdidos rio abaixo. Agora você precisa criar novos apoios (sobre retrabalho);
- Você descobriu que estava faltando centenas de quilos de aço porque o estagiário acidentalmente jogou fora pensando que era sucata (sobre problemas de comunicação);
- Você recebeu o escopo de projeto do time anterior que estava construindo a ponte. Porém, o outro time deu início à construção do lado oposto do rio. Não há nenhuma maneira de fazer com que ambos projetos se encontrarem no meio do caminho (sobre pegar o bonde andando).
“Sério, rápido e rasteiro” por Bob Cormack.
Minha resposta rápida para a questão (e aos gerentes que se queixam que as estimativas de conclusão de projeto nunca são confiáveis) é o seguinte: ao escrever software, você está resolvendo problemas que você nunca resolveu antes. Por isso, estimativas de dificuldade e de tempo de conclusão, são aproximações (as vezes mesmo quando há um escopo bem desenhado).
* Se você tivesse um software que já resolveu o problema em questão, você simplesmente o reutilizaria.
Apesar da brincadeira e de saber que projetos de software podem sim ser bastante complexos, nós, da Vibbra!, esperamos que se tornem cada vez mais acessíveis. Afinal, “software está dominando o mundo” como atestou Marc Andreessen e não podemos deixar que tamanha complexidade nos vença.
