Tempo para entender um código fonte

Um problema que, infelizmente, é comum no setor de desenvolvimento, é o de ter que mexer em código feitos por outras pessoas ou mesmo códigos feito por nós mesmos mas de meses ou anos atrás.

No o livro: A Arte de Escrever Programas Legíveis de Dustin Boswell e Trevor Foucher vi a ideia da métrica "tempo-para-entender".

Ela funciona mais ou menos assim, eu escrevo um código depois escolhemos alguém da nossa equipe de desenvolvimento e medimos quanto tempo esse alguém leva par ler e entender o meu código. Esse "tempo-para-entender" seria a métrica teórica que deveríamos minimizar.
Para que alguém entenda completamente o código, ele deve ser capaz de fazer alterações, encontrar bugs e compreender como ele interage com o restante do código.

Acredito que ela possa melhorar nossa forma de programar e minimizar o custo de manutenção do código alheio. Poderíamos comparar os bons e maus hábitos de cada um na equipe e tentar eliminar tudo que dificulta a compreensão do código.

Lembrando:

Um programa deve ser escrito pensando nos outros programadores da equipe, pois o maior custo de um programa está em sua manutenção por outros desenvolvedores.
Em muitos casos, alguns milissegundos a menos em determinadas rotinas não fazem diferença para os usuários, já o tempo que gastamos para dar manutenção em um código de difícil entendimento e consequentemente quando demoramos de corrigir os erros e estouramos os prazos, isso provoca grandes aborrecimentos nos clientes.

"Códigos devem ser escritos de modo a minimizar o tempo necessário para sua compreensão."