23 de fevereiro de 2012

Você programa como Edison ou como Tesla?

Nesse carnaval, um dos artigos que saiu da minha sempre crescente lista no Instapaper, foi sobre as diferentes abordagens para a solução de problemas adotadas por dois grandes inventores: Thomas Edison e Nikola Tesla. Além de ter gostando bastante do artigo[1], gostei do que aprendi das pesquisas adicionais que fiz por causa dele (referências no final) e, por fim, tive a motivação que faltava para voltar a postar aqui. Esse post explora o contraste entre as abordagens de Edison e Tesla aplicadas ao desenvolvimento de software.

Edison e o trabalho árduo

"Gênio: 1% inspiração e 99% transpiração" (Thomas Edison)
"Eu não falhei 700 vezes. Não falhei nenhuma vez. Eu fui bem sucedido em provar que aquelas 700 alternativas não funcionam. Quando eu tiver eliminado as que não funcionam, encontrarei aquela que funcionará." (Thomas Edison)

Belas afirmações! Você por acaso conhece alguém bem sucedido que não tenha trabalhado duro nas suas ideias? Se não houver disposição para executar uma ideia, o que muitas vezes envolve desistir de um caminho e tentar outro, a mais brilhante das ideias não vai a lugar algum.

Porém, Tesla, que foi assistente de Edison durante algum tempo, era partidário de uma abordagem diferente.

Tesla e a otimização do trabalho

"Se Edison tivesse que procurar uma agulha no palheiro, ele examinaria palha por palha até encontrar a agulha. Fui uma triste testemunha de coisas como essa, sabendo que um pouco de teoria e cálculo teriam economizado noventa porcento do seu trabalho." (Nikola Tesla)

Quem você acha que teve mais razão nas suas afirmações? Ora, de certa forma, ambos estavam corretos. Disposição para trabalhar arduamente é importante, mas otimizar a maneira como você trabalha também. Uma coisa complementa, não exclui, a outra.

Caso você não saiba, a Edison é atribuída a invenção da lâmpada elétrica incandescente; aquela que gasta mais energia gerando calor do que luz. E Tesla inventou a lâmpada fluorescente, muito mais econômica. Edison também foi o pioneiro na geração de energia elétrica contínua (DC); eficiente, porém cara. Enquanto Tesla foi o pioneiro na energia alternada, muito mais barata, e que se tornou e continua sendo o padrão mundial.

O ponto que quero trazer à atenção aqui é: quando você resolve problemas, você age mais como Edison ou como Tesla? Um breve incidente pessoal ajuda a explicar a diferença no contexto do desenvolvimento de software.

Meu momento Edison

Atualmente estou trabalhando num projeto usando Titanium Mobile (veja meu blog sobre Titanium). A linguagem usada pelo Titanium é o JavaScript, que comecei a conhecer de verdade de um ano pra cá. Nesse projeto, a app mobile recebe dados no formato Json de um WebService. Esses dados incluem um array de centenas de objetos ordenados por um atributo específico. Porém, em um dia de trabalho solitário em home office na semana passada, surgiu a necessidade de se fazer buscas nesse array por um atributo diferente da sua ordenação. Não seria conveniente fazer uma busca sequencial em centenas de elementos. Então, sem medo de encarar o trabalho envolvido, implementei um mecanismo de indexação que consistia em manter um segundo array contendo em cada elemento um objeto com dois atributos: o valor do campo pesquisável e sua posição no array original. Esse array seria ordenado pelo tal atributo pesquisável. Para isso, implementei um BubleSort e uma busca binária, ambos customizados para trabalhar com arrays de objetos. Levei algumas horas para terminar essa solução e, no final, me senti orgulhoso por ter realizado aquele trabalho árduo. Mas, no dia seguinte, ao explicar minha solução para um colega no escritório, todo meu orgulho foi por água abaixo.

Antes que eu terminasse minha explicação ele perguntou: Por que você não usou um hashtable? Então, minha ficha caiu. Todo objeto JavaScript é um hashtable! E o pior é que eu já sabia disso. Eu não precisava implementar ordenação nem busca. Bastava, ao invés de usar o segundo array, usar um objeto cujos atributos fossem os valores do campo pesquisável e cujos respectivos valores fossem sua posição no array original.

