Pragmatismo na prática de engenharia de software
Muita gente confunde pragmatismo com fazer o mínimo possível. Eu vi engenheiros usarem esse termo como desculpa para entregar código ruim sem teste e depois se acharem filósofos. O que é ser pragmático de verdade não tem nada a ver com preguiça ou atalho. Tem a ver com fazer a escolha certa considerando o contexto real em que você está trabalhando. Vou explicar do jeito que eu entendi depois de quebrar a cabeça anos. O pragmatismo começa pela definição filosófica mesmo, aquela do William James e do John Dewey, que dizia que uma ideia só é verdadeira na medida em que funciona na prática. Na engenharia de software isso se traduz numa coisa simples: a solução mais elegante do mundo não serve se ela não resolve o problema que o negócio precisa resolver agora. Mas aí já entra a parte chata, porque "resolver o problema agora" depende inteiramente de quem pergunta e qual é o horizonte de tempo dele.
O que é ser pragmático de fato
Ser pragmático significa tomar decisões baseadas em consequências mensuráveis, não em ideais abstratos. É escolher a ferramenta errada pro futuro se ela funcionar certo hoje. É aceitar dívida técnica quando o prazo aperta, desde que você anote a dívida e tenha plano de pagar. É reconhecer quando um protocolo complexo como Kafka ou gRPC é overkill e simplesmente usar HTTP com JSON. Eu tive um caso específico num projeto há alguns anos. A equipe toda queria implantar uma arquitetura de microsserviços com service mesh, istio, tracing distribuído e tudo mais. O sistema tinha talvez 50 requisições por segundo e era usado internamente por 30 pessoas. Eu argumentei contra por dois motivos práticos: a complexidade operacional triplicaria o tempo de deploy e qualquer bug de rede seria impossível de debugar sem SRE dedicado. A direção não gostou da resposta. Eu cedi. Implementamos os microsserviços. Em três meses estávamos gastando mais tempo consertando problemas de conectividade entre serviços do que desenvolvendo features novas. A solução pragmática teria sido um monólito bem estruturado com módulos separados, que era exatamente o que tínhamos antes e funcionava perfeitamente. Aprendi que ser pragmático às vezes significa empurrar a pedra colina acima e dizer não mesmo custando reputação.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto que ninguém gosta de ouvir: pragmatismo tem limite. Quando você entrega algo pragmático demais você acumula dívida técnica que janta seu velocity por meses. Já vi times que fizeram trocas pragmáticas semanais durante um ano inteiro e no final não conseguiam mais fazer deploy porque o código virou um monstro inexplicável. O pragmatismo puro sem disciplina vira caos. O equilíbrio é tratar cada concessão pragmática como um empréstimo com juros, não como uma doação. A nuance que os iniciantes sempre perdem é a diferença entre pragmatismo e oportunismo. Oportunismo é mudar de ideia toda vez que alguém mais poderoso na sala fala algo diferente. Pragmatismo é olhar para os dados, o prazo, a equipe disponível e o requisito real, e tomar uma decisão que pode ser impopular. Eu já vi gerente de produto pedir para remover validações de input porque "o usuário não vai digitar errado". Remover validação de input não é pragmatismo, é ingenuidade. Isso é falta de critérios. Pragmático seria validar no frontend pra UX boa e também no backend pra segurança, usando uma biblioteca existente em vez de escrever validação customizada do zero.
Outra coisa prática: pragmatismo exige métricas. Sem métrica você não sabe se sua decisão foi pragática ou sorte. Se você escolheu banco SQL em vez de NoSQL, me mostre os dados de query pattern. Se você escolheu não fazer refatoração, me mostre o sprint backlog e o custo de oportunidade. Decisão pragmática sem justificativa baseada em dados é só opinião disfarçada. O lado ruim que ninguém vende é que pragmatismo depende muito da maturidade do time. Num time júnior, pragmatismo vira gambiarra porque ninguém tem criterio pra saber onde traçar a linha. Num time sênior, pragmatismo vira paralisia porque todo mundo vê dez caminhos diferentes e ninguém decide. O pragmatismo funciona melhor quando existe um engineer owner que tem autoridade técnica pra decidir e responsabilidade pelo resultado.
Se você quer começar a pensar de forma mais pragmática amanhã, aqui vai um checklist que eu uso: primeiro, qual é o problema real que estou resolvendo? Segundo, qual é o custo de cada alternativa em tempo, dinheiro e manutenção? Terceiro, o que acontece se eu estiver errado? Se a resposta pro terceiro item for "nada grave", vai de pragmatismo. Se for "perda de dados ou downtime de horas", esquece pragmatismo e vai de engenharia sólida mesmo.
