Desenvolvedores

Como existe uma equipe dedicada para testar as aplicações, o desenvolvedor acaba relaxando nos testes que ele deveria implementar, e passa a responsabilidade do teste para aquela equipe, com o seguinte pensamento: “Ok, ok, vou testar aqui mais ou menos aqui porque o teste pra valer é com o pessoal da equipe de testes… Se eles não pegarem, o cliente também não pega. E se o cliente pegar, bem, foram eles que deixaram passar…”

Equipe de testes

A equipe de teste, que certamente não deve usar testes automatizados, executa os testes conforme o humor da equipe, ou seja, um dia pegam pesado, no outro a paciência não está tão grande e o teste sai mais “fraquinho”. O ponto aqui é que os testes acabam nunca sendo repetidos da mesma maneira, e isso é muito ruim porque acaba passando uma falsa sensação de dever cumprido para a equipe e de segurança para o resto da empresa.

Jogo de empurra-empurra

Além do comportamento mostrado anteriormente pelas duas equipes, é quase certo que existirá uma concorrência entre as equipes, sempre com o intuito de culpar o outro. Se um bug é pego em produção e o cliente reclama, a equipe de desenvolvimento argumenta que a culpa é da equipe de testes que deixou o erro passar. Já a equipe de teste rotula todos os desenvolvedores de incompetentes, porque sempre enviam uma versão da aplicação cheia de erros, e dos mais básicos possíveis.
Na verdade as duas equipes deveriam estar trabalhando juntas, e quando digo juntas quero dizer lado a lado. Os analistas de teste devem sentar com os programadores para ajudar a pensar os testes que devem ser implementados. Só assim, com atenção e foco dobrados é possível chegar a uma quantidade mínima de erros.

A responsabilidade é sua

Depois do que falei acima, muita gente vai dizer o seguinte: “Ah, mas na minha empresa é assim mesmo, as equipes são separadas e a gerência entende que assim é melhor… blá, blá, blá“. Faça um favor para você mesmo, tome a responsabilidade de criar os testes para você, como se não existisse outra maneira de fazer software (na verdade essa é a única que funciona a longo prazo). Não espere que o seu gerente, o líder de equipe ou seja lá quem está acima de você peça para você implementar os testes. Inclua sempre nas suas estimativas o tempo necessário para escrever os seus testes, organizar o seu código, deixar tudo limpinho.
Lembre-se, o código é seu, a responsabilidade é sua!

Gostou ou não gostou? Ah, não concorda não? Então fala aí! Quero ouvir :-)

O que me traz a esse assunto é a tal da “Economia porca“. Funciona assim, o dono da empresa, ou o departamento responsável pelas compras ou mesmo o gerente, decide que gastar dinheiro com um equipamento melhor para o seu desenvolvedor, um servidor para build, controle de versão, banco de dados ou seja para o que for que se precisa da máquina, é caro e não será feito agora. Como a empresa está querendo economizar, então eles resolvem deixar aquele PC meia boca para o desenvolvedor mesmo, e o resto, banco, controle de versão e build (se deixarem você colocar um processo de build automático), vai ficar tudo na mesma máquina. E o pior, essa máquina é aquela melhorzinha e que todas as equipes de desenvolvimento terão que compartilhar. Isso é economia porca! É uma falsa economia.

O resultado disso é um impacto brutal, tanto na produtividade do seu time de desenvolvimento quanto na motivação, no ânimo das pessoas para fazerem as coisas acontecerem. O desespero é tanto que eu já vi casos onde o sujeito estava disposto a pagar, ele mesmo, por uma máquina, só para poder trabalhar melhor. Talvez fosse um bom investimento mesmo, só para evitar o estresse que isso causa, mas convenhamos que pagar para trabalhar é meio chato :(

Como resolver isso? Bem, eu não sou especialista em finanças e nem tenho experiência em administração de empresas para deixar aqui um receita de onde é mais eficaz economizar. O que sei, do ponto de vista de quem já foi afetado por esse tipo de economia é que, esse tipo, não vale a pena. Muito provavelmente o dinheiro que a sua empresa está ecnonomizando não comprando mais máquinas, irá perder com a correção de erros, com horas gastas em configuração de máquinas compartilhadas, em contratação de novos profissionais e até mesmo por colocar um produto tarde no mercado, já que aquele produto que deveria estar pronto, ainda não saiu porque acabou atrasando, sabe-se lá por qual motivo.

Pense nisso. Você concorda, tem uma visão diferente? Compartilhe conosco :-)

