Estes dias eu estava pensando nos reais custos de adotar uma nova tecnologia. Imagine que vc sempre trabalhou com Java e tem que trabalhar com .Net, o que causou essa escolha? Que estratégia existe por trás?

Bom, o principal custo esta vinculado com a capacidade de um time ou equipe de entregar, ou não, uma determinada release. Entra ai a curva de aprendizado, que não pode ser encarado como aprender a sintaxe de uma linguagem e sim compreender os fundamentos da mesma, bem como entender a infra-estrutura necessária para que ela desenvolva o seu papel.

Quem aprendeu PHP sabe como desenvolver uma pagina dinâmica, trabalhar com formularios, sessão e acesso a banco de dados, porém sabe que basta editar um arquivo e subir para o servidor que ele é ‘executado’. Passar para um mundo J2EE onde vc tem uma estrutura de diretórios para respeitar, arquivos de configuração e, principalmente, entender a filosofia J2EE, a diferença entre os servidores de aplicação, as particularidades do garbage collector, etc, enfim, não é uma tarefa simples.

Imagine que vc tem 2 semanas para desenvolver uma aplicação: o que vc escolheria? Antes de pensar “ah, 2 semanas, pra web eu faria em Rails”, pense que vc tem que desenvolver um uma equipe que não conhece Rails. Nesse caso, 2 semanas pode ser tempo muito curto para se comprometer com uma entrega se vc pensa em termos de Scrumm por exemplo, pois o time não conhece a sua velocidade (e, nesse caso, não importa velocidade pois vc TEM que terminar o projeto no prazo). Se a equipe inteira conhece PHP, metade conhece Java e apenas um cara conhece Ruby on Rails, seria interessante considerar PHP pois essa experiência acumulada colabora para a solução do problema: entregar software funcionando numa determinada data.

Quando temos liberdade de escolha e tempo necessário, podemos explorar outras linguagens, frameworks e tecnologias, usando alguns Sprints para desenvolver a habilidade necessária de implementar e, principalmente, de dar manutenção.

Outro ponto importante é a testabilidade do codigo: se vc não tem uma equipe com proficiência em testes unitários, cobrar num projeto com prazo curto pode ser um tiro no pé pois prazo curso geralmente detona o humor dos envolvidos, prejudicando a adoção de novas ideias. Um projeto de tres meses, por exemplo, seria ideal pois eu posso usar um dia (ou parte dele) para efetuar um pequeno workshop ou dojo sobre TDD e tecnologias de teste, se necessário. E o ideal é começar com testes pois codigo legado nem sempre é facil de injetar testabilidade (e as vezes deixa de funcionar no processo, ai o telefone toca, vem um esporro, é lindo).

Passei por uma situação curiosa certa vez: um serviço crítico seria adicionado à uma api de serviços com algum tempo de vida. Como ninguem sabia como testar direito usando PHP (criar mocks não é tão simples, pelo menos naquela época), desenvolvi um pequeno script que efetuava testes funcionais: eu utilizava aquele serviço usando todas as combinações possiveis de parâmetros e situações.

O grande problema dessa abordagem é desenvolver algo que pode receber atualizações: naquele momento eu tinha criado um modelo de forma a descrever os testes como estruturas de dados, assim bastaria adicioanr novas estruturas que eu teria, de forma simples, novos testes. Testes automatizados são uma tecnologia que pode agregar qualidade e, portanto, tem um custo também. Não vou ser fatalista e dizer que software sem suite de testes não tem qualidade (vide um hello world), mas vc pode atingir um patamar de qualidade superior com uma suite de testes completa, tanto por causa dela quanto pela mudança cognitiva que isso acarreta. Eu explico: desenvolver testes muda a forma como programamos. Não precisa ser TDD ou BDD: basta programar com atenção e esmero, este ultimo o grande responsável pelo sucesso de um projeto.

O desafio agora é desenvolver scripts de teste no estilo Cucumber/RSpec. Falarei disso no futuro, ainda mais que estou reinventado a roda – mas por um bom motivo.