Fotografia de capa por Ries Bosch, tirado por uma Nikon D5600
Galera umas das lições mais importantes que tive na minha carreira é saber nivelar complexidade instrumental de complexidade inerente.
Complexidade instrumental = Linguagens/bibliotecas/frameworks que você coloca no projeto
Complexidade inerente = É a complexidade do projeto em si
Ex:
Complexidade instrumental = Node.js, Typescript, ReactQuery, Zod..
Complexidade inerente = Aplicação de apostas online, sistema de controle de estoque
Quando criamos um produto precisamos nivelar essas duas, caso contrário o que acontece é
Complexidade instrumental > inerente = over engineering
Complexidade inerente > instrumental = reinventar a roda
As vezes colocar ReactQuery no projeto vai mais atrapalhar do que ajudar.
Tá, mas como acho o ponto de equilíbrio?
Aí entra um movimento chamado boringtechnology.club, que funciona basicamente assim:
No lado esquerdo temos problemas do nosso negócio e do lado direito temos as tecnologias que pode ou não nos ajudar a resolver os nossos problemas.
O objetivo é tentar conectar os círculos para resolver o problema (escolha da tech).
A cada escolha, vem também um benefício e um custo de manutenção, ou seja, se você for resolver outro problema e precisar de outra tecnologia, a equipe paga pelo custo de manutenção.
Se você tem 1 benefício para 1 custo, logo eles se anulam, agora se você tem mais de um benefício para um mesmo custo, a escolha da tecnologia se paga.
Nesse caso, 1 tecnologia resolve 2 problemas com o mesmo custo 🔥