O Paradoxo do Inventor 

May/15
22

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. )

2 comentários para “O Paradoxo do Inventor”

  1. Ol√° Sergio, tudo bem?

    O que você pensa a respeito de avaliação individual em empresas de desenvolvimento de software? Acredito que isso seja extremamente contra a ideia de times e desenvolvimento colaborativo. O que você pensa?

    Grato

  2. √Č uma pergunta de dif√≠cil resposta.Em geral eu sou contra os processos onde rh ou gerentes sem no√ß√£o fazem essas avalia√ß√Ķes. √Č tudo sem sentido e sem subst√Ęncia. E n√£o √© apenas em equipes de software. Por outro lado h√° que destingir o trigo do joio e conversar com as pessoas pode ser muito iluminativo. Eu n√£o sou coatch, vejo q se o avaliador √© s√©rio pode ser proveitoso do ponto de vista pessoal, mas atrelar com metas e essas coisas √© completamente errado e ultrapassado.

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos