Nós que somos programadores sabemos o quão simples é o ato de desenvolver um software, é sentar algumas horas1Muitas e pronto, temos um jogo, ou um site, ou uma calculadora. Porém, quando vamos para um nível corporativo, as coisas deixam de ser assim, perdendo-se meses, as vezes até anos.

A vida já é bastante complicada, desenvolvimento de software não deveria ser.

Garanto que isto é um desejo de muitos programadores, porém nós que estamos na indústria de desenvolvimento de software sabemos que não é bem assim que funciona.

Perdidos entre reuniões, prazos e incêndios do dia a dia, fiquei me perguntando: Onde erramos?

A partir disso eu decidi estudar meu dia a dia e após um mês, constatei alguns itens interessantes:

• 60% do meu tempo foi gasto resolvendo problemas de naturezas similares
• 10% foram reuniões e/ou telefonemas que poderiam ser um e-mail
• 30% foi de fato produtivo, gasto em evoluções do software

Os 10% de reuniões ou telefonemas não tem muito onde melhorar, é uma cultura empresarial onde eu não posso influenciar facilmente, porém os 60% são bem problemáticos.

Tentando entender a causa deles, eu me deparei com uma situação bem similar ao Go Horse 2Vale a pena ler também os itens do eXtreme Go Horse.

• Hierarquia 3Todos nós sabemos que um pedido da diretoria vale muito mais do que o do seu colega.
• Entrega a qualquer custo 4Quantos “puxadinhos” já fizemos para garantir uma entrada de um projeto?
• Enriquecimento dos acionistas 5Cliente? Só depois de terminar o que o dono pediu.
• Trabalhando sem perder tempo 6“Quando foi a última vez que alguém leu uma documentação”.

Claro que estou problematizando os assuntos, não é sempre assim nem muito menos com essa intensidade, porém várias das causas podemos apontar, são muitas vezes dificultadas por outros problemas existentes.

Procurando melhorar a situação, me deparei com um guia de 12 passos para um código melhor, do Joel Spolsky7The Joel Test: 12 Steps to Better Code

O teste de Joel são 12 simples perguntas que devem ser respondidas com um sim ou não cuja a resposta indica muito a saúde do seu processo de desenvolvimento como um todo, onde ao responder “não” para qualquer uma delas, é bem detrimental. Segue uma transcrição delas:

1. Você usa controle de versão?
2. Consegue compilar seu projeto em apenas um passo?
3. Você faz compilações diárias?
4. Você gerência os bugs em uma ferramenta?
5. Você corrige os bugs antes de escrever novo código?
6. Você tem um planejamento atualizado?
7. Você tem uma especificação?
8. Seus programadores trabalham em um ambiente quieto?
9. Você utiliza as melhores ferramentas/equipamentos que se pode comprar?
10. Você tem pessoas dedicadas para realizar testes?
11. No seu processo seletivo, candidatos devem escrever código?
12. Você faz o teste de usabilidade do corredor?8Pegar a primeira pessoa não relacionada com o projeto no corredor e pedir para ela testar.

Conseguir responder sim para todas é o ideal, porém 10 e 11 ainda podemos considerar um nível tolerável, porém qualquer coisa menor que isso indicam sérios problemas, característicos de empresas que adotam a metodologia Go Horse.