Estes dias navegando em busca de novas formas de se programar, padrões e melhores práticas, me deparei com este texto abaixo, achei de extrema importância e decidí compartilhar com vocês, vale a pena investir alguns minutos com esta leitura! Espero que seja de bom proveito.
Enjoy it!
Forte abraço!

Por Joel Spolsky
Traduzido por Alberto Tadeu Simon
Editado por Nadia Karasawa
9. 8. 2000

Já ouviu falar do SEMA? É um sistema um tanto obscuro que diz o quão boa é uma equipe que produz software. Não, espere! Não siga o link! Você vai levar pelo menos seis anos tentando entender aquilo. Assim, inventei meu próprio teste, altamente irresponsável e medíocre, para medir a qualidade de uma equipe. A grande vantagem é que ele requer mais ou menos 3 minutos. Com o tempo economizado, você poderá até fazer um curso de Medicina.

O Teste Do Joel Você usa controle de código? Você pode compilar em somente um passo? Você faz compilações diárias? Você tem uma base de dados de bugs? Você corrige os bugs antes de escrever código novo? Você tem um cronograma atualizado? Você tem uma especificação? Os programadores tem condições de trabalho tranqüilas? Você usa as melhores ferramentas que o dinheiro pode comprar? Você tem testadores? Novos candidatos escrevem código durante a entrevista? Você faz testes de usabilidade de corredor?

O legal do Teste do Joel é que é fácil responder rapidamente”sim” ou “não” cada questão. Você não precisa calcular linhas-de-código-por-dia ou média-de-bugs-por-ponto-de-inflexão. Atribua à sua equipe 1 ponto para cada “sim” respondido. O ruim sobre o Teste do Joel é que você não deve usá-lo para se certificar que seu software de controle de usina nuclear é seguro.

Uma pontuação 12 é perfeita, 11 é tolerável, mas 10 ou menos indica que você tem sérios problemas. A verdade é que a maioria das empresas de software funcionam com uma pontuação 2 ou 3, e elas precisam de uma grande ajuda, porque companhias como a Microsoft funcionam com 12 pontos todo o tempo.

Claro, estes não são os únicos fatores que determinam o sucesso ou o fracasso: por exemplo, se você tem uma ótima equipe trabalhando em um produto que ninguém quer, bem, as pessoas ainda assim não vão querê-lo. E é perfeitamente possível imaginar um time de “pistoleiros” que não fazem nada disto e que ainda conseguem produzir softwares incríveis que são capazes de mudar o mundo. Mas, em todos os outros casos, acertando estes 12 itens, você terá uma equipe disciplinada que pode entregar softwares consistentemente.

1. Você usa controle de código?

Já usei pacotes comerciais de controle de código, já usei o CVS, que é grátis, e deixe eu te dizer, o CVS é excelente. Se você não possui controle de código, você ficará estressado tentando fazer com que os programadores trabalhem todos juntos. Eles não têm como saber o que outras pessoas fizeram. Erros não podem ser recuperados facilmente. Outra coisa boa sobre sistemas de controle de código é que o código fonte em si é salvo no disco de cada programador — nunca ouvi falar de nenhum projeto que usa controle de código que tenha perdido algum pedaço de código.

2. Você pode compilar em somente um passo?

Com isto, quero dizer: em quantas etapas você monta uma compilação, a partir da última versão de código? Boas equipes possuem um único script que faz um checkout completo do zero, reconstrói cada linha de código, faz os EXE’s, em todas as suas várias versões, linguagens e combinações de #ifdef, cria o pacote de instalação e cria a mídia final — layout do CDROM, download do website, o que seja.

Se este processo possui mais de uma etapa, ele tende a ter erros. E quanto mais perto você chega da data de entrega, mais você quer ter um ciclo realmente rápido para corrigir o “último” bug, fazer os EXE’s finais, etc. Se você leva 20 etapas para compilar o código, executar o construtor de instalação, etc, você vai enlouquecer e cometerá erros bobos.

Por esta razão, a última companhia em que trabalhei migrou do WISE para o InstallShield: nós exigimos que o processo de instalação fosse capaz de rodar, de um script, automaticamente, durante a noite, usando o NT Scheduler, e o WISE não pode rodar através do agendamento noturno, então nós o rejeitamos. (Os caras gentis na WISE me garantiram que sua última versão suporta compilações noturnas.)

3. Você faz compilações diárias?

