O custo real da mudança em desenvolvimento de software

Há duas posições amplamente opostas (e muitas vezes incompreendidas) sobre como pode ser caro para alterar ou corrigir o software, uma vez que foi projetado, codificado, testado e implementado. Uma afirma que é extremamente dispendioso deixar alterações para o final, o que aumenta o custo da mudança exponencial. A outra posição é que as mudanças devem ser deixadas para o mais tardar possível, porque o custo de mudança de software é – ou pelo menos pode ser – essencialmente plana ( é por isso que nós o chamamos “soft”ware ).

Que posição é certa? Por que devemos nos preocupar? E o que podemos fazer sobre isso?

Custo exponencial da mudança

Voltando ao início dos anos 1980, Barry Boehm publicou algumas estatísticas (Software Engineering Economics, 1981), que mostrou que o custo de fazer uma mudança de software ou correção aumenta significativamente ao longo do tempo – você pode ver a curva original que ele publicou aqui.

Boehm analisou dados coletados de projetos baseados em Waterfall na TRW e IBM na década de 1970, e constatou que o custo de fazer uma mudança aumenta à medida que você se move desde as fases de análise de requisitos para arquitetura, design, codificação, testes e implantação. Um erro de requisitos encontrado e corrigido enquanto você ainda está definindo os requisitos não custa quase nada. Mas se você esperar até depois que você concluir o projeto, a codificação e o teste do sistema e entregá-lo ao cliente, pode custar até 100 vezes mais.

Algumas advertências aqui. Primeiro, a curva de custo é muito maior em grandes projetos (em projetos menores, a curva de custo é mais parecida com 01:04 em vez de 1:100). Os casos em que o custo da mudança se eleva até 100x são raros – o que Boehm chama Architecture- Breakers, onde a equipe recebe um direito fundamental arquitetônico de suposição errada (dimensionamento, desempenho, confiabilidade) e não descobre até depois que os clientes já estão usando o sistema e funciona com sérios problemas operacionais. E esta análise foi toda feita em uma pequena amostra de dados de mais de 30 anos atrás, quando o código de desenvolvimento era muito mais caro e demorado.

Alguns outros estudos têm sido realizados desde então, mas a maioria volta nas descobertas de Boehm – pelo menos a ideia básica de que quanto mais tempo se leva para descobrir que você cometeu um erro, mais caro é para corrigi-lo. Estes estudos têm sido amplamente referenciados em livros como “Code Complete“, do Steve McConnell, e usados para justificar a importância das primeiras revisões e testes:

Estudos ao longo dos últimos 25 anos têm provado conclusivamente que vale a pena fazer as coisas certas da primeira vez. Mudanças desnecessárias são caras. Pesquisadores da Hewlett-Packard, IBM, Hughes Aircraft, TRW e outras organizações descobriram que consertar um erro no início de construção permite que o retrabalho seja feito de 10 a 100 vezes menos caro do que quando ele é feito na última parte do processo, durante o teste do sistema ou após o lançamento (Fagan 1976; Humphrey, Snyder, e Willis, 1991; Leffingwell 1997; Willis et al, 1998; . Grady 1999; Shull et al 2002; Boehm e Turner, 2004).

Em geral, o princípio é o de encontrar um erro tão perto quanto possível do momento em que foi introduzido. Quanto mais tempo o defeito permanece na cadeia alimentar do software, mais profundo o dano que provoca. Uma vez que os requisitos são feitos em primeiro lugar, os defeitos de requisitos têm o potencial de ficar mais tempo no sistema e sair mais caro. Defeitos inseridos no software upstream também tendem a ter efeitos mais amplos do que aqueles inseridos downstream. Isso também faz com que os defeitos precoces sejam mais caros.

Há alguma controvérsia sobre a forma exata e completa destes dados, o quanto podemos contar com eles e quão relevantes eles são hoje – quando temos ferramentas muito melhores de desenvolvimento e muitas equipes passaram de desenvolvimento pesado de Waterfall sequencial para leve iterativo, com abordagens de desenvolvimento incremental.