Voltando a questão do profissionalismo, essa semana eu estava lendo o livro “Scrum direto das trincheiras“, onde em determinado trecho o autor menciona que para ele a qualidade interna de um sistema não é negociável. Você pode conferir um resumo neste post, no blog da Rosana Angelo, minha colega de trabalho, onde ela fala exatamente sobre isso também. Porém, o ponto aqui não é falar de qualidade ou profissionalismo, simplesmente porque o autor do livro falou isso ou aquilo. Vou contar uma histórinha para ilustrar…

Eu ouvi uma vez um amigo, na primeira empresa onde trabalhei como programador, que dizia o seguinte: “com programação a gente só não faz chover, todo o resto a gente consegue fazer de um jeito ou de outro“. Eu sinceramente não garanto o teor das palavras, mas a idéia era essa. Uma frase desse tipo pode levar a interpretações do tipo: “testar é besteira, se ocorrer algum erro, depois consertamos“, ou ainda, “gastar tempo melhorando esse código aqui, pra quê, está funcionando…“, ou “Ok, vamos colocar só mais está coluna aqui na tabela do banco de dados, isso vai facilitar muito as coisas…“.

Esses tipos de abordagens são extremamente nocivas, porque no fundo estão baseadas naquele tipo de pensamento que foi mencionado antes, ou seja, se fizer assim funciona, mas se fizer de outro jeito, também funciona. O ruim é que quase sempre, quem decide, acaba escolhendo o caminho mais curto, que muitas vezes, não é o mais adequado, mas sim o mais rápido e barato possível. É justamente nesse ponto que precisamos mostrar o nosso profissionalismo e fazer como o autor do livro sobre Scrum (Henrik Kniberg), não negociar qualidade. Você pode negociar outras coisas como tempo, o quanto deve ser entregue, o custo, mas não a qualidade do seu código. (Apenas um adendo aqui, código de qualidade é um código no qual você confia, e você só pode garantir o seu código se você o testá-lo).

Não está convencido, então pare e pense sobre outras profissões, como médicos ou dentistas. Não podemos esquecer que em todas as profissões existem bons e maus profissionais, mas em geral esses profissionais tem um padrão de qualidade mínimo, sem o qual eles não tem como trabalhar e não trabalham. Um médico, a não ser em uma guerra, por exemplo, não vai abrir um sujeito em um local inapropriado, sem equipamentos de suporte e sem uma equipe qualificada para lhe dar suporte. Penso sobre isso, e da próxima vez que alguém pedir para você dar aquela “ajeitadinha” no sistema, diga NÃO!

Logo no começo do livro, capitulo 1 ou 2, ele menciona que: “Programar, codificar uma aplicação é uma atividade social“. Não se trata de uma tradução literal mas essa é a mensagem. Achei a afirmação muito interessante, e confesso que jamais havia pensado na tarefa de codificação como uma prática social. Eu sempre enxergava, tomando como exemplo um projeto open source qualquer, o ato de criação do projeto e mesmo o trabalho em equipe nesse sentido mas nunca o código em si. Normalmente pensamos da seguinte maneira: “O código é meu!“. Eu diria que essa afirmação é verdadeira até que você faça o commit do “seu” código para o repositório, depois disso, não mais.

