Esse é um relato dos meus 20 anos no mercado. Por sorte e até ironia do destino, eu vi o papel do arquiteto desde o dia 1 de minha jornada de trabalho. Isso me possibilitou entender que arquitetos e desenvolvedor possuem interesses diferentes. Aqui vou mostrar o que esses anos vendo e ajudando projetos me possibilitou compreender.

Não existem deuses!

Embora na prática a gente veja arquitetos cheios de ego, e perdão por isso, já estive ocupando essa posição de arrogância.

Eu já acreditei que todo desenvolvedor se tornaria arquiteto um dia, e que arquitetura fosse um caminho natural, que fosse um passo após a senioridade. Eu estava enganado.

Hoje faço uma leitura diferente e parte dela eu vou trazer aqui nesse texto.

Mas uma característica importante é que interesses de desenvolvedores e arquitetos são diferentes, e dependendo dos stakeholders, podem até ser conflitantes.

Qual o papel de uma arquitetura?

Segundo Robert C. Martin ( Uncle Bob ) em Clean Architecture:

O objetivo da arquitetura de software é minimizar os recursos humanos necessários para construir e manter um determinado sistema.

Em termos mais abstratos, o objetivo de uma arquitetura de software é assegurar que os objetivos de longo prazo serão cumpridos junto com os objetivos de curto prazo.

A arquitetura está mais ligada à estratégia para ganhar a guerra, já o desenvolvimento diário, cotidiano, de uma funcionalidade, está mais próximo da batalha da vez.

A arquitetura dialoga com os interesses da corporação, empresa ou C-level. O desenvolvimento dialoga com o interesse dos stakeholders.

São forças que podem estar alinhadas, empurrando em uma mesma direção, MAS NÃO É MUITO DIFÍCIL VERMOS O OPOSTO.

Não é nada raro encontrarmos situações de total desalinhamento entre interesses de longo prazo e objetivos de curto prazo. Ou interesse corporativo, versus interesse dos stakeholders de um projeto.

Como e porque stakeholders podem ter interesses diferentes dos interesses da corporação?

Nós vamos encontrar esse desalinhamento na natureza humana. Pois é pelo exato mesmo motivo que pessoas estão obesas, fumam, se drogam, se matam aos poucos diariamente. Ou não poupam dinheiro para ter um futuro melhor.

Se há uma certeza que tenho na vida é que a maior fraqueza humana está à prova quando temos benefícios imediatos se opondo a benefícios futuros. Nós não temos por padrão, o drive de cadenciar ambos. Nossa sociedade não lida bem com isso.

O esperado é que busquemos benefícios imediatos em detrimento benefícios futuros, mesmo que esses sejam ainda mais recompensadores. Seja para sua vida, sua saúde, sua prosperidade. A natureza humana exige sacrifícios hoje para que amanhã, se você estiver vivo, possa usufruir do que você está acumulando em saúde, capital, intelectual … muitas vezes esse acúmulo, se torna exponencial.

A incerteza do amanhã faz com que busquemos hoje uma solução imediata e intensa para um problema, mesmo que sacrifiquemos nosso futuro por isso. Afinal, no futuro, esse problema se tornará urgente o suficiente e teremos a chance de fazer o mesmo!

Os gestores de caos

Quantos e quantos gestores de CAOS você já teve? Eu tive muitos!

Você sabe aquele gestor que adia tudo que é importante, até que aquilo vire urgente? Porque quando há uma crise, ele não só consegue transformar isso em capital político, mas consegue carta branca para infringir processos, regras, limites financeiros, para alcançar o objetivo de curto prazo que agora é emergencial, afinal, conter uma crise é o mais importante agora não?

Boa parte das vezes (e eu arrisco chutar que todas as vezes) a crise poderia ser evitada, ela sequer precisava ter ocorrido se houvesse quem defendesse os interesses estratégicos desse projeto. Boas são as chances dos stakeholders produzirem demandas que culminarão exatamente nessa crise futura.

Uma crise futura previsível é irrelevante perante uma conquista ou realização imediata.

