Category Archives: armadilhas

Aventuras de Gulliver - bom livro!

Meu problema com micro-serviços

Micro-serviços em sua essência são mais uma estratégia de componentização e, sinceramente, acho muito difícil criticar qualquer tentativa de se chegar a este objetivo. Gosto muito da estratégia, mas algo “nela” me incomoda bastante. Sabe o quê? A maneira como muitas vezes a vejo ser vendida.

Neste post exponho algumas falácias que vejo repetidas vezes em apresentações e posts. Acredito que seja um esforço fundamental pois a desonestidade intelectual (muitas vezes acidental) dos defensores de qualquer posição comprometem significativamente aqueles que, iludidos, adotam equivocadamente aquilo que lhes foi transmitido. Sendo assim, vamos às falácias.

Uma aplicação monolítica é uma coisa, e uma mal feita, outra

Aplicações monolíticas não são bugs e a prova é a quantidade imensa de casos de sucesso acumulados ao longo da história da computação: temos mais de meio século de experiência em arquiteturas deste tipo. Negar este passado é loucura ou desonestidade intelectual (para dizer o mínimo).

O que esquecem de mencionar aqueles que defendem este ponto de vista  é que sempre há uma medida. Se o sistema for excessivamente extenso, naturalmente este será dividido em unidades fisicamente independentes. Esta divisão ocorrerá de forma evolutiva ou mesmo durante o processo arquitetural.

Reparem que usei a palavra extenso e não complexo. Complexidade independe do tamanho da aplicação e pode ocorrer tanto em pequenas aplicações de linha de comando quanto micro-serviços quanto aplicações monolíticas.

Bons argumentos em defesa de aplicações monolíticas você encontra neste post (leitura obrigatória). Outra leitura muito interessante sobre a estratégia monolítica encontramos neste texto do Chris Richardson, que inclusive expõe alguns pontos negativos.

E, bom: que tal irmos direto pra fonte e citar o Martin Fowler que foi um dos primeiros a escrever sobre o assunto e um dos principais responsáveis pela sua popularização:

não perca tempo considerando micro-serviços, a não ser que você tenha um sistema muito complexo para ser gerenciado como um monolito (tradução minha)

Esta dicotomia monolitos/micro-serviços é em si muito pobre. Sinto muita falta em apresentações de comparativos entre micro-serviços e outras estratégias de componentização que são simplesmente ignoradas.

A falsa novidade

Hoje para mim fica claro que micro-serviços não são uma novidade apesar de serem vendidos como tal. Os vejo como uma visão diferente do SOA. Um excelente texto sobre isto é este do Steve Jones. Também escrevi sobre isto, mas meu texto não é tão bom quanto o dele.

Historicamente é mais uma tentativa de componentização através de computação distribuída. Já vimos isto com o EJB, SOAP, CORBA, RPC, DCOM, OSGi, XDR e tantas outras tecnologias que vieram antes.

Em todas estas abordagens você tinha os pontos abaixo com graus variados de dificuldade na obtenção dos objetivos:

  • Processamento distribuído
  • A tentativa de se ter independência tecnológica (DCOM, EJB e OSGi conseguem isto através de algumas gambiarras estratégais)
  • Estratégias para se lidar com a ausência de um ou mais componentes externos
  • Monitoramento

Talvez a novidade seja o ponto de vista muito influenciado pela emergência da cloud (Larry Elison tinha um ponto de vista interessante sobre a nuvem apesar de muito criticado) que viabiliza economicamente a estratégia.

(quando você estuda a história da computação, novidades vão se tornando cada vez mais raras, e fica muito nítido que esporadicamente nos vendem o velho com um novo nome)

A velha falácia do espantalho

Aqui entra a desonestidade intelectual em sua forma mais pura. São apresentados exemplos absurdos envolvendo arquiteturas monolíticas: coisas que apenas um completo imbecil faria e que não fazem parte do cotidiano de praticamente ninguém.

Alguns exemplos: “usar um servidor de aplicações pesadíssimo para hospedar uma aplicação mínima”, “uma aplicação monolítica contendo altíssimo acoplamento entre seus componentes” (o que  ocorre em sistemas de qualquer escala). Na Wikipedia tem um texto legal sobre isto.

São argumentos que distorcem grotescamente o argumento do outro visando com isto ridicularizar o “oponente” diante dos demais.

Me lembram muito aquelas propagandas exageradas que passam de madrugada na TV, como… estas:

Normalmente desconfio de argumentos que tem como base a presença de alguém que não possua um cérebro fazendo bobagem.

A solução perfeita

Você questiona pelos custos da abordagem (seu lado feio) e simplesmente não obtém resposta. Ou então obtém uma resposta como “na realidade, escrever aplicações monolíticas é que é errado”.

Sério que existe uma solução perfeita e esta se chama micro-serviço? Sério que alguém realmente acredita nisto? Obviamente há custos envolvidos que não podem ser negados: você está lidando com  uma solução distribuída, e todas as dificuldades que envolvem este modelo se manifestam aqui. Quer uma lista rápida? Vamos lá:

  • Latência de rede
  • A possibilidade da falha de uma dependência remota
  • O custo do próprio protocolo que nem sempre é feito para se obter máximo desempenho (HTTP, JSON, XML)
  • A necessidade de um monitoramento mais forte
  • A necessidade de se ter um componente de descoberta de endpoints

E aqui ainda não mencionei os custos relacionados às mudanças culturais que sua equipe deverá passar, ou mesmo das complexidades envolvidas quando se possuí um ambiente tecnologicamente heterogêneo dentro de uma instituição.

Negar os custos é  desonesto. E uma desonestidade maior ainda quando te dizem que estes problemas podem ser minimizados usando-se uma solução que você vende.

Aliás, é mais que desonesto: é irresponsável.

Uma visão muito ingênua de escalabilidade

Você realmente acredita que basta incluir mais instâncias do seu micro-serviço para que ele escale? Escalabilidade vai muito além disto. Envolve arquitetura, boa qualidade de código, boas estratégias de otimização.

Escalabilidade vertical é realmente tão limitada assim? Qual o contexto? É curioso: esta palavra essencial, contexto, simplesmente não é mencionada. Por falar nisto…

A ausência de contextos

Nunca vi uma estratégia que, em si, seja ruim. Agora: uma estratégia no contexto errado, sim. Algo que sempre me surpreende em apresentações ruins sobre micro-serviços é o quão negligenciado este ponto é.

