Parte 2 – A entropia do software

Ainda que comparado com engenharias que tratam mais do mundo físico (como a Engenharia Civil), a Engenharia de Software está imune a praticamente todas as leis físicas. Entretanto uma delas nos atinge em cheio quando se trata de “complexidade” são elas as leis da entropia. Entropia (do grego εντροπία) significa o grau de desordem de um sistema.

A entropia é uma característica inerente a sistemas complexos (assim como o software) que são caracterizados pela sua grande quantidade de componentes e relações/interações entre si.

As leis da entropia garantem que no universo a entropia tende ao máximo. E quando a entropia aumenta (a palavra complexidade é muito genérica e muito má utilizada em diversos contextos) o grau de controle do que se está observando cai.

Para ilustrar a questão de complexidade analisemos a figura abaixo:

Perceba que para N  nós de uma rede, se todos estes nós se comunicarem uns com os outros, seguimos uma quantidade de relações que seguem a fórmula onde o número de conexões total é dado por C = (N x  (N – 1)) / 2, ou seja, ao passo que introduzimos novos componentes em um sistema a quantidade de relacionamentos e dependências também tende a aumentar. 

Estendendo um pouco esta discussão (não tratada no livro), podemos imaginar nossas arquiteturas atuais, sistemas distribuídos, baseados em SOA ou até mesmo em Microsserviços (SOA feito da maneira correta), APIs e etc onde possuímos inúmeros pequenos componentes independentes e distribuídos que são organizados de modo a resolver os desafios específicos de cada sistema.

 Outra característica interessante de se comentar são as propriedades emergentes de sistemas complexos. Pense em um avião, que é um sistema complexo, a união de todas seus componentes fazer com que ele seja capaz de voar, mas se pegarmos apenas uma turbina, ou apenas as asas, ou somente um pequeno conjunto de seus componentes, essa capacidade emergente não aparece, sendo necessária a união de tudo o que há no avião para que essa capacidade se manifeste. 

O mesmo ocorre com seu sistema, apenas um de seus algoritmos, ou um de seus serviços, não resolve o problema por completo. Apenas a junção e organização de seus componentes serão capazes de resolver o desafio enfrentado por completo.

Muitos são os fatores que contribuem para a Entropia no software e os mais importantes aparentam ser os psicológicos e os culturais. Todos nós já vivenciamos projetos que mesmo muito bem planejados acabam em uma desordem total, ou então projetos que apesar de seus problemas e dificuldades, terminam com boa organização e código bem escrito.

Então, o que faz a diferença par “controlar” a Entropia no software?

Você já ouviu falar da “Teoria da Janela Quebrada”?
Pesquisadores chegaram a conclusão que edifícios limpos e bem conservados podem rapidamente se tornarem feios e destruídos e tudo começa com uma simples janela quebrada.O que isso quer dizer? Pense em um belo prédio, agora imagine que uma janela desse prédio seja quebrada. Nesse momento ele deixa de ser tão belo, certo? E se essa janela não for rapidamente consertada, o que pode acontecer? Esse é o ponto central desta teoria. A partir deste momento, quando uma janela não for rapidamente consertada as pessoas que ali convivem e interagem com aquele espaço, mudarão rapidamente sua visão sobre a conservação do prédio e até mesmo a sua utilidade e poderão passar a vandalizar o local, quebrando não somente as janelas mas com o passar do tempo levando o prédio a uma completa destruição.

No software é exatamente o mesmo que acontece, tudo começa com um bom plano e a melhor das intenções quanto ao que será desenvolvido, mas com o passar do tempo e conforme as dificuldades vão surgindo, acabamos assumindo débitos técnicos e tomamos decisões que nem sempre são as melhores, com a ideia de que no futuro (doces mentiras) conseguiremos tempo para corrigir e colocar as coisas em ordem como deveria.

É aí onde mora o perigo. A partir desta decisão postergada, próximas pessoas que terão contato com aquele software já declaradamente com problemas não dará importância ao que está fazendo, afinal, o que é uma gambiarra a mais ou a menos? 

Resumindo, desordem só gera mais desordem.

E se o software estiver “impecável”, com boas decisões de arquitetura, boa orientação a objetos, tecnologias bem aplicadas e etc? Neste caso, todos que entrarem em contato se sentirão no dever de manter aquela bela forma, de cultivar as boas práticas e organização que ali foi plantada.