Há quem capitalize uma crise,

mesmo que essa crise pudesse ter sido evitada,

mesmo que seja reflexo acidental, ou até intencional de suas ações, decisões e/ou atitudes,

mesmo que tenha sido anunciada.

Eu vi isso acontecer incontáveis vezes!

Eu estive, como desenvolvedor ou arquiteto, diversas vezes, fazendo parte do quadro de coadjuvantes que simplesmente executava esses interesses.

Algumas vezes eu tive a oportunidade de dizer não, outras vezes eu conseguia contornar e lavar a roupa suja depois da implantação.

Mas a maioria das vezes eu simplesmente tinha de fazer o melhor com a restrição que me era entubada.

O ecossistema corporativo é propício para o caos, e beneficia tratadores de crises!

O reflexo dessa disparidade entre interesse estratégico e objetivo de curto prazo é a produção de caos em formato de crises recorrentes!

Não cuidar da arquitetura, dos débitos técnicos, produz esse caos, que hora ou outra culminam em crises.

O mesmo caos que alimentará e impulsionará a carreira do gestor que, ao se deparar com outra crise no futuro, será novamente incentivado por “resolvê-la”. Mas nunca será encorajado a não produzi-la.

Esse é um ciclo vicioso, que beneficia quem atenua e ameniza as crises em vez de valorizar a não existência de crises.

O jogo de interesses do mercado corporativo faz com que um gestor de caos e um político tenham os mesmos interesses e se comportem da mesma forma.

Fazer o que precisa ser feito não é popular.

Mas contornar crises, é! Assim nascem os salvadores da pátria. A política e o universo corporativo possuem mais semelhanças do que podemos imaginar.

Não há diferença entre esse profissional e um político que realiza ações populistas para gerar capital político e midiático com o intuito de conquistar o próximo mandato e se perpetuar no poder, ignorando muitas vezes, investimento em infraestrutura, no qual sua colheita será no longo prazo, e possivelmente por um concorrente político.

Afinal, se ele não estiver mais ali, outro colherá, e se ele estiver, ele terá carta branca, budget para contornar a crise, de forma a gerar novos problemas que culminarão em novas crises, que ele mesmo será beneficiário da solução no futuro.

Não é diferente na política, não é diferente na vida.

E assim gradativamente vamos gerando lixo ao invés de software. “Toneladas” de lixo virtual.

Tóxico, principalmente aos novatos, estagiários e qualquer um que “se forme” nesse ambiente tecnicamente tóxico.

Quando a gambiarra é o único caminho, sua vida se torna um caos. Porque para cada gambiarra, serão necessárias outras.

Eu conheço algumas receitas de bolo para chegar a esse caos

Isso mesmo, são decisões ruins das quais eu vi os resultados e te asseguro que produzirão efeito similar em qualquer lugar.

Se olharmos para a arquitetura inicial da maioria dos projetos que tiveram um bom e experiente arquiteto presente, a maioria das demandas foram pensadas desde o início do projeto.

Em linhas gerais, são perguntas como:

Como fazer?

Como evoluir?

E quando chegar lá, o que será possível fazer?

Já são respondidas no primeiro mês de projeto. Elas fazem parte da estratégia de evolução de uma arquitetura, onde prevemos o que será refeito quando e o que deixaremos para depois. Não é ao acaso, é deliberado e intencionalmente escolhido atacar ou não o problema e vislumbra-se a arquitetura pensando nesse objetivo de longo prazo. A visão atual, é o início da jornada até esse outro momento.

É parte da estratégia da arquitetura, e eu defendo que arquitetura é o exercício dessa estratégia em si, dedicar atenção ao futuro do projeto. Entender o que não faz sentido hoje, mas o que fará sentido no futuro. Para que seja possível construir um caminho objetivo, que leve do estado atual ao objetivo no futuro.

A maior parte das grandes falhas em arquiteturas que eu conheço são baseados em um único equívoco:

Não fazer o que deveria ser feito!

São cenários em que:

