Joel on Software   Joel sobre Software

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel On Software" em Inglês

Escreva ao autor(Apenas em Inglês)

Já ouviu falar da SEMA? Trata-se de um processo esotérico imparcial para medir a qualidade de uma equipa de software. Não, espere! Não clique no URL ! Vai demorar-lhe cerca de seis anos só para o perceber aquilo. Por isso resolvi fazer o meu próprio processo, bastante irresponsável e descuidado, para calcular a qualidade de uma equipa de software. A parte boa disto é que o processo em si demora cerca de 3 minutos. Com todo o tempo que poupa poderá ir estudar medicina.

A coisa boa do Teste do Joel é que é fácil de obter um sim ou não para cada pergunta. Não precisa de descobrir quantas linhas-de-código-por-dia ou média-de-bugs-por-ponto-de-inflexão. Atribua à equipa um ponto por cada resposta "sim". A problema acerca do Teste do Joel é que você nunca o deverá usar para ter certeza que o software de uma central nuclear é seguro.

Um resultado com 12 pontos é perfeito, 11 é tolerável, mas 10 ou menos significa que você tem sérios problemas. A verdade é que a maior parte das organizações estão a funcionar com um resultado de 2 ou 3 pontos, e precisam de ajuda a sério, porque empresas como a Microsoft funcionam com 12 pontos a tempo inteiro.

Claro que estes não são os únicos factores que determinam o sucesso ou o fracasso: em particular, se você tem uma equipa de software excelente a trabalhar num produto que ninguém quer, bem, as pessoas não o vão querer na mesma. E é possível imaginar uma equipa de "pistoleiros" desregrados e indomáveis que não faz nada do que está descrito no teste e consegue produzir software incrível que muda o mundo. Mas, sendo tudo normal, se você consegue estas 12 coisas correctas obterá uma equipa disciplinada que pode produzir consistentemente.

1. Usa controlo de versões de código?
Tenho utilizado pacotes comerciais para controlo de versão de código e usei o CVS, que é gratuito, e deixe-me dizê-lo, CVS é bom. Mas se você não tem controlo de versão de código, vai ter grandes problemas quando tentar colocar vários programadores a trabalhar em conjunto. Programadores não têm maneira de saber o que os outros estão a fazer ou fizeram. Erros não podem ser revertidos facilmente. Outra coisa boa acerca sistemas de controlo de versões de código é que o código fonte vai estar "checked out" em cada disco local do programador -- nunca ouvi falar de um projecto de software a usar controlo de versões de código que tenha perdido uma grande quantidade de código.

2. Consegue fazer uma compilação num passo único?
Com isto quero dizer: quantos passos vão ser necessários para fazer uma "compilação para distribuição" a partir do código fonte mais recente? Em boas equipas existe um único conjunto de comandos que você pode executar que faz um checkout completo de raiz, recompila tudo, faz os ficheiros executáveis em todas as versões e linguagens, combinações de #ifdef, cria o pacote de instalação e produz o suporte final -- CDROM, download para o website, ou o que mais for necessário.

Se o processo é composto por mais de um passo, é propenso a erros. E quando nos aproximamos da data de lançamento, vamos querer ter um ciclo rápido para corrigir o "último" bug, fazer os executáveis finais, etc. Se isto são 20 passos para compilar o código, construção do instalador, etc., você vai dar em doido e em conjunto vai fazer erros estúpidos.

Por esta razão, a última empresa onde trabalhei mudou do WISE para o Installshield: nós requeremos que a processo de instalação fosse capaz de executar, a partir de um "script", automaticamente, durante a noite através da utilização do scheduler do NT, e o WISE não conseguia; por isso mandámo-lo porta fora (o pessoal simpático na WISE assegura-me que a última versão suporta de facto compilações nocturnas).

3. Faz compilações diárias?
Quando você usa controlo de versões de código, às vezes um programador acidentalmente faz o checkin de alguma coisa que vai fazer com que a compilação falhe. Por exemplo, ele adicionou um ficheiro de código novo e tudo compila perfeitamente na sua máquina, mas esqueceu-se de o adicionar ao repositório de código. Ele bloqueia o seu computador e vai para casa, esquecido e feliz. Mas ninguém mais pode trabalhar, logo têm de ir para casa também, tristes.

Fazer falhar uma compilação é tão mau (e comum) que ajuda fazer as compilações diárias para estarmos certos de que nenhuma falha passa despercebida. Em grandes equipas uma boa maneira de assegurar que as falhas são corrigidas imediatamente é fazer uma compilação todas as tardes, por volta da hora do almoço. Toda a gente deve fazer o máximo de checkins antes do almoço. Quando voltam do almoço a compilação está feita. Se trabalhou, fixe! Toda a gente faz o check out da última versão do código e continua a trabalhar. Se a compilação falhou, você corrige, mas todos os outros continuam a trabalhar com o código antes da compilação, que não tem falhas.