Por que eu implementei uma solução muito mais complexa do que era necessário quando eu tinha total condição de conceber uma solução extremamente mais simples? Após refletir um pouco, identifiquei pelo menos dois motivos:

  • Parei de pensar em alternativas na primeira solução que me veio à mente;
  • Me apeguei (ainda que temporariamente) àquela solução.

O resultado foi comparável à lâmpada incandescente de Edison. Funciona, mas gasta mais energia produzindo calor que luz.

Como seria à moda Tesla

"Se quiser derrubar uma árvore na metade do tempo, passe o dobro do tempo amolando o machado." (Provérbio chinês)

Esse provérbio se encaixa muito bem no estilo pragmático de Tesla. Infelizmente, o problema que acabei de contar não aconteceu num dos meus dias mais pragmáticos. Se eu tivesse pensado um pouco mais nas soluções possíveis para aquele problema, provavelmente teria chegado na solução mais simples e óbvia. Ou, se tivesse praticado o desapego à minha ideia e chamado o meu colega no GTalk para conversar sobre o problema, provavelmente ele teria me sugerido a solução mais simples.

No final das contas, levei cerca de 5 minutos para reescrever a minha solução Edison usando a abordagem Tesla. Evidentemente, esse retrabalho não fui inútil porque o aprendizado que vem da tentativa e erro têm o seu valor. Foi o que Edison quis dizer ao citar suas 700 tentativas de acertar. Mas, como Tesla nos lembrou, um pouco de teoria e cálculo podem economizar muito trabalho.

Edison e Tesla: estilos complementares

No dia a dia do desenvolvimento de software, encaramos problemas que exigem tanto um perfil Edison quanto um perfil Tesla. Disposição para encarar os desafios e aprender com os próprios erros é fundamental, mas se fizermos uma pausa antes de colocar as mãos no teclado e pensarmos de maneira analítica sobre as soluções possíveis, economizaremos tempo e "energia". Se for possível compartilhar esse momento analítico com mais alguém, melhor ainda. É preciso apenas cuidar para não ficar pensando indefinidamente.

De hoje em diante, tenho um lema: antes de gastar energia resolvendo um problema, preciso pensar se é hora de ser um Edison ou um Tesla.

Que achou desse artigo? Deixe seu comentário.

Foto: Globo de plasma, uma das invenções de Nikola Tesla. (Wikipedia)

[1] ^ Scott Berkun. "Edison vs. Tesla: two approaches to problem solving"

Para saber mais:

18 comentários:

Arthur Carvalho disse...

É muito difícil saber pesar qual a hora de ser cada momento (Edison ou Tesla).
Muitas vezes eu tento realizar algo da melhor forma possível. Para isso, então, estudo bastante antes de aplicar.
Agora os problemas que muitas vezes eu tenho passado (e que acontece muito com nossa área de tecnologia) são: Não saber a hora de parar o apredizado e partir pra realização; Perder o foco com tanto conteúdo existente e começar a estudar outras coisas no meio do caminho.
Creio que o ideal seria que nós mesmos entedessemos qual é a forma que estudamos (individualmente) e apartir daí saber qual é a forma de se comportar na hora de resolver um problema.

Parabéns, escreveu ótimo artigo.
@armoucar

Dirlei Dionísio disse...

Oi Arthur,

Concordo que na prática as coisas são bem mais complexas. Mas eu diria que, em geral, o estilo Tesla é para quando estamos decidindo como fazer e o Edison, para quando já decidimos.

Sobre aprendizado, eu tendo a preferir começar com uma visão geral (lendo um livro, por exemplo) e em seguida partir para um uso real do novo conhecimento (a "realização", como vc disse). No caminho, descubro que preciso aprender mais sobre alguns detalhes e me dedico a eles conforme a necessidade surge. Mas isso é bem pessoal e concordo que cada um deve descobrir seu melhor estilo de aprendizado.

Muito obrigado pelo comentário.

Grande abraço!

Lucas Polo disse...