Quando você está usando controle de código, acontece de um programador acidentalmente dar um checkin em algo que quebra a compilação. Por exemplo, ele adicionou um novo arquivo, e tudo compilou bem em sua máquina, mas ele esqueceu de adicioná-lo no repositório de código. Então ele trava sua máquina e vai para casa, distraído e feliz. Mas ninguém mais consegue trabalhar, então todos também vão para casa, infelizes.

Quebrar a compilação é tão ruim (e tão comum) que ajuda a fazer compilações diárias, para garantir que nenhuma quebra fique despercebida. Em grandes equipes, uma boa maneira de garantir que as quebras sejam corrigidas imediatamente é fazer a compilação diária no horário de almoço, por exemplo. Todos fazem quantos checkin’s forem possíveis antes do almoço. Quando voltarem, a compilação estará pronta. Se ela funcionou, legal ! Todo mundo pega a última versão dos fontes e continua trabalhando. Se a compilação falhar, você a conserta, e todos podem continuar trabalhar com a versão anterior dos fontes.

Na equipe do Excel nós tínhamos uma regra que quem quebrasse a compilação, como “punição”, era responsável por supervisionar as compilações até que outro a quebrasse. Isso era um bom incentivo para não quebrar a compilação, e uma boa maneira de passar todos pelo processo de compilação de maneira que todos aprendiam como ele funcionava.

Leia mais sobre compilações diárias em meu artigo  Compilações Diárias são suas Amigas.

4. Você tem uma base de dados de bugs?

Não importa o que você diga. Se você está desenvolvendo código, mesmo numa equipe de um, sem uma base de dados organizada listando todos os bugs conhecidos no código, você estará entregando código de baixa qualidade. Muitos programadores pensam que podem manter a lista de bugs em suas cabeças. Besteira. Eu não consigo me lembrar de mais do que dois ou três bugs de uma vez, e na manhã seguinte, ou na correria da entrega, eles são esquecidos. Você deve definitivamente manter registro dos bugs formalmente.

Base de dados de bugs podem ser complicadas ou simples. Uma base de dados de bugs mínima deve incluir os dados seguintes para bug:

• passos completos para reproduzir o bug
• comportamento esperado
• comportamento observado (do bug)
• a quem ele foi designado
• se foi consertado ou não

Se a complexidade do software de acompanhamento de bug é a única coisa barrando você de acompanhar seus bugs, faça apenas uma tabela simples com 5 colunas com estes campos críticos e comece a usá-la.

Para mais informações sobre acompanhamento de bugs, leia Acompanhamento de Bugs Indolor.

5. Você corrige os bugs antes de escrever código novo?

A primeira versão completa do Microsoft Word for Windows foi considerada uma “marcha da morte”. Ela não terminava nunca. Estava sempre cheia de lapsos. Toda a equipe estava trabalhando horas absurdas, o projeto estava atrasando de novo, de novo, de novo, e o stress era inacreditável. Quando a maldita coisa finalmente foi entregue, anos depois, a Microsoft mandou toda a equipe para Cancún em férias, e parou para um sério exame de consciência.

O que eles perceberam foi que os gerentes de projeto tinham sido tão insistentes em manter o cronograma que os programadores simplesmente correram com a codificação, escrevendo código extremamente ruim, porque a fase de correção de bugs não fazia parte do cronograma formal. Não houve nenhuma tentativa de manter a contagem de bugs baixa. Muito pelo contrário. Conta-se que um programador que tinha que escrever código para calcular a altura de uma linha de texto simplesmente escreveu “return 12;” e esperou a chegada do relatório de bugs. O cronograma foi meramente um checklist de funções esperando para serem transformadas em bugs. No post-mortem, isto foi comentado como uma “metodologia de infinitos defeitos”.

Para corrigir o problema, a Microsoft adotou universalmente algo chamado de “metodologia de defeito-zero”. Muitos dos programadores sorriram amarelo, uma vez que isto soava como um conceito gerencial de que eles poderiam reduzir a contagem de bugs por decreto. Na verdade, “defeito-zero” significa que a qualquer momento, a mais alta prioridade é eliminar os erros antes de escrever qualquer código novo. Eis o porquê.

Em geral, quanto mais você espera antes de corrigir um bug, mais custoso (em tempo e dinheiro) ele fica para ser corrigido.

Por exemplo, quando você comete um erro de sintaxe ou digitação que o compilador captura, corrigí-lo é basicamente trivial.

Quando você tem um bug em seu código e o vê na primeira vez que tenta executá-lo, você será capaz de corrigí-lo imediatamente, porque todo o código está ainda fresco em sua mente.

Se você encontrar um bug em um código que escreveu há alguns dias, levará um certo tempo para caçá-lo, mas quanto você relê o código que escreveu, irá lembrar-se de tudo e será capaz de corrigir o bug numa parcela razoável de tempo.

