Condenado ao Padrão

O desenvolvimento de qualquer sistema enfrenta, ao longo do tempo, vários problemas pelo aumento da entropia do código fonte. Porém, esse problema se amplifica muito quando o sistema já nasce com problemas conceituais.

Uma Iniciativa Errada…

Por incrível que pareça, o Paulo Maluf (esse mesmo) cunhou uma das frases mais importantes para quem projeta sistemas embarcados. Eu penso nela sempre que algum gênio resolve que o que está funcionando bem e já está bem feito deve ser refeito porque ele simplesmente acha:

A coisa mais perigosa que existe é um burro com iniciativa.

~Paulo Maluf

Quando este burro resolve meter a mão na massa ou por péssima alocação de recursos temos ele trabalhando na definição de algum projeto, certamente teremos em um futuro próximo o velho problema de manter um legado que não pode ser consertado.

Quando a Coisa “Pega”

Algumas coisas nascem com esse defeito fundamental e acabam muito difundidas. Então, por “ditadura de maioria” se tornam padrão. Aí já era.

Na concepção de sistemas em geral, ao longo da vida do projeto, ciclos de implementação e testes se alternam para eliminar equívocos dos desenvolvedores ou falhas na hora de fazer alguma tarefa. Queria fazer A e fez-se B. Ou era para ter feito A, mas o entendimento foi outro e acabou-se fazendo B. A isso eu chamo de bugs. Normal, a boa dupla de verificação e validação.

Vou usar o exemplo do calendário. Para mim, o calendário foi algo que partiu de uma definição ruim, pois quando começaram a organizar os dias em ciclos, não se tinha total conhecimento do problema. Devido a este fraco conhecimento dos detalhes do problema, em algum momento alguém percebeu que havia um escorregamento nas datas. Então, alguém finalmente mediu o ano direito e concluiu: precisamos de um dia extra, de vez em quando. Desde então, viemos fazendo gambiarras.

  • Temos 365 dias no ano.
  • 6 meses com 31 dias.
  • 5 meses com 30 dias.
  • 1 mês com 28/29 dias.
    • E este é o segundo mês do ano.

Tudo porque alguém encasquetou que o ano tem que ter 6 meses com 31 dias. O exemplo do calendário é, para mim, o melhor exemplo da manutenção de uma especificação mal feita. Vejamos uma alternativa:

  • temos 365/366 dias.
    • Um bom número para dividir isso, é, de fato, 12.
    • Vamos reaproveitar o que está bom.
    • 365÷12 = 30 e resto 5.
  • 7 meses de 30 dias
  • 5 meses de 31 dias.
  • Um mês (dos 7 meses de 30 dias) vai, a cada 4 anos, ter 31 dias.
    • Este mês especial não será o segundo, mas sim o último
    • o dia extra em estilo de LIFO, acontece em Dezembro.

Fechou, mais elegante e melhor, mais simétrico. Mas… nunca vai funcionar ou virar realidade. É impossível  mudar a estrutura atual sem muita dor de cabeça: e quanto mais se demora a abandonar um padrão ruim, pior para mudar ele. O calendário atual virou padrão; e um padrão bem ruinzinho.

O caso do calendário é um ótimo exemplo. Ele me remete a quantas vezes os desenvolvedores são agraciados em herdar um trabalho ruim e mal feito, mas não por haver péssima qualidade de implementação,  mas sim, uma definição ridiculamente mal feita e o inevitável resultado de um produto porcaria.

Defective by Definition

Eu chamo um produto todo tapado de defeitos e “defeituoso por projeto” (deffective by design). Mas não é esse o caso. Quando um produto é  imaginado de maneira que, não interessa o quão boa seja sua implementação, o resultado final sera algo difícil de usar, funcionalmente debilitado ou com durabilidade ridícula, costumo chamar isso de “defective by definition”.

Produtos nessa categoria tendem a gerar uma carga absurda de trabalho e um esforço de manutenção absurdo para tentar, inutilmente, contornar defeitos inerentes ao sistema. Tudo piora quando, para completar, começam os add-ons.

“Vamos por uma placa filha” ou “faz um sistema independente”. Começam a enfiar coisas no sistema para remendar os problemas e o resultado final é um Frankenstein que ninguém mais entende, que padronizou um monte de bobagem e que ninguém pode mais mexer.

E aí temos o paradoxo da “solução não-causal”.

A Solução Não-Causal

O problema dos “padrões ruins” é um assunto divertido para quem vê de fora. Muito triste para quem vê de dentro. Já presenciei diálogos assim:

-Dev1: quem fez este software não está  mais aqui e foi muito mal documentado. Melhor não mexer nele.

-Dev2: ok, então encontramos hardware compatível. Vamos ter que mexer no hardware.

-Dev1: não podemos mexer no hardware, pois temos muitos em estoque.

-Dev2: e onde vamos mexer em para resolver o problema?

-Dev1: ai é que é  o problema mesmo. Não podemos mexer em nada para resolver o problema.

-Dev2: e como vamos resolver?

-Dev1: e isso que estamos tentando decidir.

