Pré-Processadores CSS: um passo em frente, dois atrás?

Oi,

Para os aficionados do Rails, o advento dos pré-processadores não é mais uma novidade. Tema aflorado ao de leve e terrívelmente programado em versões pré-3 do Rails através dos infâmes templates RJS, ganharam uma importância renovada assim que o Coffeescript e o SCSS foram adoptados como escolhas pré-definidas do esqueleto de uma aplicação nova a partir do Rails 3 (alguns de vocês devem ter notado as linhas adicionadas ao vosso Gemfile inicial) e o HAML foi adoptado como o formato preferido da comunidade para escrever os seus templates. Gosto de avaliar imparcialmente todas estas adopções da comunidade em termos do benefício para a minha produtividade, adequação às novas técnicas, "efeitos secundários" (por exemplo, se é compatível com HTML5, se o meu IDE de eleição reconhece a linguagem e existe suporte "ir-para"), entre outros factores mais contextuais.

Preferindo me referir a conteúdo (HTML) e comportamento (Javascript) em uma outra ocasião, gostava de me concentrar na parte da apresentação (CSS), aquela em que reconheço mais benefícios do pré-processamento para a vida de quem mantem o código (ou a especificação, se quisermos ser puristas e lembrar que CSS não é realmente código).

Para quem é do tempo que se escrevia CSS "à pata", sabe do que eu falo quando eu digo que esta foi provavelmente a tarefa menos programática, mais inconsequente e mais predisposta a erro humano que já colocaram nas mãos de um profissional na área da informática. Isso deve-se a várias razões, a maior delas, que será importante para a minha conclusão, sendo a de que apresentação não é tarefa para engenheiro, cientista ou simples programador informático.

O CSS foi desenvolvido como uma especificação de apresentação para generalizar regras de renderização para os elementos HTML pertencentes a um documento segundo uma estrutura ramificada. A primeira especificação foi completada em 1996, o que em anos Internet é equivalente ao tempo do Antigo Egipto. À medida que as necessidades do mercado se impuseram, as aplicações se tornaram cada vez mais polidas e ambiciosas visualmente e a adopção da especificação dos navegadores se fragmentou, começando a surgir os primeiros problemas.

A minha primeira experiência com CSS coincidiu com o meu primeiro emprego e com a minha introdução à ferramenta Ruby on Rails, por volta de 2008. 4/5 desenvolvedores mantinham os ficheiros CSS de duas aplicações, cada uma delas com significativa envergadura, e logo, diferentes requisitos visuais. Todas as regras CSS estavam espalhadas por 3 ficheiros, pois na altura não existiam pré-processadores e os desenvolvedores mais experimentados diziam que 3 ficheiros era o máximo que os navegadores podiam carregar concorrentemente sem perdas de performance para o usuário (ou o seu navegador). Existiam algumas pré-directivas para decidir em que ficheiro entrava determinada regra, tentávamos usar comentários para estruturar as áreas a que as regras se referiam, tentávamos optimizar os espaços brancos, mas no geral, à medida que novas funcionalidades e características eram introduzidas separadamente, o esforço redundava em fracasso. Outra curiosidade era que puros desenvolvedores, gente que coda, é que tratava de escrever as especificações de elementos visuais para os quais não haviam regras matemáticas definidas, somente um esboço enviado pelo designer de serviço. A situação proporcionava a tarefa diária de falar directamente com o designer para se informar do código hexadecimal de certa cor, ou qual a distância entre elementos, ou informar que determinada imagem ainda não tinha sido entregue, algo que achava extremamente ineficiente e até tristemente cómico. CSS tornou-se o meu pesadelo de desenvolvimento, com o qual lidei nos meus projectos seguintes.

Alguns dos problemas que experienciei nos tempos pré-pré-processamento podem ser assim mais sucintamente e claramente descritos:

- CSS não é linguagem de programação, mas é geralmente visto pelos decisores como tal, e quem geralmente mantém a especificação acaba por ser gente que programa.
- Requisitos visuais é algo que profissionais da informática não compreendem.
- Não havendo ferramenta de minificação, todo o esforço de compactar artificialmente a especificação resulta em menos legibilidade posterior.
- Designers, decisores, accionistas em geral, não testam em modo de desenvolvimento, somente em produção ou numa fase intermédia. Todas as listas de correcções resultantes só aumentam a confusão na priorização de tarefas do desenvolvedor.
- Designer sabe e escreve HTML e CSS. Que eles não participem no processo de desenvolvimento é de uma redundância extrema, já que quem desenha delega esta função para uma entidade que não "fala a mesma língua". Aqui posso também culpar a forma como as ferramentas (em que incluo o Rails) são arquitecturadas, não proporcionando uma integração fácil para um não-programador.
- Várias dificuldades na fragmentação do suporte de funcionalidades para diversas versões de diversos navegadores (estou a falar de um tempo em que nem o IE8 nem o Chrome existiam, e os prefixos ainda não tinham sido adoptados pelos desenvolvedores; desde aí a confusão só aumentou).

Os pré-processadores colmatam todas estas falhas? É difícil dizer... Penso que todos eles identificam falhas de design do CSS, pontos de melhoria, dificuldades de manutenção, e conseguem resultados bastante impressionantes, gerando outros problemas no caminho. Em alguns casos, surgem da frustração de programadores em terem que trabalhar com uma especificação que desconsideram. Noutros casos, são optimizações na forma de colaboração.

Sintaxe

Quem já tem alguma experiência tanto com SASS como com LESS consegue fazer a correspondência entre o formato prévio ao processamento e o CSS que é gerado:

/* SASS */ 

.botoes
  width: 230px
  a
    display: inline

/* CSS */
.botoes {
  width: 230px;
}
.botoes a {
  display: inline;
}

Adoptam-se aqui conceitos de linguagens de programação orientadas a objectos na forma como as regras são agrupadas e estruturadas mais relacionalmente, ganha-se clareza na leitura das regras e não existe um corte abrupto entre sintaxes (quem conhece CSS compreende facilmente tanto SASS, como LESS, como SCSS). O reverso da moeda aqui é que, só se concentrando na relação entre elementos, perde-se noção do CSS que é gerado, resultando em falhas de optimização nas regras de CSS que é no fundo o que é entregue aos navegadores. Um pequeno exemplo:

/* SASS */
.botoes
  width: 230px
  a
    padding: 10px 
    display: inline
  span
    padding: 10px 
    display: block

/* CSS */
.botoes {
  width: 230px;
}

.botoes a {
  padding: 10px; 
  display: inline;
}

.botoes a {
  padding: 10px;
  display: block;
}

em vez de:

/* CSS */ 
.botoes a, botoes b {
  padding: 10px;
} 

.botoes a {
  display: inline;}

.botoes a {
  display: block;}

A utilização do novo sintaxe implica uma maior atenção para identificar possíveis problemas de optimização. Mas há aqui um claro benefício na redução do número de linhas de código que se têm que manter em relação ao CSS correspondente.

Variáveis