Desta forma, anotemos mais uma das dicas dos autores:
#4 – não conviva com janelas quebradas

Contribuindo um pouco mais com esta ideia, no Livro “Código Limpo” do Uncle Bob (recomendo a leitura) ele cita a regra dos escoteiros:
“Deixe o lugar mais limpo do que estava quando você chegou”

Esta regra nos serve também como mais um mantra para o dia a dia, tenhamos em mente sempre manter a organização daquilo que estamos fazendo e deixá-la melhor do que a encontramos.

Seja um código, arquitetura, documentação ou processo.
Não convivamos com janelas quebradas! 🙂

O programador pragmático – O início

O que faz um programador pragmático?

  • Pragmático (adj):  – Que é prático; que realiza algo objetivamente. – Que se preocupa com uma ação concreta e eficaz; prático. – Que considera o aspecto objetivo das coisas, por oposição ao abstrato; objetivo.

Partindo do princípio de que cada programador possui características únicas (assim como todo os seres humanos, sim também somos humanos) os autores elencaram algumas características as quais acreditam que todos programadores pragmáticos compartilham, tais como:

  • Adotar tecnologias antes de se tornarem populares (early adopters), mas também se adaptar rapidamente ao lidar com algo novo (fast adapters).
  • Curiosidade, tendem a se perguntar como as coisas funcionam, pois assim podem tomar decisões melhores baseados em novas informações.
  • Pensamento crítico, não assumem nada como cem por cento verdadeiro ou porque as coisas são “simplesmente assim”.
  • Realistas, tentam sempre entender a natureza de cada problema que enfrentam. Isso faz com que possam avaliar o grau de dificuldade de cada desafio. E isso os motiva.
  • São bons generalistas, se esforçam para se manterem atualizados sobre novas tecnologias ainda que continuem especialistas nas tecnologias do seu dia a dia. 

Sendo estas as características consideradas básicas a todos os programadores pragmáticos elas são inseridas como dicas pontuais ao longo dos demais capítulos, sendo as duas primeiras: 

#1- Importe-se com seu ofício

  • Não há nada mais importante em fazer software do que você se importar em fazer isso bem feito.

#2- Pense! Sobre o seu trabalho

  • Como um mantra para programadores pragmáticos, não como um pensamento pontual, pense sobre tudo o que você faz, sobre suas decisões, ou a forma como age com relação aos desafios que enfrenta em sua carreira. Ainda que pareça custoso, questionar-se terá um retorno muito importante sobre o tempo investido conforme você e seu time se tornam mais eficientes.

Um pragmatista, de acordo com os autores, é alguém que preza pela individualidade do trabalho, sem deixar de lado a importância do trabalho em grupo, mas que cuida e preza pela qualidade do que faz e de cada decisão individual que toma sobre a execução do seu ofício.

Como metáfora, pense nos construtores das catedrais da idade média. Elas levavam anos/homens para serem construídas e cada cortador de pedra, pedreiro, carpinteiro e vidraceiro acreditavam em sua contribuição individual para a completude e sustentação do todo ao longo do tempo. Assim como a passagem do conhecimento para cada nova geração de trabalhadores que se juntavam a grande empreitada eram ensinados da importância de cada detalhe que passavam a assumir dali em diante.

Esse pragmatismo, deve ser visto como uma execução contínua e responsável do trabalho diário com foco em seu impacto com a visão do todo a longo prazo.

“Um turista visitando o Eton College, no Reino Unido, perguntou ao jardineiro como ele conseguiu aquele gramado tão perfeito. 
– Isso é fácil. Respondeu. – Regue toda manhã, apare todos os dias e enrole a grama uma vez por semana. 
– Mas é só isso? Impressionado disse o turista.
– Sim! Respondeu. Faça isso por 500 anos e você também terá uma grama perfeita.”

Um programa é como um gramado, diariamente precisa de uma grande quantidade de pequenos cuidados. Inclusive onde ninguém vê, com relação ao cuidado com a terra, fazendo diariamente sua irrigação e adubamento quando necessário. 

