Muitas vezes em projetos novos ou em novas funcionalidades de projetos é comum termos que implementar alguma funcionalidade que vai além do mero crud e que demanda um pouco mais de conhecimento de algoritmia ou de uma área especifica como inteligencia artificial ou estatística, por exemplo. Alguma coisa que desafia a equipe.

Perante isto,  o programador e/ou o gerente médios tendem a usar alguma lógica do tipo : “vamos fazer da forma mais simples”. Frases como “Não queremos reinventar a roda” e “não queremos sobre engenharia” são comuns neste ponto. As pessoas tendem naturalmente a achar que “simples” significa “a forma que nos obrigar a pensar menos”. Contudo ha um problema fundamental e subtil com esta linha de pensamento. A frase que melhor descreve isto é aquela atribuida a Eisntein : Tudo deve ser feito quão simples possível, mas não mais simples (Everything should be make as simple as possible, but not simpler). Isto é muito profundo. Tome um tempo para entender o que significa.

Significa que não devemos “estupidificar” a decisão e destruir as capacidades de uma solução porque ela foi pensada da forma mais simples. Isto é também chamado de pensamento “bottom-up” ou “incremental”. Significa que você começa do zero e vai adicionando conhecimento até que o conjunto dos conhecimentos resolver seu problema. Por oposição você pode utilizar o pensamento “top-down” ou “clean room” que é partir da formulação do seu problema que é a mais abstrata possível e  que ainda contém o seu problema.  Por exemplo, calcular a potencia de um número. Calcular a potencia inteira positiva de um número inteiro positivo é mais ou menos simples , basta somar o numero uma certa quantidade de vezes definida pela potencia. Isto resolve o seu problema, mas não resolver se o número for negativo ou não for inteiro. Por exemplo, não resolve se você estiver trabalhando com BigDecimal e precisa calcular um potencia em que a base o expoente são ambos BigDecimal. Portanto,  você pode usar a primeira forma de pensamento e ir aumentando o alcance da sua solução passo-a-passo, primeiro tirando o constrangimento de ser inteiro e depois de ser positivo. Ou voce pode abstrair o problema o máximo possível implementando uma solução que permite qualquer número se elevado a qualquer número. Esta solução, depois de um estudo, irá levar você a concluir que isto só é possível se o resultado da operação for sempre um número complexo. e como todos os número que nos interessam podem ser escritos como um complexo (inteiros, reais, frações, positivos, negativos, etc… ) isto resolve o problema de uma forma “top-down”.

Este exemplo é corriqueiro e se baseia em saber alguma matemática. Na realidade os problemas a que me refiro tendem a ter um solução mais velada que demanda alguma pesquisa e que à partida nem sabemos que existe uma solução geral ótima. Então, nesse cenário mais realista, nem sempre é trivial decidir o caminho a tomar e é isto que promove a ideia de “temos que fazer simples”.

Neste cenário entramos então em um aparecente cisma. De um lado aqueles que acham que não devemos atacar o problema como um todo, e do outro aqueles que acham que sim. O primeiro grupo não irá se preocupar em entender as intercidades do problema e simplesmente em achar uma solução que funciona (“funciona” significa aqui : obtem o resultado esperado em todas as circunstancia que me lembrei de testar, mas não necessariamente sempre). O segundo grupo tentará entender a classe do problema e se existe um classe de soluções já existentes para ele.

O primeiro é mais rápido no sentido de obter algo “funcionando”, mas é uma porta de entrada da “gambiarra” e a longo prazo irá se mostrar falho. O grupo que defende isto sempre utiliza algum tipo de argumento “depois a gente muda”, mas isso nunca acontece de fato. O segundo é mais lento, é preciso investigar e estudar mais. É preciso pensar e refletir. Em suma: estudar o problema. A solução tende a ser mais eficiente e duradoura a longo prazo.

Ao contrário do que parece senso comum, não é verdade que atacar um problema na sua forma mínima é a forma mais eficiente de gastar seus recursos. Efetivamente, existe uma probabilidade maior de – usando os mesmos recursos –  um projeto mais ambicioso tenha mais sucesso. Esta conclusão importante, é aparentemente um paradoxo e, é conhecida como o Paradoxo do Inventor.

