Category Archives: armadilhas

Meu problema com aplicativos de taxi (e as soluções)

Dentro do carro pela segunda vez minha esposa avisou o motorista que ele havia tomado o caminho errado. O carro acelera bruscamente, freia e para no acostamento.

_ Já que está tão ruim desçam do carro agora!

Em choque saímos do veículo (eu, minha esposa e uma amiga), mas a história não termina aí. O motorista também sai do carro, saca uma carteira da polícia e grita em nossa direção:

_ Vocês não estão lidando com qualquer um: vejam quem sou!

Percebo o motorista com algo estranho na outra mão, que está próxima da parte de trás do seu cinto. Por estar assustado temo ser uma arma e, para defender minha esposa e nossa amiga, parto em direção do sujeito aos gritos e este se acovarda, volta para dentro do veículo e parte para “atender” outros azarados passageiros.

Lendo as notícias recentes talvez em um primeiro momento você creia se tratar de um taxista “convencional”, certo? Errado.

Meu histórico recente

Pelo menos duas vezes por dia pego algum taxi (tradicional ou não). Estatísticamente a possibilidade de algo dar errado comigo é muito grande e, de fato, ocorre com frequência. Apenas algumas das situações pelas quais passei nos últimos seis meses:

  • Chamo um taxi, no aplicativo aparece um motorista e, quando o carro chega, é outra pessoa completamente diferente (inclusive há casos nos quais ao negar a corrida fui ameaçado de porrada)
  • Motoristas malucos que não respeitam um sinal qualquer e andam a 100 por hora
  • Um motorista louco que joga seu carro contra um carro do Uber
  • Gente que nega me devolver troco e faz um cavalo de pau comigo dentro
  • Um motorista que joga seu carro contra um ônibus por que “estava estressado”
  • Um motorista que quer “dar um susto” em seu colega e quase bate o veículo comigo dentro

A lista é longa e já virou até piada entre meus amigos. Não sei se ocorre com outros consumidores com perfil similar ao meu, mas ao menos comigo, em Belo Horizonte, ocorre bastante.

E agora o detalhe curioso: 100% dos incidentes que tive se iniciaram usando um aplicativo de transporte. O melhor serviço de transporte que uso é o ponto de taxi perto da minha casa, para o qual ligo pedindo um carro.

Dado que vou continuar usando estes serviços (não tenho escolha (por enquanto)), resolvi escrever este post pra ver se os responsáveis pelos aplicativos ouvem minhas reclamações (que agora estou tornando públicas) e sugestões.

A grande falha e minhas sugestões

Muitos destes aplicativos dizem que filtram os motoristas que os usam, no entanto com absolutamente TODOS que usei passei por algum inconveniente que colocou minha integridade em risco.

Todos dizem oferecer excelente suporte ao passageiro caso algo dê errado: você pode, por exemplo, dar nota a um motorista. Pode também entrar em contato com os responsáveis pelo aplicativo reportando o acontecimento, o que é ótimo. Alguns até te respondem!

Aí entra a falha: eu devo poder reportar que algo está errado não depois do incidente, mas sim antesdurante.

Se chamo um taxista e vêm outro, naquele momento devo alertar a operadora do ocorrido. Na maioria dos aplicativos, o máximo que posso fazer é cancelar a viagem. O problema é que este cancelamento ocorre com o “falso motorista” diante de mim. Resultado? Minha segurança agora está em risco e você muitas vezes se vê coagido a participar de uma viagem com alguém que não foi chamado.

(será que a nota que vejo do motorista é realmente a dele ou de outro que veio atender em seu lugar?)

Primeira sugestão: poder reclamar antes da viagem ocorrer

Todo aplicativo deveria ter esta funcionalidade: se não gostei do motorista ou se veio outra pessoa, naquele momento devo alertar os responsáveis pelo aplicativo, não depois.

Estou falando isto como usuário do Windows Phone, talvez para Android seja diferente. Falando nisto…

Segunda sugestão: a segurança do passageiro não deve depender do sistema operacional do seu telefone

Se você oferece um aplicativo de transporte, está lidando com a segurança dos seus usuários. E parte da segurança vêm justamente do modo como o usuário interage com o aplicativo.

O único aplicativo de taxi que usei e possuí qualidade para usuários Windows Phone é o Way Taxi. Tirando ele, os demais simplesmente fedem.

Lançar versões inferiores de um aplicativo que pode colocar os seus usuários em risco para outras plataformas só por que possuem menos usuários. Tenho um nome adequado para esta postura: irresponsabilidade.

Sugestão? Se vão lançar uma versão inferior para uma plataforma, não lancem.

Terceira sugestão: botão de pânico durante a viagem

O motorista pode causar uma boa primeira impressão e por sua vida em risco durante o trajeto. Logo, durante a viagem eu, como passageiro, devo poder notificar a operadora dos perigos que eu possa estar correndo E devo ser atendido prontamente.

Com isto posso atuar também durante a viagem.

Quarta sugestão: seguro

Talvez isto seja feito, mas nunca vi ser divulgado. Se pego um carro usando um aplicativo, e um acidente ocorra comigo motivado por imprudência do motorista, quem me cobre?

Se você oferece serviço de transporte, por que não mostrar que confia em seus motoristas também?

(dúvida: será que eu, enquanto consumidor, se sofrer algum acidente durante o percurso devido à imprudência do motorista que contratei pelo aplicativo, posso processar a empresa que mantém o serviço?)

Quinta sugestão: uma central de atendimento POR TELEFONE

O incidente ocorreu e você busca as opções de feedback no aplicativo: você está tenso, não consegue achar e, às vezes, realmente não existe. Por que não há um número de telefone de fácil acesso nestes programas???

Se houvesse um número e você pudesse ligar para uma central, que te fornecesse um número de protocolo ou qualquer coisa, a situação seria muito mais fácil. Falar é mais fácil que digitar, sabiam?

Lembram o incidente que mencionei no início deste post? Só pude reportar a operadora em casa, pois não encontrei a funcionalidade no aplicativo pra Windows Phone. Neste meio tempo o indivíduo estava atendendo outras pessoas pela cidade e as pondo em risco.

As antigas “centrais de taxi” tinham isto. Por que os aplicativos não podem ter também?

E mais: dado que vou ligar para reclamar por que algo está muito errado, não devo pagar por isto. Éticamente o correto é ser uma ligação gratuita.

O dia seguinte…

A operadora “prontamente” me respondeu três dias depois e, para não perder o cliente, me ofereceu R$ 20,00 de crédito. Bacana saber o preço da minha segurança, lhes disse que não queria o dinheiro mas mesmo assim o incluíram na próxima viagem que fiz com eles.

Por que fiz a próxima viagem? Me prometeram que nunca mais pegaria uma viagem com aquele motorista, idem minha esposa e minha amiga. Ok: parece justo, dei azar naquele trajeto. Não ocorrerá novamente: afinal de contas, todos dizem que este é o melhor serviço de transporte do país e que possuí o melhor atendimento, certo?

Algumas semanas depois…

Pela manhã minha esposa pede um carro pelo aplicativo. É o mesmo motorista. Ela cancela a viagem.

Então eu peço mais uma viagem com o mesmo aplicativo: o mesmo motorista, que devia estar perto de nós. Mas notei um detalhe escabroso: sua avaliação era de 4.8 estrelas (em 5).

Entrei em contato com a operadora, mas ela ainda não me respondeu.

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.

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.

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.

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

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.