Mas se você encontrar um bug num código que escreveu há alguns meses, provavelmente terá se esquecido de um bocado de coisas a respeito deste código, e ele será muito mais difícil de corrigir. Neste tempo, você pode ainda estar corrigindo o código de outra pessoa, de férias em Aruba, caso em que corrigir o bug é como a ciência: você deve ir devagar, ser metódico e meticuloso, e você não sabe quanto tempo levará para descobrir a cura.

E se você descobrir um bug no código que já tenha sido entregue, irá incorrer em despesas incríveis corrigindo-o.

Eis uma razão para corrigir bugs assim que acontecem: leva menos tempo. Há outra razão, relacionada com o fato de que é mais fácil estimar quanto tempo levará para escrever novo código do que para corrigir o bug. Por exemplo, se eu te pedir para estimar quanto tempo levará para escrever código para ordenar uma lista, você pode me dar uma estimativa razoavelmente precisa. Mas se eu te pedir para estimar quanto tempo levará para corrigir aquele bug que acontece quando o Internet Explorer 5.5. está instalado, você não pode nem mesmo adivinhar, porque você não sabe (por definição) o que está causando o bug. Pode levar 3 dias para rastreá-lo, ou pode levar 2 minutos.

Isto significa que, se você tem um cronograma com uma série de bugs a serem corrigidos, o cronograma não é confiável. Mas se você corrigiu todos os bugs conhecidos, e tudo o que restou é código novo, então seu cronograma será impressionantemente mais preciso.

Outra coisa legal sobre manter o contador de bugs em zero é que você pode responder mais rapidamente à concorrência. Alguns programadores pensam nisto como manter o produto pronto para entrega durante todo o tempo. Então se seu concorrente introduz uma nova característica fantástica que está roubando seus clientes, você pode implementar esta característica e entregá-la imediatamente, sem ter que corrigir um grande número de bugs acumulados.

6. Você tem um cronograma atualizado?

O que nos traz aos cronogramas. Se seu código é extremamente importante para os negócios, há uma série de razões pelas quais é importante saber quando o código estará pronto. Programadores são notoriamente avessos a fazer cronogramas. “Estará pronto quando estiver pronto!” gritam ao pessoal de negócios.

Infelizmente, isto não serve. Existem muitas decisões que precisam ser feitas antes da entrega do código: demos, exposições, propaganda, etc. E a única maneira de fazer isto é tendo um cronograma, e mantendo-o atualizado.

Outra coisa crucial sobre um cronograma é que ele te força a decidir quais funcionalidades irá implementar, escolher as menos importantes e cortá-las, ao invés de atrasar a entrega do produto por causa dessas featuritis (também conhecidas como esquisitices do escopo).

Manter cronogramas não precisa ser difícil. Leia meu artigo Cronogramas de Software sem Sofrimento, que descreve uma maneira simples de fazer cronogramas incríveis.

7. Você tem uma especificação?

Escrever especificações é como usar fio dental: todos concordam que é uma coisa boa, mas ninguém o faz.

Não tenho certeza do porquê, mas provavelmente deve-se ao fato de que a maioria dos programadores odeia escrever documentos. Conseqüentemente, quando equipes consistidas somente de programadores atacam um problema, eles preferem expressar suas soluções em código, ao invés de em documentos. Eles preferem começar a escrever código a produzir uma especificação primeiro.

Na fase de projeto, quando você descobre problemas, pode corrigí-los facilmente editando algumas linhas de texto. Uma vez o código escrito, o custo de corrigir problemas é dramaticamente alto, tanto emocional (pessoas odeiam jogar código fora) quanto em termos de tempo, então existe resistência corrigir os problemas. Um software que não foi escrito a partir de uma especificação normalmente desenvolve-se mal e o cronograma fica fora de controle. Parece ter sido este o problema da Netscape, onde as primeiras quatro versões tornaram-se uma tal bagunça que a gerência estupidamente decidiu jogar o código fora e começar de novo. E cometeram o mesmo erro com o Mozilla, criando um monstro que ficou fora de controle e levou vários anos para alcançar o estágio alfa.

Minha teoria favorita é que este problema pode ser corrigido ensinando programadores a serem escritores menos relutantes enviando-os para um curso intensivo de redação. Outra solução é contratar gerentes de programação espertos que escrevam a especificação. Em ambos os casos, você deve reforçar a simples regra: “nenhum código sem especificação”.

Aprenda mais sobre escrever especificações lendo minha série em 4 partes.