E se ao invés de alternarmos nas duas formas de raciocínio, mesclarmos as duas? Você chegou a solução do seu problema, mas poderia aplicar a abordagem Tesla e gastar mais energia para melhorar sua solução. E assim, gastar mais e mais energia melhorando, porém utilizando agora uma abordagem mais científica. Edson resolveu o problema com 700 tentativas, Tesla faria em bem menos, mas e se Tesla e Edson trabalhassem juntos? Na 700ª tentativa essa lâmpada se acenderia, sozinha e faria café. =)

Muito bom o seu texto cara, confesso que esse aqui é blog que vai além dos códigos, traz inspiração. Continue assim.

Dirlei Dionísio disse...

Oi Lucas,

Gastar mais energia (Edison) melhorando uma solução usando a abordagem científica (Tesla) é uma boa para certos casos. Se performance é um fator crítico para sua aplicação, por exemplo, vale investir nessa direção. Mas, geralmente, as soluções precisam ser apenas suficientemente boas, o que nem sempre é o que gostaríamos de fazer. Parar de otimizar é um desafio, mas é necessário.

Obrigado pela visita e pelo comentário.

Abraço!

Pierre Abreu disse...

Quase sempre não dá para saber se a solução adotada é a melhor solução, só depois de implementá-la que se é possível veslumbrar outras soluções mais interessantes (quando o cérebro não está saturado eheh). Na maioria dos casos temos um tempo curtíssimo para achar uma solução de um problema, isso acaba fazendo que criemos soluções "bacalhoadas", que acabam se tornando modo edison de fazer, pois esse "bacalhau" pode se tornar um novo problema, gerando assim um novo trabalho.
Pessoalmente acho que o mais importante é ter a solução!
Mas não fique triste :) porque vc gastou um tempinho implementado o segundo array e as buscas, veja como ponto positivo que vc aplicou teorias acadêmicas (que na faculdade nos perguntamos porque estamos aprendendo isso :) em javascript, reforçando assim sua experiência e conhecimento!. aquele abraço

Dirlei Dionísio disse...

Verdade, Pierre, dificilmente sabemos se a solução que escolhemos é a melhor. Acho que o importante é evitarmos a mentalidade "tentativa e erro" de Edison e pensar um pouco antes de escolher uma solução, mesmo quando a única que pode ser implementada é um "bacalhau". Até "bacalhaus" deveriam ser pensados e não acontecerem por acaso.

Valeu pela visita, abraço!

Eric Hideki disse...

Achei sensacional o artigo, cara. A tentativa e erro é fundamental para o nosso aprendizado, até porque através desse erro que foi cometido nunca mais irá se repetir. Me lembro uma vez quando estava criando um sistema de gerenciamento em Visual Basic 6 e estava dando um erro completamente estranho. Levou - se então 2 semanas contendo 4 pessoas analisando o caso (2 estudantes e 2 prof.), o atributo não estava batendo com o que era fornecido, com isso, por um dia um outro professor olhou e disse: O campo está como Integer e você está passando String, mude isso. O que na verdade era o grande problema é que passava o valor com aspas duplas ("", String) ao invés de aspas simples ('', Integer), isso foi em um campo WHERE na SQL.

Até hoje nunca me esqueço, se tivesse olhado direito a documentação, grande parte desse problema seria resolvido.

Texto muito bom, novamente parabéns pelos seus textos.

Dirlei Dionísio disse...

De fato, o lado bom da tentativa e erro é o aprendizado. Não cometer os mesmos erros já é um avanço. O próximo passo é evitar novos erros.

Muito obrigado pelo feedback, Eric! Grande abraço.

Anônimo disse...

Bom que voltou a atualizar o blog! Sou um programador de SP, e tenho o blog nos favoritos a muito tempo, com a esperança de atualizações rs!

Dirlei Dionísio disse...

Legal, Anônimo! Ainda bem que não frustrei suas esperanças :) Se quiser ser notificado quando houver atualizaçoes no blog, você pode se inscrever por email, assinar o feed rss ou me seguir pelo Twitter. Deve ser mais prático do que ter que vir aqui periodicamente pra ver se tem novidade.

Espero não demorar tanto para publicar o próximo artigo aqui (tenho publicado mais no outro blog), mas dependo de conciliar inspiração e tempo, o que não é tão fácil.

Grande abraço!

RAFAEL COSTA TEIXEIRA disse...