O paradoxo é que à primeira vista realizar algo mais complexo não parece poder ser mais eficiente que realizar algo mais simples. Na cabeça da maioria “mais complexo” significa “necessidade de mais recursos” , ou seja, “mais caro”, ou “não cabe na minha cabeça”. Este pensamento afeta os resultados em muitas empresas de tecnologia, e especialmente de software, mas também na sociedade como um todo – porque atacar um problema da sociedade de cada vez se estão todos ligados ? A pessoa comum dirá : “porque atacar todos ao mesmo tempo é muito complexo”. Aqui “complexo” significa “não consigo pensar em tanta coisa ao mesmo tempo”.  Portanto, porque  – supostamente – o complexo está além da capacidade de pensar ou além do bolso, ele é descartado imediatamente e a maioria das empresas prefere usar o mecanismo incremental e ir aumentando o alcance das suas soluções passo-a-passo.

O pulo do gato é entender que existem situações onde atacar o problema mínimo é realmente a melhor forma de continuar, mas que este fato não significa que é sempre assim ou que esse é a melhor forma. A melhor forma é atacar sempre um problema mais amplo.

O problema é que lidar com a complexidade é algo subjetivo que depende de muitos fatores culturais e educacionais. Ou seja, algo é sempre simples, para quem já sabe fazer. Daqui a questão do Inventor. É a criatividade e o conhecimento que a pessoa ou grupo têm que permite otimizar os recursos para produzir algo melhor, que lida mais facilmente com o complexo, ou que traduz o complexo para algo mais fácil de pensar sobre. Mesmo sem criatividade ou conhecimento a força gerada por querer ciar algo – a intenção de inventar investingando -, é ela, em si mesma, suficiente para causar o mesmo efeito se a base for sólida. O exemplo clássico é nos dado pelo Google. Tudo começou quando duas pessoas tentaram criar um melhor algoritmo para encontrar páginas na internet. Este algoritmo era diferente e foi criado partindo de diferentes princípios do que era comum na época. O algoritmo foi oferecido ao Yahoo – na época um dos maiores motores de busca – mas foi negado. Então os inventores criaram sua própria empresa em torno ao seu algoritmo e o nasceu o Google. A diferença é que o Yahoo estava interessado em uma solução incremental e não entendeu o poder de um novo algoritmo que era tão diferente. É isto que acontece em muitas empresas de tecnologia. Alguém na empresa propõe uma melhoria, mas a gerencia não enxerga o ganho e não está disponível a investigar. Isto leva a empresa a perder capital proprietário e intelectual, porque além de não seguir o novo rumo, acabará perdendo a pessoa que teve a ideia, mais tarde ou mais cedo.

Bom, então quer isto dizer que devemos sempre seguir o que alguém inventa ? Não necessariamente. De boas intenções está o inferno cheio, e não é realista assumir que todas a pessoas conseguem ser inventores. Contudo, a cultura das empresas de software daqui é que nem sequer vamos tentar.Aquelas que tentam são chamadas hoje de “Start ups”. Que são realmente tubos de ensaio de ideias que podem vir a ter um mega impacto (como o Google), ou não. Contudo a diferença é que alguém apostou em testar a ideia e não necessariamente na ideia em si. O Paradoxo do Inventor representa que existe uma probabilidade não nula de você obter muito ganho apostando em coisas novas. É como ir em Las Vegas, ou apostar na bolsa, é uma aposta de grande ganho com grande risco, mas que pode compensar bastante. O truque é gerenciar o risco de forma a que os recursos não sejam gastos infinitamente e entender que esses mesmos recursos poderiam simplesmente estar pegando pó em algum lugar ou estarem sendo gastos em uma solução cara que não leva a empresa a lado algum. Seria como ter o dinheiro na poupança onde é seguro, mas lento obter um ganho, ou apostar na bolsa onde o ganho é rápido, mas menos seguro. Para uma empresa, usar-se do paradoxo do inventor é o equivalente intelectual a “não ponha seus ovos na mesma cesta”.

Se alguém na empresa realmente sabe fazer algo e isso é invisível a empresa estará perdendo uma oportunidade de inovação sem saber. Aliás, não querendo saber.  Se, e quando, alguém consegue uma inovação é porque se compromete consigo mesmo a realizar a prova do paradoxo do inventor usando seus recursos da forma certa e em vez de tentar resolver um problema ad hoc (ou seja, apenas aquela situação) tentar ver um cenário maior e resolver de uma forma mais genérica que permite mais simplesmente resolver o problema em mãos.