8. Os programadores têm condições de trabalho tranqüilas?

Existe uma extensa documentação sobre ganhos de produtividade obtidos ao dar aos profissionais do conhecimento espaço, quietude e privacidade. O livro clássico de gerenciamento de software Peopleware documenta extensamente estes benefícios de produtividade.

Eis o problema. Todos nós sabemos que estes profissionais trabalham melhor entrando no “fluxo”, também conhecido como “estar na zona”, onde eles estão completamente concentrados em seu trabalho e totalmente desligados de seu ambiente. Eles perdem a noção do tempo e produzem grandes coisas através da concentração absoluta. Escritores, programadores, cientistas e mesmo jogadores de basquete podem te dizer algo sobre “estar na zona”.

O problema é que entrar no “fluxo” não é fácil. Quando você tenta medí-lo, parece que leva uma média de 15 minutos para se começar a trabalhar na produtividade máxima. Às vezes, se você está cansado ou já fez uma porção de trabalho criativo naquele dia, você simplesmente não consegue entrar em transe e gasta o resto de seu dia de trabalho com besteiras, navegando na web, jogando Tetris.

O outro problema é que é muito fácil sair do transe. Barulho, chamadas telefônicas, sair para almoçar, dirigir 5 minutos até a Casa do Pão de Queijo para um café e interrupções de colegas de trabalho – principalmenteinterrupções de colegas de trabalho — tiram você do transe. Se um colega de trabalho te faz uma pergunta, causa 1 minuto de interrupção, mas tira-lhe do transe e faz com que você leve uma meia hora para estar produtivo novamente, e sua produtividade geral está em sérios problemas. Se você está em um ambiente de baias barulhento como o tipo que as cafeinadas empresas pontocom adoram criar, com caras do marketing gritando no telefone perto de programadores, sua produtividade será desperdiçada, assim como a do profissional do conhecimento que é interrompido de tempos em tempo e nunca entra “na zona”.

Com programadores, é especialmente difícil. Produtividade depende de ser capaz de manipular uma série de pequenos detalhes em um curto espaço de memória tudo de uma vez. Qualquer tipo de interrupção pode causar a dispersão destes detalhes. Quanto você retoma o trabalho, você não pode se lembrar de cada um dos detalhes (como nomes de variáveis locais que estava usando ou onde você estava na implementação daquele algoritmo de busca) e você tem que lembrar estas coisas, o que o retarda um bocado até que você volta à velocidade original.

Eis a matemática. Digamos (como a evidência sugere) que se nós interrompermos um programador, mesmo que por um minuto, estaremos realmente desperdiçando 15 minutos de produtividade. Para este exemplo, vamos tomar dois programadores, João e Manoel, em baias abertas próximas no padrão Dilbert de fazenda de engorda de gado. Manoel não consegue lembrar o nome da versão Unicode da função strcpy. Ele pode procurá-la, o que leva 30 segundos, ou pode perguntar ao João, o que leva 15 segundos. Uma vez que ele está sentado ao lado do João, ele pergunta ao João. João se distrai e perde 15 minutos de produtividade (para economizar 15 segundos do Manoel).

Agora vamos colocá-los em escritórios separados com paredes e portas. Agora quando Manoel não lembrar o nome daquela função, ele pode procurar, o que ainda leva 30 segundos, ou ele pode perguntar ao João, o que agora leva 45 segundos e envolve se levantar (uma tarefa difícil, dada a forma física média de programadores!). Então ele procura. Agora Manoel perdeu 30 segundos de produtividade, mas nós salvamos 15 minutos do João. Ahhh!

9. Você usa as melhores ferramentas que o dinheiro pode comprar?

Escrever código numa linguagem compilada é uma das últimas coisas que ainda não podem ser feitas instantaneamente num computador doméstico de fundo de quintal. Se seu processo de compilação leva mais que alguns segundos, usar o mais novo e mais potente computador irá poupar seu dinheiro. Se a compilação leva até 15 segundos, os programadores ficarão entediados enquanto o compilador roda e passarão a ler The Onion, o que irá distraí-los e matar horas de produtividade.

Debugar código visual com um único monitor é doloroso, se não impossível. Se você está escrevendo código visual, dois monitores farão as coisas muito mais fáceis.

A maioria dos programadores eventualmente tem que manipular bitmaps de ícones ou barras de ferramentas, e a maioria dos programadores não tem um bom editor de bitmaps disponível. Tentar usar o Microsoft Paint é uma piada, mas é o que a maioria dos programadores têm de fazer.

