Regra 10: 1 em programação e redação

Neste artigo, o autor analisa a quantidade de tempo gasto na escrita de livros ou código de programa e chega a um padrão interessante. Pode ser usado para agendar o trabalho do projeto.

Lei de Hofstadter: Qualquer empresa sempre dura mais do que o esperado, mesmo se você levar em consideração a lei de Hofstadter.
- Douglas Hofstadter, Gödel, Asher, Bach

Escrever prosa e código tem muito em comum. Mas a semelhança mais notável é provavelmente que nem escritores nem programadores podem terminar seu trabalho a tempo. Os escritores são famosos por quebrar os prazos. Os programadores conquistaram a reputação de pessoas cujos resultados sempre são seriamente diferentes dos cálculos iniciais. Surge a pergunta: por que?

Hoje eu tive uma idéia de como responder. E minhas descobertas me surpreenderam.

Estudando meus livros

Ambos os meus livros, Olá, startup e Terraform: lançamos e trabalhamos , escrevi no ambiente de criação de livros da Atlas , que fornece o gerenciamento de todo o conteúdo usando o Git. Isso significa que todas as linhas de texto, todas as edições e todas as alterações foram confirmadas no log de confirmação do Git.

Vamos verificar quanto esforço foi gasto escrevendo dois livros.

Oi inicialização

Vamos começar com o meu primeiro livro, Olá, inicialização . Possui 602 páginas e aproximadamente 190 mil palavras. cloc o cloc no repositório git Hello, Startup e obtive os seguintes resultados (por simplicidade, as partes fracionárias são descartadas):



602 páginas contêm 26.571 linhas de texto. A parte do leão está escrita em AsciiDoc , semelhante ao Markdown. É usado pelo Atlas para escrever quase qualquer conteúdo. Usando HTML e CSS, o Atlas define o layout e a estrutura de um livro. Além deles, existem outras linguagens de programação (Java, Ruby, Python e não apenas), nas quais vários exemplos são escritos para os tópicos discutidos no livro.

Mas 602 páginas e 26.571 linhas são apenas o resultado final. Eles não refletem cerca de 10 meses de redação, alteração, edição, revisão, ajustes estilísticos, pesquisas, anotações e outros trabalhos que contribuem para a publicação do livro. Portanto, para obter idéias mais úteis, usei o git-quick-stats para analisar todo o registro de confirmação do livro.



Então, adicionei 163.756 linhas e excluí 131.425, o que totaliza 295.181 linhas de material processado. Ou seja, acontece que escrevi ou excluí um total de 295 181 linhas, das quais 26 571 permanecem como resultado. Essa proporção é um pouco acima de 10: 1. Para obter cada linha publicada, eu tive que escrever outras 10 primeiro!

Admito que contar o número de linhas adicionadas e removidas do Git não pode ser considerado uma métrica ideal para o processo de edição. Mas, pelo menos, isso nos permite entender que um cálculo simples não é suficiente para avaliar o trabalho realizado. Uma parte substancial do processo não foi refletida no log de confirmação do Git. Por exemplo, os primeiros capítulos foram escritos no Google Docs antes de eu me mudar para o Atlas e várias edições foram feitas no meu computador sem confirmação.

Apesar de esses dados estarem longe do ideal, acredito que a proporção geral de "material de texto original" para publicado seja de 10: 1.

Terraform: começamos e trabalhamos

Vamos verificar se essa proporção é aplicável ao meu segundo livro Terraform: lançamos e trabalhamos , que contém 206 páginas e cerca de 52 mil palavras.

A saída simplificada do cloc :



206 páginas consistem em 8410 linhas de texto. Novamente, a maior parte do texto está escrita no AsciiDoc, embora este livro contenha significativamente mais exemplos de código escritos principalmente no HCL, o idioma principal do Terraform. Além dele, existem muitos Markdowns que eu usei para documentar exemplos de HCL.

Usaremos o git-quick-stats para verificar o histórico de revisões deste livro:



Por quase cinco meses, adicionei 32.209 e excluí 22.402 linhas, totalizando 54.611 linhas recicladas. A precisão da avaliação do processo de edição deste livro sofre ainda mais, pois o trabalho começou como uma série de postagens de blog que passaram por uma revisão tangível antes de serem transferidas para Atlas e Git. O volume dessas postagens do blog ocupa pelo menos metade do livro; portanto, será lógico aumentar a taxa final do texto processado em 50%. Ou seja, resultará em 54611 * 1,5 = 81 916 linhas de texto editável, resultando em um total de 8410 linhas.

