Otimização Prematura vs. Débito Técnico

Lá na empresa temos um evento de uma hora onde o pessoal pode compartilhar conhecimento sobre qualquer assunto, normalmente a cada edição tentamos agrupar por temas, técnicos, variados e validação de produto. E quando eu digo variados, é variado mesmo! Vai de ensinar a como dar um feedback (acredite, não é algo simples) até a quais as diferenças do português brasileiro e o "dialeto Gaúcho" ¯\_(ツ)_/¯. Em outro post, falo mais sobre esse evento e sua importância no nosso contexto enquanto área de inovação.

Em uma das minhas participações neste evento fiz uma talk sobre o assunto que falarei aqui hoje. Lembrando que tudo o que será dito aqui se encaixa em um contexto, não tente levar tudo ao pé da letra pois o seu contexto pode ser completamente diferente.

Na grande maioria das vezes quando estamos criando uma aplicação do 0, temos um grande green field para trabalhar, ou seja, liberdade para escolher quase tudo. Então vamos lá:

• Escolha do framework

Como bons desenvolvedores javascript já escolhemos o framework antes de pensar em qualquer outra coisa. Não importa se esta em beta, alpha, gama, o que importa é que seja hypado.

• Microservices

Obviamente utilizaremos uma arquitetura de micro-serviços bem modularizada e robusta para que a nossa solução escale facilmente quando atingirmos milhares de acessos.

• CI / CD e o Flow

Agora é a hora de escolhermos o flow de trabalho e que ferramentas serão utilizadas para fazer o deploy, configurar pipelines, ferramentas de qualidade de código e testes, monitoramento da saúde da solução e por assim por diante…

• Cloud ou MultiCloud

Quase tudo pronto, falta escolher a cloud em que vamos operar ou AS clouds. Porque por exemplo, nos sentimos mais a vontade trabalhando com o Watson do que com o LUIS, mas as melhores soluções para deploy são as da AWS. Está decidido, precisamos de duas nuvens.

Dois meses de codificação, configuração e integração da stack, a nossa solução finalmente vai ao ar, e:

Um inovador e esplendido To-do app.

Obviamente esse caso foi um pouco forçado, mas quando investimos o dobro do tempo para escrever o código mais performático e que na verdade vai render 1 nano segundo de performance ou quando aprovisionamos a melhor infra estrutura para garantir a estabilidade daquilo que sequer sabemos se será necessário escalar, caímos na armadilha da Otimização prematura.
Neste cenário, teremos um maior tempo de desenvolvimento, porém, provavelmente entregaremos melhorias de uma forma mais ágil e também o tempo investido na correção de bugs será menor.

Mas, o que ocorre na maioria das vezes, é que o desenvolvedor utiliza isso como argumento para entregar um software ruim para o cliente, ou seja, "Não vou escrever um código limpo e performático, pois é Otimização prematura". E quem paga o preço é o cliente, quando recebe uma solução cheia de bugs, instável e com uma usabilidade ruim.

Para exemplificarmos o Débito Técnico, utilizaremos uma arquitetura de monolito ❤.

Lembrando que uma arquitetura de monolito não é sinônimo de Débito Técnico, apesar de que na maioria das vezes as duas caminham de mãos dadas.
Aqui nos desprendemos de todas aquelas escolhas de ferramentas e focamos somente em entregar a solução, seja de que forma for.

Consequentemente, teremos menos tempo de desenvolvimento pois só teremos que cuidar do nosso tijolinho (app). Pois ele não precisa ser extremamente modularizado, pode ficar tudo em um "componente" mesmo, sem problemas. Aqui a nossa regra de negócio se mistura com a View, que se mistura com o Model e pela união dos seus poderes formam a Controller.

Nesse cenário entregamos mais rápido, porém o custo de performance, manutenção e entregas rápidas de valor ao cliente serão drasticamente afetados. Sem contar as anomalias que serão geradas oriundas de um código criado por um desenvolvedor que abraçou completamente o Débito Técnico.

Ambas as escolhas impactam em uma coisa muito importante, principalmente se você é uma Startup. E ela é o tão precioso:

Quando optamos pela Otimização e investimos muito tempo criando o estado da arte, o nosso concorrente já entregou o seu MVP e já esta validando se a solução vai dar aderência no mercado, enquanto que se optarmos por abraçar o Débito, chegaremos mais rápido ao mercado, mas provavelmente a nossa solução terá um imensidão de bugs que impactará na usabilidade do usuário e assim a sua opinião frente ao nosso produto.

E agora ?

Você precisa usar o Débito para entregar mais rápido e conseguir validar suas idéias, ao mesmo tempo que você também precisa da otimização para entregar uma solução funcional para o seu público alvo. O segredo aqui é o mesmo da vida: o equilíbrio. Você pode estar se perguntando agora, "Tá, mas e quando eu sei ponto de maturação ?" A resposta é: não sei!
Lembre-se que lá no início eu disse que o contexto importa. Não existe uma bala de prata para isto e você precisa exercitar o conceito do Lean Startup aqui: Construir, Medir e Aprender. Somente desta forma você saberá o quão maduro está para começar a refatorar e otimizar a sua aplicação.

Enfim, a mensagem final e também a versão TL;DR; desse post é:

Use o débito técnico a seu para favor para entregar mais rápido, mas seja sábio para deixá-lo para trás quando estiver maduro.

Até o próximo!