Se seu cliente possuí uma forte limitação de infraestrutura, será que micro-serviços realmente são uma boa opção? E se sua equipe não se adequa à aplicação dos micro-serviços? Sua equipe que é ruim ou você que é um tirano?

Se não me mostrar o contexto, a conversa acaba ali. É simples assim e não há muito o que dizer a este respeito.

Concluindo

Micro-serviços são uma estratégia interessantíssima, mas infelizmente correm o risco de serem vistos em breve como uma falácia devido ao modo como é descrita. Este post é quase uma continuação de algo que escrevi recentemente sobre palestrantes e acredito que seja um bom exemplo do que quis dizer naquele momento.

Caso se interesse pelo que penso sobre micro-serviços, tenho dois posts neste blog sobre o assunto que podem ser lidos aqui e aqui.

amigo-da-onca

Como aproveitar ao máximo um palestrante

Então você está assistindo a uma apresentação em um evento ou um consultor está na sua empresa mostrando algo que pode tornar sua vida melhor. Terminada a palestra, em uma conversa entre colegas você critica o conteúdo ministrado e obtém como resposta algo como o clássico “quem é você para criticar fulano?”.

Ou então algo ainda mais interessante: a apresentação lhe deu um novo ânimo pois agora sabe que seus problemas acabaram! Você quer aplicar aquele conteúdo em sua vida e no dia seguinte começa a luta. Tudo nos primeiros momentos vai maravilhosamente bem, mas logo você nota que as rosas que lhe venderam possuem mais espinhos do que lhe contaram.

Sou consultor e de vez em quando palestro em eventos ou empresas. Como consultor estou cansado de ver pessoas tendo prejuízos monstruosos devido a algo que foi mal compreendido ou dito em uma apresentação. Como palestrante sempre temo que o que digo gere muito prejuízo a quem me ouviu falar (e creio que todos os palestrantes deveriam ter esta preocupação).

Neste post lhe darei algumas dicas para não cair nestas armadilhas. Como tirar máximo proveito do palestrante, aquela pessoa que aparenta ser tão mais carismática que nós?

Termos fundamentais

Este post gira em torno de dois conceitos que considero fundamentais quando vou avaliar qualquer palestra.

Responsabilidade e irresponsabilidade

amigo-da-onca

Simples e direto: responsável é aquele que será procurado após suas ações serem executadas, tendo estas sido bem sucedidas ou não. Já o irresponsável executa suas tarefas e parte.

Na esmagadora maioria das vezes o palestrante expõe o tópico e sai. Ele irá embora, mas a impressão permanece nos ouvintes. O expectador é o maior responsável pelo que faz com o conhecimento transmitido.

Arrogância

miniature-pinscher

No livro “Direita e Esquerda”, Norberto Bobbio dá a melhor definição do conceito que conheço: é “a confiança excessiva nas próprias habilidades”.

Eu e você já fomos arrogantes ao menos uma vez. Um esforço honesto de memória nos exporá situações nas quais realmente acreditávamos conhecer um assunto e transparecemos isto a alguém, para depois descobrirmos que não eramos tão bons assim naquilo.

Quem está falando?

who_is_talkingA pessoa é mais que um nome, e a pesquisa a respeito do passado do palestrante é um excelente detector de arrogância. Tudo bem que existem exceções, mas como levar a sério alguém que se apresenta para falar de um assunto, por exemplo, desenvolvimento de software e se apresenta assim?

Fulano Simpático é profundo conhecedor do assunto X e possuí três anos de experiência como desenvolvedor

Você busca o currículo da pessoa e descobre que destes três anos, um foi como estagiário, dois em apenas uma empresa e que o assunto X tem pelo menos 15 anos de existência. Se a apresentação for algo como a exposição da sua experiência, talvez seja interessantíssimo: é fascinante ver as dificuldades enfrentadas por iniciantes, mas se for uma aula detalhada sobre o assunto… desconfie: a genialidade infelizmente não é um artigo popular no Universo.

Havendo tempo, uma busca rápida pelo LinkedIn, blog, artigos publicados ou coisa similar já expõe bem a natureza do palestrante. Este é o primeiro passo: detecte a possível arrogância do sujeito. (redes sociais como Facebook não contam: é lugar de se postar trolagem (o meu pelo menos é)).

Experiência não é tudo: o mínimo de consistência também é importante. Se um dia a pessoa fala sobre X, em outro sobre Y, depois sobre Z, A, D, H, E, J  e os assuntos são distantes uns do outros, vejo algumas opções:

  • Estou diante de um especialista em porra nenhuma
  • É alguém que curte novidades e divulgá-las (e isto é positivo, desde que não se venda como profundo conhecedor dos assuntos tratados)
  • Dificilmente a pessoa teve tempo para trabalhar efetivamente com os assuntos tratados na prática

Mas conhecer melhor o passado do palestrante te traz outra vantagem: te ajuda a fazer melhores perguntas. Entenda: ninguém conhece a totalidade de um assunto, pois todo conhecimento é definido pelo contexto em que o sujeito se encontra. Se você me perguntar como se deve aplicar Groovy e Grails no processamento de Urânio não vou saber te responder.

E sabe qual a vantagem de boas perguntas? Elas te dão um monte de conteúdo. 

E o lado feio?

duascaras

Você vê a solução e ela parece linda. Mas não tem nenhum porém, nenhum lado feio, nenhuma limitação??? Na minha opinião esta é a pergunta mais importante: quanto custa?

Nos últimos anos a ausência desta pergunta gerou prejuízos imensos que pude ver em primeira mão. Seguem dois exemplos:

  • Equipes que abandonaram completamente o modelo relacional e abraçaram alguma solução NoSQL, como MongoDB, para depois perceberem que coisas “bobas” como integridade referencial não são algo “careta e ultrapassado”.
  • Empresas que realmente acreditaram que seria possível reduzir a complexidade dos seus sistemas adotando micro-serviços que se pegam em uma situação BEM pior que a anterior por que não se falou muito a respeito dos custos envolvidos.

Quando o palestrante não fala muito a respeito dos trade-offs, isto não quer dizer que a pessoa é má intencionada: está apenas apresentando seu aspecto irresponsável e talvez arrogante. Terminada a apresentação, a bola está com você.

Normalmente a pessoa está tão enamorada pelo assunto apresentado que não consegue ver suas limitações: qualquer um que já tenha se apaixonado sabe do que estou falando.

