Como trabalhador em uma faculdade pública onde a gestão do atual reitor está perto de acabar, todo o meu departamento foi obrigado a entregar uma documentação inteira de tudo que foi feito no ano todo, e ainda uma explicação de todos os processos e páginas de todos os sites que temos. Resultado: dois dias inteiros de trabalho perdido.

Esta prática de documentar bem o software vem do início da tecnologia da informação, onde o cara programava com cartões perfurados e o software então levava o dia inteiro compilando. Documentar bem o software era essencial para não perder dias de trabalho compilando algo que não funcionaria bem.

Com o tempo, a velocidade dos computadores aumentaram bastante, e podemos ver o resultado do nosso código de forma quase instântanea. Ao mesmo tempo, a complexidade dos softwares foi aumentando mais e mais. A documentação começou a não dar mais conta de tudo, e não era mais uma solução eficiente.

Para resolver isso, foram decidindo que a solução para isso era fazer mais e mais documentação. Criar mais e mais papel que ninguém vai ler. E isso não resolve problema algum.

Veja nosso caso, aqui na UERJ. Perdemos cerca de dois dias sem que uma única linha de código fosse produzido, porque toda a equipe estava produzindo a documentação. E aposto que o reitor não lerá nem um quinto das mais de 100 páginas.

Eu diria que um código limpo e claro, com comentários nas partes necessárias, vale muito mais do que uma documentação. Um código que fale por si, sem gambiarras, sem algoritmos bizarros. Isso sim vale muito mais do que uma documentação (que fica desatualizada em uma semana) e ainda desperdiça menos o tempo dos programadores.

Posts recomendados:

  1. Você tem tempo?