terça-feira, 11 de agosto de 2015

Débito Técnico ou Dívida Técnica?


É interessante como os idiomas nos pregam algumas peças, independente de ser seu idioma nativo ou não. O parônimo é uma dessas peças: palavras que tem grafia e pronúncia parecidas, mas significados diferentes. E quando tentamos traduzir estes parônimos para outras línguas acabamos cometendo ainda mais equívocos.

"Débito Técnico" é um destes equívocos. Eu mesmo ainda não consigo ler "Technical Debt" e não pensar de imediato em "Débito Técnico". Qual o equívoco? Em inglês, "debt" significa dívida, e não débito. "Debit" (notem o "i" adicional) poderia ser traduzido como "débito".
Technical Debt = Dívida Técnica
Façamos uma analogia com números pequenos e juros simples (não compostos) para simplificar a conta.

Definiremos uma unidade de medida de valor de software como "Yanaga". Por que "Yanaga"? Poderia ser qualquer nome: é só para termos um referencial de medida, e como o blog é meu acredito que os leitores já esperam algum egocentrismo mesmo :-)

Sua equipe é capaz de entregar 100 "Yanagas" por semana de valor em software.

Mas por algum motivo há uma funcionalidade muito importante para ser entregue nesta semana e para atender esta demanda você pega um empréstimo técnico (uma gambiarra) de 50 "Yanagas". Assim você consegue entregar 150 "Yanagas" de valor e a sua funcionalidade muito importante.

Na próxima semana você esperava continuar entregando os 100 "Yanagas" de valor. Mas como você contraiu uma dívida técnica, você tem juros para pagar. Você não consegue mais desenvolver com o mesmo desempenho pois aquela gambiarra da semana passada faz com que você tenha mais problemas, mais bugs etc. Suponha que aquela gambiarra lhe custe 40% da dívida. Esta semana você entregará somente 80 "Yanagas" de valor.

Ao final de 3 semanas a sua dívida técnica terá lhe custado 60 "Yanagas" de valor. E você emprestou somente 50.

Percebem que se em algum momento você não quitar a sua dívida técnica a sua geração de valor em software fica comprometida?

E a situação é muito pior quando mesmo já tendo uma dívida técnica resolvemos contrair mais um empréstimo. Assim a dívida aumenta, e chega num determinado momento em que simplesmente não entregamos mais valor.

Quando pensamos em dinheiro sabemos os problemas que a dívida nos traz, e também sabemos quais são as atitudes que devemos tomar. Por que com código pensamos diferente? Traduzir Technical Debt como Dívida Técnica talvez nos ajude a refletir melhor nessa situação.

terça-feira, 9 de setembro de 2014

Sempre conteste o status quo!


Quando criança, tive a grande oportunidade de estudar filosofia durante alguns anos. É evidente que devo considerar-me um ignorante enquanto filósofo devido à ínfima quantidade de estudo, mas se há algo que aprendi nas aulas e que carrego de modo absolutamente fundamental na vida é a necessidade do questionamento constante.

Duvide de tudo. Duvide de todos. Duvide principalmente de si mesmo e de suas convicções. Não basta aceitar os fatos somente porque "os outros dizem", "os outros acreditam" ou porque "sempre foi assim". Use a lógica e o pensamento para chegar ao porquê das coisas. Busque a verdade incessantemente, mesmo sabendo que a verdade absoluta é inatingível.

Toda a evolução do conhecimento humano é baseada no constante questionamento. Antes acreditava-se que a terra era plana, que a mesma era o centro do universo - depois que o sol era o centro do universo e que o universo era finito! Só evoluímos porque alguém se dispôs a contestar o status quo.
"Status quo: estado atual das coisas".
Sei que muitas vezes incomodo os outros com meus questionamentos - só a informação não me basta, eu preciso saber os porquês. Eu aprecio pensar diferente. E notem que pensar diferente não implica em estar certo ou errado: implica em construir argumentos a favor ou contra um determinado pensamento. Se poderemos evoluir e criar novas conclusões a partir disso é tarefa para a nossa lógica e razão.

E infelizmente lógica e razão são virtudes cada vez mais escassas, pois as pessoas estão perdendo a capacidade de contestar o status quo...