(dica: se o palestrante tem um slide mostrando os custos da tecnologia e o expõe rapidamente, peça para que fale mais a respeito do assunto ;) )

Desconfie do carisma/”atitude”

poison

Já reparou que na natureza as coisas muito coloridas (como a flor acima) normalmente são armadilhas? Numa palestra o que realmente interessa é o conteúdo, mas há aqueles palestrantes que são simplesmente excessivamente carismáticos.

São pessoas divertidas, simpáticas, engraçadas, bem articuladas. Ou então podem possuir aquela postura mais radical, quase agressiva. Aquele sujeito “adoravelmente desagradável” que conquista a sua simpatia. É difícil vencer esta tentação. Todo mundo quer ser como aquela pessoa, e se ela diz algo, deve ser o correto, certo? Certo?

dr_house

Minha dica? Dou tempo ao tempo. Tento resistir ao carisma e prestar atenção no conteúdo. Espero passar um mês e tento me lembrar do conteúdo. O que mais me impressionou? O palestrante ou o conteúdo?

(nos meus 36 anos fica claro para mim que a maior parte das pessoas que me influenciaram eram na realidade tolos carismáticos (e esta descoberta não foi decepcionante, mas sim um alívio))

Pergunte (não precisa ser na hora)

Eu sei que fazer uma pergunta em público pode dar uma vergonha danada. Talvez você fique com medo de dizer alguma bobagem na frente de todos e isto muitas vezes te cala. Mas quem disse que a pergunta precisa ser feita durante a palestra?

Todo palestrante expõe seus dados de contato. Se acha que não é interessante perguntar naquele momento, faça como eu: anote todas as suas dúvidas e em seguida lhe envie um e-mail. Nunca encontrei alguém que não me respondesse, por mais importante que fosse.

Estude antes da apresentação

Quando vou a uma palestra que realmente me interessa costumo estudar um pouco sobre o assunto antes do evento. Isto me ajuda bastante a fazer melhores perguntas e na compreensão do que vai ser exposto.

Não precisa ser um estudo profundo: muitas vezes uma leitura de 20 minutos antes do evento já é suficiente pra te contextualizar.

Peça pelas fontes

Dificilmente todo o conteúdo apresentado foi criado pelo palestrante. Pra tirar máximo proveito do que foi exposto sempre peça as fontes usadas na apresentação. Muitas vezes o que mais aproveito em uma palestra é justamente a bibliografia!

É uma oportunidade excelente de entrar em contato com textos que dificilmente você ouviria a respeito se não tivesse participado do evento. Se o autor não expor suas fontes, apenas pergunte por alguma sugestão de leitura.

Lembre que a bibliografia nem sempre é explícita, mas sempre está presente. Basta prestar atenção nos nomes citados durante a palestra.

Existe mais de uma realidade

infinitas_terras

Conhecer o passado do palestrante traz outra vantagem: você passa a entender sua realidade, que sempre é distinta da sua, e este é um ponto importantíssimo.

Muitas vezes o palestrante é criticado por que o ouvinte não consegue por em prática aquilo que foi exposto. Uma razão comum (quando bobagens não foram ditas) é o fato de estarem em realidades diferentes. Exemplo clássico: alguém que trabalhe em uma empresa gigantesca falando sobre sua infraestrutura de servidores. É uma realidade restrita, dado que a esmagadora maioria dos ouvintes comemora e muito se tiver mais de um (mesmo com a cloud).

Então para tirar máximo proveito do que foi exposto é fundamental a contextualização. O que está sendo apresentado funciona (ou não) dentro do contexto do palestrante. É sua responsabilidade portanto, se quiser aplicar o que viu, adaptar (se possível) o que foi exposto para a sua realidade.

Seja crítico e valorize suas próprias experiências

Não é raro estar em uma palestra e presenciar o palestrante desdenhar um conjunto de conhecimentos que fazem parte do seu dia a dia. Neste momento você deve se fazer o seguinte questionamento: se é tão ruim assim, por que têm funcionado para nós?

Esta é uma pergunta importantíssima. Já cansei de ver o clássico momento “Java sucks, use X que é melhor”. Se não for apresentada uma excelente justificativa para a troca, pulo fora na hora.

Não estou dizendo para você ser um reacionário: apenas para não desvalorizar os conhecimentos que já tem. Não é o fato do outro estar com o microfone na mão que o torna o dono da verdade.

Concluindo

Palestras e eventos são uma fonte praticamente infinita de riqueza intelectual quando bem aproveitados e de prejuízos imensuráveis se o ouvinte não adotar uma postura ativa, questionadora e crítica.

Ter uma postura crítica diante de uma apresentação não deve ser visto como uma postura negativa, mas sim como a tentativa de se extrair o máximo possível de eventos cuja finalidade é nos formar.

Então você é o legado?

O que é legado?

Santo Agostinho, que de santo mesmo tinha muito pouco.

Dica: você sempre encontrará frases divertidas em Santo Agostinho

De uns tempos para cá tenho notado que cada vez mais pessoas falando sobre “software legado”. E sabem o que acho mais interessante? Elas caem em uma situação parecida com a que Santo Agostinho enfrentou ao falar sobre o tempo.

“Que é, pois o tempo? Se ninguém me pergunta, eu sei; se quero explicá-lo a quem me pede, não sei.” – Santo Agostinho

Troque a palavra “tempo” por “sistema/software legado” e faça uma auto crítica. Se eu te perguntar o que é software legado você vai saber me responder de forma clara e imediata? Já falei aqui como lido com legado, mas nunca apontei uma definição para este. Neste post faço isto,  mas antes vou mostrar algumas definições faláciosas.

“Todo software que você escreve depois de um tempo vira legado, assim como todo aquele que não foi escrito por você.”

Esta definição é um contra-senso e dá pra provar com lógica pura, quer ver? Se digo que um software é legado, a palavra “legado” denota uma categoria (ou conjunto) no qual alguns softwares se encaixem e outros não. Legado é adjetivo. Se é adjetivo, diferencia, se diferencia, deve haver algo que não seja legado.

Se tudo é legado, não há diferenciação, portanto não há legado. O software que você está escrevendo não é legado pois ainda não foi para produção e para o cliente sequer existe de fato, então cairia fora desta definição, mas aí entra aquela outra que também é furada.