Aconteceu comigo em um trabalho a alguns anos atrás. Não podíamos usar hibernate porque o cliente não deixava. O cliente nos dava um framework meia-boca que nada mais era que um casca para o JDBC e nos obrigada a usar esse framework. O framework funcionada por templates. A ideia era ter todos os SQL em arquivos xml, e usar o frameworks para escolher e executar as queries. O conceito é que assim as queries poderiam ser alterada para otimização depois pelos DBAs sem recompilar o código. Este mecanismo é chamado Named Queries e algumas ferramentas como o Hibernate e o JPA suportam isto. Mas também suportam outras coisas. A principio parece uma boa ideia, mas para desenvolvimento era insustentável para o projeto. Contudo, ninguém queria resolver o nosso problema. Nem o cliente porque acha sua api o máximo (e o projeto era waterfall então o ónus da demora seria da nossa empresa e não dele), nem a nossa diretoria porque “queria manter as cosias simples” leia-se “não entendi o seu problema e não quero gastar dinheiro com isso”- não entendendo que a faca estava sobre a sua cabeça e não sobre a do cliente porque o ônus era seu.. Em uma semana criei uma derivação do framework do cliente – graças a Deus a API era extensível embora não por design , mas por falta dele- que permitia definir as queries sem escrever SQL. O SQL era gerado dinamicamente a partir de objetos que eram construídos usando um builder e um metamodelo era usado para depois transformar os objetos em SQL (padrão Query Object + Interpreter). Obviamente isto simplificou o trabalho e acelerou o desenvolvimento, inclusive anos mais tarde ajudou a prover mais funcionalidades e melhor performance e a resolver um problema inerente ao banco de dados que não aceitava mais que 256 itens num comando ‘in’. O framework detetava isto simplesmente fazia mais queires e agregava o resultado. Do ponto de vista da aplicação apenas uma querie tinha acontecido. Os recursos gastos em uma semana pouparam muito tempo, dinheiro e dor de cabeça ao longo de 3 anos, mas ninguém quis apostar nisso no inicio nem reconheceu isso no final. Apenas a equipe que trabalha todos os dias com isto sentiu a diferença.Deu certo porque eu sabia que iria ser vantajoso e já tinha experiencia com esse tipo de frameworks. Eu não conhecia o Paradoxo do Inventor na época, mas o meu “sentido-aranha” dizia que era o certo. Mas! Grande “MAS”… já vi muita gente tentar o mesmo e dar com os burros na água. O próprio cliente tinha seguido esse caminho criando uma API que era um monstro e no fim, inútil, porque foi desenhada com a filosofia dos anos 80 para sistemas dos anos 2000.

Um corolário do Paradoxo do Inventor é que quando nos deparamos com um problema que parece complicado ou impossível de resolver, devemos aumentar o escopo da solução, ou seja, não tentar resolver aquele problema especifico, mas achar a solução para uma família de problemas, onde aquele se enquadra. Ou seja:  abstrair o problema. Não tentar apenas calcular a potencia dos números que lhe interessam, mas de todos. Não apenas resolver a escrita das queries que você precisa, mas de todas. Não tentar melhorar um algoritmo que é falho na essência, mas criar outro que não partilha dos mesmo problemas.

Empresas que entendem que o seu maior valor está na capacidade de usar a inventividade dos seus colaboradores são as empresas que saem na frente. Claro que isto não é aleatório. A empresa que reconhece este valor procura ter nos seus quadros pessoas com capacidade inventiva – para não cair no buraco do paradoxo que é investir em pessoas incapazes -e ao mesmo tempo tem processos para incentivar e descobrir estas pessoas. Os famosos projetos 20% do Google servem para isto. Não é para “dar tempo livre às pessoas” , mas para cultivar a sua criatividade , enxergar no que elas são capacitadas e no fim colher os lucros ( e os louros) do seu trabalho.  Hoje atribuímos um conjunto imenso de coisas à “criatividade do Google”, mas isso é apenas porque não sabemos os nomes da várias pessoas envolvidas. Empresas não produzem coisas, pessoas é que produzem.

Da próxima vez que pretender ousar e seu gerente não deixar, negocie um teste. Faça ele apostar e banque a aposta. Faça uma prova de conceito. Demonstre na prática que é possível melhorar.

No fim é importante se lembrar sempre que gastar menos não é necessariamente melhor. Às vezes significa apenas ser sovina ou “curto-de-vista”.

P.S.

Não pude resistir a esta citação que traduz o real problema e a razão de porque as pessoas dizem preferir soluções “simples”

As pessoas não gostam de pensar. Se pensamos, chegamos a conclusões. Conclusões nem sempre são agradáveis. – Helen Keller
(People do not like to think. If one thinks, one must reach conclusions. Conclusions are not always pleasant. )