Eu havia lido sobre o blog day 2007, mas não foi algo que me chamou atenção o suficiente, então deixei passar batido. Olhei com mais cuidado quando o Thiago Arrais, depois de ser citado pelo José Oliveira, indicou esse blog entre os que ele acompanha. Nada mais justo do que eu citar aqui alguns – cinco também – dos blogs que acompanho com mais atenção. De comum entre eles estão os posts com textos trabalhados com cuidado e publicações com freqüência menor, aquela velha história sobre qualidade e quantidade.

São eles:

Mergulhando no Caos: e não é para devolver a gentileza. Dê uma navegada pelo blog e você verá que os posts são acima da média, com idéias bem elaboradas e descritas de maneira competente. De lambuja você lê acompanhado de uma cabeça voadora, a do Arrais, claro.

Blog da Caelum: nesse blog os desenvolvedores da Caelum se revezam para escrever sobre Java, Padrões de Projeto, Ruby e, faz pouco tempo, Scrum.

* batteries not included: Daniel Martins é um sujeito curioso o suficiente para estudar um mundo de coisas em Java, Ruby, Smalltalk, Groovy e por aí vai. Os posts são geralmente bem completos e com informações para sair do zero caso você não saiba muito sobre os assuntos tratados por ele.

Blog do Guilherme Chapiewsk: Encontrei o blog do Chapiewski – sim eu copiei e colei – através do Phillip Calçado e assinei o feeds logo. A maior partes dos posts trata de agile e testes, vale uma boa olhada.

Code Comics: blog com quadrinhos? Preciso dizer mais o que?

Anúncios

Como desenvolvedores de software nós trabalhamos para criar ferramentas que automatizem ou melhorem tarefas. Escrevemos software para análise de dados financeiros, para gerar relatórios sobre como anda o relacionamento com os clientes e para uma infinidade de propósitos. É bastante natural querermos então automatizar tanto quanto possível do nosso trabalho. Daí criarmos rotinas prontas para compilação, empacotamento, testes e toda e qualquer tarefa que se mostre repetitiva. Se você não faz isso no seu trabalho, saiba que perde tempo a cada execução manual e repetitiva de alguma tarefa que pode ser automática.

Não é de surpreender que, nessa sede de tornar tudo executável com um clique, vez ou outra alguém tente automatizar o que não deve. Afinal, eis aí uma maneira de maximizar a previsibilidade e a eficiência da tarefa: ninguém corre o risco de esquecer um passo importante e acabar com resultados errados. Mas existe a contra mão para não ser automatizada. Uma via intimamente relacionada a tarefas com impacto na maneira de pensar das pessoas.

Deixem-me esclarecer de onde essas alucinações vieram.

Exemplo de prática com impacto nas pessoas: em metodologias agéis, quando pensamos em artefatos tais quais modelos, diagramas e afins, o mais importante não é o artefato em si, e sim o trabalho de criar, o fazer. Por causa disso, usamos artefatos fáceis de gerar – como story cards – e de descartar caso estejam errados. Os cartões têm, claro, seu valor, só que o que importa mesmo é o jogo do planejamento, a reunião na qual eles, os cartões, são escritos. Pode passar despercebido, mas olhar mais para o fazer é uma maneira de criar sinergia porque as pessoas desenvolvem o hábito de, juntas, realizar tarefas.

O outro impacto provocado por quadros com story cards, gráficos burn-down, ou outros artefatos pendurados até onde a vista alcança é que eles impactam as pessoas o tempo todo sobre como o projeto está, desde quando você entra no ambiente até quando sai. Mais ainda, os quadros vão além de serem apenas um snapshot do projeto, eles são um estimulo para o senso de que as tarefas precisam ser terminadas. Ferramentas sem impacto visual, por outro lado, não produzem estimulo na mesma proporção, basta pensar que issues trackers, mesmo os melhores, não estão sempre a vista.