segunda-feira, 28 de julho de 2014

The Developer's Conference 2014 São Paulo: Sorteio de entradas para as trilhas Cloud Computing e DevOps


Nos dias 05 a 09 de Agosto de 2014 acontecerá o maior evento para desenvolvedores do Brasil, o The Developer's Conference São Paulo.

Neste ano terei a honra de coordenar a trilha de Cloud Computing - juntamente com Rafael Nunes, e a trilha de DevOps - juntamente com +Bruno Souza. Para completar minha participação também serei palestrante nas trilhas de Android, Software Livre, DevOps, Arquitetura Java e Java.

Para poder ajudar e atrair uma quantidade ainda maior de profissionais interessados ao evento decidi sortear 1 entrada para a trilha de Cloud Computing e 1 entrada para a trilha de DevOps.

As regras do sorteio são as seguintes:
  1. Os sorteios serão realizados no dia 30/07/2014 às 16:00h e os resultados serão divulgados no meu twitter @yanaga.
  2. Para participar dos sorteios é necessário me seguir no twitter e dar retweet no tweet abaixo.
  3. Se a pessoa sorteada não puder comparecer no evento, será sorteada uma outra pessoa sucessivamente até que alguém confirme.
  4. Casos omissos, ambíguos etc serão decididos por mim :-)
Participe!

sábado, 19 de julho de 2014

Carpe Diem


Há algum tempo eu ganhara de presente algumas garrafas de vinho (de rótulos muito bons). Estes vinhos me foram dados por amigos, alunos, colegas - pessoas das quais tive o prazer de compartilhar algum tempo no passado.

Antes que alguém possa me questionar, já de antemão respondo que sim, sei que o vinho possui uma série de prerrogativas para ser armazenado de modo correto. Temperatura constante, humidade, ausência de luz etc. Mas na ausência de uma adega tentei armazená-los do melhor modo possível.

Esta semana tive um ímpeto e resolvi que finalmente degustaria daqueles bons vinhos que estavam guardados. Pus quatro garrafas para refrigerar, e mais tarde escolhi uma e a abri. Tive dificuldade em abri-la, pois a rolha quase esfarelou. Verti o vinho na taça e notei um cheiro acre. A cor era de um vermelho bastante escuro e intenso. Bebi. O gosto estava horrível, com um toque azedo. Lamentei, e após um suspiro de lamentação despejei todo o conteúdo da garrafa no ralo da pia.

Repeti o mesmo processo nas outras três garrafas. Uma coisa ou outra variou durante o processo, mas sempre com o mesmo resultado: gosto ruim e o líquido escoando pelo ralo.

Esta experiência enológica frustrante levou-me a uma série de reflexões. Durante todo estes anos eu sempre guardei aqueles vinhos para poder degustá-los numa ocasião especial. Um dia especial, uma comemoração especial ou uma visita especial. Mas por um motivo ou outro nunca os abri. E quando o fiz, não pude apreciá-los pois já estavam estragados.

Muitos de nós temos outros vinhos guardados. Com outros nomes. O seu vinho pode ser uma viagem, uma comemoração, um passeio, alguém... Não deixe seus vinhos estragarem. Pois no final, nos arrependemos mais das coisas que não fizemos que das coisas que fizemos. Eu não teria me arrependido de ter tomado o vinho antes. Aproveitem as oportunidades que lhes restam, pois eu tentarei aproveitar as minhas.

Aproveitem o dia. Carpe diem.



quinta-feira, 10 de abril de 2014

Há dias que não valem a pena...


Em muitas situações de nossas vidas somos expostos a opiniões diferentes. Ainda bem. É salutar poder encontrar opiniões divergentes, pois o mundo seria um lugar absurdamente monótono e estagnado se todos concordássemos sempre.

Em todas as situações em que me deparo com alguém que pensa diferente, sempre penso primeiro: "estou errado". E depois com base em meus próprios argumentos tento me convencer de que posso estar certo. Às vezes ganho de mim mesmo, às vezes não. Não me importo nem um pouco em ser convencido por um argumento melhor que o meu. Mas também não aceito argumentos fracos.

