Uma história de terror dos tempos modernos

Esta é uma obra de ficção, nenhum dos fatos descritos aconteceu! Tudo o que eu escrevi obra de uma mente cheia de criatividade…

Era uma vez uma empresa pequena, mas lotada de bons desenvolvedores e com uma equipe de Arquitetura de Dados terrivelmente burocrata.

Imaginem que todos os modelos de dados criados pelos desenvolvedores tinham que ser avaliados e padronizados pelos terríveis ADs.

A direção da empresa acreditava que tendo uma equipe centralizada que fizesse a governança dos bancos de dados, eles teriam dados de qualidade. Na realidade não acreditava muito, mas um dos donos havia trabalhado como AD no passado e resolveu criar esta equipe, mesmo contrariando os outros 3 sócios.

Eram 15 desenvolvedores e 2 ADs. Quase que de forma sincronizada todos eles submetiam seus modelos para a equipe de AD, que não dava conta de avaliar modelos maravilhosamente criados!

Existia um padrão para criar e definir os modelos de dados, mas infelizmente a documentação era muito extensa e os desenvolvedores precisavam criar código e não ler documentos.

A equipe de AD reclamava injustamente dos itens abaixo:

• Os desenvolvedores achavam desnecessário normalizar os dados, criavam tabelas “orientadas a telas” porque funcionava melhor;
• Os padrões corporativos não eram seguidos, afinal os atributos deveriam ser conhecidos pela equipe de desenvolvimento;
• A definição das entidades era igual ao nome da entidade;
• O nome lógico dos atributos era escrito sem os termos conectores (preposições) conforme descrito no manual. E as definições eram a cópia do nome lógico, mas utilizando as preposições.

Quando os modelos chegavam para a avaliação da equipe mais ranzinza da empresa, as guerras começavam! Os ADs não eram ágeis! Impactavam as sprints, mudavam os nomes dos atributos e o pior… Questionavam!!! Era terrível ver a sabatina que eles faziam com os desenvolvedores!

Eles eram tão chatos, que certa vez um desenvolvedor disse “eu não devia contar a verdade para vocês, por que vocês sempre querem alterar tudo!”. Os desenvolvedores tinham uma vida difícil!

Todas as vezes que eles submetiam um modelo para a avaliação do AD o modelo voltava normalizado, com definições nos atributos e entidades, os tipos de dados alterados para ficar de acordo com o padrão corporativo que só os chatos conheciam, os nomes físicos eram gerados e o pior… eles documentavam até coisas que os desenvolvedores exigiam que ficasse errado.

O trabalho da equipe de AD era pautado na premissa de garantir a qualidade dos dados, um dos absurdos que eles diziam era que para ter qualidade era preciso saber o que o dado significava, definir corretamente seu data type, criar restrições nas colunas… Ou seja, um monte de teoria sem valor. O importante era criar aplicativos, porque era isso que trazia dinheiro para a empresa.

Dentre o conjunto de desenvolvedores uma equipe de 2 pessoas se destacava… Não pela incapacidade de criar modelos de dados pelo menos coerentes, mas por criar ótimos aplicativos! Rápidos e bonitos! Exatamente como os sócios da empresa gostavam.

Um belo dia, a “dupla dinâmica” propôs a solução para os problemas dos desenvolvedores… Criar sistemas usando um banco de dados NoSQL. A ideia era ótima! Porque se os chatos dos ADs só serviam para validar o schema dos bancos de dados, se fosse utilizado um banco de dados sem schema, todos ganhariam tempo porque não precisavam submeter para eles os modelos de dados.

E assim foi feito! E claro que a produtividade quadruplicou! Cada equipe criava seu próprio banco de dados NoSQL da maneira que era mais apropriada para as aplicações.

Nenhuma equipe de desenvolvimento precisava da equipe de AD. Todos os chatos foram demitidos. Com muito esforço ficou um! Que era responsável por manter os bancos de dados com schema “funcionando”.

O problema começou quando um dos sócios da empresa ouviu falar da nova moda… O big data! Ele queria tomar decisões utilizando seus dados.

A primeira estratégia foi criar um data lake. O sócio da empresa e líder técnico do projeto, ordenou que todos os dados da empresa fossem “despejados” no data lake. E assim foi feito.

Era complicado saber como usar os dados… Por isso uma empresa super conceituada foi contratada para ajudar o sócio a tomar decisões com seus dados.

Nesta etapa descobriu-se que a empresa super conceituada não era tão boa assim… Eles pediram para ver a definição dos dados, queriam entender a origem dos dados do data lake, questionaram fórmulas, criticaram a falta de gestão dos metadados, e o pior é que elogiaram o trabalho dos chatos dos ADs… O que causou revolta em todos da empresa!

Foi então sugerido que fosse realizado um trabalho de limpeza dos dados. Os desenvolvedores odiaram a ideia, mas como o contrato com a empresa estava longe de acabar eles toparam.

A produtividade despencou! Os projetos atrasaram… E o pior uma auditoria externa começou! Os auditores questionavam preços, formulas, informações contábeis, tudo o que era proveniente dos sistemas era questionado… Mas não era um problema porque os desenvolvedores maravilhosos conheciam muito bem as suas aplicações e se colocaram a disposição dos auditores para explicar tudo.

O data lake já era chamado de “lago de lixo” por que 90% dos dados não serviam para tomada de decisão, a auditoria estava a todo vapor até que o inesperado aconteceu… Os desenvolvedores fizeram um bolão e ganharam na mega sena!!!

Todos foram embora, ninguém mais conhecia os dados… Como os desenvolvedores eram muito bons utilizavam técnicas de programação próprias, a leitura e compreensão do código fonte era bem complicada…

O resultado da auditoria rendeu multa para a empresa… O “lago de lixo” transbordou… O último AD sobrevivente resolveu investir na carreira de decorador e os sócios decidiram fechar a empresa.

E assim termina a história de terror. Mas não se preocupem! Nada disso acontece no dia-dia das empresas… é tudo ficção!