A partir daí você pode imaginar minha surpresa ao ver essa noticia no InfoQ mostrando como um conjunto de artefatos com apelo visual foi substituído por uma ferramenta com – verdade seja dita – alguns recursos pra lá de interessantes, mas, vejam só, longe dos olhos das pessoas, ou ao menos não tão perto assim. Espero que eu não seja o único a perceber que menos informação é irradiada. Talvez ainda faltem as ferramentas certas, ou o hábito de usá-las como se deve, mas acho que, assim como há espaço para mais automatização no que diz respeito a tarefas repetitivas, feitas por maquinas, há espaço para menos automação, para tarefas que requerem aquilo que os serem humanos – ao menos os mais interessantes – têm de sobra: criatividade, curiosidade e tato.


Curiosidade é um comportamento naturalmente questionador, um estado no qual se quer aprender mais sobre algo, um aspecto emocional que direciona para investigação e aprendizado. Essa é uma pequena compilação das definições sobre curiosidade. Provavelmente você pode encontrar outras melhores do que essas, um dicionário de bolso com certeza vai lhe ajudar. Entretanto, para mim, o mais adequado é chamar curiosidade de motor.

Mas por que?

Vamos começar com listas sobre as características fundamentais para se tornar um bom desenvolvedor de software. Há quem diga que fundamental é a habilidade para resolver problemas, que ser preguiçoso (eu não gosto muito dessa palavra para denotar o que se tenta explicar) é um bom começo, enfim, listas e mais listas sobre o assunto. Em todas elas há uma faceta sempre presente, geralmente descrita de maneiras diferentes: a vontade de aprender, o gosto por aprender, o amor por aprender. Gosto de resumir as descrições de aprendizado como curiosidade. Para mim, curiosidade é o motor para me movimentar a ter iniciativa, daí para fazer coisas boas – outras nem tanto – acontecerem, o tal gosto por aprender, saber, descobrir, explorar. Iniciativa, vinda da curiosidade ou não, é o que eu chamo de “não coincidência”, mas espere, eu não vou enveredar por esse caminho, não é o propósito desse post.

Um dos grandes exemplos sobre como curiosidade pode ser benéfica é a Toyota. Lá a solução de problemas é feita com perguntas consecutivas para chegar à causa raiz, algo um bocado mais profundo e efetivo do que apenas apagar os incêndios que surgem no meio do caminho. Assim a Toyota lida com a causa dos problemas uma única vez, ao invés de lidar com as consequências várias vezes. Perguntar “por que” fundamenta a cultura de curiosidade que ajudou a Toyota a crescer sempre, não apenas porque os funcionários resolvem de vez os problemas, mas porque assim as pessoas aprendem, mudam de idéia, aperfeiçoam as que já possuem.

As empresas mais interessantes para trabalhar já perceberam o quanto precisam de pessoas capazes de aprender. Não é mais o caso de requerer um currículo com uma lista de siglas, mas de encontrar alguém que possa fazer essa lista crescer. Isso é imprescindível para software porque não existe uma tecnologia só para resolver todos os problemas, não existe um framework para preencher a vaga em todo e qualquer projeto. Você até pode tentar, afinal, faz sentido usar o que já se sabe, tanto que experiência é o item mais citado nas vagas de emprego. Está aí também o motivo pelo qual as empresas tentam usar uma gama pequena de tecnologias para desenvolver todos os projetos que chegarem à fabrica. Só que isso não precisa ser excludente com olhar pela janela para perceber o quanto outras alternativas podem ser bem mais interessantes, mesmo nos casos onde você já imagina como resolver o problema com o que já conhece.

ps.: Não que esse post seja tão bom assim, mas como curiosidade é importante para mim, resolvi renomear o blog para “Motor Curiosidade”. Acho um nome melhor do que o antigo.


