Temos linguagens, tecnologias, padrões arquiteturais, processos, ferramentas. Temos incontáveis formas de entregar código em produção. Desde de um desenvolvimento dirigido à testes com integração contínua em ambiente distribuído até um arquivo modificado e que sobe para produção via FTP.
No fim do dia, o que importa é código funcionando em produção, aceito pelo cliente e o pagamento no bolso.
O caminho que cada um vai levar para alcançar esse objetivo varia, muitos conseguirão muito dinheiro por caminhos diferentes dos livros que lemos. Existem muitas formas para um mesmo fim.
Um cliente satisfeito, às vezes, é um cliente que pagou menos
Quando chamo um prestador de serviço de elétrica, manutenção ou hidráulica eu invariavelmente pergunto sobre alternativas de um serviço caro, e não raro, escolho alternativas com menos qualidade, mas que cabem no orçamento.
A qualidade em um serviço está quase sempre atrelada à durabilidade e a taxa de defeitos ao longo do tempo.
Morando em casa alugada, é muito raro eu topar pagar por um serviço excepcional que vai gerar um benefício de 10, de 20 anos para o imóvel. Eu topo que ocorra um defeito em dois anos.
Quando estamos nós, desenvolvendo software, nem sempre o cliente quer um software durável ao longo do tempo. Muitas vezes a solução tem um foco de ciclo de vida mais curto mesmo.
E está tudo bem.
Mas então qualidade não é importante?
Claro que é. É totalmente importante.
E muito provavelmente as empresas de maior porte e mais longevas precisarão e muito de softwares robustos, confiáveis e duráveis.
Muitas startups triunfarão e terão curvas de crescimento poderosas se os alicerces do software desenvolvido forem sólidos o bastante.
Nós, programadores e programadoras, entregaremos nossas soluções com cada vez menos erros e mais confiabilidade quanto maior nossa qualidade técnica.
Qualidade técnica nos aproximará de softwares mais lucrativos.
Quando eu produzo um código com TDD (e isso é 20% das vezes hoje em dia) eu tenho certeza absoluta que isso deixa meu código mais à prova de erros. Meu serviço fica com certeza mais confiável.
Quando eu organizo um sistema de deploy eficiente, eu tenho certeza que isso vai gerar imensa tranquilidade nas minhas demandas de atualização do software.
Quando crio uma arquitetura onde acerto nos locais onde ela deve ser flexível, é um prazer imenso adicionar uma nova feature com um esforço quase insignificante.
E isso não faz a menor diferença para o meu cliente, porque o que ele consegue ver ou avaliar é o software funcionando.
Interesse pela qualidade deve ser foco do programador, não do cliente
Alguns contextos, alguns tipos de trabalho, especialmente em começo de carreira, quando estas empresas atendem 15, 20 clientes, não exigem uma confiabilidade de 100%.
Já trabalhei em contextos onde era tolerável um erro ocorrer em produção na frente do cliente para que o custo fosse menor. Não é raro as pessoas desejarem pagar menos por um site, mesmo corporativo, em detrimento de melhor velocidade de carregamento, SEO e arquitetura de informação.
Esse tipo de contexto muito provavelmente vai se apresentar.
Porém, quanto mais usuários tem uma solução. Quanto mais as pessoas pagam por um produto, mais exigente as pessoas ficarão e mais confiabilidade e qualidade serão cobradas.
Ser um profissional de alto nível técnico nos aproxima de ambientes mais lucrativos. Nenhum líder em empresa que exige confiabilidade vai colocar alguém na sua equipe que possa levar risco para o código em produção.
Portanto, defendo, que em começo de carreira, nenhum programador e programadora espere dos seus chefes ou chefas, dos seus clientes, uma postura de favorecimento da qualidade.
A busca por qualidade técnica deve ser uma busca do programador.
Com o tempo isso nos aproximará de contextos onde essa qualidade técnica será valorizada. Nos ajudará a desenvolvermos soluções nos nossos ambientes locais com mais segurança do que clientes não tão bem cuidados estão acostumados e isso eleva o nível.
Apenas não espere das lideranças essa postura.
Tenhamos nós, essa postura.