![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiB8fDpK5JMLpNKdf4in_E07tP2njA00wjv3cOGoJ1KVjcmw7qV9SOfM3ZvHeXwKtJ2_okSmAgE3l19QhFKM1Ir2TsnLnJAnM8SzY2kkM4QwkSrgl4NdTgdbl6Ca8u4ZfjSNdu4PK5ygw/s320/Entropy.png)
Esbarrei no termo esses dias lendo sobre "What Is Time? One Physicist Hunts for the Ultimate Theory", e achei muito interessante a definição. Nunca havia parado para realmente entender o termo, mas é incrível como está conectado sobre várias áreas do cotidiano, inclusive no trabalho de Analista de Sistemas.
Por definição entropia é uma função de não conservação de estado. Ou seja, pouca entropia define que o estado da coisa está pouco alterado, muida entropia define que o estado está bem alterado em relação ao estado inicial. Existe um ponto máximo de entropia, podemos defini-la como "pior que está não fica". Ou seja as coisas tendem para o caos e a desordem automaticamente, aumentam a entropia.
Um exemplo simples é quando deixamos um maço de folhas empilhados sobre a mesa e depois saimos, depois de uma semana, quando voltarmos, muito provavelmente o maço estará desorganizado.
Relacionando com desenvolvimento de softwares, quando começamos um projeto sabemos onde está tudo, o softwaer funciona e a coisa está organizada, dai então entra outro programador, outra equipe, os prazos apertam, etc, e a coisa começa a ficar um pouco mais confusa. Nesse momento estamos aumentando a entropia, as coisas começam a ficar mais desorganizadas ou não documentadas. Com a evolução do software e manutenções corretivas se atinge um estado de entropia máxima, e o sistema não suporta mais "novas funcionalidades" e sequer correções pequenas se tornam uma tortura. Esse é o ponto de reescrever o software ou o módulo.