Essa melhoria contínua é o que conhecemos através da cultura japonesa como Kaizen, que refere-se a filosofia ou práticas que incidem sobre a melhoria contínua de processo. Filosofia responsável pelo grande aumento da produtividade da manufatura japonesa no pós segunda guerra. Tendo um de seus princípios centrais o “mantra”:

“Hoje melhor do que ontem, amanhã melhor do que hoje!”

E sob este mote, seguiremos com as reflexões e aprendizados passados ao longo de todos os capítulos do livro, sempre com comentários e reflexões baseadas em experiências reais pelas quais já passei.

Fique a vontade para comentar!

Capítulo 1 – Uma filosofia pragmática

Em termos de abordagem pragmática, uma das coisas mais importantes é tomarmos para nós a responsabilidade total daquilo que executamos.

Seja em planejar uma nova iteração, seja ao desenhar uma nova arquitetura ou seja fazendo um simples código CRUD. Uma das coisas mais difíceis (sim é sempre difícil e aprendemos isso com o tempo e humildade) é admitirmos nossos erros (segundo os autores) e adiciono aqui algo não mencionado pelos autores, aceitar críticas e melhorar continuamente. Se lembram do “Hoje melhor que ontem e amanhã melhor que hoje”?

Devemos ter atenção as situações em que riscos devem ser ponderados com responsabilidade, por exemplo, quando a execução de algo não depende apenas de nós, como entregas de outras equipes, contato com clientes ou prestadores de serviços externos. Estas situações, devem ser tratadas com cuidado, pois não devem servir como desculpas, ou as famosas “muletas”, para possíveis problemas do dia a dia. Uma boa abordagem a ser praticada é antes que esse tipo de problema ocorra já estejam mapeados os casos de contorno para cada um deles, ou ao menos que esteja clara a situação que futuramente pode vir a impactar de alguma forma as atividades que desempenhamos.


Além de estarmos atentos aos problemas que possam ocorrer, caso algo saia fora do planejado e sairá com toda certeza, pensemos em opções para contornar o problema, seguindo a dica #3:“Apresente opções, não desculpas”, dos autores.

As vezes essas opções serão coisas como propor a escrita de testes (unidade/integração), propor fluxos de trabalho (as vezes engessados e dolorosos), refatorar um legado problemático (ainda que nem sempre as pessoas entendam o valor de um código manutenível e escalável), dentre outras. De toda forma, tenha sempre opções, é como dizia Henry Ford “Não encontre defeitos, encontre soluções. Qualquer um sabe queixar-se”.

Um ponto sobre responsabilidade e transparência não abordado, é a questão psicológica de Ancoragem(discutida no livro Digital Work in Analog World, irei escrever sobre ele no futuro),quando somos ancorados por vieses implantados por outras pessoas, imagine a seguinte situação:

Você é um desenvolvedor experiente, conhece bem o sistema em que trabalha e seu “chefe” chega e diz: – Essa funcionalidade sai hoje né? Certeza que você mata isso ainda hoje.Nesse momento seu psicológico é posto a prova, como uma necessidade de auto afirmação, ou de confirmação do que se é, e faz com que você seja ancorado a esta afirmação, fazendo com que você (nós) caia nela, mesmo sabendo que provavelmente terminar a tarefa naquele dia é completamente infactível, ou no mínimo implicará em horas extras, ou algum contorno não desejado para finalizá-la. 

O tipo de situação acima citado pode e deve ser enfrentado sempre, com base na transparência e sinceridade sobre a situação real daquilo em que estamos envolvidos. Quando alguém fizer este tipo de abordagem, seja honesto consigo mesmo. Justifique os motivos pelo qual as coisas não são tão “simples” como aparentam, ou proponha uma solução de escopo reduzido para o que é esperado como entrega de valor (uma hora falarei sobre MVPs). 

Antes de dar qualquer resposta sobre um problema, pare e pense se a resposta parece razoável ou se ela soa completamente estúpida, seja transparente, não pense apenas no problema, pense em soluções (inclusive as de contorno, elas podem salvar o seu dia) e não se deixe ancorar, isso não faz mal apenas a você. 

Resumindo, dizer que o gato (ou cachorro) comeu seu código não é uma desculpa honesta, pense sempre em formas de superar as barreiras que venha a enfrentar e não apenas nas barreiras.

Se você gostou desde texto compartilhe e comente! =)