Analogias são uma maneira poderosa de explicar algum conceito: parte-se de um principio já conhecido e estabelecido para tentar explicar ou mesmo formar um outro. Tome como exemplo explicar uma escala baseada em outra (“se X é um fusca, então Y é uma ferrari”): o conhecimento prévio sobre um fusca e uma ferrari é transportado para X e Y, seja lá o que forem. Mas, apesar de analogias serem usadas como uma ferramenta poderosa para dar explicações, algumas podem apenas direcionar para concepções erradas e por vezes desastrosas. Em desenvolvimento de software não faltam analogias. Desenvolver software é como construir prédios; é como criar uma linha de produção; é como fazer um filme e tantas outras que não chegaram a ganhar algum destaque.

Traffic due to filmingEmbora algumas analogias pareçam completamente razoáveis, sequer chegam perto do que é realmente desenvolver software. Não é como construir casas. Derrubar e repintar paredes é, por vezes, trivial em software, mas não é quando se trata de cimento e tijolos de verdade. Começar de cima para baixo não é razoável quando se constrói casas, mas pode ser quando se desenvolve software. Não é como uma linha de produção porque não existem, nos bons projetos de software, divisões tão fortes e distintas separando cada uma das fases. Por fim, não deveria ser como fazer filmes já que estouros de tempo e orçamento não são bem vistos e eu nem preciso de uma analogia para explicar isso. Mas existe uma analogia que eu considero certeira: Desenvolver Software é Como Dirigir. Ela foi feita por Kent Beck no eXtreme Programming Explained: “Driving is not about getting the car going in the right direction. Driving is about constantly paying attetion, make a little correction this way, a little correction that way”. No livro esse trecho é usado para dar uma idéia a respeito XP, algo sobre não criar planos impossíveis de serem seguidos por resistirem às mudanças. É sobre como é mais sensato pensar onde se quer chegar e reagir de acordo durante o caminho, da mesma maneira como é dirigir: você pensa onde quer chegar, pensa nos caminhos e reage a engarrafamentos, acidentes, semáforos, buracos e pedestres.

Só que nós podemos levar essa analogia um pouco além.

Uma porção de motoristas, a maior parte que eu conheço, para falar a verdade, tem algum seguro contra acidentes ou roubo. Seguro é uma maneira que os motoristas encontraram para se proteger quando algo extremo acontece – caso de um acidente ou roubo. Mas não são os únicos mecanismos já que temos air bags, cintos de segurança, freios de ultima geração, e mais uma porção de acessórios prontos para nos ajudar nesses casos extremos. Entretanto, bons motoristas sabem que nem seguro e nem acessórios são itens melhores do que direção defensiva. Você não acelera mais do que o necessário porque existem limites de velocidade, não ignora sinais vermelhos, se mantém atento quanto aos outros carros para ficar a uma distância considerada segura. E isso o tempo todo, afinal é melhor ser cuidadoso do que experimentar os air bags. Acidentes causam muitos danos: lesões físicas, traumas, falta de confiança – para esta última, basta perceber como a maior parte dos clientes encara com desconfiança os projetos de software.

Com software não é diferente. Você pode até ter seguros, geralmente em forma de contratos estipulando perdas e ganhos quando casos extremos acontecem, mas se manter atento para evitar acidentes é mais razoável, principalmente quando é o passageiro – no caso o cliente – quem sofre mais com as conseqüências. Boas práticas, testes automatizados e integração contínua são algumas maneiras que os bons desenvolvedores encontraram para dirigir defensivamente, elas dão suporte para reagir quando o trânsito muda e ajustes precisam ser feitos. Não pára por aí, assim como bons motoristas se preocupam em oferecer feedback aos outros (vide as sinalizações feitas, ou mesmo alguém alertando sobre uma porta aberta), bons desenvolvedores se comunicam bastante para prover as setas e alertas necessários.

Já passamos por muitos acidentes, tanto em desenvolvimento de software quando na direção de carros. Outros acidentes virão, seja por nossa culpa ou por causa de desenvolvedores desavisados, mas é preciso aprender com cada um deles para criarmos softwares melhores.