Category Archives: armadilhas

“Legado” é um termo maldito

O termo “legado”, quando aplicado a software sempre me incomodou: tanto que algum tempo atrás busquei uma melhor definição para esta palavra dentro do nosso contexto de TI. Hoje volto ao assunto para dizer que não uso mais a palavra “legado” com meus clientes e colegas e explico minhas razões.

O termo que todo mundo busca a definição (inclusive eu)

Fui um dos palestrantes da trilha de legados da QCon Rio 2015 e, para minha sorte (ou azar), fui o último a falar, o que me permitiu assistir a todas as apresentações sobre o assunto. O que achei interessante é que quase todos (inclusive eu) apresentaram seu próprio conceito de legado.

(e neste texto ainda apresento mais definições sobre legado, o que mostra ser um fenômeno global, e não uma particularidade daquele evento)

Claramente há algo errado aqui: se dentro de um contexto bem definido (ou ao menos aparentemente) há tantas definições para uma mesma palavra, surgem duas possibilidades:

a) A palavra não possuí um significado real
b) Devíamos ou categorizar este termo ou mesmo buscar outras palavras

A  má impressão criada pela nossa indústria

Diversas vezes um cliente chega para nós pedindo que executemos manutenções ou evolução em seus sistemas com frases do tipo: “temos este sistema legado, que me disseram ser velho e ultrapassado, mas não tenho dinheiro para reescrever do zero”.

Lendo o código fonte observo que foram usadas tecnologias como Spring BootGrailsPHP, JavaScript, JSF ou qualquer outra que é ativamente desenvolvida hoje. Pior ainda: o sistema tem no máximo 5 anos de idade. Não poderia ser categorizado como “velho”, e levando-se em conta que normalmente está em uso, muito menos “ultrapassado” ou “obsoleto”, pois claramente está satisfazendo objetivos de negócio ali.

Fato é que muitas consultorias e profissionais normalmente ao invés de venderem a evolução do sistema preferem a reescrita por dizerem dar menos trabalho e sair mais barato (o que normalmente  é uma grande mentira e ainda escreverei sobre isto, mas enquanto isto, pode ler este excelente texto do Joel Spolsky).

A situação é ainda pior: já vi apresentações sobre “legados” na qual o palestrante usa o termo “evolução” e apresenta uma completa reescrita como resultado (atualmente uma das formas que esta reescrita vêm disfarçada é como micro-serviços).

Resultado: o termo “legado”, que deveria ter uma conotação positiva (conhecimento e experiência adquirida ao longo do tempo, conquista, satisfação por ter construído algo que é passado pra frente) passa a ser visto por muitos como um defeito.

(não creio que a maior parte dos profissionais e consultorias que vendam a reescrita imediata sejam mal intencionados. Na minha opinião o problema surge da nossa formação. Um dia ainda escreverei sobre isto)

Que termo uso agora

O mais óbvio e tedioso:  “software que você já tem” ou “software pré-existente” ou, ainda “software que não escrevi” ou algo similar pelas seguintes razões:

a) O cliente (que é quem realmente importa) entende o que estou dizendo imediatamente
b) Muitos clientes nunca ouviram o termo “legado”, o que evita a necessidade de explicar uma palavra que creio ser tão mal empregada em nosso idioma
c) Me fornece (e à indústria) um ponto inicial que possibilite uma melhor criação de sub-categorias que auxiliam na definição de estratégias

Sobre categorização

O termo “software que você já tem” é elementar: não consigo pensar em uma categoria superior a este (“software”, talvez :D) , mas consigo pensar em “tipos de software que você tem”. Segue uma pequena lista:

  • Aquele que temos o código fonte
  • Aquele que não temos o código fonte (sim, acontece e muito)
  • Aquele que é parte de sua infraestrutura (SGBD, Sistema Operacional, protocolos de rede)
  • Ou outra categorização qualquer que represente o nível de posse do cliente sobre um software

