Explicação da entropia do software: causas, efeitos e soluções

Este artigo é destinado ao desenvolvedor de software ou gerente de projeto que está curioso sobre o que é entropia de software, os efeitos práticos em seu trabalho e os fatores subjacentes que contribuem para seu crescimento.

O objetivo principal é criar uma consciência da entropia de software porque é um fator em todas as formas de desenvolvimento de software. Além disso, exploramos um meio pelo qual a entropia de software pode ser atribuída a um valor concreto. Somente quantificando a entropia de software e observando seu crescimento em lançamentos sucessivos podemos realmente entender o risco que ela representa para nossos objetivos atuais e planos futuros.

O que é entropia de software?

A entropia de software ganha o nome da principal característica da entropia no mundo real: é uma medida de caos que permanece a mesma ou aumenta ao longo do tempo . Dito de outra forma, é uma medida da instabilidade inerente construída em um sistema de software com relação a alterá-lo.

Infelizmente, a entropia de software raramente recebe a importância que merece.

Não é levado em consideração ao retirar alguém de uma equipe de desenvolvimento, iniciar prematuramente um ciclo de desenvolvimento ou implementar “soluções rápidas” – momentos em que, na verdade, é mais provável que cresça.

O desenvolvimento de software é uma arte e um ofício cujos principais blocos de construção são mal definidos. Enquanto os construtores trabalham com cimento e pregos, o desenvolvedor de software trabalha com afirmações lógicas e um conjunto de suposições. Estes não podem ser segurados na mão e examinados, nem podem ser ordenados por um oitavo de polegada. Embora o observador casual possa ser tentado a comparar o desenvolvimento de software com a construção, além de algumas semelhanças superficiais, é contraproducente fazê-lo.

Apesar dessas dificuldades, podemos, no entanto, traçar as diretrizes que nos permitirão entender as fontes de entropia de software, medir a extensão do risco que ela representa para nossos objetivos e (se necessário) quais medidas podem ser tomadas para limitar seu crescimento.

A definição proposta de entropia de software é a seguinte:

onde I é derivado do número de problemas inesperados introduzidos durante a última iteração de desenvolvimento, C é a probabilidade percebida de que a implementação de mudanças no sistema agora resulte em um novo I > 0 e S é o escopo da próxima iteração de desenvolvimento. Em geral, valores de E abaixo de 0,1 são considerados bons. Um E de 0,5 é considerado alto e valores acima de 1,0 são esmagadores.

O conceito de uma iteração de desenvolvimento é essencial para nossa compreensão da entropia de software. Estes são ciclos de atividade que levam de um comportamento do sistema para outro. As metas que estabelecemos para nós mesmos durante a iteração do software são chamadas de escopo . No desenvolvimento de software, esses ciclos envolvem a modificação ou expansão do código subjacente do software.

Todas as modificações no código ocorrem em uma iteração de desenvolvimento, mesmo que aqueles que as executam não as considerem dessa maneira. Ou seja, organizações menores que se orgulham de construir seus sistemas usando uma metodologia “rápida e suja” – com pouca ou nenhuma coleta de requisitos ou análise – ainda usam iterações de desenvolvimento para atingir seus objetivos. Eles simplesmente não os planejam. Da mesma forma, mesmo se o comportamento de um sistema modificado divergir de alguma forma de nossas intenções, ele ainda foi alcançado por meio de uma iteração de desenvolvimento.

Na verdade, o risco de que isso aconteça é exatamente o que nossa consciência da entropia de software pretende explicar e nosso desejo de medi-la pretende limitar. Em termos práticos, então, podemos definir a entropia de software da seguinte forma.

Qualquer dado sistema tem um conjunto finito de questões abertas conhecidas I ₀ . No final da próxima iteração de desenvolvimento, haverá um conjunto finito de problemas conhecidos e em aberto I ₁ . A entropia inerente do sistema especifica o quanto nossa expectativa de I ₁ provavelmente diferirá de seu valor real e quanto a diferença provavelmente aumentará nas iterações subsequentes.

Efeitos da entropia de software

Nossa experiência prática dos efeitos da entropia do software depende de como interagimos com o sistema em questão.