“Se foi para a produção virou legado!”

Também não se aplica, a primeira versão do seu sistema, a qual você possui completo controle sobre o código fonte e arquitetura, que está brilhando de lindo pode ser chamado de legado? Sabemos que não. É apenas uma variação da primeira definição que mostrei.

“Legado é todo aquele software que precisa ser substituído por ser obsoleto ou não servir mais!”

Também não. Este software não é legado, mas sim inadequado ao contexto em que se encontra. Entra aí o conceito de obsoleto. Em que sentido obsoleto? Regras de negócio que não se aplicam mais? Uma plataforma de desenvolvimento que NINGUÉM no MULTIVERSO conheça?

A história do ambiente de desenvolvimento críptico também é furada. Ok, você pode ter dificuldade em encontrar mão de obra especializada, mas nada além do custo (que nem sempre é tão exorbitante assim quanto nos vendem) impede que você treine ou aprenda aquele ambiente também antes né? (sempre me soa a preguiça)

“Código legado é código sem testes.” – Michael C. Feathers

Sim, eu li o livro

Sim, eu li o livro

Desconfio que esta falação toda em cima de código legado é motivada pelo livro do Michael C. Feathers que o Robert Martin tem divulgado bastante atualmente. Neste livro há uma definição bem interessante: “código legado é código sem testes”.

Em uma primeira análise é uma boa definição: se o código não tem testes você não sabe explícitamente o que ele faz, logo não há controle sobre ele. Você não sabe se vai quebrá-lo quando for implementar uma nova funcionalidade ou mudança.

O problema desta definição é o escopo: apenas o programador (e talvez o arquiteto). Para o programador código legado é aquele que considera ruim o que, normalmente não passa de uma questão de ego (Fabio Akita tem um texto excelente sobre isto) e ignorância a respeito do contexto que gerou aquele sistema. É simplesmente não ter uma resposta honesta para a pergunta “o sistema deveria ser deste modo por que eu quero ou por que realmente é uma necessidade?”.

(Sobre o livro, bom: me decepcionou pois é mais um livro de refactoring do que sobre arquitetura na minha opinião. Um dia ainda escrevo um review sobre ele. Resumindo: micro demais e macro de menos, mas mesmo assim recomendo a leitura.)

wizardofoz1

Então você é o legado?

O que é um sistema legado?

Sistema legado é aquele cujo controle foi perdido por seus principais stakeholders. – Definição Lobo Weissmanniana

Software legado tem valor e prova disto está no fato de ser usado. Ignorar isto é menosprezar seu cliente e divulgar aos sete ventos sua própria arrogância e cegueira.

Software legado é aquele cujo controle sobre sua evolução foi perdido pelos principais interessados. E ei: o principal interessado não é o programador ou a equipe de desenvolvimento, mas quem o financiou e os usuários finais. Minha diferença em relação a Feathers é o foco: o dele é a equipe de desenvolvimento, o meu o usuário final.

Testes são importantes? Não, são vitais pois garantem a malha de segurança para a equipe de desenvolvimento e tudo o mais que todos nós, desenvolvedores, já estamos cançados de saber. No entanto para quem financia são na prática apenas um dialeto desconhecido. No que diz respeito à proximidade dos testes com o cliente final o mais próximo que iremos ter é o BDD mas, convenhamos, o usuário executivo não se interessa tanto assim por eles quanto se interessa pelo sistema final NO MUNDO REAL.

Quão “antiga” é a plataforma de desenvolvimento também não fazem um sistema legado. Prova disto é a imensidão de sistemas feitos em Ruby on Rails, Grails, Spring, .net e outros feitos às pressas como “MVP” que deixam seus patrocinadores desesperados com uma quantidade imensa de bugs a serem resolvidos e evoluções caríssimas. Em contrapartida, temos um verdadeiro universo de sistemas feitos em COBOL, FORTRAN, DELPHI e VB cujas instituições financeiras possuem completo controle sobre si e não podem ser considerados como legado. A diferença entre um e outro? Controle.

Quando evoluo um sistema legado o objetivo final é simples: devolver o controle a quem interessa. Mas como se perde este controle? De imediato as seguintes causas me vêem à mente:

  • Perda de contato com a equipe responsável pelo desenvolvimento do sistema.
  • Complexidade ingerenciada: você mantém a equipe mas esta perdeu o controle sobre a complexidade do sistema devido a problemas arquiteturais.
  • Perda do próprio conhecimento do sistema decorrente de ausência de documentação ou alta rotatividade dos stakeholders envolvidos na confecção original.
  • Aparente perda de controle: sinistro mas já vi acontecer. Ocorre quando alguém diz que o sistema é ruim apenas para justificar sua reescrita sem apresentar fatos concretos. (muito comum, especialmente quando você está buscando consultorias no mercado para evoluir seu legado)
  • Perda do código fonte.
  • Ou qualquer outra ausência do elo que ligava você à idéia original que gerou aquele sistema.

Entenda: simplesmente refatorar uma base de código não restaura o controle ao stakeholder pois ele nos paga essencialmente para não ter de se preocupar com isto. Para o investidor ter novas funcionalidades ou evoluções e adaptações implementadas em um prazo e custo aceitável, em um todo que seja compreensível, isto sim é ter controle sobre um sistema. ISTO é evoluir um legado, ou melhor, atualizar um sistema.

(Sabe aquele sistema que “não serve mais” ou é “obsoleto”? Quando é verdade, você tem controle sobre ele, pois sabe que não mais se aplica. Por isto não considero legado. Nestas situações há consciência de que deve haver um descarte. O máximo de descontrole que pode haver neste caso são pessoas que ainda o usam.)

Concluindo

É sempre a questão de uma boa definição. Claro que outras definições existem e podem até ser melhor que a minha, no entanto o que observo é que raríssimas vezes vejo a palavra chave fundamental, controle, ser aplicada. Se você domina um sistema, não há problema, você sabe como ele pode e deve evoluir. De resto, é o mito do legado como bem descrito no blog do Fabio Akita que citei acima.

PS: uma definição alternativa poderia ser “o que separa o desenvolvedor infantil do aduto”, mas achei que poderia soar um pouco agressiva.

Nota – 7/5/2016

Hoje vejo que minha definição de legado na realidade não o define, mas sim o problema principal que envolve o conceito.

E também vejo que o termo legado sequer deveria ser usado. Explico as razões neste post.

