Quando a solução é o problema

Como evitar o excesso de engenharia e funcionalidades inúteis no software

Se só tiver um martelo, tudo se vai parecer com um prego.

Os engenheiros de software e designers acreditam que para criar e melhorar o software, basta exercer seu ofício. O produto sofre de baixo envolvimento dos utilizadores ou interrupções? Eles dizem: "Vamos para uma sala projectar uma solução no quadro branco". Existe uma crença ingénua e generalizada nesta área. A crença é que basta projecto e engenharia para resolver problemas. Esta crença mascara um ponto perverso: cada acto de projecto e engenharia, longe de ser uma de solução, é uma "intervenção numa situação complexa" [Baumer & Silberman, 2011].

Criar software é como a cirurgia

O software é subtil e complexo; miríades de componentes interagem num frágil equilíbrio de design, engenharia, marketing e utilizadores do mundo real. Na sua complexidade e inter-relação, o software é como o corpo humano. E apesar de todos os esforços de fazer a criação de software primitiva e matemática, é muito mais parecido com sangue e cirurgia intestinal. Risco, consequências imprevisíveis, e complicações ensombram cada procedimento.

A medicina moderna classifica este risco como "iatrogenia" – o dano não intencional que surge a partir do tratamento médico. Hoje em dia, a iatrogenia mata mais pessoas do que o cancro. Nos Estados Unidos, a iatrogenia mata entre 3 a 10 vezes mais pessoas do que os acidentes de viação. Mais, por mais estranho que pareça, só nos últimos tempos é que a medicina começou a salvar mais vidas do que aquelas que tira.

Em comparação com a disciplina da medicina, a engenharia de software ainda é jovem e imatura. Não é, portanto, nenhuma surpresa que o software moderno esteja cheio de funcionalidades e correções que fazem mais mal do que bem. Lembra-se do OpenSSL v1.0.1, ou a última actualização do sistema operativo que bloqueou o seu smartphone? A cura foi pior que a doença. Está na altura de se reconhecer a iatrogenia no software. Está na altura dos profissionais de software estudarem e prevenirem os efeitos nocivos do projecto e engenharia.

Não existe nenhum martelo

Os profissionais sofrem de deformação de domínio (deformação profissional), ou da “Lei do Instrumento”. Quando confrontados com um problema, tendemos a responder com o martelo que temos nas nossas mãos. Raramente nos questionamos se o problema beneficiariam ou não com as marteladas. Raramente nos questionamos se estamos sequer diante de um prego ou não. Como resultado dessa falta de questionar, a chamada "resolução do problema" é muitas vezes a "exacerbação do problema." Para superar a Lei do Instrumento devemos mudar a nossa mentalidade. A chave para essa mudança vem num soberbo e conciso artigo, “Quando a implicação é Não ao Projecto”:

"Em vez de imaginarmos que o projecto em tecnologia oferece soluções para os problemas de insustentabilidade, sugerimos pensar no projecto como uma intervenção em uma situação complexa." - Baumer & Silberman, 2011

Como parar com o excesso de engenharia

Faça três perguntas

Agora que entendemos projecto e engenharia como uma intervenção numa situação complexa, como podemos evitar o imprevisto e consequências não intencionais da intervenção? A resposta é que temos que fazer perguntas antes de desenhar um único pixel ou escrever uma única linha de código. Baumer e Silberman oferecem as seguintes três questões:

1. "Poderia a tecnologia de ser substituída por uma abordagem low-tech ou não-tecnológica, igualmente viável a situação? “
2. “Será que a intervenção tecnológica resulta em mais problemas ou danos do que a situação que está a abordar?”
3. “Será que a tecnologia resolve uma transformação tratável computacionalmente
   um problema em vez de o problema em si? "
   (ou seja, é a tecnologia de um substituto pálido para a solução real)

Mude a cultura da sua organização

Se quiser evitar o excesso de engenharia e o empilhar de funcionalidades, os seguintes valores culturais serão construtivos:

1. Valorize não fazer coisas. Inicie um debate na sua organização acerca de "menos é mais" [REWORK]. Evangelize esta mensagem numa forma que as equipas de software a possam apreciar.
2. Explore a “extravenção”. É isso mesmo, explore que funcionalidades pode remover para melhorar o produto. Antoine de Saint Exupéry capturou a extravenção numa linha brilhante “a perfeição é finalmente atingida não quando não há mais nada a acrescentar, mas quando não há mais nada a retirar” (Se pretender uma abordagem mais formal à extravenção, consulte o artigo How to Cut Features and Enjoy it — 20+ questions to find the simplest design).
3. Documente os caminhos não tomados. A fim de superar a Lei do Instrumento e evitar revisitar o mesmo terreno no futuro, documente o que não está a fazer e por que não está a fazê-lo. Coloque os caminhos não tomados no wiki, mesmo se todos os seus instintos lhe dizem para colocá-los numa gaveta de arquivo. Assim como a deformação de domínio nos encoraja a começar a martelar sem pensar, a deformação de publicação desencoraja-nos a documentar as coisas que nós não fazemos (a deformação de publicação é poderosa o suficiente para cegar a própria história. Consegue citar uma pessoa, viva ou morta, que seja celebrada por não ter feito algo?).

Continue a criar

Este artigo não defende o ludismo. Engenheiros e designers dão o seu melhor quando criam em território desconhecido. Este artigo defende uma mudança na perspectiva. Projeto e engenharia são intervenções em situações complexas. Praticar isto é praticar a humildade e precisão. O software, as pessoas que o utilizam e as situações que o criam são mais complexas do que pensamos que sejam. Espere resultados surpreendentes, não lineares, de cada intervenção. Lembrar-se disto é evitar iatrogenia no software. Primum non nocere, “primeiro não causar dano” é uma máxima global da medicina. Também se devia se tornar no grito de guerra de profissionais de software.

Bibliografia recomendada

Taleb, Nassim Nicholas, Antifragile: Things That Gain From Disorder, EUA, Random House, 2012

Este livro fornece um modelo de sistemas complexos que o ajuda a ver os contornos antes de intervir. "Em suma, qualquer coisa em que há intervencionismo ingénuo, ou melhor, mesmo apenas intervenção, terá iatrogenias." - Nassim Taleb

 

Tradução livre do artigo “When the solution is the problem”, de Aneesh Karve.