Os usuários têm uma visão estática do software; eles estão preocupados com como ele se comporta agora e não se importam com as partes internas de um sistema. Ao realizar uma ação predefinida, os usuários assumem que o software responderá com um comportamento predefinido correspondente. No entanto, os usuários são os menos preparados para deduzir o nível de entropia no software que estão usando.

A entropia do software está ligada à noção de mudança e não tem significado em um sistema estático. Se não houver intenção de alterar o sistema, não podemos falar de sua entropia. Da mesma forma, um sistema que ainda não existe (ou seja, a próxima iteração é realmente a primeira de sua existência) não tem entropia.

O software pode ser percebido como “com erros” do ponto de vista de um usuário, mas se durante as iterações subsequentes os desenvolvedores e gerentes de software estiverem atingindo seus objetivos conforme planejado, devemos concluir que a entropia no sistema é realmente muito baixa! A experiência dos usuários, portanto, nos diz muito pouco, ou nada, sobre entropia de software:

• Os desenvolvedores de software têm uma visão fluida do software. Eles estão preocupados com o modo como um sistema funciona atualmente apenas na medida em que deve ser mudado, e estão preocupados com os detalhes de como ele funciona para elaborar uma estratégia apropriada.

• Os gerentes talvez tenham a visão mais complicada do software, tanto estática quanto fluida. Eles devem equilibrar as exigências do curto prazo com as demandas de um plano de negócios que se estende ainda mais no futuro.

As pessoas em ambos os papéis têm expectativas. A entropia do software se manifesta sempre que essas expectativas são prejudicadas. Ou seja, desenvolvedores e gerentes de software fazem o possível para avaliar os riscos e planejar para eles, mas – excluindo interrupções externas – se suas expectativas forem frustradas, só então podemos falar de entropia de software. É a mão invisível que interrompe as interações de componentes que não estavam no escopo, faz com que os servidores de produção falhem inexplicavelmente e retém um hotfix oportuno e econômico.

Muitos sistemas com altos níveis de entropia dependem de indivíduos específicos, principalmente se houver membros juniores da equipe de desenvolvimento. Essa pessoa possui conhecimento tal que os outros não podem realizar suas tarefas sem sua “valiosa” contribuição. Ele não pode ser capturado em diagramas UML padrão ou especificações técnicas porque consiste em um amálgama de exceções, palpites e dicas. Esse conhecimento não depende de uma estrutura logicamente consistente e, portanto, é difícil — se não impossível — transferi-lo para qualquer outra pessoa.

Suponhamos que, com grande determinação e esforço, tal organização seja capaz de dar a volta por cima e estabilizar seu departamento de TI. A situação parece ter melhorado porque, quando o desenvolvimento de software está parado, qualquer progresso é encorajador. No entanto, na realidade, as expectativas atendidas são baixas e as realizações desinteressantes em comparação com os objetivos elevados que estavam ao alcance enquanto a entropia ainda era baixa.

Quando a entropia de software sobrecarrega um projeto, o projeto congela.

Não pode haver mais iterações de desenvolvimento. Felizmente, esta situação não surge instantaneamente. A marcha lenta mas precipitada em direção à beira de um penhasco é algo que todo sistema sofre. Não importa quão bem organizada e eficiente seja a primeira versão, ao longo de sucessivas iterações de desenvolvimento, sua entropia - e, portanto, o risco de que as coisas aconteçam inesperadamente - crescerá a menos que medidas específicas sejam tomadas para evitá-la.

A entropia do software não pode ser reduzida. Assim como a entropia no mundo real, ela só cresce ou permanece a mesma. A princípio, seus efeitos são desprezíveis. Quando começam a se manifestar, os sintomas são leves e podem ser mascarados ou ignorados. Mas se uma organização só tenta combater a entropia de software depois de se tornar o risco dominante em um projeto, infelizmente descobrirá que seus esforços são em vão. O conhecimento da entropia de software é, portanto, mais útil quando sua extensão é baixa e os efeitos adversos são mínimos.