chaplin_tempos_modernos

Produtividade pra que, quem e como?

Diversas vezes caio nestas conversas em que a palavra produtividade pula como pipoca. Terminado o diálogo me afasto das pessoas, relembro o que dissemos e fico com a certeza de que só falamos bobagem. Por que?

O que é produtividade afinal?

Se você trabalha com desenvolvimento de sistemas ou qualquer outra atividade que envolva a geração de algum produto o termo produtividade sempre surge em conversas com gestores ou colegas ao tratarmos o modo como executamos nossas tarefas. E sabem o que é mais interessante? Não é raro vermos alguém sair chateado destas conversas. Quem é esta danada? Da forma mais ingênua possível, poderíamos defini-la como

Quanto você produz em determinado período de tempo.

Quantas linhas de código, funcionalidades, casos de uso, módulos, textos, imagens você produz por dia? Será que você consegue superar sua média? Existe uma meta em nosso ambiente de trabalho: será que você vai conseguir batê-la nesta sprint?

Percebem algo errado em todas estas perguntas e na própria definição? Eu sim: são vazias. Por que vazias? Por que raríssimas vezes tem um contexto. Não existe produtividade, mas produtividades.

As produtividades

Existe ferramenta de mais alta produtividade que o velho copiar e colar? Precisamos criar uma série de páginas, o tempo é mínimo, seu aperto máximo, sua mente em transe te diz para copiar e colar diversos trechos de código HTML e JavaScript em todas aquelas páginas. Você não pensa, age! O relógio, assim como você, não para: ctrl-c pra cá, ctrl-v pra lá, executa aqui, executa ali e voilá: as páginas estão prontas no prazo e você conseguiu! Algum gestor passa por você e te encara com satisfação naquele momento de cumplicidade efêmera.

Aquele dia foi de imensa produtividade, mas sempre a criatura volta para visitar seus pais cobrando as falhas de sua formação. E de repente o criador se vê sofrendo buscando tratar os traumas de sua criatura. Você fica horas (quando não dias ou meses) pagando o preço da sua economia porca.

A criatura sempre volta

A criatura sempre volta

No nosso amigo copiar e colar vemos um tipo específico de produtividade: a de curtíssimo prazo. É possível ter altíssima produtividade a curto prazo de tal modo que nossa criatura, ao visitar-nos, traga boas notícias? Sim, mas são raras estas situações.

Há também aquela outra ferramenta interessante que nos permite uma produtividade média a curto prazo (para a aflição dos gestores ansiosos) que nos propicia entregar bem próximo do prazo o que nos foi proposto fazer: se chama “pensar com calma”. A usamos quando projetamos aquilo que desejamos obter. Por algum tempo nossa criatura não irá se mostrar de forma concreta, e dependendo de quão rico é o seu conhecimento a respeito do problema, pode ser que o prazo não seja cumprido.

A diferença é que sua criatura é melhor formada: as cicatrizes quando existem são mais discretas e fáceis de serem corrigidas. Seu cliente pode estar até chateado devido ao leve atraso, mas ele a vê funcionando e, ainda mais legal, você sente orgulho da sua criatura e  mostra suas entranhas para seus colegas!

A criatura sempre volta

A criatura sempre volta

Todos sabemos que a maior parte da vida de um software ocorre após este ter sido entregue (em média 85% do tempo é gasto em manutenção). Aquele seu custo inicial transforma-se em lucro. Sua produtividade agora é altíssima na época que mais importa: manutenção.

Há uma balança aqui: alta produtividade no início, baixa no fim e vice-versa. Claro: quando você reaproveita conhecimento é possível ter altíssima produtividade durante todo o ciclo de vida do seu sistema, mas infelizmente estas situações são muito raras (ainda).

Kico: aonde você quer chegar com este papo?

Produtividade e valor. O que é valor?

enso

Este é o ponto fundamental deste post. O termo produtividade só possuí sentido quando pensado como valor. “Valor” é outra destas palavras que usamos em vão. Algum tempo atrás passei a buscar seu real significado e isto mudou radicalmente (e de forma muito positiva) minha visão do mundo. Segue sua definição:

Valor é a justificativa por trás da escolha.

Por que você diz que seu Macintosh vale mais que um PC? Por que pagar mais pelo produto ou profissional X? Quanto vale Y? Produtividade por que? Pra quem? O que quero com isto?

Você comprou um Mac talvez por que considere uma máquina melhor montada, com excelentes componentes e um sistema operacional superior que não irá estragar tanto quanto o oferecido pela concorrência. Você pagou a mais pelo profissional X por que sabe que ele lhe entregará um resultado positivo dentro dos seus padrões e expectativas de qualidade. Estas razões são justificativas. Valorizar é apresentar justificativas para uma escolha. O tal do valor agregado? Um conjunto de justificativas a mais que mostrem que você estava certo.

Quando tratamos produtividade como valor a história muda. Aqui seguem dois exemplos baseados nas situações que falei acima:

  • Pode usar e abusar do copiar e colar, pois o que você está fazendo será usado uma única vez para em seguida ser jogado fora e não temos dinheiro o suficiente para algo melhor elaborado. (uma justificativa tosca, mas uma justificativa!)
  • Invista na arquitetura do seu sistema o máximo que puder pois queremos algo que durará 10, 15 anos e sabemos que 85% deste tempo será gasto em manutenção.

Percebe agora por que aquela conversa com seu gestor sobre produtividade te incomodava? Este é o tal do “contexto” que falei acima: as justificativas necessárias para que lhe seja cobrado determinado nível de produtividade.

Ainda mais importante: para quem você está sendo produtivo? Será que todos os seus clientes exigem o mesmo nível de produtividade? Esta questão deixo como dever de casa para você.

Produtividade e ferramentas

toolbox

Ouvimos muito o termo produtividade quando o assunto é ferramental. “Programadores .net geram X pontos de função por hora, enquanto profissionais Java Y”. Sério? Em quais contextos e restrições? Entende agora por que estas métricas normalmente não fazem sentido?

É aquela velha história da ferramenta certa para o trabalho certo. Programadores Java escrevem X linhas de código por hora. Me pergunto quanto produzirão caso precisem escrever algo de baixíssimo nível. Será que se aplica? Acho que o cara do Assembler ganha hein?

E tem também toda aquela história sobre o mito da bala de prata que o Fred Brooks fala com absoluta autoridade no “Mythical Man Month”. O que é uma ferramenta valiosa?