Não está entendendo? Explico já. O Uncle Bob coloca em seu livro que devemos ter muito cuidado com o código fonte que escrevemos, porque afinal de contas quando o fazemos, estamos quase sempre fazendo isso para que outras pessoas “leiam” o nosso trabalho. O ato de escrever em si traz consigo esse sentido, ou seja, geralmente escrevemos algo para um outro alguém ler. Em nossa profissão isso também não é diferente, pois nada garante que o autor original do código será a pessoa que dará manutenção no mesmo.

Como o Uncle Bob tanto insiste no livro, o código que escrevemos precisa ser muito claro e direto, ele precisa ser capaz de transmitir sua intenção de forma objetiva, para que as outras pessoas que forem ler o código não percam um enorme tempo tentando entender o que pretendíamos com aquilo. Quantas vezes você já se viu nessa mesma situação? Quanto tempo já não perdeu por conta disso? Não seria ótimo encontrar um código que falasse com você, quando precisar dar manutenção nele? Reflita sobre isso. Tente imaginar como será dar manutenção no código que você acabou de escrever. Será que você mesmo vai conseguir entender ele depois de uns 2 ou 3 meses? Experimente chamar um colega e pedir para que ele “leia” o “seu” código para ver se a intenção está clara para ele. Só não vale dar pistas :-) Se ele não entender, pare, reescreva e depois chame uma pessoa diferente e peça que leia. Faça isso até que as pessoas não tenham nenhuma dificuldade para interpretar o seu código.

Se você é desenvolvedor e estava procurando uma boa leitura, eu recomendo fortemente esse livro. Aliás, eu penso que o sujeito não devia sair da faculdade sem antes tê-lo lido. É o tipo de livro que todo profissional da área de computação e sistemas deve ler e as empresas deviam ter em suas bibliotecas.

A diferença entre o “pensam” e o “pensaram” está, entre outras coisas, na habilidade em convencer os demais sobre o seu ponto de vista, tornando a sua maneira de pensar “comum”. Os que “pensam” diferentemente da maioria ainda precisam convencer o resto do mundo sobre suas visões. Entre os que “pensaram”, muitos foram bem sucedidos e muitos não foram capazes de tal proeza.

Porém, penso que a principal observação quanto as situações citadas é que, é muito importante e faz toda a diferença, acreditar no seu ponto de vista, na sua idéia, no seu negócio e tentar, da melhor maneira possível, convencer outras pessoas sobre isso. Temos muitos exemplos de pessoas brilhantes que não souberam vender as suas idéias ou defender os seus pontos de vista e que acabaram sendo taxadas de medíocres. Seja persistente, trabalhe as suas habilidades de interação social e corre atrás daquilo em que você acredita. Corra o risco de ser chamado de louco, afinal de contas, eu prefiro ser chamado de louco do que de medíocre.

Todo esse papo acima foi inspirado por uma visita a uma livraria, quando procurava por algum título interessante, esbarrei por acaso com um livro que havia sido deixado perto do local de consulta de preços. O livro, “O iconoclasta“ foi escrito pelo neurocientista Gregory Berns e tenta explicar como e porque algumas pessoas tendem a ver as coisas de modo direferente do resto do mundo.

A capa do livro traz a definição de iconoclasta que encontramos no dicionário, que é a seguinte: Pessoa incomum que interpreta a realidade de maneira distinta e faz o que o senso comum julga inalcançável. Trata-se de uma leitura muito interessante porque o autor mescla histórias de iconoclastas famosos com explicações científicas detalhadas sobre o funcionamento do cérebro. Ele fala sobre o que tornava cada pessoa mencionada um iconoclasta e ainda explica como essas características são processadas pelo cérebro. É um livro fascinante e eu recomendo a leitura.

De fantástica essa prática não tem nada. Alguns podem dizer que isso é um boa prática, já que realmente o código da sua aplicação passa a não depender de código alheio, interagindo somente com o seu próprio código. Penso que para se obter esse tipo de benefício basta encapsular o código que utiliza o framework ou API XXX em um método, mas não é necessário “esconder toda a implementação em algo, que de novo não tem nada“. E onde fica o aprendizado nesses casos? Como as outras pessoas no seu time irão aprender a trabalhar com o framework XXX? Isso é ruim para a evolução profissional dos desenvolvedores e ruim para a equipe como um todo.