Tanto SASS como LESS permitem a utilização de variáveis para identificar propriedades que de outro modo teriam que ser repetidas em vários pontos da especificação, tais como fontes ou cores. As aplicações web utilizam em geral o mesmo esquema de cores, com algumas variantes na tonalidade. Por exemplo, a cor dos links é a mesma de determinado ícone ou plano de fundo, entre outros. Em CSS, o código hexadecimal correspondente teria que ser copiado em várias regras. Caso algum dia a decisão fosse revertida em favor de outra cor, esse código teria que ser substituído em todos esses sítios, e provavelmente de algumas regras que não fariam parte do escopo dessa mudança. As variáveis não resolvem todas as falhas, mas facilitam a manutenção de tais propriedades.

/* SASS */

$blackbetty: #000

.botoes
  background-color: $blackbetty
.imagens
  background-color: $blackbetty 



/* CSS */
.botoes {
  background-color: #000;
}

.imagens {
  background-color: #000;
}

Mudar de cor, neste exemplo, implica reescrever uma linha de código, ao invés de duas.


Propriedades exclusivas dos navegadores

Ás sintaxes acrescentam-se outras ferramentas de pré-processamento destinadas a resolver outro tipo de problemas. Um deles é o pesadelo dos prefixos vendor. Muitas vezes os navegadores implementam propriedades específicas aos mesmos, que mais tarde são adoptadas por outros navegadores e posteriormente estandardizadas (um pouco virado do avesso, este processo). O processo de estandardização é geralmente longo, e os fornecedores não querem esperar para mostrar as funcionalidades aos clientes, quando só a especificação oficial é que falta. Na indústria dos navegadores foram então adoptados os prefixos vendor, que se destinam a identificar implementações de propriedades em um navegador (ou motor de renderização) que ou são específicas a esse navegador ou são uma primeira versão de uma propriedade que ainda se encontra em fase de avaliação pelo W3C (exemplos no CSS3). Tomemos como exemplo a propriedade border-radius. Todos os navegadores suportam a propriedade, providenciam uma especificação proprietária, mas nem todos suportam a especificação oficial. A forma mais segura que quem escreve CSS pode utilizar a propriedade bem-sucedidamente redunda no seguinte exemplo:

.arredondado {
  -moz-border-radius: 10px;
  -khtml-border-radius: 10px;
  -webkit-border-radius: 10px;
  border-radius: 10px;
} 

Esta regra tem as vantagens de ser compreendida pelos motores de renderização mais utilizados no mercado, ser eficiente (os motores de renderização começam pela última regra, logo privilegiam a forma estandardizada e ignoram a proprietária caso a identifiquem), mas é altamente desvantajoso do ponto de vista de manutenção por representar 4 linhas de especificação para manter. E esta propriedade é até relativamente simples de manter no formato crú em comparação com outras em que a ordem dos argumentos varia de prefixo para prefixo. Existem duas (que eu conheça) bibliotecas/ferramentas em ruby que nos facilitam a vida, com sintaxe semelhante para estes casos, o bourbon e o compass. Ambas estabelecem um conjunto de funções SASS mapeadas a cada propriedade ainda não estandardizada que no acto do pré-processamento são substituídas pelas versões proprietárias nas regras onde são declaradas. A regra acima descrita seria então escrita do seguinte modo:

/* Bourbon / Compass */
@include border-radius(10px);

Uma linha de código para manter.

Sprites

Uma das optimizações mais importantes quando se constrói uma aplicação web é a redução do número de pedidos HTTP que um documento dispara. Uma típica aplicação moderna geralmente utiliza muitas imagens na sua experiência de utilização, o que tem influência no tempo de carregamento total de uma página web. Uma típica forma de optimizar esse processo no CSS é colocar todas as imagens utilizadas em uma aplicação no mesmo ficheiro e fazer uso da propriedade background-position para renderizar cada componente incluída.

a {
   background-image: ("button.png");
}

a:hover {
  background-image: ("button-pressed.png");
}

a:active {
  background-image: ("button-active.png");
}

O exemplo acima descrito (em CSS puro) representa 3 diferentes estados de um elemento e apresenta uma diferente imagem de fundo para cada um, cada uma delas num ficheiro diferente. O exemplo acima descrito implica 3 pedidos HTTP diferentes ao servidor web pelas imagens. Todos estes pedidos, ou a latência por eles provocado, aumentará o tempo de carregamento de uma página e o atraso na renderização dos elementos visuais para o usuário, o que em casos extremos pode dar-lhe tempo para preparar um café enquanto espera ou simplesmente fechar a página e voltar ao Facebook. Comparemos agora com o exemplo seguinte, também em CSS puro.

a {
   background: url("images/buttons.png") no-repeat;
   background-position: 0 0;
}

a:hover {
  background: url("images/buttons.png") no-repeat;
  background-position: 0 -20px; 
}

a:active {
  background: url("images/buttons.png") no-repeat;
  background-position: 0 -40px,
}

Neste caso só existe um ficheiro (chamado na gíria sprite) contendo as imagens dos diversos estados do botão a ser baixado do servidor web. Um pedido HTTP,  uma clara melhoria de performance no carregamento da página. Já a manutenção dificultou. Quem estiver responsável pela introdução das imagens na página tem que saber agora de antemão a posição da imagem desejada no ficheiro e escrevê-la explicítamente. Não só isso, se dois desenvolvedores diferentes necessitarem de introduzir uma nova imagem correspondente a um novo estado no mesmo ficheiro, e contando que trabalham em dois terminais diferentes e utilizam um sistema de versionamento do código, não podem reposicionar as imagens que já existem, têm que contar que o colega não insira a imagem deles exactamente na mesma posição em que eles inserem, e no final, nada disso vai ajudar, porque muito provavelmente o sistema de versionamento não consegue fundir ficheiros em formato binário, só textual, o que vai implicar posteriormente e conjuntamente reposicionar as novas imagens, recalcular as posições e reescrever as regras. Dizem que este processo de desenvolvimento é responsável pela maior parte dos casos de violência doméstica a nível mundial.
Existem duas formas de tentar contornar este problema no universo Rails. A primeira é recorrer a funções SASS. Desta forma, poder-se-ia descrever programáticamente a posição de uma imagem no sprite. Da minha experiência, acaba-se por deixar a nova programatização definar a visualização, privilegiar a generalização, e acaba por se perder controlo na optimização do CSS resultante de novo. A outra forma é usar a ferramenta Compass. Esta tem uma propriedade muito interessante: deixa-nos ter as imagens em ficheiros diferentes, permitindo-nos declará-las separadamente como no primeiro exemplo, e o pré-processamento vai fundir essas imagens num sprite, calcular o seu posicionamento e escrever o CSS correspondente.
 

/* SASS/Compass */
@import "buttons/*.png";
@include all-buttons-sprites;

a
  @include buttons-sprite(button);
  &:hover
    @include buttons-sprite(button-pressed);
  &:active
    @include buttons-sprite(button-active);

/* CSS */
.buttons-sprite, a, a:hover, a:active {
   background: url("/images/buttons-2323r3r32s21swed.png") no-repeat;
} 

a {
   background-position: 0 0;
}

a:hover {
  background-position: 0 -20px; 
}

a:active {
  background-position: 0 -40px,
}