Isso não significa que toda organização deva dedicar recursos para limitar o crescimento da entropia em seus produtos. Grande parte do software que está sendo desenvolvido hoje – software orientado ao consumidor em particular – tem uma expectativa de vida relativamente curta, talvez alguns anos. Nesse caso, seus stakeholders não precisam considerar os efeitos da entropia do software, pois raramente se tornará um obstáculo sério antes que todo o sistema seja descartado. Existem, no entanto, razões menos óbvias para considerar os efeitos da entropia de software.

Considere o software que executa a infraestrutura de roteamento da Internet ou transfere dinheiro de uma conta bancária para outra. A qualquer momento, há uma ou mais versões deste software em produção e seus comportamentos coletivos podem ser documentados com precisão razoavelmente alta.

A tolerância ao risco de um sistema é uma medida de quanto e que tipo de comportamento inesperado podemos permitir confortavelmente de uma iteração de desenvolvimento para a próxima. Para os tipos de sistemas mencionados, a tolerância ao risco é muito menor do que, digamos, o software que roteia chamadas telefônicas. Este software, por sua vez, tem uma tolerância ao risco menor do que o software que aciona o carrinho de compras de muitos sites comerciais.

A tolerância ao risco e a entropia de software estão relacionadas, pois a entropia de software deve ser mínima para ter certeza de que permaneceremos dentro da tolerância de risco de um sistema durante a próxima iteração de desenvolvimento.

Fontes de entropia de software

A entropia do software surge da falta de conhecimento . Ela resulta da divergência entre nossas suposições comuns e o comportamento real de um sistema existente. Este fato explica por que a entropia de software só tem significado no contexto de modificação de um sistema existente; é a única vez que nossa falta de compreensão terá algum efeito prático. A entropia de software encontra terreno mais fértil em um sistema cujos detalhes não podem ser entendidos por uma única pessoa, mas sim espalhados por uma equipe de desenvolvimento. O tempo também é um poderoso apagador de conhecimento.

Código é a expressão de uma série de asserções lógicas. Quando o comportamento do software (e, portanto, seu código) não corresponde à lógica que ele pretende expressar, podemos falar de sua entropia inerente. Essa situação pode surgir de três maneiras: A lógica é bem conhecida e diverge de sua expressão, existem vários entendimentos da lógica que o código pretende expressar ou a lógica não é bem conhecida.

• A primeira situação - a lógica é bem conhecida e diverge de sua expressão atual - é a mais fácil de abordar, mas também a menos comum. Apenas sistemas muito pequenos mantidos por talvez dois participantes, um desenvolvedor e alguém responsável pelo plano de negócios, se enquadram nessa categoria.

• A segunda situação — a lógica não é bem conhecida — é rara. Para todos os efeitos, a iteração de desenvolvimento não pode nem começar. Se em algum momento todas as partes interessadas concordarem, é provável que enfrentem a primeira situação.

A mente humana interpreta suas experiências, filtrando-as e modificando-as efetivamente na tentativa de encaixá-las em um quadro pessoal. Na ausência de hábitos de desenvolvimento eficazes – baseados na livre troca de ideias, respeito mútuo e expectativas claras – pode haver tantas interpretações de como um sistema funciona atualmente quanto há membros da equipe. Os objetivos da equipe para a iteração de desenvolvimento atual podem estar em disputa.

Muitos desenvolvedores se protegem dessa situação reforçando seus próprios entendimentos sobre o que é exigido deles e como o sistema “deveria” ser organizado. Os gerentes e outras partes interessadas, por outro lado, podem involuntariamente procurar mudar as suposições de outros membros da equipe em uma tentativa equivocada de facilitar suas próprias vidas.

Chegamos agora à fonte mais comum de entropia de software: há interpretações múltiplas e incompletas da lógica que o sistema pretende expressar. Como há apenas uma única manifestação dessa lógica, a situação é, por definição, problemática.