Olá Dirlei ,

Já algum tempo acompanho o seu blog , e esta espetacular , pena que demora um pouco para ser atualizado , mas td bem , sei que é por conta do seu tempo disponivel.

Sobre esse post , muitas vezes trabalhando em uma equipe de desenvolvimento de software , temos que programar no estilo Edson , por causa da pressão e dos prazos extremamente curtos para entregar o projeto.

Somente quando o cliente fala que esta muito lento , é que revemos o código para codificar no estilo Tesla.

Ótimo post , continue assim.

Abs.

Anônimo disse...

Dirlei ,

Bom dia !

Estou sempre acompanhando o seu blog , é muito alem dos códigos , como já foi comentado , traz motivação , para os programadores.

Gostaria de compartilhar uma alegria , a 2 anos atras postei no seu post de:

http://maisquebomcodigo.blogspot.com.br/2010/06/5-dicas-para-aproveitar-sua.html

Eu sou aquele @Anonimo que trabalhava como operador de infra-estrutura em uma empresa de informatica , o qual meus superiores eram bem receptivos a novas idéias.

Então.... um dos pequenos aplicativos que desenvolvi , foi muito bem aceito , e logo depois fui indicado para uma vaga de programador jr. , o qual já faz 1 mes e meio que estou nessa nova função , e não parou por aí , ganhei um premio da empresa por esse aplicativo que desenvolvi.
Agora posso dizer que trabalho oficialmente como programador.

Continuarei acompanhando...

Abs.

Dirlei Dionísio disse...

Oi Unknown, acredito que quando os prazos são extremamente curtos é ainda mais importante usarmos a abordagem Tesla para a solução de problemas. Muitas vezes um pouco de raciocínio analítico nos ajuda a encontrar soluções mais simples, o que economiza tempo valioso, como exemplifiquei nesse artigo. É verdade que fazer isso sob pressão não é fácil, mas geralmente o esforço compensa.

Obrigado pelos elogios e continue acompanhando o blog. Grande abraço!

Dirlei Dionísio disse...

Oi Anônimo, meus parabéns pelas suas conquistas! Fiquei muito feliz por saber que seus esforços estão sendo recompensados, obrigado pela notícia. Sucesso na sua nova função! Um abraço.

Unknown disse...

Olá Dirlei, boa tarde.

Você vai fazer mais algum post em breve ? rsrsrs, ou você está escrevendo em outro lugar?

Abraço

Dirlei Dionísio disse...

Oi Andre, o próximo post está aguardando inspiração e tempo. Assim que conseguir isso, quebro o jejum. Mas foi bom saber que há alguém esperando novo artigo :)

Eu tenho postado com mais frequência no meu blog sobre Titanium, já viu?

http://maisquetitanium.blogspot.com

[]s

Generalnuck disse...

Cara, primeiramente lhe parabenizo pelo artigo bacana.
Segundo complemento que, na verdade não é mesclar as 2 formas de pensar como alguns disseram. O modo Tesla é o melhor jeito sempre, porém para homens limitados como nós é impossível agir daquela forma todo o tempo, pois para isso precisaríamos ter uma memória tamanha que só Tesla tinha. Somos muitas vezes obrigados a trabalhar como Edson, pois assim como ele somos HOMENS INFERIORES A TESLA! Admitamos, qualquer um que leia a biografia de Tesla vai saber o monstro cerebral que ele foi. O nível intelectual dele era absurdo, ele não esquecia de nada, tinha memória fotográfica e decorava projetos de máquinas e as dimensões de cada peça.
O que nos resta, é estudar ao máximo para programar como tesla o máximo possível! Porém sempre haverá momentos Edson(Não que isso seja motivo de vergonha, é claro).

Dirlei Dionísio disse...

Oi Generalnuck, valeu pelo feedback!

Eu não tenho certeza se o modo Tesla é o melhor jeito sempre. Há um momentos em que a "transpiração" citada pelo Edison vale mais que a "teoria" do Tesla.

Talvez desafio mais interessante (já que estamos longe de ser como qualquer um dos dois) seja identificar quando é hora de ficar pensando e quando é hora de suar a camisa.

Obrigado pela visita e pelo comentário!

Abraço.