Voltemos ao nosso cenário dos dois desenvolvedores suicidas. Cada um deles vai introduzir um ficheiro diferente no directório correspondente e declará-lo na regra SASS respectiva. Ao submeter as mudanças para o controlo de versionamento, este vai identificar dois ficheiros binários diferentes em vez de um binário alterado separadamente, não vomitando conflitos. Com o tempo ganho os dois desenvolvedores decidem beber uma cerveja juntos.
Para mim só existem vantagens no processo em si. As desvantagens advém do suporte da ferramenta para determinados casos de uso: ao que sei ainda não existe suporte para geração de sprites em formato SVG (é no entanto algo que está planeado) e a geração do sprite final está optimizada para 24-bits, algo que pode causar problemas em navegadores mais antigos como o famigerado IE6 ou mesmo para transporte por redes 3G para dispositivos móveis. Não é no entanto um estado definitivo.

Concatenação

Outra das grandes desvantagens dos tempos anciãos era ter que escrever todas as regras no mínimo de ficheiros, não se podendo separar contextualmente. O SASS permite importar regras de ficheiros diferentes, através do @import. Deste modo podemos, por exemplo, colocar todas as regras para botões num ficheiro SASS diferente, e importá-lo no ficheiro principal declarado no documento.

/* SASS */
/* buttons.sass */
a
  color: green

/* application.sass */

@import "buttons"

.content 
  width: 200px

/* CSS */
/* application.css */
.content {
  widht: 200px; 
}

a {
  color: green;
}

A vantagem neste caso é podermos separar as regras contextualmente e termos desta forma o código fonte mais manutenível. Mas esta abordagem tem outra desvantagem: limita-nos o debugging em modo de desenvolvimento. Se utilizarmos uma ferramenta como o Firebug ou a consola do Chrome para inspeccionarmos as regras CSS acima descritas, a regra para o elemento 'a' vai estar identificada como pertencendo ao ficheiro application.css na linha 5, o que não corresponde ao nosso código fonte SASS. Num projecto com diversos ficheiros .sass pode dificultar-nos a identificação do ficheiro onde determinada regra inspeccionada está descrita.
Esta desvantagem pode ser mitigada recorrendo ao sprockets, uma biblioteca Rails que pretende centralizar as estratégias de pré-processamento, compilação e minificação tanto para apresentação (suporta SASS, LESS e SCSS) como para comportamento (Coffeescript). Em modo de desenvolvimento, por exemplo, os ficheiros .css entregues ao navegador são distribuídos separadamente quando declarados num ficheiro css que actua como manifest.

/* SASS */
/* buttons.sass */
a
  color: green

/* application.css */
//= require buttons

.content 
  width: 200px


/* CSS modo dev */

/* application.css */
.content {
  widht: 200px; 
}

/* buttons.css */
a {
  color: green;
}

Mesmo que o número da linha não seja o correspondente à sua versão SASS (isto é um problema de debugging do SASS em geral), pelo menos conseguiremos identificar o ficheiro onde a regra se encontra.

Pré-Processamento e Minificação

O ambiente de desenvolvimento Rails possui várias ferramentas que auxiliam a minificação de ficheiros .css há já bastante tempo. A biblioteca Sprockets simplesmente centralizou o processo. O deenvolvedor somente tem que declarar qual a biblioteca a utilizar (closure, uglifier, yui) e o sprockets insere o passo da minificação no processo de geração do ficheiro CSS. O que nos leva ao passo final da pilha. Depois de ter facilitado todo o processo de desenvolvimento com sintaxe, separação de ficheiros, etc..., o Sprockets centraliza em um passo (um comando) todo o processo de concatenação de todas as regras SASS em um único ficheiro .css minificado, entre outras tarefas relacionadas com outras tecnologias. Na verdade, pode ser gerado mais que um ficheiro .css final, sendo que para isso é necessário então mais que um ficheiro manifest. Uma ferramenta deveras flexível, que também dá acesso a funções auxiliares para gerar os caminhos absolutos (URI) das imagens utilizadas, cujo timestamp pode ter sido actualizado.


Conclusão

"Poh, tanta vantagem, pra quê esse título tão pessimista"? É, o título é um pouco exagerado. Na verdade, todas essas ferramentas (e outras que provavelmente me esqueci de referir), cada uma à sua maneira, conseguiu resolver cada um dos problemas que fui tendo desde que comecei a trabalhar em aplicações web. Mas resolveu exclusivamente problemas de desenvolvedor. Os outros foram esquecidos.

O HTML e as suas extensões, como o XHTML, foram publicitados na sua incepção como ferramentas para designer. O objectivo aqui seria provavelmente introduzir o designer em tarefas de templatização do lado do cliente e libertar os desenvolvedores para tarefas funcionais do lado do servidor. O CSS foi visto como a extensão apresentacional do HTML, logo foi sempre visto como uma ferramenta de designer, tanto que estes são formados nas duas especificações. No entanto, as várias ferramentas desenvolvidas para acelerar o processo de desenvolvimento web seguiram a direcção de ligar todas as componentes, sem estabelecer uma ponte invisível entre os dois contextos (o que se vê/ o que faz). As velhinhas JSP (Java Server Pages) foi das primeiras ferramentas populares que embebia código Java nos templates HTML. O PHP vive de ser embebido em templates HTML (e é muito popular entre designers). E a biblioteca por defeito usada pelo Rails na geração de HTML é o ERB, que permite embeber código Ruby dentro de templates HTML (o HAML aplica uma metodologia semelhante). Todos eles contribuíram para, em projectos de larga escala, afastar cada vez mais o designer do HTML ou forçá-lo a aprender a programar. Os projectos Rails estão pejados de gente que faz a ponte entre os dois mundos, gente que programa e desenha, e que os torna em "donos do projecto" e relativamente ineficientes nas duas tarefas que têm a cumprir (50% do tempo, 50% da produtividade). Já no caso em que eles se afastam, caso queiramos reverter o processo e trazê-los de novo para O HTML e o CSS, tenho as minhas reservas quanto aos pré-processadores. O problema em geral das ferramentas que nomeei é que são mais paradigmáticas para gente de informática. Para o designer trabalhar com SASS, tem que aprender não só a sintaxe, mas a integrar a tecnologia. Ora, ele já sabe CSS, e este é ubíquo nos navegadores. Qual é o valor profissional que o SASS tem para ele? Vale a pena a longo prazo ou é para um projecto de 8 meses? O próprio Compass é uma ferramenta mais usada na comunidade Rails e muito dirigida pela linha de comandos (o que é um vade retro para designers), ainda não existindo uma integração convincente para ambientes de desenvolvimento front end.

Reconheço as vantagens para mim. Mas para a indústria em geral? Só o tempo o dirá.

Na beira do abismo, dar um passo em frente

Oi

