Estivemos a pouco visitando um cliente que pretende desenvolver/utilizar um framework de programação visando um maior controle e desempenho dos aplicativos que irão rodar na empresa. Hoje em dia eles não têm uma padronização na programação dos softwares da casa e, pior, estes não são instrumentados. Esta falta de instrumentação, por sua vez, é responsável por certo caos no dia a dia da operação, pois fica difícil: saber que parte do aplicativo está causando problemas; fazer um capacity planning; etc.

Conversando sobre as expectativas reais que eles deveriam esperar com o uso de um framework, alertamos:

1. Um framework não garante desempenho. A chance de uma query causar scan table ou um lock, ou de um programador causar um loop infinito ou um memory leak, ou etc., é independente do uso ou não de um framework. No entanto, um framework pode ajudar a prover informações em tempo de compilação (ex.: forçando a tipagem forte) ou execução (ex.: incluindo log e instrumentação) para que seja mais simples achar e corrigir erros;
2. Um framework não é barato. Ele exige um treinamento ostensivo para arquitetos e programadores, pois ele induz a uma forma de desenhar e programar um aplicativo. No entanto, quando a cultura está estabelecida, é normal conseguir melhor qualidade e produtividade devido ao reuso e alto grau de repetição nas tarefas de programação;
3. Um framework por si só não garante uma programação correta. É fácil errar uma fórmula, é muito simples escrever uma query que traz milhões de linhas, é simples armazená-las numa variável de sessão, é mais simples ainda fazer um binding destas milhões de linhas em um grid. Porém, com boas práticas de revisão de design e de programação é simples visualizar erros como estes.

Portanto, aviso então aos navegantes: frameworks devem ser acompanhados por treinamento, arquitetura e processos que garantam a qualidade, produtividade e desempenho. Sozinho, nenhum destes vem de graça.

Este caso me fez recordar também de um outro cliente que produz um software altamente dependente do bom uso do banco de dados e que me pediu ajuda para melhorar a qualidade do produto. Como ele não tinha nenhum especialista em banco de dados e vendo que boa parte dos problemas advinha disto (sim – ele tinha muitos processos), recomendei a ele a contratação ou o investimento na formação de especialistas na empresa. Neste instante, para a minha surpresa, obtive uma resposta veemente: - não quero ficar refém de um profissional caro como este!

Bem, pelo que me consta, até hoje o produto tem problemas de qualidade e desempenho!

O que há de comum nestes dois casos? Creio que até hoje ainda não há solução de software/hardware que garanta qualidade e desempenho de um aplicativo sem um investimento mínimo no lado do recurso humano. Treinamento, um mínimo de processos e ferramentas adequadas faz a diferença entre o sucesso ou fracasso no uso de uma tecnologia.

Estou errado?