Abrace a complexidade do software

As abordagens “tradicionais” de desenvolvimento de software que valorizam os processos definidos de trabalho, estimativas precisas, a produtividade e o controle, seguir o planejado e um contrato detalhado com o cliente, não aceitam que a falta de ordem no desenvolvimento de software é um fato – e não necessariamente uma coisa ruim. Estas abordagens geralmente levam as equipes de desenvolvimento a apresentarem atrasos nas entregas, péssima qualidade (sobretudo no código) e resultados insatisfatórios ao cliente. Quando este cenário não é tão expressivo, as equipes de desenvolvimento apresentam desempenho aquém de suas potencialidades e alta insatisfação. Mas por que? Porque  o software é algo que embute alta complexidade que deriva dos quatro elementos seguintes:

A complexidade do domínio do problema: Os requisitos de software podem ser difíceis de se expressar. Ao adicionar todos os outros (muitas vezes implícitos) requisitos, tais como usabilidade, desempenho, custo e confiabilidade, tem-se uma complexidade ainda maior para expressá-los. Toda esta complexidade geralmente é percebida no “déficit de comunicação” que existe entre os diversos atores: clientes, usuários e desenvolvedores de um software. Para tentar suplantar esta dificuldade entre os atores, a forma comum é registrar os requisitos em uma grande quantidade de texto formatado, acompanhado de alguns desenhos, mas que podem ser de difíceis de apreender, visto que dependem do contexto, do conhecimento e da interpretação dos atores envolvidos. Uma complicação a mais é que os requisitos de software geralmente mudam durante o desenvolvimento. Pode ocorrer quando o tempo entre a comunicação até a apresentação do requisito traduzido em uma solução no software é demasiado longo e o cliente ou usuário muda de ideia sobre o requisito. Também pode ocorrer por um efeito contrário, resultante da interação entre os atores, onde a simples apresentação do software ao usuário pela equipe de desenvolvimento faz com que o requisito mude, traduzido normalmente pela frase “não era isto o que eu queria”.

A dificuldade de gerir o processo de desenvolvimento: A tarefa fundamental da equipe de desenvolvimento de software é criar uma solução simples para um problema complexo. No entanto, para atender o volume de requisitos a equipe de desenvolvimento é obrigada a escrever uma grande quantidade de código para um novo software ou a reutilização de muito código ou software existente em novas formas. Com isto, se pode chegar a milhares ou até milhões de linhas de código combinadas e que interagem de outras milhares de formas diferentes. O que gera enorme complexidade para as pessoas que estão trabalhando nestes códigos. Nenhuma pessoa possui cognição suficiente para entender tal software completamente. Para enfrentar este desafio utilizamos uma equipe com vários desenvolvedores de software. Ter mais desenvolvedores significa uma comunicação mais complexa e, portanto, uma coordenação de informações mais difícil além da necessidade contínua de manter uma unidade e integridade do software que está sendo criado.

A flexibilidade possível através de um software: Uma empresa de construção civil não forja vigas personalizados para um novo edifício. Quando o edifício está construído, há enorme restrição para mudar, quando não inviável estruturalmente, alguma porta ou janela de lugar mesmo que o cliente queira. No entanto, na indústria de software, tais práticas são comuns. Software é criado em camadas e estruturas extremamente flexíveis. O desenvolvedor pode criar blocos de códigos básicos e personalizados para um software. Mudanças em um software, com quase nenhuma exceção, são viáveis. Assim, software oferece a máxima flexibilidade. E como resultado desta flexibilidade, o software é intensivamente dependente do esforço e conhecimento das pessoas.

O problema do comportamento: Pequenos blocos de código são criados para atender a pequenas necessidades e interagem entre si para alcançar funcionalidades de negócio do cliente. Em software estes pequenos blocos de código são feitos aos milhares e permitem várias combinações que geram uma explosão de comportamentos diferentes. Assim como mudar uma peça do motor pode gerar um comportamento diferente do automóvel, mudanças em pequenos blocos de software podem gerar novos comportamentos, por vezes inesperados e não desejados. Além disto, como colocar um combustível diferente para o motor de um automóvel pode mudar os resultados do mesmo, mudanças no ambiente onde estão estes softwares e nos dados que entram neles podem gerar resultados diferentes e por vezes inesperados. Este é um motivo forte para se executar uma grande bateria de testes em software. Entretanto, testes exaustivos e completos a respeito de todos os possíveis comportamentos em algo tão complexo como software, podem estar fora da capacidade intelectual dos desenvolvedores e de qualquer modelo matemático de predição de comportamento.

Toda estes elementos remetem ao software uma complexidade intrínseca, com alta incerteza e baixa relação entre causa e efeito. Como uma propriedade essencial entende-se que pode-se lidar com esta complexidade mas nunca se pode fazê-la desaparecer. Se não se pode eliminar tal fato, a complexidade essencial em software, se faz necessária uma nova visão para lidar com ela. Esta nova visão se trata de pessoas auto organizadas para desenvolver algo complexo como o software, se adaptando às variações e mudanças que ocorrem em qualquer estágio do seu desenvolvimento. Assim, ao invés de evitar ou tentar controlar toda esta complexidade, deve-se abraça-la.

Referências

BECK, Kent. Extreme Programming Explained. Publisher: First Edition September 29, 1999. ISBN: 0201616416, 224 pages.

WALDROP, M. Mitcheel. Complexity. New York: Touchstone Book, 1992.

YOUNG, Bobbi J. BOOCH, Grady. CONALLEN, Jim. ENGEL, Michael W. HOUSTON, Kelli A. MAKSIMCHUK, Robert A. Software Complexity: How Do We Bring Order to Chaos? Nov 30, 2007.