Feliz 2013 e isso tudo, foi bom e sobrevivemos, facto não somenos importante. Mas adiante, que a Terra girou, o tempo passou e a altura para novos voos chegou. É, estou no mercado, levantando a calçinha para quem der mais e melhor, porque é assim a ordem natural das coisas. Porquê, perguntam-se? Acho que foi um conjunto de razões pessoais e profissionais, algumas das profissionais sentidas muito pessoalmente. Primeiro, sou pago abaixo do meu nível. Sou estrangeiro em terra estrangeira, facto muitas vezes aproveitado pelos empregadores de países relativamente desafogados, que vêem uma oportunidade para prestar serviço social ao meu país enquanto baixam os custos operacionais. Infelizmente não consegui fazer valer os meus trunfos da melhor forma quando aceitei este emprego, algo que tenho tentado corrigir desde então. Segundo, não me sinto valorizado profissionalmente. Como assim? Passado mais de um ano e continuam a atribuir o mesmo tipo de tarefas chatas que te entregavam no início. Por agora devem estar a pensar: "porra, se te dão as mesmas tarefas chatas é porque tu provavelmente não mostraste competência para mais, né? Bruxo.". Penso que não foi isso. Tem mais a ver com a situação em que me encontro.

Introdução

Faço parte de uma equipa de desenvolvimento formada por 3 pessoas, ate há 1 mês por 4. Um de nós é o encarregado pelas operações IT (CTO a partir daqui). Faz basicamente administração do sistema e servidores, trata da distribuição das iterações, para além de (pouco) desenvolvimento. É, um pouco por causa da posição que detém, considerado o "líder" do grupo. O outro é o auto-proclamado "Chefe dos Designers". Quando entrei na empresa, perdia cerca de 40% do tempo no tratamento da apresentação das aplicações web, e no resto do tempo programava. Hoje praticamente só programa, apesar de manter o mesmo título. ("ex-designer" a partir daqui). É responsável directamente por grande parte do código e indirectamente pela maior parte dos problemas de que sofremos de momento (já voltarei ao tema). O membro que falta (recém-saído da empresa) era desenvolvedor a tempo inteiro, saído 9 meses antes da sua entrada na empresa da universidade (estava há 3 meses na empresa quando entrei) e com pouca experiência no desenvolvimento web, embora com vontade para aprender ("outro" a partir daqui). Quando entrei na empresa, caí num projecto já estabelecido, com uma base de código gigantesca e não documentada, e 4 meses depois iniciámos o desenvolvimento de raíz de um segundo projecto que veio a substituír o primeiro como prioridade de topo da empresa.

Avaliação da equipa de IT

Depois de longa análise, entendi que me encontrava numa equipa em estado avançado do princípio de Peter. Para o compreender é preciso ter em conta a história da empresa anterior à minha entrada.
O projecto foi iniciado 3 anos antes da minha entrada. Na altura, faziam parte da equipa 3 desenvolvedores, e durante esses 3 anos o número de membros oscilou sempre entre 3 e 5. O CTO anterior era respeitado pela comunidade ruby do país e desenvolveu alguns projectos interessantes. Devido ao turnover relativamente moderado e número baixo de elementos-núcleo, nunca chegaram a implementar medidas de colaboração na equipa. Implementavam extreme programming ao máximo. A dívida técnica foi-se acumulando. Entretanto chegou à empresa um estagiário, desistente de uma escola de cinema, para completar tarefas de design. Foi desempenhando a sua função de modo satisfatório, razão pela qual eu penso que o convidaram para se juntar a tempo inteiro à equipa, com enfoque especial na colaboração directa com a equipa de IT e no design da plataforma. Travou amizade com um dos membros da equipa de IT e começou a desenvolver interesse pelo lado da programação, tanto que começou a fazer uma perninha em algumas tarefas nesse âmbito.
Cerca de 6/7 meses antes da minha entrada, o CTO original decide doutorar-se e procurar outras pastagens, decisão que possivelmente terá causado algum pânico, pois numa empresa com tão poucos empregados, o conhecimento é geralmente muito centralizado. Um dos outros membros da equipa inicial também decide sair, sobrando o terceiro membro para carregar a bandeira. Imagino que tivesse pouca experiência com a administração dos servidores e tenha sido instruído da melhor e mais rápida maneira possível. O que é irrelevante para a discussão. Não só isso, como um segundo membro importante da equipa saía, tinham que suprir da melhor forma a falta desse outro recurso. O resultado? O estagiário-agora-membro designer passou a fazer mais que uma perninha, passou a enfiar as duas mais um braço. Chegados ao momento da contratação do meu colega "outro" recém-saído, faziam então parte da equipa um dos desenvolvedores iniciais, com 0 experiência de liderança e a dar os primeiros passos na administração do sistema, e um sujeito que passou de designer estagiário a membro em regime de tempo parcial da  equipa de desenvolvimento em menos de 2 anos. Ambos (o primeiro principalmente) eram então os responsáveis por uma base de código e conteúdos gigantesca (para cima de 30 tabelas na base de dados) e não documentada.
Pausa para reflectir: Ficaram vagas por preencher que exigiam alguma responsabilidade e experiência. Duas possibilidades: procurar pessoas com o mesmo grau de competência para preencher as posições em falta (a opção inteligente) ou promover elementos da equipa (a opção mais barata). Alarme Princípio de Peter. Primeiro sintoma? Ao receberem o novo elemento na equipa, não o integraram na base de código existente de maneira a facilitar a sua adaptação, mas responsabilizaram-no pela integração dos serviços da plataforma numa plataforma embebível no facebook. Um outsourcing quase interno. Esta era a ocupação do novo elemento quando eu entrei na empresa.
Qual era o meu perfil à altura da entrada? Eu era alguém já experienciado no desenvolvimento web e Rails, relativamente independente. Não era nenhum ás, mas já tinha bastante confiança tanto com a framework como com a linguagem de programação. Esperava-se de mim, pelo que entendi, preencher a vaga do segundo membro original de imediato e com o passar do tempo responsabilizar-me por tarefas de manutenção dos servidores que eram do encargo do CTO. Para além disso iria iniciar-se o desenvolvimento do tal segundo projecto mencionado acima, que foi pensado na altura como um spin-off da plataforma principal, e eu estaria na linha da frente no desenvolvimento desta. Apesar de não conhecer o passado da empresa, compreendi o que esperavam de mim, e fiz por isso. Completava as minhas tarefas e sugeria até algumas melhorias à plataforma existente. Exemplo? Cada utilizador da plataforma tinha um mural como o do facebook, onde se formava uma corrente de posts vindos da própria plataforma e das redes sociais associadas à conta. No meio do conteúdo vinham links, que eram apresentados como links textuais. Eu desenvolvi um widget para embeber esses links nos posts, por iniciativa própria. Não o escrevo para me gabar. Quero somente esclarecer que, enquanto aqui estive motivado, produzi, colaborei, dei o corpo ao manifesto, não tomei nada por garantido. Outros exemplos? Na primeira semana, pedi documentação do projecto ao CTO, do qual ouvi a resposta "aqui nunca precisámos". Quando insisti que, enquanto membro novo da equipa, precisava eu, respondeu-me que iria "tratar disso". Passaram 3 meses, altura em que sugiro uma apresentação sobre documentação à equipa de desenvolvimento e apresentei várias ferramentas para rails e javascript que nos permitiam documentar o nosso código e apresentar a documentação em formato HTML... excepto para javascript, que não tinha um gerador de HTML fiável... e aí eu programei um. E passámos a ter documentação. Durante cerca de um ano implementámos scrum na equipa, por minha sugestão. Como eu disse, eu tava aqui para melhorar a mim e aos que me rodeavam. Jogador de equipa, camisa 10, distribuindo passes, "there is no I in TEAM".
Com o passar do tempo, a situação foi-se estagnando. Nunca cheguei a aprender da administração dos servidores. Nunca cheguei a assumir novas responsabilidades. O único projecto que me passou totalmente para as mãos, o desenvolvimento de uma REST API para a plataforma secundária-agora-principal, foi minado desde o início pelos membros anciãos da equipa, desde a escolha da framework (3 meses depois de iniciado o desenvolvimento) até à prioridade de integração no projecto principal (não está ainda em produção, e provavelmente vou sair da empresa sem que esteja). Passou-se o mesmo com as responsabilidades de administração do servidor, que nunca cheguei a tomar para mim. E com os outros, o que se passou?