E esta categorização nos ajuda a pensar melhor o “seu software“. Ao analisar a situação do cliente (a mais importante), a comunicação fica mais simples e direta. É curioso que nas apresentações que vejo sobre legados só escuto sobre a primeira categoria: “aquele que temos o código fonte”. Aonde ele é executado? Como é o ambiente que o rodeia?

(é interessante notar que as pessoas confundem “legado” e refatoração, e esta é minha prinicpal crítica ao livro do Feathers – legado não é só o código)

A partir do momento em que um termo mais simples é usado na conversa, tudo flui, impressionante.

Minha antiga definição de “legado” não era uma definição

Ano passado busquei uma definição de legado e eis a que cheguei:

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

Leia atentamente o que acabei de escrever: isto é uma definição? Hoje creio que não, pois não defini um termo, mas sim o problema fundamental do seu software.

O que é legado? Em português (e pensando no contexto brasileiro) é um termo que causa mais confusão que o necessário, haja visto os pontos que expus. Sendo assim, não irei mais me preocupar com a sua definição ou mesmo seu uso.

(ainda escrevo sobre um possível hype envolvendo este assunto (hype este que não se desenvolverá de forma saudável devido às falhas em nossa formação que comentei em parênteses anteriores))

Meu problema com a infantilização

Tratar adultos como crianças, especialmente desenvolvedores, sempre me irritou. Algum tempo atrás inclusive escrevi sobre isto aqui no blog. O foco da minha opinião é o desperdício de algo fundamental: o processo de amadurecimento.

Vejo de forma muito clara este processo infantilizador se manifestando em vagas de emprego que buscam “padawans”, “jedis”, “super-heróis”, “rockstars” (vergonha alheia infinita). Isto sem mencionar grande parte da cultura “geek” que, devo confessar, não raro vejo carregada de fortíssimo caráter infantilizador. Isto sem mencionar “apresentadores” e “palestrantes” que se vestem como crianças. Nossa, quanta vergonha alheia!

Mas o que é amadurecer?

Para mim envolve a expansão intelectual. Vou partir de um exemplo banal. Ao encontrar alguém usando um chapéu de Mario e lhe pergunto por que o está usando. Normalmente a resposta é um “por que é legal”.

Por que o chapéu?  Por que é legal!

Por que o chapéu?
Por que é legal!

Esta é uma resposta válida, mas se forçar a barra e perguntar “por que é legal?”, não raro o indivíduo infantilizado não vai saber responder. Resumindo: a futilidade (um aspecto infantil resultante de uma percepção limitada) está se manifestando. Lhe interessa o ato de fazer graça. Então, como seria uma resposta adulta?

(já se perguntou por que, na sociedade ocidental na qual o riso é visto com desprezo, de repente ser uma pessoa “divertida e engraçada” passa a ser visto como algo super positivo? Dica de leitura)

“O que envolve o conceito do Mario é interessante e me agrada”. Me lembro quando era pré-adolescente e vi o Mario Bros pela primeira vez. Algo completamente diferente de todos os jogos que havia jogado até aquele momento: o cenário era muito rico e toda a mecânica era algo revolucionário para nós.

free_download_super_mario_bro_game

O que me impressionava era o puramente sensório: a experiência de controlar o Mario e todas aqueles elementos secretos no jogo eram algo fascinante para alguém com 12, 13 anos (muitas cores e surpresas, além de uma música top). A coisa ficou realmente interessante quando notei uma similaridade naquele jogo com algo que já conhecia.

smb3_mush2

Aquela história do Mario comer um cogumelo e de repente crescer. Já havia visto isto em algum lugar: em Alice no País das Maravilhas, mas ao contrário. Ela encolhia.

alice-on-mushroom-3

Caramba! E de repente, observando as ilustrações do livro de Lewis Carroll, conseguia ver no cenário que se movia do Mario elementos daquela história (Mario era um ser diminuto entre cogumelos?). Isto ampliou meus horizontes  e me fez começar a questionar outras coisas: quem criou o Mario? Foi a Nintendo. Mas quem dentro da Nintendo teve esta ideia? Foi o Myiamoto. Quem é ele? O que inspirou este sujeito?