Como surge essa falta de conhecimento? A incompetência é um caminho. E como já vimos, a falta de acordo sobre os objetivos da próxima iteração de desenvolvimento é outra. Mas há outros fatores a serem considerados. Uma organização pode pretender empregar uma metodologia de desenvolvimento, mas depois abandona ao acaso alguns ou todos os seus aspectos no chão. Os desenvolvedores de software são então encarregados de completar tarefas vagas, muitas vezes abertas à interpretação. As organizações que implementam mudanças em sua metodologia de desenvolvimento são particularmente vulneráveis ​​a esse fenômeno, embora não sejam as únicas. Conflitos pessoais que a administração desconhece ou não consegue resolver também podem levar a uma divergência perigosa entre expectativas e resultados.

Há uma segunda maneira, mais importante, de perdermos conhecimento técnico sobre um produto: na transferência. Capturar o conhecimento técnico no papel é um desafio até mesmo para os escritores mais proficientes. A razão é que o que transcrever é tão importante quanto como . Sem a disciplina adequada, um redator técnico pode registrar informações demais. Alternativamente, eles podem fazer suposições que os levam a omitir pontos essenciais. Depois de produzida, a documentação técnica deve ser mantida meticulosamente atualizada, uma proposta difícil para muitas organizações que perdem o controle dos documentos quase tão logo são escritos. Devido a essas dificuldades, o conhecimento técnico raramente é transferido apenas em documentos, mas também em pares ou outras formas de interação próxima entre humanos.

A entropia de software dá trancos e barrancos sempre que um participante ativo deixa uma equipe de desenvolvimento. Eles estão levando um pedaço valioso de know-how com eles. Replicar esse know-how é impossível e aproximá-lo requer um esforço considerável. Com atenção e recursos suficientes, entretanto, conhecimento suficiente pode ser preservado para que o crescimento da entropia do sistema possa ser minimizado.

Existem outras fontes de entropia, mas estas são relativamente menores. Por exemplo, a podridão de software é o processo pelo qual um sistema é inesperadamente afetado por mudanças em seu ambiente. Podemos pensar em software de terceiros nos quais ele depende (como bibliotecas), mas existem outras causas mais insidiosas de apodrecimento do software, geralmente resultantes de mudanças nas suposições nas quais o sistema foi baseado. Por exemplo, se um sistema foi projetado com certas suposições sobre a disponibilidade de memória, ele pode começar a funcionar mal em momentos inesperados se a memória disponível for reduzida.

Como calcular a entropia: atribuindo valores a C, S e I

I é o número de problemas comportamentais não resolvidos em um sistema de software, incluindo a ausência de recursos prometidos. Essa é uma quantidade conhecida que geralmente é rastreada em um sistema como o JIRA. O valor de I é derivado diretamente dele. I é o número de “unidades de trabalho” que foram abandonadas ou deixadas incompletas durante a última iteração de desenvolvimento, além do número de unidades de trabalho resultantes de problemas comportamentais recém-introduzidos e inesperados. Como I é contado como um número de unidades de trabalho, podemos relacioná-lo com o valor de S, que é o escopo da próxima iteração de desenvolvimento nas mesmas unidades de trabalho. O que exatamente compõe uma “unidade de trabalho” depende da metodologia de desenvolvimento.

C é a probabilidade percebida de que, quando as unidades de trabalho no escopo forem implementadas, o número de questões em aberto I1 reais na próxima iteração será maior do que sua estimativa agora. Este valor reside no domínio 0 <= C <= 1.

Pode-se argumentar que a probabilidade C é precisamente o que a entropia de software pretende medir. No entanto, existem diferenças fundamentais entre esse valor e nossa medida de entropia de software. A probabilidade percebida de que algo vai dar errado é exatamente isso: não é um valor real. No entanto, é útil porque os sentimentos das pessoas que estão participando de um projeto são uma fonte valiosa de informações sobre o quão estável ele é.

O escopo S leva em consideração a magnitude das mudanças propostas e deve ser expresso nas mesmas unidades que I. Um valor maior de S diminui a entropia porque estamos aumentando o escopo das mudanças propostas. Embora isso possa parecer contra-intuitivo, devemos ter em mente que a entropia é uma medida de como o desenvolvimento do sistema pode não atender às nossas expectativas. Não basta dizer que a entropia é uma medida da chance de introduzir problemas. Naturalmente, tentamos antecipar os riscos e levá-los em consideração em nosso planejamento (e, portanto, em nossa estimativa de I1, que pode muito bem aumentar acima de ₀ ). Claramente, quanto mais confiantes estivermos em assumir um grande escopo de mudança, menos entropia pode ser considerada no sistema - a menos que aqueles que planejam as mudanças e/ou as executam sejam incompetentes. Essa possibilidade, no entanto, provavelmente se reflete no valor atual de I .