• CTO: Com a perda de importância gradual da plataforma inicial foi cada vez tendo menos mão na parte do desenvolvimento, preocupando-se somente com a manutenção das iterações, integração contínua e administração do servidor. Escreveu alguns scripts para importar conteúdo externo de parceiros estratégicos; assumiu a posição de scrummaster nos nossos scrums, se bem que isso foi mais fruto da sua condição de CTO do que das suas qualidades de liderança naturais, as quais não possui; isso ficou bem patente na gestão dos conflitos pessoais e profissionais entre o ex-designer e o "outro", que chegou a incluir agressões verbais por e-mail. Nunca soube também gerir a descentralização de conhecimento na equipa, talvez devido à sua falta de interesse no assunto. Partilhar o seu conhecimento representava delegar tarefas e perder importância no grande esquema empresarial. Notei também o seu enfado com a parte do desenvolvimento, para a qual já não contribuía tão activamente, salvo as ocasionais correcções de erros de produção ou recolocação de ficheiros em pastas diferentes. E quando menciono "desenvolvimento" no seu caso quer isso dizer desenvolvimento do lado do servidor, porque os seus conhecimentos do lado do cliente foram sempre insatisfatórios: o HTML era algo circunstancial para ele, o CSS algo que não compreendia bem e abominava até (compreensível, sou tão pouco o maior fã), mas algo que eu não compreendia era como o seu javascript era tão pobre. Era tão pobre que ele delegava responsabilidades nesse departamento ao ex-designer, muito mais interesado nessa vertente. E: nunca soube separar a relação de amizade da de colega de trabalho com o ex-designer, algo que certamente não ajudou.