Mario -> Alice no País das Maravilhas -> Nintendo -> Miyamoto -> Lewis Carroll -> Problemas lógicos -> Matemática

A rede cultural se expande: vejo mais pontos e ligações entre eles. Questiono estes relacionamentos e busco confirmações a seu respeito. Resumindo: saio de algo simples e  fútil:  termino em um universo totalmente novo que não para de se expandir conforme interajo com ele.

A pergunta “por que você usa este chapéu de Mario?” adquiriu profundidade. E neste processo de amadurecimento noto que até minha capacidade em aceitar críticas foi ampliada: ao ver um número maior de possibilidades no mundo, são grandes as chances de eu realmente estar errado e existirem alternativas muito superiores. Resumindo: eu venço outra barreira infantil que é a do solipsismo. Estou em um mundo rico com o qual interajo.

Amadurecer é bom e a vida adulta é maravilhosa. O adulto tende a ser sábio, ao contrário da criança. Então, o que ganho ao infantilizar? Para responder a esta pergunta, é importante responder outra: como é ser uma criança?

(algo fascinante: vejo esta “expansão intelectual” em praticamente tudo, basta tentar)

Como é ser criança?

Odiava ser criança. Brincar era legal, não havia trabalho (meus pais me mantinham), mas nem por isto meus problemas eram menores. Há adultos que te controlam e definem o que deve ser feito. Além disto, o mundo é assustador pois você não o conhece direito por ter uma visão limitada da realidade.

E justamente por ter uma visão limitada a criança se vê a mercê do adulto a quem deve obedecer de forma compulsória. O medo do desconhecido faz com que a criança se torne um ser quase solipsista, que vive em um mundo apenas seu, mas controlado por forças desconhecidas.

Seus problemas também não são tão menores como pensamos: basta se lembrar dos medos  que sentia ao se imaginar levando bomba na escola ou na possibilidade de perder seus pais, quem cuidaria de você? E se seus pais não fossem tão legais assim? E se você fosse adotado? Existem monstros no escuro?  Os medos da infância parecem tolos hoje que somos adultos, mas na época eram aterrorizadores.

Verdade seja dita: romantizamos a infância. Além da vulnerabilidade e dependência em relação aos adultos, sabe o que mais a “boa criança” costuma ser? Dócil. Afinal de contas, uma “criança boazinha”, tal como somos criados, é aquela que recebe “presentes do Papai Noel”, é aquele ser que não questionaque obedece.

Pra que infantilizar então?

Essencialmente por que você quer ter um controle maior sobre o outro, que não desejamos vir a se tornar um questionador. E que te admire, pois você estará, em relação ao infantilizado, como o adulto em relação à criança.

É curioso como em diversos casos de infantilização que observo os manda-chuva são pessoas extremamente adultas, formais, exemplares. Já notou isto?

E por que o fútil é tão valorizado? O que faz da fábrica de doces algo sedutor? Ela faz com que o adulto se esqueça dos problemas relativos ao seu amadurecimento. Você afunda o adulto em tolices para que ele se torne dócil.

Por que uma biblioteca de quadrinhos e não clássicos ou grandes livros? Por que os segundos são “chatos”? O que os torna chatos ou, ainda melhor, “quem” os vende como tal?

Por que me incomoda então?

Por que ao diminuir o indivíduo, termina por lotar de tolos o mundo. Confesso sentir calafrios ao pensar na formação de futuras gerações. Será este medo o resultado do meu envelhecer? Talvez.

Me incomoda muito pensar que as pessoas, em sua carência, acabam por se colocarem em uma posição inferior sem a menor necessidade.

Devo ser uma pessoa séria sempre então? Não: só tem de evitar se tornar um “retardado”.
(já notou que normalmente quem se da bem possuí uma forte tonalidade séria?)

PS:

controvérsias sobre a relação entre o Mario e Alice no País das Maravilhas, no entanto o simples fato de podermos fazer a conexão por conta própria já me parece algo incrível.

PS 2:

Sou contra o “trabalho infantil” :D

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.