É aquela que você adota em um dado contexto e se sente seguro com sua escolha por ter se baseado em um número significativo de justificativas. Dica: uma justificativa isolada não é suficiente para adotar um framework/linguagem/etc. E se a justificativa for apenas preferências pessoais… abre o olho!

Conclusões

A mensagem é simples: não existe produtividade em si. O termo produtividade só faz sentido com base em uma série de justificativas que, na prática, serão as restrições do seu problema.

E a produtividade? Em si é outro valor. Você a usará como um dos parâmetros para delinear seu caminho. Ela te responderá coisas do tipo: “este projeto é viável no prazo que recebi pois minha produtividade, baseada nestas justificativas, é X”.

Uma justificativa, baseada em justificativas: uma meta-justificativa. :)

cubo_vazado

Existe código bonito?

Mudei tudo por que achei que estava muito feio

Inúmeras vezes ouvi esta frase para em seguida me questionar: o que é ser bonito? Em 2004 meu plano de vida era fazer mestrado na área de Estética (Filosofia, não Cosmética). Foi uma decisão que não se concretizou, mas o problema fundamental – a essência do belo – nunca me abandonou. Este é  mais um daqueles posts nos quais penso o modo  como usamos as palavras. :)

Código é arte ou apenas desejamos que seja?

Quando uso termos como “belo”  ou “feio” falamos sobre o que agrada ou não. O que é o (des)agradável? Esta é a questão fundamental da Estética, e há uma área de imensa subjetividade neste território: como o assunto é software, uma armadilha se arma diante de nós.

O que é arte? Quando a questão estética emerge a primeira coisa que pensamos é em arte pois é a maneira mais direta em que a questão estética se manifesta. Pensamos em pinturas, esculturas, filmes, poemas, músicas…  No livro “Arte é o que eu e você chamamos Arte” do Frederico Morais há 801 definições para o termo “Arte”. Com tantas definições, podemos pensar em alguns aspectos que sempre aparecem:

  • Há a criação de um produto: pintura, escultura, música… código?
  • Há uma atividade artesanal.
  • Há criatividade de alguma forma (bastante polêmico este ponto)
  • Há uma pessoa que gera o produto, o “artista”

E ao pensarmos no artista, nos vêm diversas imagens à cabeça: um pintor, escultor, músico, cantor, ator, escritor e tantas outras atividades que pensamos estar diretamente relacionadas à criação. São aquelas pessoas que acabam se tornando de uma forma ou outra nossos ídolos. Talvez por isto haja este esforço em tentar aproximar código de arte: queremos ser ídolos também.

O melhor livro que conheço sobre História da Arte

O melhor livro que conheço sobre História da Arte

Esta visão do artista, no entanto, é preponderantemente a que temos formada no século XX (e final do XIX). Dado que há um trabalho artesanal, há um outro tipo de artista que poucas vezes vejo ser mencionado: o relojoeiro (ou engenheiro, mas vou focar no relojoeiro). Este, para mim, é aquele que mais se aproxima do programador/desenvolvedor (ou o nome da moda que você quiser).

Excelente livro de Frederico Morais sobre a definição de arte

801 definições de arte que Frederico Morais compilou

A imagem do relojoeiro não soa excitante o suficiente para muitos, talvez por isto não se fale tanto a seu respeito como um artista, mas gosto dela pois me trás aquilo que agrada tanto quem compra meu software como quem o manipula: o objeto complexo, artesanal, preciso, difícil de ser feito e que requer paciência infinita. A mesma coisa se aplica à pintura, mas com uma diferença: o relógio precisa atender à risca o requisito de mostrar o tempo com precisão. Há subjetividade, mas o aspecto objetivo grita mais.

(o aspecto pintor é também fundamental. Recomendo a leitura do texto Hackers and Painters de Paul Graham : http://www.paulgraham.com/hpt html)

Aqui está como tornar a coisa um pouco mais excitante para vocês: já ouviu falar em Jaquet Droz? No vídeo abaixo você pode ver um dos seus trabalhos. Mais de 6000 partes interagindo entre si, programaticamente, em 1774. Muito similar ao que você faz hoje com seu código.

Então, sim: há um aspecto artístico no código. É uma atividade criativa (com limitações que falarei a seguir), há um produto (o software), é artesanal (sempre é diferente) e uma pessoa, o “artista” está por trás daquela criação. Mas o que torna o código belo?

O que torna o código belo?

Após anos lendo sobre Estética fica claro para mim o que é belo (sou arrogante). Segue a definição Kiconiana Espartana de belo:

Belo é aquilo que atende a um ou mais requisitos de alguém e com isto o agrada.

Ok, então qual a definição Kiconiana de código bonito?

Código bonito é aquele que funciona e sua equipe consegue entender

O requisito a ser atendido é funcionar: quando faz exatamente aquilo que foi proposto. Neste ponto o código é quase bonito. Se funcionar consumindo o mínimo de recursos computacionais e executando da forma mais rápida possível sem incluir bugs, tá bonitinho (feio arrumadinho).

O alguém é sua equipe. A coisa vai ser bonita mesmo apenas quando sua equipe (não só você)  conseguir entender claramente o funcionamento da sua criatura. Aqui entra o limite criativo do código: se for inteligível por apenas um, estamos lidando com um risco, e não um produto. Risco por que você não terá outra pessoa capaz de evoluir aquele objeto com a saída do seu criador.

Se houver uma discussão em sua equipe do tipo: “olha: eu faço de uma maneira e você de outra, gosto não se discute”, já sabe: a situação foi pro pior lado possível do problema estético que é o estritamente subjetivo. Seu objetivo que é criar um objeto com finalidade bem definida se perdeu, e seu código, por mais belo que cada tolo acredite ser, para o resto da equipe não passa de uma horrorosa aberração.

Sendo assim, você só pode dizer que “mudou a coisa toda por que tava achando muito feia” quando os requisitos acima tiverem sido satisfeitos. Na realidade, você sequer pode dizer “eu acho”, pois o bom profissional (de software) não “acha”, ele é pago para oferecer seu parecer técnico e soluções acerca dos problemas que enfrenta.

PS: dicas de leitura

Este assunto é um ramo extenso da Estética: a “beleza das máquinas”. Você vai encontrar muitos livros bacanas a respeito, mas neste post vou indicar apenas dois.

a_beleza_das_maquinas

“A Beleza das Máquinas” de David Gelernter: é sobre de que maneira o conceito de belo se manifesta em produtos industrais. Você irá ver exemplos que vão do telefone ao desktop do Macintosh. Leitura excelente.

cultura_da_interface

“Cultura da Interface”, de Steven Johnson: uma leitura excelente sobre o modo como elementos culturais e estéticos se manifestam na interface dos sistemas que usamos.

piratas

Eu e algumas justificativas para piratear livros

Acho que foi segunda feira que vi meu nome sendo citado no Facebook em uma frase mais ou menos assim: “é uma sacanagem o que você está fazendo com o Henrique Lobo Weissmann (…)”. Cliquei no link para ver do que se tratava e isto deu início a uma experiência deprimente.

Um post em um grupo bastante conhecido de desenvolvedores web no Facebook em que um sujeito postava um link para o site mega.com. Acessando o site estavam presentes diversos livros (incluindo o meu). Primeiro li os comentários, diversas pessoas agradecendo o sujeito pelo seu feito (frases como “CARA, EU TE AMO!”) e o sujeito respondendo a quem o criticava ironicamente dizendo que “só queria ajudar :)”. Até aí nada de surpreendente: tolos e suas tolices.