• Ex-designer: Com o envolvimento cada vez maior no desenvolvimento da nova plataforma, a sua importância aumentou. Como aconteceu esse aumento de envolvimento? Quando foi dado o "ok" para o início do desenvolvimento, o design apresentado ainda não tinha sido totalmente validado pelo resto dos responsáveis na empresa. Isso levou a que sugestões aparecessem na fase de apresentação de determindadas funcionalidades tais como o motor de busca, sugestões essas invasivas que criavam incerteza, tanto no desenvolvimento como no design. Eis que o ex-designer, já programador oficial, se fechou em copas quanto ao design, e começou a desenvolver a plataforma sozinho, de acordo com o que achava que seria melhor. Ou seja, foi desenhando e programando ao mesmo tempo sigilosamente. Debatia as suas decisões (quando debatia) com um círculo muito fechado de pessoas. Quando a plataforma foi lançada, era claro que o nosso amigo ex-designer se tinha tornado de facto parte integrante da equipa de desenvolvimento a tempo inteiro. Toda esta situação e a importância que adquiriu ajudou a que a sua atitude se tornasse cada vez mais pedante para com os seus colegas, excepto claro para com o seu grande amigo CTO. Escusado será dizer que ainda sofremos hoje tanto com as suas decisões técnicas, que tem sido refactorizadas há mais de um ano mas estão ainda longe de resolver tudo, como com as suas decisões relativas ao design, que por sugestão de um dos então investidores, teve que ser totalmente reformulado três meses depois. Falando de decisões técnicas, vou mencionar 2 das minhas preferidas:
•  o sujeito, descontente com o estado do código javascript da plataforma anterior (e com razão, era esparguete até mais não), decidiu aplicar os seus conhecimentos adquiridos de programação para objectos ao código a ser executado no cliente, e desenvolve a sua mini-framework MVC para javascript, completa com renderização do lado do cliente utilizando uma biblioteca já na altura deprecada (sobre o que foi avisado). O desenvolvimento da framework incidiu bastante sobre aproximar a API de um objecto Javascript à de um objecto Ruby. A manutenção desta mini-framework MVC tem sido atribulada (a cada semana, aparece algum erro novo, ou algum método ou alguma assinatura de alguma API é removido, renomeado ou inserido). Está longe de ser uma ferramenta utilizada por todos os membros da equipa, devidos aos erros constantes provocados pelas mudanças. Agora vou só listar algumas frameworks open-source que pululam por aí: ember.js, backbone.js, angular.js . E concerteza há mais. Está tudo dito.
• o sujeito, descontente com a forma como a pesquisa era processada, com pedido Ajax GET do navegador enquanto os parâmetros de pesquisa eram guardados no parâmetro cardinal (#) do cliente (html5 hashchange) (e especialmente com esta última, por não ser uma solução suportada fora-da-caixa no Internet Explorer 7), decide alterar totalmente toda a estrutura, introduzindo o conceito de objecto de pesquisa, onde são persistidos os argumentos da pesquisa. O formulário GET da página inicial passou a formulário POST onde os parâmetros da procura vão directamente parar à base de dados, passando o formulário da página dos resultados a responder com PUT, sendo cada pesquisa uma actualização do estado da pesquisa no servidor. E assim reinventou-se a roda... Resultado? Recursos alocados para guardar algo que não deveria ser guardado e que não representa valor para a empresa (a pesquisa); guardando o estado na base de dados, fez com que efectivamente a pesquisa deixasse de ter estado no cliente. Não entendem o que quero dizer? Experimentem implementar uma solução assim, fazer 10 pesquisas, e depois carregar no botão do navegador para voltar atrás. Com e sem implementação Ajax da procura. Dica: as vossas 9 procuras anteriores perderam-se... Uma nota em relação à implementação inicial: deixámos de suportar o Internet Explorer 7. Parece que houve qualquer coisa a ver com o design que motivou a decisão... Quanto ao resto, só tenho isto a dizer: html5 history API.

• E onde estamos hoje? A sua posição de "Chefe Designer" que já não desenha junto com a importância para a manutenção do imenso código inconsistente que produziu tornou-o num elemento imprescindível para o parco futuro que esta empresa possa vir a ter. Tornou-se indispensável pelas piores razões. Defende com unhas e dentes o que desenvolveu e opõe-se veementemente à sua reformulação/substituição. E não desenha (repito-me). 

• Outro: Nem sei bem o que dizer do terceiro elemento. Era claramente inexperiente quando chegou. Não pescava nem muito Rails nem muito Ruby. Nem tão pouco javascript. O javascript dele era horrível, tenho que ser sincero. Ele diria que sabia mais de C, e provavelmente teria razão. Era um terrível comunicador. Falava alto e num tom um pouco irritante. Como eu, era estrangeiro. Comunicava em inglês com a equipa porque não falava a língua do país. O seu inglês era cheio de erros e possuía um sotaque genuinamente terrível, sendo difícilmente compreendido até por ingleses. Não fez um mínimo esforço na aprendizagem da língua daqui, e teve oportunidades para isso, mas preferiu desinteressar-se do assunto e comprometer indirectamente a sua integração, tanto no país como no trabalho. Não sendo pedante, era algo fanfarrão.
• Por outro lado, sabia reconhecer as suas limitações, e tentava procurar alguém que lhe direccionasse. Não sendo muito independente no trabalho, compensava sendo consciente. Mas foi pessimamente integrado na equipa. E a comunicação foi só uma pequena parte. Foi sempre colocado em tarefas e projectos que lhe mantinham à margem das grandes responsabilidades. O seu papel nunca foi diminuído, porque sempre foi minimal. As suas ideias e sugestões eram geralmente rebatidas ou silenciosamente ignoradas. E algumas eram realmente boas sugestões. Exemplo? Contextualizar os commits do git relativamente à tarefa em questão, para que as listagens se compreendessem melhor. Só eu peguei nessa dica. O CTO nunca soube como o utilizar bem, vendo nele provavelmente alguém com um curso tirado num país de segunda categoria e em quem não reconhecia competência técnica nenhuma. Chegou mesmo a comentar que o ex-designer era melhor tecnicamente. O que talvez não fosse mentira, dependendo do contexto. Mas se eu nomeasse "waterfall" ao ex-designer, não sei bem o que me responderia. A propósito, a relação com o ex-designer foi especialmente atribulada. O ex-designer parecia partilhar da opinião relativa ao país de segunda categoria, mas era muito mais verbal. E o outro, não gostando de ficar atrás, puxava dos galões com o seu curso universitário adquirido, que era claramente algo que ficava a remoer na cabeça do ex-designer, de formação nem designer, nem programador. Todo este atrito se revelou péssimo para a equipa, motivou debates acesos sobre conceitos e metodologias, e-mails abertamente ofensivos e um clima de guerra fria dentro da equipa de IT, que no conjunto amputou a nossa relação tanto pessoal como profissional, e agravou a consideração já de si minimal que a equipa-núcleo nutria pelo "outro".
• Porém, no final, saiu de cena com a graça de quem nasce com o cú virado para a lua (com todo o mérito): Numa fase em que a empresa já o tentava amigavelmente "recolocar", decidiu tomar a iniciativa e encontrar ele colocação, e eis que surgiu uma oportunidade para trabalhar para a principal empresa de telecomunicações do país. Vai receber formação, mudar para uma área com mais saída (redes), vai manter o foco em Ruby, e no final vai ser um muito melhor profissional do que alguma vez teria sido ficando nesta empresa, porque vai estar integrado num sistema de avaliação mais impessoal e ao mesmo tempo menos falível, e onde as suas qualidades podem ser valorizadas e as deficiências colmatadas. Desejo-lhe sorte. É um rapaz que genuinamente quer aprender e ser melhor profissional, que não se coloca acima da equipa e que gosta de trabalhar, e sob as condições certas tem tudo para se tornar melhor profissional. Só tem a ganhar. Agora tem é que aprender a língua daqui e acabar com a falha de comunicação se quer vingar.

Avaliação da empresa

A empresa é um caos. Desorganizada em todos departamentos, dos quais só me foquei no que me diz respeito, mas onde todos contribuíram directa ou indirectamente para o desfecho que se avizinha. Passo a explicar: quando eu entrei na empresa, esta já estava algo estabelecida no mercado nacional com o produto principal, uma rede social para o mundo da música. Porém, já se sentia a pressão da competição internacional, e cada vez mais apareciam outro tipo de aplicações que giravam em torno de manter, disponibilizar e comercializar conteúdo musical online. A empresa achava que tinha um trunfo para se nivelar no seu produto seguinte: uma plataforma feita sobre a principal, que permitia licenciar rapidamente conteúdo musical para vários tipos de uso. A decisão inicial foi utilizar o conteúdo da plataforma principal, consequentemente limitando o escopo da ideia e dirigindo o desenvolvimento numa direcção que se provaria errada. Quando eu entrei, já tinha sido desenvolvida uma solução para estabelecer planos de preços para licenças na plataforma principal, apesar de não haver plataforma secundária nenhuma. Os constrangimentos começaram. Quando comecei a desenvolver o primeiro rascunho da plataforma, decidiu-se reutilizar a mesma base de código da plataforma principal. O constrangimento das adaptações anteriores já se encontrava lá, e conceptualmente argumentava-se ser o mais correcto, pois não se visualizava uma plataforma sem a outra. Gerou-se deste modo um monólito. Foi este monólito que foi lançado há cerca de um ano, com direito a conferência de imprensa, aperitivos, tudo. A ideia parecia ter sido validada. Mas, com o passar das semanas, reparou-se que ninguém licenciava conteúdo. Um mês passou, uma compra. Algo não parecia bem. Por esta altura, já trabalhava connosco alguém que supostamente iria "melhorar os nossos processos de negócio". Ele começou a introduzir conceitos completamente alienígenas naquela empresa, tais como "testes de usabilidade", "testes A/B", "métricas de usabilidade". Em 2 semanas conseguiu convencer todos os decisores de que o produto precisava de um design completamente novo (imaginem como isso não feriu o orgulho do ex-designer). Ao mesmo tempo a importância deste segundo produto começou a aumentar, começando a ser foco da estratégia de marketing da empresa, que por esta altura continuava à procura de mais investidores. Começaram a ser estabelecidas parcerias estratégicas com outras plataformas web de conteúdo musical, sendo este exportado para a base de dados da plataforma secundária, que passou a ter então uma mistura não muito consistente de conteúdo musical da plataforma musical sujeito a sincronização e conteúdo de parceiros assim devidamente marcados. Foi desta altura talvez o pior código-esparguete que jamais vi. As reuniões para aprovar as novas propostas de design intensificavam-se. Claramente havia uma facção dos decisores que estava permanentemente descontente com as propostas e outra que se colocava do lado do responsável pelo design. Enquanto isso, eu completava a actualização das duas plataformas de Rails 2 para Rails 3 (quem já teve que o fazer sabe que é um esforço hercúleo). Foi aí que tudo aconteceu ao mesmo tempo: o novo design foi finalmente aprovado, a actualização foi completada com sucesso e a equipa foi informada que a manutenção da plataforma principal iria terminar, passando o nosso foco para a plataforma secundária, que a partir daí iria se separar conceptualmente da sua irmã siamesa. Ficámos então com um monólito actualizado, 70% do qual nunca mais iriamos ver, e 30% do qual iria ser extraído para um projecto autónomo e independente. Para a semana seguinte foi então marcada uma reunião para apresentar à equipa em geral o novo design, no qual não tinham participado nem decidido. E esta foi talvez a reunião profissional mais surreal que já tive: para além de apresentarem o novo design, que repetia alguns dos erros do design anterior e acrescentava alguns novos (tais como botão para registo do utilizador no canto inferior direito!!), numa manobra de ilusão de colaboração, quiseram integrar o resto da equipa, permitindo-lhes escolher por voto a cor base da plataforma!! Limitaram a nossa escolha a 7 cores e 3 padrões também. Obviamente que a equipa, aterrada de pára-quedas nessa reunião, mal conseguiu esboçar uma opinião sobre o assunto. Para simbolizar o processo, deixo aqui a escolha de um colega meio-holandês: "Escolho o laranja, porque enfim, sou holandês".
Foi nesta altura que se começou a falar de que provavelmente iríamos necessitar de uma API externa, para facilitar a importação de conteúdo para a nossa plataforma. O outro estava encarregado da integração da autenticação na plataforma, e o ex-designar com a implementação do novo design. O CTO estava entretido com scripts de importação e manutenção do servidor. Eu fiquei encarregue da nova tarefa. Perguntaram-me se a API estaria pronta daí a 2 semanas. Apeteceu me rir. Mas comentei que precisava de tempo para analisar alternativas. Para mim, era claro que, ou se começava a separar as aplicações e as várias componentes, desfazendo o monólito, ou a API teria que ser feita em cima do monólito. Fui pela primeira opção, porque gosto de sofrer. Comuniquei que era impossível começar com a API sem pelo menos primeiro separar a base de dados existente em duas, uma para cada aplicação. Tarefa simples, pensei eu. O pesadelo que se tornou portar os dados de uma base de dados para a outra roubou-me 3 semanas. Quando terminei, comecei então a implementar a primeira versão da API, usando uma framework mais minimal que o Rails para o efeito, e programando um mapeamento de dados diferente para o efeito. Por esta altura, a empresa começava a dar os primeiros solavancos, quando o nosso "optimizador de processos" bateu com a porta, citando diferenças de direcção com o nosso CEO. Eu pensei comigo mesmo que todas as resistências na escolha do novo design e desagrado geral com o modo de fazer as coisas na empresa também contribuiu, não só para o seu fraco desempenho, como para a sua saída eventual. Com ele levou dois potenciais investidores. E quando o dinheiro prometido voou, foi logo marcada nova reunião. Foi comunicado que o "outro" iria ser "emprestado" para um projecto de um amigo do CEO enquanto se aguardava mais financiamento, e que o ex-designer iria pegar nas tarefas dele. Não faço a menor ideia o que ocupava o CTO. Mas, mais uma vez, a responsabilidade de uma das funcionalidades fulcrais no futuro da plataforma e da empresa iria passar para as mãos do ex-designer. Que logo nessa altura começou a mover esforços para detonar o meu trabalho. Reparou que o meu mapeamento para a base de dados não fazia tudo o que o mapeamento original fazia. No que lhe dei razão, era válido o que dizia. Depois questionava a minha escolha, porquê DataMapper e não o ActiveRecord original. Argumentei que queria experimentar uma coisa nova, mas que estava disposto a estudar possibilidades. Ele tomou por iniciativa substituir em um dia os modelos DataMapper pelos ActiveRecord. Como era de esperar, não o conseguiu. Aí pressionou o CTO para me fazer voltar atrás e fazer tudo com Rails. E aí foi quando pisaram um calo. Não era da competência dele me mandar fazer o que quer que fosse. Foi marcada reunião, em que os dois me tentaram demover, colocando argumentos que só expressavam a preguiça mental dos ditos cujos ("o Rails a gente já conhece", entre outras razões semelhantes). Bati o pé. Aí pressionaram-me. E eu reagi como animal agrilhoado: com agressividade. Disse-lhes que a tarefa era minha, a decisão era minha, que já a tinha tomado fazia meses, e que ninguém me ia dizer o que fazer por ter pesquisado no tema 3 dias quando eu tinha lá andado 3 meses. E terminei por dizer que da consistência do mapeamento com ActiveRecord encarregava-me eu. A reunião terminou em tom pesado. Mas daí a uma semana os modelos tinham sido portados com sucesso.
Mas isso representava outro problema: eu não podia simplesmente copiar as coisas de um lado para o outro; de alguma forma os modelos tinham que ser partilhados. E ainda não tínhamos desfeito o monólito completamente. Aí eu disse ao CTO: inviável sem separar as aplicações. E aí passou a minha sub-tarefa. Portei os ficheiros para a segunda aplicação. Depois portei o código para a segunda aplicação. Foi longo e moroso. Tal como o seguinte: passar o mapeamento da base de dados para uma biblioteca partilhada. Algo que saía do âmbito do Rails e o qual eu nunca tinha feito até altura. Mas consegui. A biblioteca funcionou, foi partilhada nos dois projectos (aplicação e API) e deste modo calei algumas bocas.
Com isto aproximava-se o Natal. E aí caíu a bomba: os investidores estavam a ficar impacientes. Queriam já estar mais acompanhados por essa altura. Ameaçaram fechar a torneira. Os empregados foram então chamados um por um, e foi-lhes comunicado que não poderíamos continuar a pagar aquele escritório, e que teríamos que transitar até ao final da semana seguinte (!) para um novo espaço. Para além disso, questionaram-me qual seria a minha disponibilidade para trabalhar a 50% até à próxima ronda de financiamento, daí a 3 meses. Pois é, a barra caíu em cima do pé. Disse que a disponibilidade era nenhuma. Tentaram demover-me, apelando ao meu espírito de equipa e ao facto de que o resto da equipa iria também sacrificar-se pelo bem comum. Cedi em parte: acordei trabalhar um mês em regime de 50%, ao que me foi respondido que, para adquirirem fundos, iriam tentar colocar-me num projecto externo por 2 meses para assegurar os fundos para me custear. Dezembro, mês do Pai Natal.
E cá nos encontramos em 2013. O lançamento das plataformas separadas anteriormente conhecidas como monólito foi cumprido no final de janeiro com sucesso, sensívelmente um ano depois do lançamento oficial da plataforma então secundária. A versão com a biblioteca partilhada aguarda ainda pela completação da área de utilizador que está a ser finalizada pelo ex-designer, tarefa essa que tem basicamente bloqueado tudo o resto, fruto de outras inconsistências na gestão das iterações ás quais o CTO não é estranho. Estou sem tarefas, em parte porque as fichas estão todas no lançamento dessa nova funcionalidade, em parte porque brevemente serei "transferido" por 2 meses para um projecto fora da empresa, mas perto do coração: um website para a loja de utensílios de cozinha da mãe do meu CEO. Porquê? Pois, qual é a empresa externa que tem o interesse de dispor de mim por um período tão curto como são 2 meses? Não encontrando ninguém para me custear, a solução acabou por vir de dentro. Deveras glamorosa.

Análise de Resultados

Aqui espero demonstrar que esta empresa, para além da falta de estrutura, foi vítima do princípio de Peter. Vejamos:

• CTO: Foi em tempos um mero desenvolvedor, com bastante competência até, julgando o grau de satisfação na resposta a dúvidas da equipa. Em questões de Ruby era claramente em quem a maior parte da equipa confiava. Porém, nunca provou qualidades de liderança: não soube moderar os conflitos internos, foi hesitante na tomada de decisões e não soube aproveitar as qualidades nem colmatar as deficiências dos membros da equipa. A responsabilidade que detinha em tarefas de administração do sistema impedia a sua participação naquilo que (ao que parece) fazia melhor: bater código. Demonstrava frequentemente comodismo na sua atitude. Não querendo concluir que foi promovido até ao seu mais elevado grau de incompetência, fico pelo menos com a ideia de que a sua produtividade estava claramente amputada. 

• Ex-designer: Talvez o curto período de carreira mais bem-sucedido de sempre, saltou em 3 anos de estudante de cinema para estagiário de design para designer a tempo inteiro para designer/programador para programador, um verdadeiro camaleão. Vinha de um contexto completamente diferente dos outros membros, de um meio artístico, e agia desse modo com o projecto, tratando-o como a sua obra magna, a sua Mona Lisa.É um auto-didacta, e como tal tiro-lhe o chapéu pelo que aprendeu em tão curto espaço de tempo, mas há certas coisas que os tech-blogs não ensinam. Quando eu andei na universidade, programar era só uma parte do jogo; salvo a rara excepção para implementar algoritmos, nunca pude escrever código para projectos sozinho, estive sempre inserido em grupos, o que implicava metodologias de trabalho, que, obviamente, nem sempre eram implementadas de forma correcta, mas que à chegada da meta se revelaram lições importantes. Aqui incluo conceitos como documentação, modelação de processos, diagramas de arquitectura de software, análise de requisitos, conceitos completamente alienígenas para o meu colega. Como designer, sofreu com o mesmo tipo de falta de conhecimentos: ignorava a existência das heurísticas de usabilidade de Jakob Nielsen, conceitos básicos de interface homem-máquina, design adaptável; para ele o ecrã do seu Mac era uma tela por preencher. Frequentemente programava em sigilo absoluto e a acumulação de responsabilidades como designer e programador levava-o a confundir as suas tarefas. Quando penso nele lembro-me do Francis Ford Coppola: quando era um zé-ninguém e ninguém lhe valorizava sai-se com "O Padrinho"; quando lhe deram rédea livre e recursos ilimitados, gastou rios de dinheiro no "Apocalypse Now" e acabou por prejudicar os seus empregadores, tanto que nunca mais iria dispor de orçamentos daquele nível. 

• Outro: Não tendo tanta experiência na matéria, era claramente um activo a valorizar, pois tinha os fundamentos base para ser competente a médio prazo. Acabou por ser vítima do princípio de Peter, pois a delegação de tarefas importantes implicava perda de controlo e importância dos outros membros da equipa, da qual não abdicavam levemente. Foi sempre mantido em projectos paralelos e tarefas secundárias por essa razão, tendo sido até ao fim o "primeiro a sair caso as coisas dessem para o torto". E foi mesmo. O facto de ser um estrangeiro que não dominava a língua do país não ajudou, obviamente. Mas, profissionalmente, representava um perigo directo para o ex-designer, que corria o risco de perder a sua influência como programador. E isso, penso eu, foi um factor determinante. 

• Empresa: Altamente hierarquizada. O núcleo era composto pelo CEO e "chefes" dos vários departamentos (TI, finanças, comunicação, design) que tomavam todas as decisões entre eles, incluindo aquelas para as quais não tinham competência. Nunca conseguiram inserir com sucesso novos elementos neste grupo, geralmente vistos como disruptores da harmonia e espírito de camaradagem existente, principalmente quando palravam sobre "produtividade" e "métricas de análise de desempenho". O círculo de decisões era, portanto, altamente fechado. Por outro lado, passavam a imagem de ser uma empresa aberta e muito informal. Era efectivamente uma start-up, sem muita burocracia, onde ocasionalmente apareci de chinelo para trabalhar. Dos vários estagiários que passaram pela empresa, maioritariamente para geração de conteúdo e comunicação, todos eles gostaram do ambiente completamente relaxado, música ambiente e boa disposição. Mas ser "aberta" é outra coisa. Tinham uma visão totalmente utópica em termos de impacto que o projecto poderia ter, e não compreendiam que, na internet, execução e timing é tudo o que uma start-up tem; se o produto não cumpre o que lhes é vendido nas apresentações e rondas de financiamento na altura certa, só resta o desinteresse, e neste planeta não se tem uma segunda oportunidade para causar uma boa primeiro impressão. Não ter apostado no planeamento revelou-se o maior calcanhar de Aquiles da empresa: desde o lançamento do produto, em fevereiro de 2012, até hoje, ou seja, um ano, as iterações centraram-se em dívida técnica (desfazer o monólito) e reformulação do design e imagem do produto (um péssimo sinal, os verdadeiros designers sabem do que falo); não foi adicionada nenhuma nova característica, nenhum processo da navegação no site foi alterado ou melhorado. Os recursos foram concentrados maioritariamente no desenvolvimento e o marketing foi praticamente esquecido. Em um ano, fundamentalmente, não foi atingido nada de novo nem acrescentado valor ao produto. Aliás, em um ano, perdeu-se o efeito surpresa, e cada vez mais aparecem competidores que aparecem com modelos de licenciamento de conteúdo muito mais inovadores. Exemplo: um dos nossos casos de uso era o licenciamento de uma música para uso num vídeo do youtube através da nossa plataforma. Hoje em dia, o youtube tem um modelo muito melhor: rastreia os vídeos subidos, compara-os com a sua base de dados, identifica conteúdos e os seus autores, e comunica-lhes a utilização do conteúdo, permitindo-lhes vários tipos de soluções, entre elas bloquear o conteúdo ou inserção de anúncios comerciais no mesmo, lucrando indirectamente. Esta solução tornou o nosso produto completamente obsoleto em menos de um ano. É difícil analisar o caso da empresa sem conhecer o contexto, mas tomo a equipa-núcleo como a grande responsável pelo insucesso do produto.

Epitáfio

Não se iludam, já estou na procura de emprego há cerca de mais de 2 meses. Estas coisas levam tempo. É importante não cometer os erros anteriores. Passar de cavalo para burro não seria inteligente da minha parte. Vou ter que jogar bem com as cartas que me saíram: estou (ainda) empregado; pagam-me a integridade do salário; tenho alguns meses até a empresa finalmente concluir que a festa acabou e fechar as portas. Vou ter que aguentar os períodos de inércia associados a esta condição e a falta de motivação que já se instalou. E preparar-me para o próximo passo, colocando a minha atenção em projectos paralelos com esse intuito. Não será fácil, porque a barra está mais acima do que antes, e não vou aceitar qualquer gata borralheira esperando que se torne princesa. O que eu quero? Ser valorizado profissionalmente, alguém em que invistam. Quero organização e uma estrutura definida de responsabilidades. Quero trabalhar na web de amanhã, a pensar nos dispositivos móveis. Quero saber o que faz um bom líder, e saber se conseguiria algum dia assumir essa responsabilidade. Quero levar toda a experiência negativa que acumulei de modo a que não cometa os mesmos erros. E acima de tudo, quero fazer parte de um caso de sucesso. Tornei-me um pouco start-up-céptico. Penso que 90% delas não sabe do que se trata, seguem o último modelo da moda, seja ele rede social ou reinvenções do formato pergunta/resposta. Gostava de fazer parte dos 10% originais, que concebem o mundo de amanhã. Só isso. Espero que não seja pedir muito.

Se for, então que seja para a Google. Mal por mal... eheh, brincadeira.

Volto à tecnologia no próximo post. Até lá, portem-se.