Na equipa do Excel tínhamos uma regra que quem quebrasse a compilação, tinha como castigo cuidar das compilações até que outra pessoa quebrasse a compilação. Isto era um bom incentivo a não quebrar as compilações, e uma boa maneira de fazer a rotação de todo o pessoal pelo processo de compilação e assim toda a gente aprendia como funcionava.

Leia mais acerca das compilações diárias no meu artigo Compilações Diárias são Suas Amigas.

4. Tem uma base de dados de bugs?
Não quero saber do que possa dizer. Se está a desenvolver código, mesmo numa equipa de uma pessoa, sem uma base de dados organizada que liste todos os bugs conhecidos no código, você vai produzir código de baixa qualidade. Muitos programadores pensam que podem conter a lista de erros na própria cabeça. Disparate. Não me consigo lembrar de mais que dois ou três bugs de cada vez, e na manhã seguinte, ou na pressa de produzir a release, eles serão esquecidos. Você tem que controlar de forma minuciosa e formal os erros no código.

Bases de dados de bugs podem ser complexas ou simples. Uma base de dados mínima e que faça jeito deve incluir para cada bug:

• passos completos para reproduzir o bug
• o comportamento esperado
• o comportamento (errado) observado
• quem é o responsável
• se foi ou não corrigido

Se a complexidade do software de controlo de bugs é a única coisa que o está a impedir de fazer um controlo dos bugs, faça uma simples tabela com 5 colunas com os pontos cruciais acima referidos e comece a usá-la.

Para mais informação acerca de controlo de bugs, leia Forma Simples de Controlar bugs.

5. Corrige os bugs antes de escrever novo código?
A primeira versão do Microsoft Word foi considerada um projecto "a caminhar para a morte". Demorou a ser feita. Sempre a deslizar. Toda a equipa estava a trabalhar horas ridículas, o projecto estava sempre a ser atrasado, e mais uma vez, e outra, e o stress era incrível. Quando a "maldita" coisa finalmente foi lançada, anos atrasada, a Microsoft mandou toda a equipa de férias para Cancum, depois acalmaram-se para fazer uma séria procura do que correu mal, uma espécie de auto-análise.

O que eles descobriram foi que os chefes de projecto tinham sido tão insistentes em manter a agenda à risca, que os programadores simplesmente aceleraram o desenvolvimento do código, escrevendo código extremamente mau, e tudo porque corrigir os bugs não estava formalmente na agenda. Não houve preocupação para manter o número de erros no mínimo. Bem pelo contrário. A história continua com um programador, que tinha de escrever código para calcular a altura de uma linha de texto, simplesmente escreveu "return 12;" e esperou que aparecesse no relatório de bugs algo relativo ao facto de a função nem sempre estar correcta. A planificação era uma mera lista de "features" que estavam à espera de serem transformadas em bugs. No "post-mortem", isto foi referido como "metodologia dos erros infinitos".

Para corrigir o problema, a Microsoft adoptou universalmente qualquer coisa chamada de "metodologia de zero erros". Muitos dos programadores na empresa riram-se baixinho, tudo porque soava como que a chefia poderia reduzir o número de bugs através de gestão autoritária. De facto, "zero erros" significava que a qualquer altura a mais alta prioridade era eliminar erros antes de escrever novo código. Aqui está o porquê.

Normalmente, quanto mais se espera para corrigir um bug, mais custos (tempo e dinheiro) implica para o corrigir.

Por exemplo, quando faz um erro ortográfico ou sintaxe que faz o compilador falhar, corrigi-lo é trivial.

Quando tem um erro no código que aparece na primeira vez que tenta executar o código, consegue corrigi-lo imediatamente, tudo porque o código ainda esta "fresco" na sua memória.

Se encontra um bug no código que escreveu alguns dias atrás, vai demorar algum tempo até o conseguir resolver, mas se reler o código que escreveu, vai conseguir lembrar-se tudo e vai-lhe ser possível corrigir o erro num curto espaço de tempo.

Mas se você encontra um erro no código que escreveu há alguns meses atrás, mais provavelmente você já esqueceu uma boa parte das coisas acerca do código, e vai-lhe ser muito mais difícil corrigir o erro. E quando chegar o momento de possivelmente corrigir código escrito por outros programadores, que poderão estar em Aruba de férias, corrigir o erro é quase uma ciência: você tem de ser lento, metódico, meticuloso, e não consegue saber quanto tempo vai demorar até descobrir a solução.

