Executando verificação de segurança...
1

Passei também mais de uma década zanzando por essa área de tecnologia, e até trabalehi um tempo para uma big tech com escritório em Mountain View. A qualidade lá importava, sim. Mas não por um ideal nobre de engenharia ou por amor ao código limpo. Importava porque alguém calculou que, no longo prazo, era mais barato. Alguém botou numa planilha que cada hora gasta em teste economizava dez horas de correção de bugs. Era uma decisão puramente econômica.

A virada de chave, a epifania que mudou tudo, não veio de lá. Veio quando troquei o mundo do software pelo mundo da engenharia. De verdade. Coisas que, se falharem, não geram um ticket no Jira, mas um inquérito judicial e investigação policial Aqui o conceito de "dívida técnica" muda de figura e simplesmente se torna inaceitável. Enquanto nosso ofício for tocado por "desenvolvedores", a dívida técnica vai crescer. No dia em que ele passar a ser dominado por "engenheiros de software", com a responsabilidade que a palavra "engenheiro" carrega, a coisa muda.

Software precisa ser tratado como uma disciplina de engenharia. Ponto. Como a civil, a mecânica, a elétrica. Até que nossa área seja regulada, até que tenhamos que assinar embaixo do que produzimos, a dívida vai continuar crescendo. Pense nisto, uma analogia simples: para levantar um prédio, ou mesmo uma casa, você precisa submeter o projeto estrutural e arquitetônico para a prefeitura. Um engenheiro civil assina, assume a responsabilidade técnica e um servidor público avalia se o projeto segue os mínimos padrões de qualidade. A verdadeira pergunta, que vale mais do que qualquer, é: por que não fazemos o mesmo com o software que hoje sustenta o mundo?

Carregando publicação patrocinada...