E, novamente, uma proporção de cerca de 10: 1 é observada!

Não é de surpreender que os escritores não cumpram os prazos. Se a programação deve entregar um livro de 250 páginas, na prática acontece que, no processo, escreveremos 2500 páginas.

E a programação?

Como está indo o desenvolvimento? Decidi verificar vários repositórios git de código aberto com diferentes níveis de maturidade: de alguns meses a 23 anos.

terraform-aws-couchbase (2018)

terraform-aws-couchbase é um conjunto de módulos para implantar e gerenciar o Couchbase na AWS, cujo código-fonte foi aberto em 2018.

A saída simplificada do cloc :



E aqui está o resultado da verificação do git-quick-stats :



Obtemos até 37 693 linhas de código funcional, resultando em 7481 linhas do código final em uma proporção de 5: 1. Mesmo no repositório com menos de 5 meses, tive que reescrever cada linha cinco vezes! Não é de surpreender que avaliar o desenvolvimento de software seja complicado: nem imaginamos que, para obter 7,5 mil linhas de código final, tenhamos que escrever 35 mil

Vamos ver como estão as coisas com produtos mais antigos.

Terratest (2016)

Terratest é uma biblioteca de código aberto criada em 2016 para testar o código de infraestrutura.

A saída simplificada do cloc :



Os resultados do git-quick-stats :



São 49 126 linhas de código em funcionamento, que se transformaram em 6140 linhas do texto final. Para um repositório de dois anos, a proporção era de 8: 1. Mas o Terratest ainda é bem jovem, então vamos dar uma olhada nos repositórios mais antigos.

Terraform (2014)

Terraform é uma biblioteca de código aberto criada em 2014 para gerenciar a infraestrutura usando métodos de programação.

A saída simplificada do cloc :



Os resultados do git-quick-stats :



Temos 12.945.966 linhas de código em funcionamento, resultando em 1.371.718 linhas do resultado final. Proporção 9: 1. O Terraform existe há quase 4 anos, mas a biblioteca ainda não foi lançada, portanto, mesmo com essa proporção, sua base de código ainda não pode ser chamada de madura. Vamos olhar ainda mais para o passado.

Express.js (2010)

Express é uma estrutura JavaScript de código aberto popular, lançada para desenvolvimento na Web em 2010.

A saída simplificada do cloc :



Os resultados do git-quick-stats :



Temos 224 211 linhas de código de trabalho, reduzidas para 15 325 linhas finais. Resultado 14: 1. Express tem cerca de 8 anos, suas versões mais recentes são o número 4.x. É considerado o framework da Web mais popular e testado em batalha para o Node.js.

Parece que assim que a proporção atinge o nível de 10: 1, podemos dizer com segurança que a base de código já está "madura". Vamos verificar o que acontece se você se aprofundar ainda mais no passado.

jQuery (2006)

O jQuery é uma popular biblioteca JavaScript de código aberto lançada em 2006.

A saída simplificada do cloc :



Os resultados do git-quick-stats :



Total de 730.146 linhas de código de trabalho, resultando em 47.559 linhas do resultado final. Relação 15: 1 para um repositório de quase doze anos.

Vamos mais dez anos atrás.

MySQL (1995)

O MySQL é um popular banco de dados relacional de código aberto criado em 1995.

A saída simplificada do cloc :



Os resultados do git-quick-stats :



Temos 58 562 999 linhas de trabalho, 3 662 869 linhas do código final e uma proporção de 16: 1 para um repositório de quase 23 anos. Uau! Cada linha do código MySQL foi reescrita 16 vezes.

Conclusões

Os resultados generalizados para meus livros são os seguintes:

Título	Linhas de trabalho	Linhas de resumo	Ratio
Oi inicialização	295 181	26.571	11: 1
Terraform: Começamos e trabalhamos	81 916	8410	10: 1

E aqui está uma tabela de resumo para vários projetos de programação:

Título	Ano de fabricação	Linhas de trabalho	Linhas de resumo	Ratio
terraform-aws-couchbase	2018	37.693	7481	5: 1
Terratest	2016	49 126	6140	8: 1
Terraform	2014	12 945 966	1 371 718	9: 1
Express	2010	224 211	15 325	14: 1
jQuery	2006	730.146	47 559	15: 1
MySQL	1995	58 562 999	3 662 869	16: 1