E se você encontrar um erro em código que já foi distribuído , vai incorrer despesas incríveis para o corrigir.

Esta é uma razão para corrigir erros imediatamente: porque vai demorar menos tempo. Há outra razão, que está relacionada com o facto de que é mais fácil prever quanto tempo demora para fazer código novo do que corrigir um erro existente. Por exemplo, se lhe perguntarem para prever quanto tempo demora a escrever código para ordenar uma lista, você pode dar-me uma estimativa boa. Mas se eu pedir para estimar quanto tempo vai demorar para corrigir um erro num código que não funciona se o Internet Explorer 5.5 está instalado, você nem sequer consegue adivinhar, porque não sabe (por definição) o que é que está a causar o erro. Pode demorar 3 dias a encontrar a causa como pode demorar 2 minutos.

O que isto significa é que se você tem um plano com  bastantes erros ainda por corrigir, o plano não é fiável. Mas se você corrigiu todos os erros conhecidos, e tudo o que fica é código novo para fazer, o plano vai ser surpreendentemente mais preciso.

Outra boa coisa acerca de manter o número de bugs junto ao zero, é de que você pode responder muito mais rapidamente à concorrência. Alguns programadores pensam nisto como sendo manter o produto pronto a ser lançado permanentemente. Se a concorrência introduz uma nova "killer feature" que já está a roubar-lhe clientes, você pode implementar apenas essa feature e lançar no momento uma nova versão, sem ter de corrigir um número grande de bugs acumulados.

6. Tem uma planificação actualizada?
O que nos trás à planificação. Se o seu código é importante para o negócio, existem muitas razões porque é que é importante para a chefia saber quando o código vai ser feito. Os programadores são notavelmente rezingões acerca de fazer planos. "Vai ser feito quando estiver feito" gritam eles para o pessoal da chefia.

Infelizmente, isso não é o suficiente. Existem diversas decisões que a chefia tem de fazer bastante antes de o código estar pronto para ser lançado: demos, feiras, publicidade, etc. E a única maneira para fazer isto é ter um plano, e mantê-lo actualizado.

Outra coisa crucial acerca de ter um plano é que força-o a decidir quais as "features" que se vão fazer, e depois força-o a escolher as menos importantes edeixá-las de lado em vez de cair em featuritis (também conhecido por "scope creep").

Manter o plano não é obrigatoriamente difícil. Leia o meu artigo Painless Software Schedules, que descreve uma maneira simples de fazer bons planos.

7. Tem uma especificação?
Escrever é como utilizar fio dental: toda a gente concorda que é bom, mas ninguém o faz.

Não tenho a certeza porque é assim, mas é provavelmente porque a maior parte dos programadores detesta escrever documentos. Como resultado, quando equipas constituídas apenas de programadores atacam um problema, preferem expressar a sua solução em código em vez de documentos. Eles vão preferir muito mais mergulhar no problema e escrever o código do que produzir uma especificação primeiro.

Na fase de design, quando você descobre problemas, pode corrigi-los facilmente através da edição de um pequeno conjunto de linhas de texto. Assim que o código é escrito, o custo de corrigir problemas é dramaticamente mais alto, tanto emocionalmente (tem que se deitar código fora) como em termos de tempo, por isso existe uma certa resistência à correcção dos problemas. O software que não foi construído a partir de uma especificação vai acabar normalmente com um design defeituoso e a planificação descontrolada. Isto parece ser o problema que existiu na Netscape, onde as quatro primeiras versões cresceram numa confusão que a gestão estupidamente decidiu deitar o código fora e começar tudo de novo. E fizeram o erro novamente com o Mozilla, criando um monstro que rodopiou fora de controlo e levou vários anos a atingir o versão alfa.

A minha teoria é que este problema pode ser corrigido através da formação dos programadores a serem menos relutantes à escrita e mandá-los para um curso intensivo de escrita de documentos. Outra solução será contratar gestores de projecto espertos capazes de produzir a especificação escrita. Em ambos os casos, você deve forçar a regra "sem especificação não há código".

Aprenda tudo acerca de escrever especificações lendo o 4-part series.

8. Os programadores têm um ambiente de trabalho agradável?
Existem ganhos de produtividade extensivamente documentados quando se fornece aos trabalhadores especializados espaço, silêncio e privacidade. O clássico livro de gestão de software Peopleware documenta estes benefícios de produtividade extensivamente.