Achatando o custo de mudar código

As regras do jogo devem mudar com o desenvolvimento iterativo e incremental – porque precisa.

Boehm percebeu, na década de 1980, que podíamos pegar erros mais cedo (e, portanto, reduzir o custo de desenvolvimento) , se pensássemos sobre os riscos iniciais, o projeto e a construção de software em incrementos. Usando, assim, o que ele chamou de modelo em espiral, ao invés de tentar definir, projetar e construir software em uma sequência Waterfall.

As mesmas ideias estão por trás: abordagens mais leves e ágeis de desenvolvimento mais moderno. Em Extreme Programming Explained (a 1 ª edição), Kent Beck afirma que minimizar o custo de mudança é uma das metas do Extreme Programming, e que a curva de custo de mudança é achatada “a premissa técnica do XP”:

Sob certas circunstâncias, o aumento exponencial do custo de modificar o software ao longo do tempo pode ser achatado. Se podemos achatar a curva , as velhas suposições sobre a melhor maneira de desenvolver software não fazem mais sentido…

Você tomaria grandes decisões, no mais próximo possível do final do processo, para adiar o custo de tomada de decisões e ter a maior chance possível de que seria correto. Você só iria implementar o necessário, na esperança de que as necessidades que você antecipar para amanhã não se tornariam realidade. Você apresentaria elementos para o projeto apenas para simplificar o código existente ou fizesse do ato de escrever o seguinte trecho de código uma coisa mais simples.

É importante entender que Beck não diz que com o XP a curva de mudança é plana. Ele diz que esses custos podem ser achatados se as equipes trabalharem para isso, aproveitando as práticas e princípios de XP como essenciais:

• Design simples, que faz com que as coisas mais simples funcionem e adia as decisões de projeto para o mais tarde possível (YAGNI), de modo que o design seja fácil de entender e fácil de mudar;
• Refatoração continuamente e disciplinada para manter o código fácil de entender e fácil de mudar;
• Primeiro-teste de desenvolvimento – escrever testes automatizados antecipadamente para pegar erros de codificação imediatamente e para construir uma rede de testes de segurança para pegar erros no futuro;
• Desenvolvedores que colaboram de perto e constantemente com o cliente para que possam construir e trabalhar juntos para criarem soluções e resolverem problemas desde o início;
• Contar com software de trabalho sobre documentação para minimizar a quantidade de papelada que precisa ser feita a cada mudança (escrever o código, não specs);
• A experiência da equipe de trabalho de forma incremental e interativa – quanto mais as pessoas trabalham e pensam desta maneira, melhor.

Tudo isso faz sentido e soa bem, embora não haja estudos que embasem estas afirmações (razão pela qual Beck desistiu dessa discussão de mudança de curva a partir da segunda edição de seu livro XP). Mas, a ideia de que a mudança poderia ser plana, com desenvolvimento Agile, já havia sido aceita por muitas pessoas.

A importância do feedback

Scott Âmbar concorda que a curva de custo pode ser achatada no desenvolvimento Agile – não por causa do projeto simples, mas por causa dos loops de feedback, que são fundamentais para o desenvolvimento iterativo e incremental. Métodos ágeis otimizam o feedback dentro da equipe, os desenvolvedores trabalhando em conjunto uns com os outros e com o cliente. E seguindo técnicas práticas, como o primeiro teste de desenvolvimento e programação em par e integração contínua fazem esses loops de feedback ainda melhores.

Mas o que realmente importa é obter feedback das pessoas que usam o sistema – é só então que você sabe se você acertou ou no que você errou. Quanto mais tempo é preciso para projetar e construir algo e obter o  feedback de usuários reais, mais tempo e trabalho é necessário para obter software de trabalho nas mãos de um verdadeiro cliente; e maior será o custo da mudança.

Otimização e racionalização; este ciclo de feedback é o que está conduzindo a abordagem de Lean Startup para o desenvolvimento: a definição de um produto viável mínimo (algo que mal faz o trabalho), obtendo-o para clientes o mais rápido possível, e , em seguida, responder ao feedback dos utilizadores através da implantação contínua da técnica A / B para teste até você descobrir o que os clientes realmente querem.