Observe que não precisamos tentar especificar a magnitude da diferença entre o valor real de I ₁ e seu valor esperado. Se presumirmos que nossos planos estão corretos quando os fazemos, também não é razoável supor que podemos prever o grau em que o resultado não atenderá às nossas expectativas; só podemos especificar uma chance percebida C de que não. No entanto, o grau em que o valor real I ₁ difere de seu valor esperado é uma entrada importante para o cálculo da entropia na próxima iteração na forma do valor derivado I .

Teoricamente, é possível que I tenha um valor negativo. Na prática, porém, essa situação nunca ocorrerá; geralmente não resolvemos problemas acidentalmente. Valores negativos para I não são um sinal reconfortante. Eles implicam que o meio pelo qual a entropia está sendo calculada é falho. O crescimento da entropia de software pode, é claro, ser reduzido tomando medidas específicas, conforme descrito abaixo. No entanto, nesses casos, não devo assumir valores negativos, pois sempre incorporamos nossas expectativas em nossos projetos.

C é um valor subjetivo. Ela existe nas mentes dos participantes de uma iteração de desenvolvimento e pode ser deduzida por meio de pesquisas e da média dos resultados. A pergunta deve ser feita de forma positiva. Por exemplo: "Em uma escala de 0 a 10 com 10 mais provável, como você estimaria as chances da equipe de atingir todas as suas metas nesta iteração de desenvolvimento?"

Observe que a pergunta está sendo feita sobre os objetivos da equipe como um todo, não um subconjunto. Uma resposta de 10 indicaria um valor de 0 para C, enquanto uma resposta de 7 indicaria um valor de 0,3. Em equipes maiores, cada resposta pode ser ponderada dependendo de fatores relevantes, como há quanto tempo um indivíduo está envolvido no projeto e quanto de seu tempo é realmente gasto nele. A competência, no entanto, não deve ser um fator de ponderação das respostas. Em pouco tempo, mesmo um membro júnior da equipe terá uma noção de quão eficaz é para alcançar seus objetivos. Equipes suficientemente grandes podem desejar descartar os valores mais altos e mais baixos relatados antes de calcular a média do restante.

Perguntar aos profissionais qual a probabilidade de sua equipe falhar é uma proposta sensível e provocativa. No entanto, esta é exatamente a pergunta que qualquer organização que deseje quantificar a entropia precisa fazer. Para garantir respostas honestas, os participantes devem dar sua estimativa de C anonimamente e sem medo de repercussão, mesmo que relatem um valor extremamente alto.

S deve receber um valor nas mesmas “unidades de trabalho” que I e, portanto, é altamente dependente da metodologia de desenvolvimento. Para equipes que empregam aspectos de uma metodologia ágil, as histórias parecem a “unidade de trabalho” mais óbvia para S e I . Nesse caso, a extensão de uma iteração de desenvolvimento abrange cada lançamento programado regularmente para produção, seja menor ou maior. Eu deveria ser quantificado como a soma do número de histórias que não foram concluídas com sucesso durante cada sprint que antecedeu o lançamento e o número de histórias geradas para inclusão em sprints futuros como resultado de problemas inesperados manifestados após o lançamento.

Observe que não consideramos hotfixes ou outros lançamentos não programados para produção como definindo a extensão de uma iteração de desenvolvimento, nem devemos subtrair quaisquer histórias associadas de I .

A dificuldade com essa abordagem é que um período de descoberta e análise deve ocorrer antes que os bugs possam ser posteriormente divididos em histórias. O verdadeiro valor de I só pode, portanto, ser definido após um atraso. Além disso, a pesquisa para C ocorre naturalmente no início de cada sprint. Os resultados obtidos devem, portanto, ser novamente calculados em média ao longo de todo o lançamento. Apesar dessas dificuldades, qualquer equipe que empregue aspectos de uma metodologia Agile provavelmente descobrirá que as histórias são a unidade mais precisa para quantificar S (e, portanto, I ).