Aqui está o problema. Todos nós sabemos que trabalhadores especializados trabalham melhor quando estão "na onda", também conhecido por estarem "no pico" [n.t. "in the zone"] , onde eles estão completamente concentrados no trabalho e completamente desligados do ambiente circundante. Eles perdem a noção de tempo e produzem excelente trabalho através de concentração absoluta. Quando isto acontece, eles conseguem fazer todo o seu trabalho produtivo. Escritores, programadores, cientistas e até jogadores de basquetebol podem fala-lhe de "estar no pico".

O problema é que entrar "no pico" não é fácil. Quando se tenta medir parece que leva em média de cerca de 15 minutos para começar a trabalhar no máximo da produtividade. Às vezes, se você está cansado ou já fez uma boa quantidade de trabalho criativo nesse dia, não consegue entrar "no pico" e vai gastar o resto do dia de trabalho na brincadeira, a navegar na internet e a jogar Tetris.

Outro problema é que é tão fácil sair "do pico". Barulho, chamadas telefónicas, ir almoçar, ter que conduzir 5 minutos para ir tomar um café e interrupções pelos companheiros de trabalho -- especialmente interrupções pelos colegas de trabalho -- tudo contribui para o atirarem fora do pico. Se um colega faz uma pergunta, causando uma interrupção de um minuto, e isto atira-o fora do pico para tão longe o suficiente para demorar cerca de meia hora a atingir a produtividade normal, a produtividade geral fica com sérios problemas. Se você está no local com muito barulho, ambiente como aquele que as dot-com "cafeinadas" adoram criar, com pessoal do marketing a gritarem no telefone ao lado, a sua produtividade vai sofrer conforme os trabalhadores especializados são constantemente interrompidos e nunca conseguem colocar-se no pico.

Com programadores, é especialmente difícil. A produtividade depende em ser capaz de jogar com bastantes pequenos detalhes na memória de curto prazo e todos ao mesmo tempo. Qualquer tipo de interrupção pode causar a perda destes detalhes. Quando se reinicia o trabalho, você não se consegue lembrar de qualquer dos detalhes (como o nome das variáveis locais que estava a usar, ou onde você estava na fase de implementação dum certo algoritmo de procura) e vai ter de procurar ou relembrar os detalhes, o que o vai atrasar bastante até que se volte novamente à velocidade normal.

Umas simples contas. Vamos supor (como os resultados sugerem) que se nós interrompemos um programador, mesmo que só por um minuto, nós estamos na realidade a desperdiçar 15 minutos de produtividade. Para este exemplo vamos colocar dois programadores, o Manuel e o Carlos em cubículos abertos um ao pé do outro num escritório em espaço aberto similar ao modelo Dilbert, tipo "aviário de engorda". Carlos não se consegue lembrar o nome da versão Unicode da função strcpy. Ele poderia procurá-la, demorando 30 segundos ou perguntar ao Manuel, o que demoraria 15 segundos. Como ele está sentado junto ao Manuel, ele pergunta ao Manuel. O Manuel é distraído e perde 15 minutos de produtividade (para poupar 15 segundos ao Carlos).

Vamos agora num ambiente de escritórios separados, com paredes e portas. Agora quando o Carlos não se consegue lembrar do nome da função, ele pode procurá-la, o que continua a demorar 30 segundos, ou poderia perguntar ao Manuel, que agora demora 45 segundos e envolve levantar-se (uma tarefa não muito fácil tendo em conta a forma atlética da maioria dos programadores!). Então ele procura o nome da função. Agora o Carlos perde 30 segundos de produtividade, mas poupamos 15 minutos com o Manuel. Ahhh!

9. Utiliza as melhores ferramentas que o dinheiro pode comprar?
Escrever código numa linguagem compilada é uma das poucas coisas que não pode ser feita instantaneamente num normal computador doméstico. Se o processo de compilação dura mais que uns poucos segundos, obter o melhor computador que o mercado pode fornecer, vai poupar-lhe tempo. Se compilar demora 15 segundos, os programadores ficarão chateados e enquanto o computador compila, eles vão ler The Onion, o que os vai manter ocupados e com isto desperdiçar horas de produtividade.

Fazer o debug de interfaces de utilizador com um monitor apenas é difícil, se não impossível. Se você está a escrever código para interfaces de utilizador, dois monitores tornam as coisas muito mais fáceis.

A maioria dos programadores tem de eventualmente manipular bitmaps para icons e toolbars. A maioria dos programadores não tem um bom editor de bitmaps. Tentar usar o Microsoft Paint para este serviço é uma anedota, mas é isto que essa mesma maioria de programadores faz.