O surpreendente (ao menos pra mim) veio na sequência quando resolvi baixar o meu próprio livro daquela lista. No rodapé de cada página é impresso o nome de quem o comprou. Não estava lá. Na mesma lista vi outros livros que possuo cópia legal. A mesma coisa. Da trabalho fazer isto: alguém gastou seu tempo removendo as marcas d’água daqueles documentos para em seguida disponibilizá-los na Internet. Trabalho de programador: colega de profissão ferrando colega de profissão. E provavelmente o tempo que o sujeito gastou fazendo isto saiu mais caro que o preço do livro: o meu custa R$ 29,00. Chamo isto de vandalismo.

Este fato sozinho já é suficientemente deprimente. O que veio depois é ainda pior: resolvi postar no mesmo grupo um texto mais ou menos assim: “Seguinte pessoal, vi aqui meu livro, junto com outros, ser pirateado. Sei que é algo que parece normal para muitos de vocês, mas aqui está minha opinião sobre o assunto. Leiam este texto que escrevi (link)”. De início vieram as pessoas se solidarizar e tal (o que se espera). Logo em seguida veio uma série de argumentos pró-pirataria. Não satisfeitos, alguns inclusive vieram com ataques a mim por Facebook, etc.

Até aquele momento pra mim parecia óbvio que piratear livro digital é errado (e pela nossa constituição é inclusive crime). Hoje vejo que não é. Sendo assim, neste post vou responder a uma série de argumentos que li.

Por que vou fazer isto

Eu poderia simplesmente me calar (como a maior parte das pessoas), mas acredito que no caso acima, mais que um crime, é uma questão de respeito. Assim como o Fernando Vieria muito bem disse em seu blog, quando pirateiam um trabalho meu, não é “apenas um livro”: aquele trabalho sou eu.

Se é estipulado o modo como o acesso aquele trabalho é feito (por pior que pareça), e este é transgredido, estão invadindo meu espaço sem autorização, ou seja, estão me desrespeitando. E mais ainda e acima de tudo: como já disse antes, isto apenas ferra o nosso país e nossa profissão.

E o papo de que “não adianta fazer nada” é falso. Sim, eu posso: se falo a respeito, ajudo a mudar esta cultura. E ei: um dos tolos que me pirateou (espalhando para outros grupos) talvez tenha sido até mesmo honesto ao me mandar esta mensagem:

Da coceira pra liberar o nome deste aqui.

Da coceira pra liberar o nome deste aqui.

Minha linha argumentativa

Vou usar o princípio da Navalha de Occam. Resumindo, é o seguinte: se começou a enrolar ou dar voltas demais é por que tá errado de alguma maneira. Se consegue ser descrito de forma sucinta é por que a probabilidade de estar correto é enorme.

Se foi estipulada uma forma de se obter meu trabalho, esta se encontra de acordo com a lei vigente em meu país (Brasil), não causa dano a ninguém e esta foi burlada de alguma forma, então a lei foi quebrada e o desrespeito afirmado à minha pessoa e a dos envolvidos na produção daquele trabalho.

O argumento da hipocrisia

“Quem é o autor para nos dizer que não podemos pirateá-lo? Afinal de contas, aposto que ele também já pirateou alguma coisa na vida!”

Contra argumentação

Um erro não justifica outro e um alheio não justifica os meus.

Consequências do argumento da hipocrisia

O objeto está a venda, se você o obtém por meios ilícitos, sim: está cometendo um crime. Levando este argumento ao extremo, um ladrão jamais poderia dizer que roubar é errado. Pior ainda: todos os crimes passam a ser válidos, uma vez que sempre há alguém que os comete e consegue sair impune. Segundo este argumento eu também posso roubar por que tenho direito à minha parcela de impunidade. Não faz sentido.

O argumento dos melhores modelos de comercialização ou obtenção de ganhos

“Você poderia alugar ou dar de graça ou (imagine sua opção aqui) e obter ganhos de formas muito melhores do que cobrando pelo seu trabalho. Veja a empresa épsilon, por exemplo, é um caso fascinante que funciona e gera lucro para seus participantes.”

Contra argumento

Ninguém tem o direito de me impor outro modelo de atuação gerando danos a mim ou ao meu trabalho.

Consequências do argumento dos melhores modelos de comercialização

Sempre haverá modelos alternativos, no entanto é inegável que o modelo de venda simples também funciona. Há o problema da pirataria? Com certeza. Quer uma prova interessante de que funciona? Meu primeiro livro caminha para as 2000 cópias vendidas: destas, bem mais de 90% são digitais e não físicas.

E sabe aquele papo de que caminhamos para uma “economia das coisas gratuitas”? Ainda não aconteceu. Pode até ter indícios, mas as pessoas ainda querem ser pagas pelo seu trabalho.

O argumento da editora exploradora

“Pirateio mesmo pois sei que a maior parte dos lucros vai para a editora e não para o autor!”

Contra argumentos

A maior parte do dinheiro precisa ir para a editora pois esta cuida de uma série de fatores como logística, diagramação, editoração, revisão, gestão, apoio ao escritor, salário dos funcionários e diversos outros custos que o autor não tem.

