Início > Pragmática > A Melhor Solução é a Simples

A Melhor Solução é a Simples

Gosto de simplicidade, tanto nas pessoas quanto nas soluções técnicas. Pessoas que focam no problema causam outros problemas.

Escovando os Dentes No Espaço

Em um post antigo, mas muito interessante, o Carlos Villela contou a história de uma solução complexa que foi ridicularizada por uma solução simples e barata:

A linha de produção de uma fábrica de pasta de dentes às vezes permitia a saída de caixas de creme dental sem o tubo. O CEO gastou $8 milhões em uma solução baseada em uma balança colocada no final da linha de produção. Essa balança detectaria a presença de caixas vazias e pararia o processo caso acusasse a presença de alguma. Em seguida, um funcionário deveria remover a caixa e apertar um botão para que o processo continuasse. Na terceira semana de uso, os relatórios não acusavam acionamento da balança. Os funcionário haviam instalado um ventilador – ao custo de $20 – que soprava as caixas vazias para fora da esteira, pois segundo eles era muito chato ter que ficar indo até a balança várias vezes ao dia para apertar o botão

Da mesma forma, os cientistas da NASA gastaram milhões de dólares para criar uma caneta que funcionasse no espaço, pois sem gravidade e sem pressão atmosférica a tinta de uma caneta comum não desce até a ponta. Os russos tiveram o mesmo problema, mas resolveram utilizando lápis para escrever no espaço!

Os dois exemplos mostram que o erro foi cometido por manter o foco no problema ao invés de focar a solução.

A Falácia da Bala de Prata

Scott W. Ambler, no livro Modelagem Ágil, fala sobre a criação de cenários do tipo “O que acontecerá se…”:

Muitas vezes, vejo desenvolvedores de software desviarem-se de suas tarefas para tentar construir um software que satisfaça às necessidades de seus usuários de um modo eficaz, com cenários tolos do tipo “o que acontecerá se…”. Eles começam a modelar demais o software para resolver todos os problemas imagináveis, com os quais os clientes dificilmente estão preocupados ou acreditam ser tão remotamente provável deles acontecerem que estariam dispostos a correr o risco. Então, por modelarem em excesso, os desenvolvedores também constroem em excesso. Sim, você não quer ser completamente simplista em seu trabalho. É razoável esperar que alguns problemas em banco de dados e falhas de rede, entre outros, realmente ocorram, mas você precisa ser realista quando estiver modelando

Há arquitetos de software que acham que a melhor solução é aquela que resolve todos os problemas do presente e do futuro, inclusive aqueles que possuem baixíssima possibilidade de ocorrer. Esses são adeptos do BDUF (Big Design Up Front) e normalmente ultrapassam o domínio do problema em suas soluções.

Lembra do famoso artigo No Silver Bullet escrito pelo Fred Brooks? Todos os desenvolvedores já leram ou no mínimo ouviram falar desse assunto, mas tem gente que teima em não aceitar o fato de que uma solução arquitetural visa satisfazer aos requisitos necessários para atender o negócio. Requisitos mudam – muitas vezes de forma não previsível – e um BDUF não é facilmente adaptável a essas mudanças. Um arquiteto que goste de BDUF e busque a perfeição utópica em uma solução tem em seu domínio do problema:

Matar uma formiga

Esse requisito é tão complexo que apenas seus olhos treinados e experientes conseguem enxergar toda a extensão do problema. Dessa forma, ele construirá uma solução arquitetural que utiliza quase todos os vinte e três design patterns do GOF (Gang Of Four), pois tentará fazer todas as permutações possíveis com os requisitos que possui mesmo que elas não façam sentido para o usuário:

Matar qualquer quantidade de formigas de quaisquer espécies – inclusive as que já podem estar extintas e espécies ainda não catalogadas ou alienígenas – em qualquer estação do ano e a qualquer hora do dia na Terra. Também deve ser possível matá-las em qualquer planeta do sistema solar,  galáxias adjacentes e dimensões paralelas mesmo nas proximidades de buracos negros

Se matar a formiga é o objetivo, há alguma explicação plausível para a extensão do domínio do problema?  Qual é a visão arquitetural? Naturalmente, uma proposta arquitetural para esse problema possuirá no mínimo uma dúzia de camadas das quais apenas umas duas desempenhem papéis relevantes.

Certa vez, ainda estagiário, precisei criar uma caixa de diálogo que seria padrão para toda a aplicação. Gastei algumas horas para construir uma solução a mais simples possível. O design ficou  tão simples que poderia ser facilmente estendido, mas meu chefe, após uma exaustiva conversa, afirmou que a solução deveria ser mais genérica. Pintou uma imagem futura da caixa de mensagens e me fez acreditar. Gastei mais alguns dias criando uma abstração mais granular  utilizando Generics e permitindo layouts plugáveis e comunicação via uma implementação de Observer. No final, nada disso foi necessário. Era muito provável que um simples JOptionPane resolvesse o problema. Só eu tive algum ganho, pois pelo menos aprendi Generics e alguns design patterns :).

Para minimizar o problema, poderíamos utilizar TDD (Test Driven Design). TDD não é Cowboy Design, que é o extremo oposto do BDUF, mas em TDD Triage o próprio Uncle Bob reconhece que essa técnica não funciona para todos os casos. Há casos em que é necessária uma arquitetura bem definida para iniciar o desenvolvimento, mas ainda assim não é justificável uma arquitetura inchada feita por um arquiteto de software com o ego igualmente inchado.

No Divã

Muitas pessoas têm nostalgia da infância. Lembram com saudade do tempo em que jogavam bola na rua e precisavam se preocupar apenas em ir à escola e fazer a lição de casa. Mas qual o motivo desse saudosismo freudiano? Será que você lembra com carinho das provas de gramática? E do caderno de caligrafia? Provavelmente não.

O motivo do saudosismo é a simplicidade dos tempos de infância. Não tínhamos contas para pagar, não havia pressão para entrega de projetos, enfim, não tínhamos compromissos, responsabilidades, micro-gerenciamento, EJB 2.1 e DBAs :).

Você trocaria seu carro, seu emprego e todos aqueles gadgets legais e bastante inúteis por uma chance de voltar a ser criança? Bom, se você for o Dijkstra, talvez.

Ninguém em sã consciência faria tal troca. As pessoas querem mais: mais conhecimento, mais desafios, mais oportunidades, mais dinheiro e mais bens. Querendo mais e mais, elas caem facilmente na cilada do egocentrismo e estão fadadas a uma vida complicada e cheia de angústias. Como uma pessoa complicada pode pensar claramente e criar soluções que simplifiquem a vida dos outros e não soluções que são apenas a externalização de suas angústias?

Conclusão

Desconfie de arquitetos de uma nota só e de suas soluções arquiteturais mirabolantes que ao invés de solucionarem um problema causam vários outros. Desconfie de mestres, doutores e gurus que falam muito, exibem diplomas, teses e artigos, mas não são pragmáticos.

Anúncios
Categorias:Pragmática
  1. Camila
    13/11/2009 às 12:19 PM

    “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.” – C. A. R. Hoare

  2. 19/02/2011 às 9:08 AM

    Achei um documentário da Discovery que mostra a produção da caneta espacial:

  1. 31/05/2011 às 11:43 PM
  2. 02/03/2013 às 8:53 PM
  3. 03/01/2017 às 6:24 AM
  4. 07/01/2017 às 8:21 AM

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: