Keep Learning Conhecimento nunca é o bastante

Comprometa-se consigo mesmo.

Uma frase que ouço com frequência é: “não se comprometa com trabalho feito para outros, apenas com um negócio próprio”. Bom, tenho que dizer que isso é um perfeito discurso de perdedor. Primeiro porque, em geral, as pessoas que falam isso estão trabalhando para outras. Segundo porque elas não tem coragem para assumir riscos e começar um negócio próprio.

Isso costuma ser trazido muito à tona em conversas com amigos e conhecidos pois prefiro trabalhar em startups em oposição à empresas grandes e tradicionais. De alguma forma, startups estão ligadas a profissionais mais comprometidos, o que nem sempre é verdade, e muitas usam esse “status” para exigir longas e estafantes jornadas de trabalho. Ninguém deve se comprometer com esse tipo de vida, seja a empresa uma startup ou não.

Não consigo me imaginar passando oito horas por dia fazendo algo com que eu não tenha comprometimento e não acredite que vai dar certo. E isso não é exclusivo à startups: esse tipo de atitude é necessária esteja você trabalhando em uma startup com mais três pessoas, em uma corporação gigantesca ou no seu próprio negócio.

Você iniciaria uma empresa para fazer algo em que não acredita? Penso que não. Então por que em um emprego “normal” isso seria diferente? Fazendo uma conta bem básica, são cento e sessenta horas por mês, durante trezentos e sessenta meses (equivalente a trinta anos), o que dá seis anos e meio continuamente fazendo algo que você não dá a mínima.

Enquanto você não inicia seu próprio empreendimento (talvez nunca), a solução é encarar o “trabalho para os outros” como seu empreendimento. Afinal, é isso mesmo o que ele é. O lucro (ou prejuízo) final pode não ficar na sua mão, mas o trabalho que você realizou e a sua satisfação com ele não dependem disso.

Se você não consegue enxergar isso como possível, é um ótimo sinal de que você deve parar de se lamentar e iniciar seu empreendimento. Comprometa-se consigo mesmo, independente do fato de, no momento, você ter um chefe ou ser o chefe.

Sentinel: agora, mais transparente do que nunca

Em Janeiro criei a gem Sentinel, que provê a funcionalidade do padrão Observer de forma transparente para código Ruby. Bom, olhando os exemplos de uso da primeira versão, é possível perceber que a biblioteca não é tão transparente assim: apesar de não alterar os métodos observados, a classe subject tem conhecimento do observer, o que não é bom (nos comentários do post linkado acima falo sobre um “hack” para contornar isso, mas não é uma solução elegante).

Com o amadurecimento da ideia e algumas alterações no código, foi possível tornar a biblioteca totalmente transparente do ponto de vista do subject a partir da versão 0.2.0. Segue um exemplo (ignore a “inocência” do código):

class User
  def save
    ...
  end
end
 
class UserObserver
  include Sentinel
 
  observe User, :save
 
  def self.notify(*args)
    #método chamado antes de user.save
  end
end

Uma atual limitação é que a interceptação é sempre feita pelo método de classe notify do Observer. O plano é que isso seja flexibilizado em breve.

Sentinel: observers transparentes para seu código Ruby

Para uma determinada funcionalidade no Busk, precisava “trackear” todas as buscas feitas no site pelos usuários. Existem várias maneiras de conseguir esse resultado. Decidi por, de alguma forma, interceptar as chamadas ao método responsável pelas buscas (que faz o tratamento da query de busca enviada pelo usuário e chama o Sphinx). Uma das formas de se fazer isso é através do padrão conhecido como Observer.

Existem algumas bibliotecas open source que implementam Observers em Ruby e até mesmo uma na própria linguagem. Porém, queria que a implementação fosse transparente, sem alterar nada no método observado, nem mesmo adicionando uma chamada para notificar os observers, como é feito na implementação mais comum. Daí nasceu a ideia de criar uma pequena biblioteca provendo essa funcionalidade através do recurso de aliasing do Ruby e o resultado foi batizado de Sentinel, disponibilizado como uma gem.

Com essa gem, é possível interceptar chamadas a métodos de instância ou de classe através de um simples mixin (veja o Readme da gem para mais informações). De forma declarativa, definimos qual o método a ser observado e qual será o Observer notificado (qualquer objeto que responda ao método notify).

Sinta-se à vontade para sugerir modificações e notificar erros.

Desenvolvedor, arquiteto, programador, engenheiro…

É realmente necessário ter equipes de arquitetura separadas de equipes de desenvolvimento? Essa pergunta é muito antiga e cada um tem uma resposta. Pra mim, não. Mas vamos pensar mais sobre isso.

Em primeiro lugar, o que é um arquiteto de software? É um desenvolvedor com muito conhecimento e experiência (minha resposta)? É um profissional diferente, especificamente treinado para a arquitetura de sistemas? É alguém que possui algum “dom” especial?

O cargo de “Arquiteto de Software” como empregado hoje na indústria do software é mais uma herança ruim da comparação entre desenvolvimento de software e construção civil. Nesta última, o arquiteto faz o projeto mas, em geral, não suja as mãos no cimento. O ponto é: arquitetar um sistema de software é ou não é fundamentalmente diferente de construir software, isto é, programá-lo, testá-lo e mantê-lo? Não. Existem algumas diferenças e algumas preocupações diferentes mas é impossível dissociar as atividades no nível em que é feito em outras áreas.

Um fato interessante é que apenas empresas grandes, com orçamentos folgados (que, em geral, desperdiçam tempo e dinheiro com futilidades e becos sem saída) costumam oferecer o cargo de arquiteto de software. Eles geralmente ficam em equipes de arquitetura, longe das equipes que “sujam” as mãos no código no dia-a-dia. Ora, isso, por si só, cria as Torres de Marfim e uma certa animosidade latente entre as diferentes equipes – que deveriam trabalhar em conjunto todos os dias.

Não faz sentido (e não é eficiente) ter equipes de arquitetura separadas, sem contato direto e constante com as equipes de desenvolvimento. Também não faz sentido empregar arquitetos de software que só planejam e não participam da execução diariamente.

Usando a já batida metáfora do desenvolvimento de software como jardinagem é fácil perceber que estamos longe do processo utilizado, por exemplo, na construção civil ou na indústria automobilística. Não é possível projetar todo o software com antecedência, como um prédio ou um carro, comprar a matéria-prima, contratar os operários e implementá-lo praticamente sem desvios. O projeto é o software e o software é o projeto.

Podemos, sim, ter um plano geral, um conjunto de guias e processos a serem seguidos, interfaces definidas, padrões e tudo mais, mas é preciso adaptação rápida à mudança. Na criação (e não construção, isso é importante) de um jardim, uma planta pode não se desenvolver por um entre vários fatores. Na criação de software, uma especificação da equipe de arquitetura pode não se encaixar nas necessidades do projeto.

Se houver uma “equipe de arquitetura” como uma entidade especial, separada, perde-se muito tempo para reagir às mudanças. Se os arquitetos são do tipo que se acha bom demais pra se sujar na programação as conseqüências são ainda piores – em primeiro lugar porque eles não tem noção da realidade do projeto enquanto fazem os planos e, em segundo, porque tendem a resistir à mudanças no que consideram um plano perfeito.

Se insistíssemos em utilizar a metáfora da construção civil, podemos comparar todo o ciclo de desenvolvimento de software com o ciclo de arquitetura e projeto de um edifício, excluindo sua construção. O desenvolvimento de software é uma atividade criativa, não “mecânica”.

Um desenvolvedor de software que não se atenta à arquitetura, que não tenta melhorar nos fundamentos básicos necessários ao entendimento do software como um todo, não passa de um programador – um mero codificador, facilmente substituível.

Um arquiteto de software que não programa, não se envolve com o dia-a-dia da produção de software e não se interessa pelos outros aspectos da disciplina, não passa de um “masturbador mental de software“. Daí para o que os americanos chamam de “Death by PowerPoint” leva um piscar de olhos.

Sim, é necessário que tenhamos a figura do “líder técnico”, aquele desenvolvedor com bastante experiência e jogo de cintura, que já viu e já fez de tudo na área. Ele, inclusive, pode ter o cargo formal de arquiteto de software. O que não pode acontecer é que ele seja um profissional isolado em uma esfera de cristal, um “deus” criando o que ele pensa ser adequado, dando ordens e ignorando eventuais questionamentos de sua intocável arquitetura. Isso é tudo o que um time de verdade não precisa.

Em resumo, um bom desenvolvedor é também um bom arquiteto. E um bom programador. E um bom qualquer coisa que seja necessária para criar software consistentemente.

Sobre investimentos, startups, limitações e tudo mais – em um parágrafo

“This is one of the reasons I encourage entrepreneurs to bootstrap instead of taking outside money. On day one, a bootstrapped company sets out to make money. They have no choice, really. On day one a funded company sets out to spend money. They hire, they buy, they invest, they spend. Making money isn’t important yet. They practice spending, not making.”

– Jason Fried (37signals) em “Making money takes practice like playing the piano takes practice”

Escrevi dois posts para, no fim das contas, não conseguir expressar a mensagem. Minha falha foi tentar explicar demais o raciocínio ao invés de simplesmente expressar a conclusão (e ainda causei alguns acidentes no caminho). Pronto, através das palavras do Jason Fried, está aí tudo que eu quis dizer sobre o tema.

PS: Sim, os dois posts anteriores foram para o limbo. Como em todo processo criativo iterativo, as tentativas fracassadas podem ser descartadas.