Mesmo a mudança de plano ainda pode ser cara

Mesmo que você faça tudo para otimizar esses loops de feedback e minimizar suas despesas gerais, isso ainda não significa que a mudança será barata. Ser rápido não é bom o suficiente se você cometer muitos erros ao longo do caminho.

O Post Agilista usa o exemplo de pintar uma casa: achar que custa US$ 1 mil cada vez que você pinta a casa, se você pintar de azul ou vermelho ou branco. O custo da mudança é plano. Mas se você tem que pintar de azul primeiro, depois vermelho, depois branco antes de todo mundo ficar feliz, você está desperdiçando tempo e dinheiro.

“Não importa o quão caro seja ou o quanto você altere a curva do “custo da mudança”, quanto menos mudanças, mais barato e mais rápido será o resultado. Planejamento não é uma palavra de quatro letras “. [ No entanto, eu gostaria de apontar que “plano” é ].

Passar muito tempo no planejamento e design é desperdício. Mas não gastar antecipadamente o tempo suficiente para descobrir o que você deve construir e como você deve construi-lo antes de construí-lo , e não tomar o cuidado para construí-lo com cuidado, é também um desperdício.

Mudança fica mais cara ao longo do tempo

Você também tem que aceitar que o custo incremental da mudança vai subir ao longo da vida de um sistema, especialmente quando um sistema está sendo usado. Este não é apenas um problema de dívida técnica. Quanto mais as pessoas usam o sistema, mais as pessoas podem ser afetadas pela mudança. Se você errar, mais cuidado você tem que ter; o que significa que você precisa passar mais tempo no planejamento e para comunicar mudanças, construir e testar a capacidade roll-back e rodar mudanças lentamente usando Canary Releases e Dark Launching – que adicionam custos e atrasos para obter feedback.

Há também as dependências mais operacionais que você tem que entender e cuidar, e mais os dados que você tem que mudar ou consertar; e isso faz com que as mudanças fiquem ainda mais difíceis e caras. Se você fizer as coisas direito, mantiver uma boa equipe e gerenciar a dívida técnica de forma responsável, estes custos devem subir suavemente sobre a vida de um sistema – e se você não fizer isso, a curva exponencial da mudança vai nas alturas!

Qual é o custo real de mudança?

O custo real é o de uma mudança exponencial, ou plana? A verdade está em algum lugar no meio.

Não há razão para que o custo de fazer uma mudança tenha que ser tão alta como há 30 anos. Nós podemos definitivamente fazer melhor hoje, com melhores ferramentas e maneiras melhores e mais baratas de desenvolvimento de software. As chaves para minimizar os custos da mudança parecem ser:

1. Coloque seu software nas mãos dos clientes o mais rápido que puder. Não estou convencido de que qualquer organização precisa realmente forçar mudanças de software de 10-50 -100x por dia, mas você não quer esperar meses ou anos para o gabarito também. Entregar menos, mas com mais frequência. E porque você está entregando mais frequentemente, faz sentido construir um canal de entrega contínua de modo que você possa forçar as mudanças de forma eficaz e com confiança. Use as ideias de Lean Software Development e talvez Kanban para identificar e eliminar o desperdício e minimizar o tempo de ciclo.
2. Sabemos que, mesmo com muito planejamento inicial e foco no design, não vamos ter tudo adiantado direito – esta é a falácia Waterfall. Mas também é importante não perder tempo e dinheiro na iteração quando você não precisa. Gastar bastante tempo em requisitos de compreensão e no design para obtê-lo, pelo menos, faz com que você economize muito mais tarde.
3. E se você está trabalhando de forma incremental e interativo faz todo o sentido pegar erros no início – quando você pode. Não importa se você faz isso através do primeiro teste de desenvolvimento e emparelhamento, ou requisitos de oficinas e revisões de código, o que funcionar para você.