Por sorte, eu não estava a frente para resolver esta bucha. Apenas fiquei de lado e, internamente, ri muito. Obvio que meu comentário foi que  decisão deveria ser apresentada aos gerentes do time de hardware, gerente de software e de produção, pois alguém teria que arcar com os custos da mudança.

Um projeto que nasce errado não tem conserto. E avacalha ótimas técnicas de desenvolvimento, como escalabilidade e modularidade. Elas viram meros instrumentos de se fazer gambiarra.

Gambiarras normalmente demandam caras bons. Os bruxos da empresa, no lugar de fazer coisas novas, ficam consertando e remendando projetos…

A Pressão dos Negócios

Os melhores desenvolvedores devem iniciar os projetos. E os piores devem corrigir erros, pois isso é uma ótima maneira de lhes ensinar a não cometê-los. Parece simples? Não  é.

Uma triste realidade das empresas é  que os melhores desenvolvedores estão alocados para resolver os problemas dos produtos em linha. Resta aos piores desenvolvedores a dificílima tarefa de começar os projetos. Parece ridículo? Não é. Faz muito sentido.

Uma empresa visa lucrar. Então imagine-se como o Gerente de Desenvolvimento e o principal produto da empresa pede uma nova funcionalidade. Isso vai trazer novos negócios. Vão pressionar até que essa funcionalidade fique pronta. Com ou sem preparo como gerente, não parece óbvio que deveria -se alocar os melhores recursos? Se sim, quem vai fazer os novos projetos?

Pois é. É  fácil entender o problema. As vezes dá para resolver. E quando não dá?

Mitigando o Problema

Eu percebi ao longo da minha carreira, que deixados soltos os desenvolvedores vão trabalhar conforme seus próprios padrões. E se tivermos 10 deles, teremos 10 padrões e 10 formas de trabalhar. Exceto por uma raridade de desenvolvedores, a maioria não vai se preocupar em alinhar uma forma comum de trabalhar com os colegas.

Como gerente  de  desenvolvimento,  busquei eu sempre estimular essa interação e os resultados sempre foram muito satisfatórios. No começo, todos desenvolvedores torciam o nariz por ter que ceder ao padrão de trabalho do grupo, porém, quando alguém herdava uma tarefa de algum colega, reconhecia ali um trabalho parecido com o seu. O mal estar dissipava-se na hora.

Mas no que isso ajuda? Aumenta muito o volume de interação do time. Assim, os desenvolvedores mais fracos podiam obter ajuda instantânea dos melhores; e aprendiam com eles. Os melhores passavam a influenciar, naturalmente, os sistemas novos desde o começo, enquanto focavam nas tarefas urgentes. E as tarefas urgentes continuavam sendo executadas com maestria em prol de novos negócios para a companhia.

Pessoas

Em resumo, nenhuma implementação, ao longo dos anos de vida de um produto escalável ficará livre de soluções tecnicamente, digamos, questionáveis. Desenvolvedores não podem se dar ao luxo de serem puristas e acreditar em utopias. A entropia aumenta conforme mais coisas se adiciona a um produto.

Contudo, um produto que nasce direito tende a sofrer menos com entropia de conteúdo. Ele permanece gerenciável por muito mais tempo,talvez até quando já não interessa adicionar mais funcionalidades ou corrigir bugs do produto. Um sistema deve sobreviver até seu suporte ser encerrado.

Regra: mais importante que as coisas que um desenvolvedor faz são as as coisas que ele define.

Por fim, tudo sempre volta ao desenvolvedor: se ele interagir com seus colegas, melhor a qualidade das coisas que ele faz. Regra: mais importante que as coisas que um desenvolvedor faz são as as coisas que ele define.

Eu sempre digo (e não canso de dizer) que o desenvolvimento é uma atividade social. Quando eu abri este artigo falando de burro, falo que burro é  quem se nega a reconhecer isso e acha que pode dar conta de sistemas enormes. E resolve fazer as coisas sozinho. Isso sim é um problema por definição. O resto é mero erro de implementação, portanto, tratável.

Creative Commons License

Esta obra está licenciado com uma Licença Creative Commons Atribuição 4.0 Internacional.

Sobre rftafas 183 Artigos
Ricardo F. Tafas Jr é Engenheiro Eletricista pela UFRGS com ênfase em Sistemas Digitais e mestre em Engenharia Elétrica pela PUC com ênfase em Gestão de Sistemas de Telecomunicações. É também escritor e autor do livro Autodesenvolvimento para Desenvolvedores. Possui +10 anos de experiência na gestão de P&D e de times de engenharia e +13 anos no desenvolvimento de sistemas embarcados. Seus maiores interesses são aplicação de RH Estratégico, Gestão de Inovação e Tecnologia Embarcada como diferenciais competitivos e também em Sistemas Digitais de alto desempenho em FPGA. Atualmente, é editor e escreve para o "Repositório” (http://161.35.234.217), é membro do editorial do Embarcados (https://embarcados.com.br) e é Especialista em Gestão de P&D e Inovação pela Repo Dinâmica - Aceleradora de Produtos.
0 Comentários
Inline Feedbacks
View all comments