O que significam todos esses números?

Regra 10: 1 em Prosa e Programação

Dado que meu conjunto de dados é limitado, só posso tirar algumas conclusões preliminares:

1. A proporção de "matéria-prima" para "produto final" para o livro é de aproximadamente 10: 1. Lembre-se dessa figura ao discutir com o editor uma programação para o envio de material. Se você precisa escrever um livro de 300 páginas, na verdade você precisa compor cerca de 3 mil páginas.
   
2. Uma regra semelhante pode ser deduzida para softwares maduros e não triviais: a proporção entre o volume do código processado e o total é de pelo menos 10: 1. Lembre-se disso quando um gerente ou cliente solicitar que você calcule os custos de tempo. Uma aplicação de 10 mil linhas exigirá que você escreva aproximadamente 100 mil linhas.
   

Essas descobertas podem ser resumidas como uma regra 10: 1 para escrita e programação :

Escrever um bom software ou texto exige que cada linha seja reescrita uma média de 10 vezes.

Próximas etapas

Obviamente, linhas de código e linhas de texto não podem ser consideradas uma medida ideal. Porém, acredito que, se você coletar uma quantidade suficiente de dados, poderá determinar se a regra 10: 1 é universal e útil para determinar o prazo para a conclusão de um projeto.

Algumas perguntas que eu gostaria de receber uma resposta:

• É possível usar a proporção de linhas de código processadas para linhas finais como uma métrica rápida para avaliar a maturidade de um software específico? Por exemplo, podemos confiar na solução dos principais problemas de infraestrutura para bancos de dados, linguagens de programação ou sistemas operacionais se, para eles, essa proporção atingir pelo menos 10: 1?
  
• O volume do texto de trabalho depende do tipo de software? Por exemplo, Bill Scott descobriu que na Netflix apenas cerca de 10% do código da interface do usuário vive até um ano , e os 90% restantes nessa época são completamente reescritos. Qual é a velocidade da substituição de código para o back-end, bancos de dados, utilitários de linha de comando e outros tipos de programas?
  
• Qual porcentagem do código é processada após o lançamento inicial? Ou seja, qual porcentagem do trabalho pode ser considerada "suporte de software"?
  

Se você é autor de livros e pode fazer uma análise semelhante, ficarei feliz em saber sobre seus resultados. E se alguém tiver tempo para automatizar essa análise, será ótimo aprender sobre os relacionamentos encontrados em vários projetos de código aberto.

Atualização de 13 de agosto

A discussão de um post sobre o Hacker News e a programação de r / Reddit revelou dois outros pontos interessantes:

1. Aparentemente, uma regra semelhante de 10: 1 se aplica a filmes , jornalismo, música e fotografia! Quem teria pensado?
2. Os leitores deixaram muitos comentários de que mesmo uma única alteração de caractere pode ser contada no Git como uma inserção ou exclusão de uma linha; portanto, um número de 100 mil linhas alteradas não significa que cada linha tenha sido processada.

A última observação é verdadeira, mas, como escrevi acima, meus dados não levam em consideração outros tipos de alterações:

1. Eu não faço confirmações para cada linha separada. Eu posso mudar isso dez vezes, mas apenas fazer um commit.
   
2. A situação descrita no parágrafo anterior é ainda mais relevante para a programação. Durante o teste de código, eu posso alterar uma linha 50 vezes, enquanto faço apenas uma confirmação.
   
3. Muitos ciclos de edição e gravação foram feitos fora do Git (alguns capítulos foram escritos no Google Docs ou Medium e edições estilísticas foram feitas em PDF).
   

Eu acho que todos esses fatores compensam a peculiaridade de contabilizar a inserção ou exclusão de linhas no Git. Obviamente, minhas estimativas podem ser imprecisas e a proporção real será 8: 1 ou 12: 1. Mas, em geral, a diferença não é muito grande e 10: 1 é mais fácil de lembrar.

Atualização em 14 de agosto

O Github Decagon criou um repositório chamado hofs-churn com um script bash para calcular facilmente quanto código foi trabalhado em seus repositórios. Ele também o usou para analisar vários repositórios, como React.js, Vue, Angular, RxJava e muitos outros, e os resultados foram bastante interessantes.