• Ao invés de criar uma tabela, criava-se uma coluna, de uma forma porca. Ignorando boas práticas de modelagem.
• Ao invés de seguir as premissas de desacoplamento, aceitar implementações que produzem nenhum reuso, e aumentam acoplamento.
• Ao invés de criar campos e flags nas tabelas, que indiquem o comportamento adequado, produz-se if’s com base em ID’s.
• Ao invés de evoluir abstrações existentes, busca-se criar novas abstrações, transformando o projeto em um canteiro de obras inacabadas.
• Ao invés de refatorar consumidores de uma abstrações antiga, eliminando-a em função de uma nova abstração, deixa que existam 2 abstrações para o mesmo assunto, criando um poço de complexidade acidental.
• sem refatorar as antigas, produzindo código duplicado.
• Ao invés de resolver o problema de uma forma escalável, cria-se gambiarras minimalistas que mais atrapalharão do que ajudarão para não “usar um canhão para matar uma formiga”.

Mas afinal, o que difere desenvolvedor de um arquiteto?

O primeiro ponto óbvio é a experiência. Não é possível fabricar experiência em uma sala de aula.

O que é possível é dar mecanismos para que toda experiência adquirida posteriormente seja vivenciada com um olhar mais clínico e mais astuto.

Desenvolvedores estão empenhados em produzir o melhor software, funcionalidade-a-funcionalidade, resolvendo um problema por vez.

Arquitetos estão empenhados em garantir que esse desenvolvimento seja mais eficiente, eficaz, e não fira os interesses de longo prazo do projeto.

Enquanto o desenvolvedor busca alcançar requisitos funcionais, o arquiteto busca facilitar a entrega desses requisitos, sem perder controle da arquitetura, garantindo que a ambição de resolver o requisito funcional não seja nocivo para a própria estrutura do projeto.

Então desenvolvedores são nocivos para o projeto?

Não! De forma alguma eu quero dizer isso. O que eu quero expressar é que atitudes como:

Se a intenção é transformar um projeto em um playground e fazer projeto que consiste em simples CRUD’s com DDD e Microsserviço, Event Source e Mensageria… com certeza!

Se o desenvolvedor quer criar novas abstrações para assuntos que já possuem abstrações, sem planejar um takeover da abstração antiga pela nova.

Se um problema deve ser resolvido com a criação de uma tabela, mas adota-se uma coluna apenas, como forma de minimizar o esforço, mesmo que não seja o certo a ser feito.

Sim, são nocivas para qualquer projeto.

Não há nada mais definitivo que uma gambiarra temporária.

E o arquiteto então é o salvador da pátria?

Lembra o que eu disse? Não há deuses e também não há salvadores da pátria.

Mas como o papel do arquiteto é trazer produtividade, e defender os interesses mais estratégicos desse projeto, ele é uma força que hora colabora como acelerador e hora como freio, construindo limites que não levem à anarquia, e que ao mesmo tempo não leve à improdutividade.

Eu deixei passar propositalmente…

Alguns temas, como eficiência na escrita de código, clean code, clean architecture, e outras decisões propositalmente. Eu vou abordar individualmente cada um desses temas em outros posts.

Onde mora o problema?

Propositalmente, eu deixei para o fim essa treta.

Então, os problemas estão com as pessoas?

Ou os problemas estão nas atitudes das pessoas?

Eu deixo aqui uma questão filosofal que gostaria que você opinasse. Eu, acredito que o problema está na atitude das pessoas diante de problemas: grandes problemas e pequenos problemas.

E acredito que a consistência em uma atitude negativa perante esses problemas faz com que a pessoa seja o problema.

Eu já vi muitos desenvolvedores dizendo que tudo que viram na vida era gambiarra e sempre projetos daquele jeito. Passaram por 2, 4 , 6 projetos assim.

Aí eu te pergunto: Qual é a única variável conhecida em 6 empresas/projetos por onde a pessoa passou?

Das duas uma, ou ela é o problema, ou o processo de escolha de lugares para trabalhar é o problema. Ou os 2.

Curtiu? Então diga o que achou!