Ganhar e perder disputas com base em argumentos é parte da vida. É interessante. É produtivo. É construtivo. Tanto quem ganha quanto quem perde uma discussão sai vencedor, pois saímos pessoas melhores.

Mas há dias em que numa discussão algumas pessoas não se sentem adversárias, e sim inimigas. Ao invés de tentar encontrar uma solução para um bem maior, procuram rancor ou o gosto de revanche. Nessas situações não se encontram vencedores: todos perdem. Perdem pois ao final não temos mais pessoas que juntas poderiam fazer a diferença: ao invés de multiplicar, subtraímos.

Há dias que não valem a pena... Ontem foi um desses dias, pois mesmo tendo ganho uma "disputa", perdi alguém que poderia me ajudar e ser ajudado. Perdemos ambos. Só que, mesmo já sendo adulto, eu ainda não aprendi a perder. E é por isso que fica um gosto amargo pra refletir.

terça-feira, 25 de março de 2014

Oracle Java Magazine: fonte gratuita de informação de qualidade

Edição de Janeiro/Fevereiro de 2014 da Oracle Java Magazine
Gostaria de divulgar na comunidade Java brasileira esta excelente fonte de informações gratuita que está desapercebida por muitos desenvolvedores.

A Oracle Java Magazine (não confundir com a Java Magazine brasileira publicada pela DevMedia) é uma publicação oficial da Oracle sobre a Tecnologia Java. Autores do mundo todo contribuem para produzir esta revista eletrônica bimestral com conteúdo de qualidade.

Seu conteúdo é em inglês, mas como já comentei em um post anterior e como também comentado por +Bruno Souza (o JavaMan) em seu blog, saber ler em inglês é uma habilidade primordial para qualquer desenvolvedor de software. Aproveitem a oportunidade para praticar!

E se vocês folhearem a edição atual e as anteriores poderão notar que muitos brasileiros contribuem para o alto nível da Oracle Java Magazine. Em muitas matérias brasileiros como +Vinicius Senger+Yara Senger+Bruno Souza+Fabiane Nardon+Fernando Babadopulos e outros fazem a diferença. Creio que isso motive ainda mais a nossa participação numa comunidade tão vibrante e engajada que são os JUGs (Java User Groups) brasileiros.

A inscrição é rápida e fácil. Você recebe as notificações da revista por e-mail. Não deixe de aproveitar esta oportunidade. Serve para provar que nem tudo que é bom tem que ser caro.

Bom proveito!

quinta-feira, 27 de fevereiro de 2014

Elegância: uma qualidade em falta no código e nas pessoas


Há algum tempo li uma discussão sobre "código elegante" em algum canto da Internet. A querela contrapunha código "que funciona" contra código "bonito". Como se fazer código "bonito" fosse modinha: o importante mesmo é fazer rodar.

Primeiramente gostaria de deixar claro que todo software é criado com um propósito de valor. Se não cumpre o seu propósito - seja porque é mal feito e não gera o valor esperado ou porque não funciona - nem deveria ser chamado de software. Deveria ser crapware ou qualquer outra coisa parecida.

Definição de elegância segundo a Wikipedia:
"Elegance is a synonym for beautiful that has come to acquire the additional connotations of unusual effectiveness and simplicity." (http://en.wikipedia.org/wiki/Elegance)
 Traduzindo literalmente:
"Elegância é um sinônimo para beleza que adquiriu as conotações adicionais de incomum eficácia e simplicidade."
Código elegante então seria algo belo (bonito - agradável ao programador, legível e fácil de entender, coeso etc), eficaz (faz o que se espera dele) e simples (com um mínimo gera um máximo de resultado). Se o nosso objetivo de vida como profissionais de software - como artesãos de software - não for produzir código elegante, então não sei mais o que é.

Além de código elegante, falta-nos a elegância de agir como profissionais:
  • Não é elegante entregar algo que não funciona.
  • Não é elegante atrasar um compromisso.
  • Não é elegante prometer algo que não vai ser cumprido.
  • Não é elegante criar expectativas de prazo falsas.
  • Não é elegante entregar menos do que foi combinado.
  • Não é elegante fazer menos do que o seu melhor possível. 

Entregar código elegante e ser um profissional elegante então não são opções. Fazê-lo e sê-lo são simplesmente questões de ética.