Isso acaba causando um efeito “veja bem…“. Funciona assim, digamos que na empresa ZXY onde o Fulano trabalhava como desenvolvedor Java, o sujeito responsável pela arquitetura do sistema fosse um desses programadores empacotadores. Por baixo de todas as “cascas” eles usavam coisas como DWR, Quartz, JQuery e JSF, mas tudo era “empacotado”. Após 3 anos de empresa ZXY, o Fulano decide sair e buscar novos desafios porque se cansou de só programar com os bloquinhos da empresa ZXY. O Fulano então envia o seu currículo mostrando tudo aquilo que sabe e é chamado para uma entrevista. O entrevistador o questiona sobre a experiência dele com os frameworks citados anteriormente e ele responde: “Veja bem… eu não trabalhava diretamente com essas APIs, mas era praticamente a mesma coisa…“.

Se você já agiu como um “desenvolvedor empacotador”, repense o que está fazendo. Isso talvez tenha um efeito bom na sua relação com o seu chefe, já que vai parecer que você está economizando muito tempo de desenvolvimento para a empresa, empacotando todo aquele código e fazendo os programadores usar apenas o seu código maravilhoso. Porém no longo prazo isso se mostrará ruim, as pessoas se sentirão entediadas e desmotivadas. Se você não é o empacotador, mas o cara que tem que lidar com os pacotes, saia enquanto é tempo…

• Será que todo mundo que trabalha com desenvolvimento de software tem os mesmos problemas com o controle de versão?
• Estamos realmente utilizando o controle de versão da maneira correta?

Encontrei respostas em 2 posts do Martin Fowler, um com o título “Version Control Tools” e outro “VCS Survey” que mostra uma pesquisa realizada por ele, mostrando o que é mais usado/confiado pelos desenvolvedores que participaram da pesquisa. Infelizmente nós não utilizamos um dos mais populares, dentre os mencionados. Com relação ao procedimento utilizado, encontrei ainda outro ótimo post do Martin Fowler sobre “Feature Branch“, que deixou claro que talvez fosse melhor mudar a nossa abordagem para desenvolver novas funcionalidades nos sistemas.
Além desses, encontrei um outro post, excelente, sobre os DVCS, que fala de um case de transição de um VCS para DVCS. É sensacional o relato do autor, que mostra como a equipe ganhou mais agilidade com a troca do sistema de versionamento.

Depois dessa pequena pesquisa, ficou claro pra mim o quanto subestimamos as ferramentas de versionamento de código. Na maioria das vezes pensamos nelas apenas como “ferramentas de versionamento de código fonte“, quando na verdade, a escolha da ferramenta correta e o uso apropriado da mesma, pode transformá-la em uma “ferramenta de expansão da colaboração e criatividade“. Para não ficar repetindo o que já foi escrito, sugiro ler este post do @gchapiewski sobre como o uso apropriado de ferramentas de controle de versão transformou o ambiente de trabalho do pessoal da Globo.com.

Não pense no controle de versão apenas como um software que guarda histórico de alterações e sim como uma ferramenta capaz de dar a você liberdade para tentar e, se preciso, voltar atrás.

Os facts:

# Falamos (eu e o Penkal) sobre as expectativas para o Agile Brazil 2010 que irá acontecer em junho na PUC-RS. Esperamos simplesmente o melhor para este evento. O Penkal, um fã incondicional, jura que vai tirar uma foto com o Martin Fowler e que o resto é resto :-)

# Foi inevitável tocar no assunto dos frameworks desenvolvidos na própria empresa, que foi tema do meu último post, já que dos 7 presentes, 6 trabalham na mesma empresa, e somos diretamente afetados por esse tipo de coisa.