Existem outras metodologias de desenvolvimento em uso hoje. Qualquer que seja a metodologia empregada, os princípios para medir a entropia de software permanecem os mesmos: a entropia de software deve ser medida entre lançamentos para produção, S e I devem ser medidos nas mesmas “unidades de trabalho” e estimativas de C devem ser obtidas de participantes diretos em de forma não ameaçadora e de preferência anônima.

Reduzindo o crescimento de E

Uma vez que o conhecimento sobre um sistema é perdido, ele nunca pode ser recuperado. Por esta razão, a entropia de software não pode ser reduzida. Tudo o que podemos esperar fazer é conter seu crescimento.

O crescimento da entropia pode ser limitado pela adoção de medidas apropriadas durante o desenvolvimento de software. O aspecto de programação em pares do desenvolvimento ágil é particularmente útil nesse sentido. Como mais de um desenvolvedor está envolvido no momento em que o código é escrito, o conhecimento dos detalhes essenciais é distribuído e os efeitos da saída de membros da equipe são mitigados.

Outra prática útil é a produção de documentação bem estruturada e de fácil consumo, principalmente em organizações que utilizam a metodologia cascata. Tal documentação deve ser respaldada por princípios rígidos e bem definidos e compreendidos por todos. As organizações que confiam na documentação como principal meio de comunicação e salvaguarda do conhecimento técnico estão bem adaptadas a esta abordagem. É somente quando não há diretrizes ou treinamento sobre como escrever e consumir documentos escritos internamente – como costuma ser o caso em organizações mais jovens que empregam metodologias RAD ou Agile – que seu valor se torna suspeito.

Existem duas maneiras de reduzir o crescimento da entropia em um sistema: Executar alterações destinadas a reduzir I ou executar alterações destinadas a reduzir C.

A primeira envolve a refatoração. As ações destinadas a reduzir I tendem a ser de natureza técnica e provavelmente já são familiares ao leitor. Uma iteração de desenvolvimento deve ocorrer. A parte dessa iteração destinada a reduzir o crescimento da entropia não fornecerá nenhum benefício comercial tangível, enquanto consumirá tempo e recursos. Esse fato muitas vezes torna a redução do crescimento da entropia uma tarefa difícil em qualquer organização.

Reduzir o valor de C é uma estratégia mais poderosa porque o efeito é de longo prazo. Além disso, C atua como um importante controle sobre o crescimento da razão de I para S. As ações para reduzir C tendem a ser focadas no comportamento e pensamento humano. Embora essas ações possam não exigir uma iteração de desenvolvimento em si, elas retardarão as iterações subsequentes à medida que os participantes aceitam e se ajustam aos novos procedimentos. O ato aparentemente simples de concordar sobre quais melhorias devem ser feitas é um caminho repleto de perigos próprios, à medida que os objetivos díspares dos participantes e stakeholders do projeto de repente vêm à tona.

Empacotando

A entropia de software é o risco de que a alteração do software existente resulte em problemas inesperados, objetivos não atendidos ou ambos.

Embora insignificante quando o software é criado pela primeira vez, a entropia do software cresce a cada iteração de desenvolvimento. Se for permitido continuar sem controle, a entropia de software acabará por interromper o desenvolvimento.

No entanto, nem todo projeto deve contar com os efeitos da entropia de software. Muitos sistemas serão retirados de produção antes que a entropia possa exercer efeitos perceptíveis e deletérios. Para aqueles cujas vidas são longas o suficiente para que a entropia represente um risco crível, criar uma consciência para ela e medir sua extensão, embora ainda baixa, fornece um meio para garantir que o desenvolvimento não seja interrompido prematuramente.

Uma vez que um sistema tenha sido completamente sobrecarregado pelos efeitos da entropia do software, nenhuma outra mudança pode ser feita e o desenvolvimento essencialmente chega ao fim.