Na minha palestra do TechEd falei bastante de arquitetura, e citei que há um teste para o qual não conseguimos escrever testes unitários. Você adivinha qual?

O teste do tempo.

Não há testes unitários para testar quanto tempo uma aplicação vai sobreviver. Uma das principais responsabilidades de um arquiteto de software é fazer com que a aplicação sobreviva o tempo esperado. E ele tem que fazer isso com as restrições impostas pelos outros requerimentos, como os requerimentos de negócio, e também os técnicos, como escalabilidade, extensibilidade, confiabilidade, e por aí vai. Não é tarefa fácil.

Sobreviver ao teste do tempo significa fazer uma aplicação que é útil ao longo de todo o seu tempo de vida, e que paga seu investimento ao longo de todo seu ciclo de vida, ou seja, que dá ROI. De nada adianta fazer uma aplicação que atende todos os requisitos de negócio, se ela custa mais do que o usuário quer pagar (ou usuários). Temos que conseguir nos equilibrar nesta relação de custo benefício. A palavra chave para isso é produtividade. Temos que ter produtividade durante todo o ciclo de vida da aplicação. Como conseguir isso?

Vamos analizar o que acontece no modelo mais difundido no mercado: o famoso "sair fazendo". Nesse modelo a equipe "sai fazendo" o código, sem se preocupar com boas práticas de desenvolvimento ou arquitetura.

Lembro bem daquelas demos no começo do ASP.Net, em que o palestrante arrastava uma tabela do Server Explorer para a página ASPX, e aparecia o datagrid, com os objetos de acesso a dados, todos já funcionando, paginando o grid, etc. Todo mundo ficava embasbacado, e o palestrante, propositalmente ou não, não contava que aquilo era demoware, ou seja, não era para ser usado em uma aplicação de verdade (e séria, e profissional). E muita gente usou. Qual o resultado? Uma altíssima produtividade, não é verdade? Claro que é, desde que você olhe para o curto prazo. No Teched usei um gráfico para representar essa atitude de trabalhar de qualquer jeito, sem boas práticas. Vamos olhar ele, só que só o seu começo:

Ele está cruzando produtividade com tempo. Temos então uma produtividade de 15, logo de início.

Esse é o gráfico com boas práticas:

Temos uma produtividade de seis, ou seja, menos da metade da produtividade do gráfico anterior, que trabalha sem boas práticas.

Observação: antes que você me pergunte "Seis o quê?", respondo: seis qualquer coisa. Imagine que este número está na sua métrica, ou seja, se você trabalha com pontos de caso de uso, então são 6 dias para um UCP (ou horas, ou sei lá), se você trabalha com análise de ponto de função, então são 6 dias para um ponto de função (ou meses, sei lá), se você trabalha com user stories, então são 6 horas por story point (ou dias, sei lá). Imagine que o número é uma medidade de entrega versus tempo, ok? Na prática não estou exibindo produtividade, mas taxa de entrega, mas a maioria das pessoas prefere o nome produtividade.

Os mais atentos já perceberam a essa altura uma pequena diferença nos gráficos. O primeiro está decrescendo, o segundo está estável. Vamos ver o primeiro gráfico completo:

A produtividade cai devagar por algum tempo. No meio do projeto ela cai vertiginosamente para 3, e fica por lá. E três é menos do que seis, certo? Quem nunca viveu isso? O projeto começa, tudo anda rápido, os prazos do nosso belo cronograma waterfall no MS Project são todos batidos, a previsão de entrega do projeto é até antecipada. Até chegarmos a uns 30% ou 40% do projeto, e tudo se enrola. O gerente do projeto volta o prazo original, de repente o prazo orignal é ultrapassado um pouco, e em pouco tempo o projeto está atrasado vários meses. Acontece o tempo todo, acontece em todo lugar.

Agora vejam o gráfico com boas práticas, completo:

Ele se mantém estável ao longo de todo o projeto. Qual a minha entrega? É a área debaixo do gráfico. Basta somar os valores para entender a entrega com uma abordagem e com a outra. 
No primeiro temos:  15+14.5+13.5+12.5+3+3+3+3+3 = 70.5
No segundo temos: 6*9 = 54

A primeira vista, temos uma produtividade maior no primeiro caso. Essa primeira vista é responsável por essa ilusão de que sair fazendo é uma boa idéia, e de que não temos tempo para sermos profissionais e trabalhar como engenheiros de verdade.

Vamos continuar nossos cálculos. Suponhamos que estas sejam semanas de desenvolvimento, e que o projeto se prolongue por 6 meses (24 semanas). Qual o resultado?
No primeiro temos: 15+14.5+13.5+12.5+3*20=115.5
No segundo temos: 24*6=144

A entrega nesse caso é 25% maior. Se o projeto se estender por um ano esse percentual dobra. O que isso significa?

Significa que temos um processo que entrega mais valor que o outro. Após os primeiros quatro períodos, entrega o dobro do valor. Por quanto tempo você quer valor? Por um pequeno e ilusório começo, ou por todo o tempo?

Esses números são apenas exemplos. Os números reais você vai ter que medir na sua equipe. Quando for fazer isso, além de somar o tempo do desenvolvedor fazendo o sistema, some também o tempo gasto em resolução de bugs que ninguém consegue resolver, problemas encontrados em produção, horas das equipes de DBAs, servidores, conectividade, segurança, horas de gestão, e por aí vai. Isso sem nem falar do stress. É possível você encontrar números ainda mais expressívos do que os que estou propondo por aqui. Mediu isso? Volta aqui e me conta, quero saber.

É claro que não é fácil para uma equipe realizar uma taxa de entrega estável. A equipe precisa estar entrosada, precisa ser um time de verdade, comprometido com a entrega final. Precisa ser uma equipe com bons conhecimentos de arquitetura e engenharia, e precisa ser suportada pela gestão da empresa. Poderia dizer que um deles é programar iterações curtas, mas não vou entrar nisso agora. Há muitos requisitos para alcançar essa linha estável, e posso garantir uma coisa: nenhum deles passa por "sair fazendo".

Da próxima vez que pensar em sair fazendo, lembre-se disso. Você está criando o que chamamos de débito técnico. Você está tomando emprestada um produtividade que você vai ter que pagar no futuro. E é você quem vai ter que explicar porque aquele designer mágico do Visual Studio parou de entregar, se antes tudo funcionava. Você está desenvolvendo de maneira não sustentável, e não vai passar no teste do tempo.

Pense nisso.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.