O autor antes de começar a escrita do livro para a editora recebe uma proposta sob a forma de contrato: este é lido e o autor assina se concordar. Ninguém o obriga a escrever coisa alguma.

Pessoalmente: não preciso ou quero deste tipo de defensor para o meu trabalho. Se eu quiser dar 100% do valor para a editora dou e absolutamente ninguém tem coisa alguma a ver com isto.

Consequências do argumento da editora exploradora

Quem diz este tipo de coisa provavelmente nunca precisou pagar uma conta na vida ou gerir um negócio.  Que fique claro: sem editoras não há mercado editorial. Hoje é possível escrever livros de forma completamente independente (vide LeanPub ou Amazon), mas os benefícios obtidos pelo simples fato de haver uma editora por trás são inegáveis. No caso de livros técnicos, o principal ganho é que uma entidade externa a mim está dizendo que tenho competência para falar sobre aquele assunto e não eu mesmo.

Mais que isto: alguém mais competente está cuidando de assuntos que desconheço como vendas, divulgação, etc. Com isto meu foco fica apenas no que sei fazer: escrever e falar sobre aquele assunto.

O “argumento” da relatividade

“Você não pode dizer que pirataria de livros é um crime, dado que o conceito de crime varia de acordo com o tempo. Algum tempo atrás homossexualidade, por exemplo, era crime, hoje não é mais. Com os novos meios de produção, nada impede que a pirataria também deixe de ser crime.”

Contra argumento

Neste tempo, neste país, pirataria de livros é crime.

Consequências do argumento da relatividade

Eu ri. Agora, falando mais sério: relativizar qualquer discussão é desonestidade intelectual, pois a partir do momento em que as coisas se relativizam, pode-se dizer qualquer absurdo, pois “tudo é relativo”. Usem isto para detectar o “intelectual” desonesto.

O argumento de que “todo conhecimento deve ser livre”

“Sou da opinião de que todo argumento deve ser livre. Sendo assim não acho errado piratear seu livro pois tenho direito aquele conhecimento”

Contra argumento

Conhecimento é uma coisa e trabalho alheio outra.

Consequências do “todo conhecimento deve ser livre”

Quando você compra um livro está na realidade pagando pelo trabalho que o autor teve de compilar aquelas informações. Aquele sujeito ficou dias, meses, anos trabalhando para que o texto chegasse naquele ponto que pudesse ser comercializado.

Ele poderia muito bem ter disponibilizado gratuitamente, é verdade, mas também pode achar que merece ser remunerado por isto através da venda dos seus exemplares, e não há absolutamente nada de errado com isto.

O conhecimento está aí, basta que você faça como o autor: ponha a bunda na cadeira e comece a pesquisar por conta própria. Você está pagando é pelo trabalho da pessoa, não pelo conhecimento. Aliás, é interessante observar que quem faz este tipo de afirmação não consegue dizer o que vêm a ser o tal do “conhecimento” cuja liberdade prega tanto.

Pirateando você está desestimulando a produção comercial. Menos produção comercial é menos “conhecimento” sendo vendido e, convenhamos: R$ 29,00 não é acessível???

Argumento da falta de recursos financeiros

“Fiz cópia pirata por que não tenho dinheiro para comprar”

Contra argumento

Se um produto só é acessível a partir da compra, e você o obtém por meios ilícitos, você está roubando.

Consequências da “falta de recursos financeiros”

Simples assim: é roubo. E cá entre nós: no caso que citei o produto custa R$ 29,00. Mesmo se fosse caro, continuaria um argumento inválido. Esta é a essência por trás de qualquer furto.

Pergunte-se: como você justifica o valor de algo como caro? Te dou uma definição: caro é quando algo lhe fornece um benefício inferior ao que você pagou. E sabe de uma coisa? Se é caro, você não precisa roubar, é só agir como uma pessoa correta e ignorar o produto.

Argumento da fama

“Ah, mas o autor escreve um livro para ficar conhecido como o expert naquele assunto. Ele fará dinheiro com palestras, eventos, cursos, etc. Não será uma pirataria boba que o irá lesar. Eu me sentiria honrado em saber que estão pirateando meu trabalho!”

Contra argumentos

A questão não é escolher a forma que lesa menos o autor, mas sim não causar a lesão.

Se o livro está a venda é por que um dos objetivos do autor é fazer dinheiro com aquele trabalho.

Consequências do argumento da fama.

A esmagadora maioria dos autores que conheço diretamente não vivem de palestrar e dar cursos sobre os assuntos tratados. Muitos (e me incluo) publicam seus livros por editoras com o objetivo de, além de ter o reconhecimento citado, também obter um lucro extra com o seu trabalho. Mesmo que lotássemos a agenda do autor com palestras e cursos, acredite: não cobriria o esforço gasto na confecção do livro.

O reconhecimento de um profissional não é obtido apenas a partir de um livro: ele é a menor parte na realidade. Entra aí participação em eventos, artigos publicados, trabalhos reais produzidos, experiência com colegas e diversas outras atividades.

Pra finalizar (e não irá finalizar)

Sei que pirataria é um problema cultural e que jamais será resolvido, mas isto não quer dizer que eu deva ser omisso. Infelizmente sou um dos poucos autores que falam abertamente sobre o assunto. Todos os autores publicados que contactei e foram pirateados concordam com o que disse acima. Sim: também se acharam desrespeitados. Curte o cara? Comece respeitando o trabalho dele.

Tadinho: tão inocente!

Tadinho: tão inocente!

Mas se você for me lesar, saiba que não ligo se me acha uma pessoa simpática ou não. Você leu este texto, leu o anterior sobre o assunto e sabe que considero isto desrespeito a minha pessoa. Te considero meu agressor.

Respeito é algo que primeiro espero. No momento seguinte, eu peço por ele. Se não o obtiver, o exijo.

PS: e você, autor?

Você sabe o trabalho que é publicar um livro e, se está a venda, também sabe que o fez para receber pelo seu esforço. Não se cale: não tenha medo de soar antipático perante esse povo que vêm com esta argumentação. Escreva a respeito para conscientizar o público.

Eu quero mais “Casas do Códigos, “DevMedias”, “Ciências Modernas” e muitas outras editoras pipocando por aí gerando livros que façam a diferença em nosso mercado. Ajudem nossa classe a progredir lutando contra o comportamento que exponho neste post.

Lembre-se: quem abaixa demais mostra a bunda.