No meu último emprego, o administrador de sistema mandava-me constantemente avisos automáticos fazendo queixa que eu estava a usar mais de ... reparem bem ... 220 megabytes de espaço no disco do servidor. Mencionei que tendo em conta o preço dos discos actualmente, o custo deste espaço era significativamente menor do que o custo do papel higiénico que eu usava. Demorar 10 minutos a limpar a minha directoria seria um desperdício de tempo fabuloso.

Equipas de software de topo-de-gama não torturam os seus programadores. Até as frustrações menores causadas pelo uso de ferramentas não adequadas vai aumentar as possibilidades de fazer os programadores tristes e mal-humorados. E um programador mal-humorado é um programador não produtivo.

Adicionando a tudo isto... programadores são facilmente subornáveis dando-lhes as coisas mais "cool" e últimas engenhocas. Isto é uma maneira muito mais barata de os fazer trabalhar para si sem lhes pagar salários competitivos!

10. Tem testadores?
Se a sua equipa não tem testadores dedicados, pelo menos um testador para cada dois ou três programadores, você está ou a lançar produtos com erros, ou está a desperdiçar dinheiro pelo facto de ter programadores pagos a $100/hora quando o trabalho pode ser feito por testadores pagos a $30/hora. Ser sovina em relação aos testadores é uma forma absurda de melhorar a economia que fico surpreendido que mais pessoas não reconheçam o problema.

Leiam Top Five (Wrong) Reasons You Don't Have Testers, um artigo que eu escrevi sobre este assunto.

11. Os novos candidatos a emprego escrevem código durante a entrevista?
Você contrataria um mágico sem lhe pedir que demonstrasse alguns dos seus truques? Claro que não.

Contrataria um cozinheiro para o seu casamento sem pelos menos provar alguma amostra da comida? Duvido (a não ser que seja a Tia Luísa, e ela iria odiá-lo para o resto da sua vida se você não a autorizasse a fazer o seu "famoso" bolo de fígado picado).

No entanto, todos os dias, programadores são contratados na base de um CV "impressionante" ou porque o entrevistador gostou de falar com eles. Ou são-lhes feitas perguntas tão triviais ("qual a diferença entre CreateDialog() e a DialogBox()?"), que podem ser respondidas através de uma vista de olhos na documentação. Não importa se eles decoraram milhares de respostas simples acerca de programação, o que importa é se eles sejam capazes de produzir código. Ou, muito pior, quando se fazem perguntas "AHA!": do tipo que parecem fáceis quando você sabe a resposta, mas que se você não sabe a resposta são impossíveis de responder.

Por favor, pare de fazer isto. Faça o que quiser durante as entrevistas, mas faça com os candidatos escrevam algum código. (Para mais conselhos, leia o meu artigo Guerrilla Guide to Interviewing.)

12. Faz "testes de corredor"?
Um teste de corredor é quando você pega na pessoa que vai a passar no corredor e força-a a tentar utilizar o código que acabou de escrever. Se fizer isto com 5 pessoas, vai aprender 95% do que há para aprender em termos de problemas de funcionalidade no seu código.

Uma boa interface do utilizador não é tão difícil como se possa imaginar, e é crucial se quiser que os clientes gostem e comprem o seu produto. Pode ler o meu livro online grátis sobre UI design, um livro curto para programadores.

Mas a coisa mais importante acerca das interfaces do utilizador é que se mostrar o seu programa a bastantes e variadas pessoas, (de facto, cinco ou seis é suficiente), rapidamente descobre os principais problemas que as pessoas estão a ter. Leia o artigo de Jakob Nielsen onde explica porquê. Mesmo que os seus conhecimentos de design de interfaces de utilizador sejam fracos, desde que você se comprometa a fazer estes testes de corredor, que em termos de custo são grátis, a sua interface de utilizador vai ser muito, muito melhor.

Quatro Maneiras Para Usar O Teste Do Joel

1. Classifique a sua própria organização de software, e diga-me qual foi, para que eu possa cuscar.
2. Se você é um chefe de uma equipa de software, use isto como "checklist" para ter a certeza de que a sua equipa está a trabalhar o melhor possível. Quando a classificação chegar aos 12 pontos, pode "deixar os seus programadores sozinhos" e preocupar-se impedir que os "business people" os chateiem.
3. Se você está a tentar decidir se deve aceitar um trabalho como programador, pergunte à empresa qual seria a classificação deles neste teste. Se for bastante baixa, tenha a certeza que vai ter autorização para corrigir estas coisas. Ou então vai sentir-se frustrado e não produtivo.
4. Se você é um investidor fazendo o possível para verificar o valor de uma equipa de programadores, ou se é uma empresa de software a considerar uma possível fusão com outra, este teste pode ser um guia básico.