Como a dívida de fato chega

Dívida técnica costuma ser descrita como gradual: um acúmulo lento, uma rampa. Neste repositório ela é mensurável, e não é uma rampa.

A arqueologia

O job de lint na CI roda bin/rubocop -f github. Aqui está quando ele quebrou, e quando foi consertado.

Um commit antes do df07c45:

$ git checkout df07c45~1 && bin/rubocop
401 files inspected, no offenses detected

No df07c45: "Challenges: progressive hints, gated solutions with XP forfeit, friendly test feedback":

$ git checkout df07c45 && bin/rubocop
414 files inspected, 16 offenses detected, 8 offenses autocorrectable

No dia anterior ao conserto, seis dias e 361 commits depois:

$ git checkout df99fec~1 && bin/rubocop
422 files inspected, 23 offenses detected, 12 offenses autocorrectable

Hoje:

$ bin/rubocop
601 files inspected, no offenses detected

Verde, depois dezesseis, depois vinte e três, depois verde de novo: consertado no commit df99fec, seis dias depois de quebrar.

flowchart TB
  A["df07c45~1: 401 arquivos, 0 ocorrências"] --> B["df07c45: 414 arquivos, 16 ocorrências"]
  B --> C["361 commits depois: 422 arquivos, 23 ocorrências"]
  C --> D["df99fec, dia 6: de volta a 0 ocorrências"]
  A --> E["o build era um sinal funcionando"]
  B --> F["um commit, um dia, uma funcionalidade"]
  C --> G["sete ocorrências a mais em 361 commits"]
  D --> H["um comando, um commit, consertado"]

As duas metades

O degrau. O df07c45 é uma funcionalidade grande. Mais de vinte arquivos, duas migrações, dois controllers Stimulus, um objeto de política, chaves de idioma nos dois idiomas, uma mudança de schema. Dezesseis ocorrências chegaram junto, todas de um cop só, todas seguras para autocorreção. Ninguém escolheu isso; uma funcionalidade grande chegou e a opinião do formatador sobre colchetes de array veio junto.

A deriva. Sete ocorrências a mais em 361 commits e seis dias. Não uma enchente: um gotejamento, no padrão que se esperaria de um sinal que parou de funcionar.

A segunda metade só aconteceu por causa da primeira. Enquanto o job estava verde, uma única ocorrência o deixaria vermelho e seria consertada no mesmo pull request. Depois que ficou vermelho, a vigésima terceira ocorrência não custou nada para ser adicionada, porque o build já estava falhando.

O que isso mostra sobre acúmulo

Dívida chega em degraus, e se acumula em rampas. O degrau costuma ser uma funcionalidade real entregue sob pressão real. A rampa é o que acontece depois, e sua taxa é definida por se algo ainda está vigiando.

Essa distinção muda o que uma pessoa líder faz sobre isso, porque as duas metades têm respostas diferentes.

Você não pode evitar o degrau. Uma funcionalidade de vinte arquivos sempre vai trazer algo junto, e um processo desenhado para impedir isso impede a funcionalidade também.

Você pode evitar a rampa completamente, e custa um comando na mesma semana. O bin/rubocop -a a qualquer momento naqueles 361 commits levaria menos de um minuto e encerraria o acúmulo. Neste repositório, foi o que acabou acontecendo: seis dias depois do degrau, alguém rodou, num commit feito segundos depois dos dois que consertaram os avisos do Brakeman de busca e validação de URL de um curso completamente diferente.

O número que importa

Não 23, e não o dia em que foi consertado. 361.

Trezentos e sessenta e um commits foram mesclados com o job de CI falhando antes de alguém agir sobre isso. Cada um deles tinha um check vermelho no pull request. E cada um foi mesclado assim mesmo, o que significa que, pelo commit cinco ou dez, o check vermelho já tinha virado parte do cenário.

Essa é a dívida real, e é a parte que o conserto não desfaz. As ocorrências foram um minuto de trabalho, quando enfim alguém fez. O hábito de mesclar apesar de um check vermelho é uma propriedade do time, levou seis dias para se formar. E vai se aplicar ao próximo check vermelho independente do que o causou, que é o único motivo de isso valer a pena estudar depois do fato, em vez de arquivar como resolvido.

A versão de quem lidera disso

Uma pessoa contribuidora individual lê essa história como "consertamos o rubocop." Quem lidera lê como três perguntas:

Por quanto tempo ficou quebrado antes de alguém falar? Seis dias, 361 commits, e foi encontrado (e consertado) pela mesma passada que por acaso estava olhando o build por um motivo não relacionado, não por um processo construído para pegar isso.

A que mais esse padrão se aplica? Na mesma semana, o mesmo mecanismo explicava seis avisos do Brakeman que também tinham ficado sem vigilância: sinal diferente, mesmo hábito.

O que tornou mesclar apesar de um check vermelho normal, e isso aconteceria de novo? Essa é a única pergunta com resposta duradoura, e ela não é respondida pelo fato de este caso específico ter sido consertado.

Pontos-chave

• Medido: 0 ocorrências antes do df07c45, 16 nele, 23 no dia antes do conserto, 361 commits depois, e então 0 de novo, consertado num único commit.
• Dívida chega em degraus (uma funcionalidade grande sob pressão) e se acumula em rampas.
• A rampa só aconteceu porque o degrau matou o sinal que a teria pego.
• O número que importa é 361: commits mesclados apesar do check vermelho, até o vermelho virar cenário, antes de alguém agir.
• Consertar as ocorrências levou um minuto; o hábito de mesclar apesar do vermelho levou seis dias para se formar. E sobreviver ao conserto é o motivo de valer a pena estudar.