# Antonio e eu, relatamos as nossas experiências recentes com Rails, para 5 caras que só mexem com Java a uns 2 anos. Tirando Penkal, o resto da turma ainda se mostra um pouco cético. Mas ficamos de marcar um encontro mostrar como podemos fazer com Rails o que ele fazem com Java.

# Tivemos também os relatos da última Campus Party, que eu e o Antonio participamos. O pessoal ficou empolgado, com vontade de ter estado lá. Eu considero aquilo a Méca dos nerds no Brasil, ou seja, pelo menos uma vez na vida você deve ir.

# Decidimos que os #horaextra-floripa passarão a acontecer às terças-feiras, já parte da galera tem problemas com a segunda, por conta de outros eventos sociais já agendados para esses dias.

Galera no #horaextra-floripa, o primeiro.

Confesso que sendo esse o primeiro, foi um pouco difícil manter o foco das conversas na área tecnológia, mas acho que tá valendo, já que um dos objetivos do encontro também é a descontração. O pessoal que participou desse primeiro encontro se mostrou empolgado com a idéia do #horaexra, até mesmo quem não foi. Aos que não puderam ir, fica o convite para o próximo, terça-feira (23), às 19 h no quiosque da Brahma no Shopping Iguatemi.
É isso, um abraço a todos e valeu pela presença! Vamos repetir :-)

• Desenvolvimento centralizado: Diferentemente do que acontece com projetos open source, naquelas empresas, o desenvolvimento, atualização e adicão de novas funcionalidades fica centralizado em uma pequena equipe, sem que ninguém mais na empresa possa ter acesso ao código para fazer suas próprias modificações. Esse posicionamento costuma ocasionar lentidão nas atualizações e limitação nas funcionalidades disponiblizadas.
• Se não foi feito aqui, então não serve: outro ponto percebido é que o que vem de fora, nunca serve exatamente, sendo assim, elas acabam tentando reinventar a roda para coisas que já existem prontas, ou praticamente. O correto seria buscar a solução open source mais próxima e se for o caso, alterar o código e ainda submeter a alteração de volta ao projeto. Vai que alguém mais precise do que acabou de ser implementado. É o mínimo que se deve fazer, como forma de contribuir com a comunidade.
• Documentação e treinamento: Outro problema ocasionado nos casos observados é que o tempo gasto para que um novo desenvolvedor alcance uma produtividade razoável, é maior quando você opta por desenvolver o seu próprio framework. Primeiro, porque o framework é algo que somente a sua empresa usa e segundo porque “geralmente” a documentação do projeto não está em dia, então você acaba gastando mais tempo tendo treinar o desenvolvedor, para que ele pelo menos conheça a API e as convenções utilizadas na empresa.

Em resumo o que devemos perceber é que criar o nosso próprio framework de desenvolvimento nem sempre (na maioria das vezes) é a solução para os problemas. Como o sujeito da foto pode atestar, carregar esse elefante nas costas só vai deixar a sua empresa mais lenta e vulnerável diante da concorrência. Por outro lado, utilizar frameworks de mercado que possuam apoio da comunidade pode trazer vantagens, tais como: facilidade para encontrar desenvolvedores treinados, suporte (fóruns, listas) e documentação atualizados e de fácil acesso e acompanhamento das tendências de mercado/comunidade, já que você estará acompanhando as evoluções implementadas no framework de mercado.

Por mais que a sua equipe seja qualificada e independente do tamanho dela, dificilmente você conseguirá superar, tanto em disponibilidade de tempo quanto em número de desenvolvedores, os projetos open source que são mantidos por centenas ou milhares de programadores pelo mundo. Comece a pensar na sua empresa como sendo parte da comunidade, contribua com o projeto ou projetos que você escolheu usar e pare de reinventar a roda!

Os encontros ficam marcados para as segundas-feiras, às 19:00 hs no boteco da Brahma no shopping Iguatemi (no térreo). Eu não vou estabelecer o dia exatamente, mas se tivermos quórum já nesta segunda (15/03), faremos. Espero por propostas de assuntos para a pauta aqui nos comentários.