Em meu último emprego, o administrador de sistemas ficou me mandando mensagens automáticas reclamando que eu estava usando mais do que… veja só… 220 megabytes de espaço em disco no servidor. Eu argumentei que, dado o preço dos discos hoje em dia, o custo deste espaço era significantemente menor que o custo do papel higiênico que eu estava usando. Mesmo gastar 10 minutos limpando meu diretório seria um fabuloso desperdício de produtividade.

Boas equipes de desenvolvimento não torturam seus programadores. Mesmo as menores frustrações causadas pelo uso de ferramentas inadequadas são acumuladas, tornando os programadores nervosos e infelizes. E um programador nervoso é um programador improdutivo.

Complementando… programadores são facilmente subornados dando-lhes o equipamento mais novo e legal. É uma maneira mais barata de colocá-los a trabalhar pra você do que realmente pagamento salários competitivos!

10. Você tem testadores?

Se sua equipe não tem testadores dedicados, ao menos um para cada dois ou três programadores, ou você está ou entregando produtos com bugs ou perdendo dinheiro, tendo programadores de U$100/hora fazendo um trabalho que poderia ser feito por testadores a U$ 30/hora. Economizar em testadores é uma falsa economia tão escandalosa que eu fico simplesmente abismado com o fato de que mais pessoas não reconheçam isso.

Leia As Cinco Principais Razões (Erradas) Para Não Se Utilizar Testadores, um artigo que escrevi sobre este assunto.

11. Novos candidatos escrevem código durante a entrevista?

Você contrata um mágico sem pedir a ele para mostrar alguns truques? Claro que não.

Você contrata um bufê para seu casamento sem provar sua comida? Eu duvido. (Ao menos que seja sua tia Maria e ela iria odiá-lo para sempre se você não a deixasse fazer seu “famoso” bolo de fígado moído).

Apesar disso, todo dia, programadores são contratados com base num currículo bonito ou porque o entrevistador gostou de conversar com ele. Ou perguntam-se questões triviais (“Qual a diferença entre CreateDialog() e DialogBox()?”), que poderiam ser respondidas com uma olhada na documentação. Você não deve se preocupar com as habilidades dos candidatos em memorizar milhares de trivialidades sobre programação, você deve se preocupar com suas habilidades em produzir código.Ou, pior ainda, perguntam-se questões “AHA!”: o tipo de questões que parecem fáceis quando você sabe a resposta, mas se você não sabe, são impossíveis.

Por favor, pare de fazer isto. Faça o que quiser durante a entrevista, mas faça o candidato escrever algum código. (Para maiores informações, leia meu Guia de Guerra para Entrevistas.)

12. Você faz testes de usabilidade de corredor?

Um teste de usabilidade de corredor é o qual você pega a primeira pessoa que passa no corredor e a força a usar o código que acabou de escrever. Se você fizer isto com cinco pessoas, você aprenderá 95% do que existe para ser aprendido sobre problemas de usabilidade em seu código.

Projetar uma interface amigável não é tão difícil quanto você pensa, e é crucial se você quer que os clientes adorem e comprem seu produto. Você pode ler meu livro grátis on-line de projeto de interface de usuário, um curto livro de instruções para programadores.

Mas a coisa mais importante sobre interfaces é que se você mostra seu programa para uma porção de pessoas (de fato, cinco ou seis são o suficiente), você descobrirá rapidamente os principais problemas que as pessoas terão. Leia o artigo de Jakob Nielsen explicando o porquê. Mesmo que sua habilidade em projetar interfaces esteja fraca, tão logo você se force a fazer testes de usabilidade de corredor, que não custam nada, suas interfaces serão muito, muito melhores.

Quatro maneiras de usar o Teste do Joel

1. Pontue sua própria empresa e me conte o resultado, para que eu possa fazer fofocas.
2. Se você é o gerente de uma equipe de programação, use isto como uma check-list para garantir que seu time está trabalhando o melhor quanto possível. Quando você começar a atingir os 12, você pode deixar seus programadores em paz e dedicar todo o seu tempo mantendo os executivos longe de chateá-los.
3. Se você está decidindo se aceita ou não um novo emprego, pergunte ao seu possível empregador como eles se classificam neste teste. Se for demasiadamente baixo, tenha a certeza de que terá a autoridade de corrigir estas coisas. De outra maneira, você ficará frustrado e improdutivo.
4. Se você é um investidor fazendo uma investigação minuciosa para julgar o valor de uma equipe de programação ou se sua empresa de software está considerando uma parceria com outra, este teste pode proporcionar um rápido princípio básico.

Esse artigo apareceu originalmente em Inglês com o título The Joel Test: 12 Steps to Better Code