Regel 10: 1 beim Programmieren und Schreiben

In diesem Artikel analysiert der Autor die Zeit, die für das Schreiben von Büchern oder Programmcode aufgewendet wird, und kommt zu einem interessanten Muster. Es kann verwendet werden, um Projektarbeiten zu planen.

Hofstadter-Gesetz: Jedes Geschäft dauert immer länger als erwartet, auch wenn Sie das Hofstadter-Gesetz berücksichtigen.
- Douglas Hofstadter, Gödel, Asher, Bach

Das Schreiben von Prosa und Code hat viel gemeinsam. Die auffälligste Ähnlichkeit ist jedoch wahrscheinlich, dass weder Autoren noch Programmierer ihre Arbeit pünktlich beenden können. Schriftsteller sind dafür berüchtigt, die Fristen zu brechen. Programmierer haben sich den Ruf von Menschen verdient, deren Ergebnisse sich immer stark von den anfänglichen Berechnungen unterscheiden. Es stellt sich die Frage: Warum?

Heute hatte ich eine Idee, wie ich darauf antworten sollte. Und meine Erkenntnisse haben mich erstaunt.

Meine Bücher studieren

Meine beiden Bücher Hallo, Startup und Terraform: Wir starten und arbeiten , schrieb ich in der Atlas -Bucherstellungsumgebung, die die Verwaltung aller Inhalte mit Git ermöglicht. Dies bedeutet, dass jede Textzeile, jede Bearbeitung und jede Änderung in das Git-Festschreibungsprotokoll übernommen wurde.

Lassen Sie uns überprüfen, wie viel Aufwand für das Schreiben von zwei Büchern aufgewendet wurde.

Hallo Start

Beginnen wir mit meinem ersten Buch. Hallo Startup . Es hat 602 Seiten und ungefähr 190.000 Wörter. Ich habe cloc im Hello, Startup Git Repository ausgeführt und die folgenden Ergebnisse erhalten (Der Einfachheit halber werden die Bruchteile verworfen):



602 Seiten enthalten 26.571 Textzeilen. Der Löwenanteil ist in AsciiDoc geschrieben , ähnlich wie bei Markdown. Es wird von Atlas verwendet, um fast jeden Inhalt zu schreiben. Mit HTML und CSS definiert Atlas das Layout und die Struktur eines Buches. Darüber hinaus gibt es weitere Programmiersprachen (Java, Ruby, Python und nicht nur), in denen verschiedene Beispiele für die im Buch behandelten Themen geschrieben sind.

Aber 602 Seiten und 26.571 Zeilen sind nur das Endergebnis. Sie reflektieren nicht etwa 10 Monate Schreiben, Ändern, Bearbeiten, Korrekturlesen, Stilanpassungen, Recherchen, Notizen und andere Arbeiten, die zur Veröffentlichung des Buches beitragen. Um weitere nützliche Ideen zu erhalten, habe ich git-quick-stats , um das gesamte Commit-Protokoll für Bücher zu analysieren.



Also habe ich 163.756 Zeilen hinzugefügt und 131.425 gelöscht, was insgesamt 295.181 Zeilen verarbeiteten Materials ergibt. Das heißt, es stellt sich heraus, dass ich insgesamt 295 181 Zeilen geschrieben oder gelöscht habe, von denen 26 571 Zeilen übrig geblieben sind. Dieses Verhältnis liegt etwas über 10: 1. Um jede veröffentlichte Zeile zu erhalten, musste ich zuerst 10 andere schreiben!

Ich gebe zu, dass das Zählen der Anzahl der zu Git hinzugefügten und aus Git entfernten Zeilen nicht als ideale Metrik für den Bearbeitungsprozess angesehen werden kann. Dies lässt uns jedoch zumindest verstehen, dass eine einfache Berechnung nicht ausreicht, um die geleistete Arbeit zu bewerten. Ein wesentlicher Teil des Prozesses wurde im Git-Commit-Protokoll überhaupt nicht berücksichtigt. Zum Beispiel wurden die ersten Kapitel in Google Text & Tabellen geschrieben, bevor ich zu Atlas wechselte, und viele Änderungen wurden ohne Commits an meinem Computer vorgenommen.

Trotz der Tatsache, dass diese Daten alles andere als ideal sind, glaube ich, dass das Gesamtverhältnis von „Originaltextmaterial“ zu veröffentlichtem 10: 1 beträgt.

Terraform: Wir beginnen und arbeiten

Lassen Sie uns prüfen, ob dieser Anteil auf mein zweites Buch Terraform zutrifft : Wir starten und arbeiten , das 206 Seiten und etwa 52.000 Wörter enthält.

Die vereinfachte Ausgabe von cloc :



206 Seiten bestehen aus 8410 Textzeilen. Auch hier ist der größte Teil des Textes in AsciiDoc geschrieben, obwohl dieses Buch wesentlich mehr Codebeispiele enthält, die hauptsächlich in HCL, der Hauptsprache von Terraform, geschrieben wurden. Neben ihm gibt es viele Markdowns, mit denen ich HCL-Beispiele dokumentiert habe.

Wir werden git-quick-stats , um den Revisionsverlauf dieses Buches zu überprüfen:



Fast fünf Monate lang habe ich 32.209 hinzugefügt und 22.402 Zeilen gelöscht, was insgesamt 54.611 recycelten Zeilen entspricht. Die Genauigkeit der Bewertung des Bearbeitungsprozesses dieses Buches leidet noch mehr, da die Arbeit als eine Reihe von Blog-Posts begann , die einer konkreten Überarbeitung unterzogen wurden, bevor sie zu Atlas und Git verschoben wurden. Das Volumen dieser Blog-Beiträge nimmt mindestens die Hälfte des Buches ein, daher ist es logisch, die endgültige Rate des verarbeiteten Textes um 50% zu erhöhen. Das heißt, es werden 54611 * 1,5 = 81 916 Zeilen bearbeitbaren Textes ausgegeben, was insgesamt 8410 Zeilen ergibt.

Und wieder ein Verhältnis von ca. 10: 1!

Es ist nicht verwunderlich, dass Autoren die Fristen nicht einhalten. Wenn der Zeitplan ein Buch mit 250 Seiten übergeben soll, stellt sich in der Praxis heraus, dass wir dabei 2500 Seiten schreiben werden.

Was ist mit Programmierung?

Wie läuft die Entwicklung? Ich habe mich entschlossen, mehrere Open-Source-Git-Repositories mit unterschiedlichen Reifegraden zu prüfen: von einigen Monaten bis zu 23 Jahren.

terraform-aws-couchbase (2018)

terraform-aws-couchbase ist eine Reihe von Modulen zum Bereitstellen und Verwalten von Couchbase unter AWS, deren Quellcode 2018 eröffnet wurde.

Die vereinfachte Ausgabe von cloc :



Und hier ist das Ergebnis der Überprüfung der git-quick-stats :



Wir erhalten bis zu 37.693 Zeilen Arbeitscode, was zu 7481 Zeilen des endgültigen Codes im Verhältnis 5: 1 führt. Selbst im Repository unter 5 Monaten musste ich jede Zeile fünfmal neu schreiben! Es ist nicht verwunderlich, dass die Bewertung der Softwareentwicklung kompliziert ist: Wir stellen uns nicht einmal vor, dass wir tatsächlich 35.000 schreiben müssen, um 7,5 Tausend Zeilen endgültigen Codes zu erhalten

Mal sehen, wie es mit älteren Produkten läuft.

Terratest (2016)

Terratest ist eine OpenSource-Bibliothek, die 2016 zum Testen von Infrastrukturcode erstellt wurde.

Die vereinfachte Ausgabe von cloc :



Die Ergebnisse von git-quick-stats :



Dies sind 49 126 Arbeitszeilen Code, die in 6140 Zeilen des endgültigen Textes umgewandelt wurden. Für ein zweijähriges Endlager betrug das Verhältnis 8: 1. Aber Terratest ist noch ziemlich jung, also schauen wir uns die älteren Repositories an.

Terraform (2014)

Terraform ist eine Open Source-Bibliothek, die 2014 erstellt wurde, um die Infrastruktur mithilfe von Programmiermethoden zu verwalten.

Die vereinfachte Ausgabe von cloc :



Die Ergebnisse von git-quick-stats :



Wir erhalten 12.945.966 Arbeitscodezeilen, was zu 1.371.718 Zeilen des Endergebnisses führt. Verhältnis 9: 1. Terraform existiert seit fast 4 Jahren, aber die Bibliothek wurde noch nicht veröffentlicht. Selbst mit diesem Verhältnis kann die Codebasis noch nicht als ausgereift bezeichnet werden. Schauen wir noch weiter in die Vergangenheit.

Express.js (2010)

Express ist ein beliebtes Open-Source-JavaScript-Framework, das 2010 für die Webentwicklung veröffentlicht wurde.

Die vereinfachte Ausgabe von cloc :



Die Ergebnisse von git-quick-stats :



Wir erhalten 224 211 Arbeitszeilen Code, reduziert auf 15 325 letzte Zeilen. Ergebnis 14: 1. Express ist ungefähr 8 Jahre alt, die neuesten Versionen sind Nummer 4.x. Es gilt als das beliebteste und kampferprobte Webframework für Node.js.

Es scheint, dass wir, sobald das Verhältnis das Niveau von 10: 1 erreicht, zuversichtlich sagen können, dass die Codebasis bereits „ausgereift“ ist. Lassen Sie uns überprüfen, was passiert, wenn Sie noch tiefer in die Vergangenheit vordringen.

jQuery (2006)

jQuery ist eine beliebte Open-Source-JavaScript-Bibliothek, die 2006 veröffentlicht wurde.

Die vereinfachte Ausgabe von cloc :



Die Ergebnisse von git-quick-stats :



Insgesamt 730.146 Arbeitszeilen Code, was 47.559 Zeilen des Endergebnisses ergibt. 15: 1-Verhältnis für ein fast zwölf Jahre altes Endlager.

Lass uns noch vor zehn Jahren gehen.

MySQL (1995)

MySQL ist eine beliebte relationale Open-Source-Datenbank, die 1995 erstellt wurde.

Die vereinfachte Ausgabe von cloc :



Die Ergebnisse von git-quick-stats :



Wir erhalten 58 562 999 Arbeitszeilen, 3 662 869 Zeilen des endgültigen Codes und ein Verhältnis von 16: 1 für ein fast 23 Jahre altes Repository. Nein, so was! Jede Zeile MySQL-Code wurde 16 Mal neu geschrieben.

Schlussfolgerungen

Die allgemeinen Ergebnisse für meine Bücher lauten wie folgt:

Titel	Arbeitslinien	Zusammenfassungszeilen	Verhältnis
Hallo Start	295 181	26.571	11: 1
Terraform: Wir fangen an und arbeiten	81 916	8410	10: 1

Und hier ist eine Übersichtstabelle für verschiedene Programmierprojekte:

Titel	Baujahr	Arbeitslinien	Zusammenfassungszeilen	Verhältnis
terraform-aws-couchbase	2018	37,693	7481	5: 1
Schrecklichste	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

Was bedeuten all diese Zahlen?

Regel 10: 1 in Prosa und Programmierung

Da mein Datensatz begrenzt ist, kann ich nur einige vorläufige Schlussfolgerungen ziehen:

1. Das Verhältnis von „Ausgangsmaterial“ zu „Endprodukt“ für das Buch beträgt ungefähr 10: 1. Beachten Sie diese Zahl, wenn Sie mit dem Herausgeber einen Zeitplan für die Einreichung von Material besprechen. Wenn Sie ein Buch mit 300 Seiten schreiben müssen, müssen Sie tatsächlich ungefähr dreitausend Seiten verfassen.
   
2. Eine ähnliche Regel kann für ausgereifte und nicht triviale Software abgeleitet werden: Das Verhältnis des Volumens des verarbeiteten Codes zur Gesamtsumme beträgt mindestens 10: 1. Denken Sie daran, wenn ein Manager oder Kunde Sie auffordert, die Zeitkosten zu schätzen. Bei einer Anwendung von 10.000 Zeilen müssen Sie ungefähr 100.000 Zeilen schreiben.
   

Diese Ergebnisse können als 10: 1-Regel für das Schreiben und Programmieren zusammengefasst werden :

Um gute Software oder Text zu schreiben, muss jede Zeile durchschnittlich zehnmal neu geschrieben werden.

Nächste Schritte

Natürlich können Codezeilen und Textzeilen nicht als ideales Maß angesehen werden. Ich glaube jedoch, wenn Sie eine ausreichende Datenmenge erfassen, können Sie feststellen, ob die 10: 1-Regel universell und nützlich ist, um die Frist für den Abschluss eines Projekts festzulegen.

Einige Fragen, auf die ich eine Antwort erhalten möchte:

• Ist es möglich, das Verhältnis von verarbeiteten Codezeilen zu endgültigen Zeilen als schnelle Metrik für die Bewertung der Reife einer bestimmten Software zu verwenden? Können wir beispielsweise der Lösung wichtiger Infrastrukturprobleme für Datenbanken, Programmiersprachen oder Betriebssysteme vertrauen, wenn dieses Verhältnis für sie mindestens 10: 1 erreicht hat?
  
• Hängt das Volumen des Arbeitstextes von der Art der Software ab? Zum Beispiel fand Bill Scott heraus, dass in Netflix nur etwa 10% des Codes der Benutzeroberfläche bis zu einem Jahr gültig sind und die restlichen 90% zu diesem Zeitpunkt vollständig neu geschrieben wurden. Wie schnell kann Code für das Backend, Datenbanken, Befehlszeilenprogramme und andere Arten von Programmen ersetzt werden?
  
• Wie viel Prozent des Codes werden nach der ersten Veröffentlichung verarbeitet? Wie viel Prozent der Arbeit können als „Software-Support“ betrachtet werden?
  

Wenn Sie Autor von Büchern sind und eine ähnliche Analyse durchführen können, würde ich mich über Ihre Ergebnisse freuen. Und wenn jemand die Zeit hat, eine solche Analyse zu automatisieren, ist es großartig, mehr über die Beziehungen zu erfahren, die in verschiedenen Open-Source-Projekten zu finden sind.

13. August Update

Die Diskussion eines Beitrags in Hacker News und Reddits R / Programmierung ergab zwei weitere interessante Punkte:

1. Anscheinend gilt eine ähnliche 10: 1-Regel für Filme , Journalismus, Musik und Fotografie! Wer hätte das gedacht?
2. Die Leser haben viele Kommentare hinterlassen, dass das Ändern eines einzelnen Zeichens in Git als Einfügen oder Löschen einer Zeile gezählt werden kann. Ein Indikator für 100.000 geänderte Zeilen bedeutet also nicht, dass jede Zeile verarbeitet wurde.

Die letzte Bemerkung ist wahr, aber wie ich oben geschrieben habe, berücksichtigen meine Daten andere Arten von Änderungen nicht:

1. Ich mache keine Commits für jede einzelne Zeile. Ich kann es zehnmal ändern, aber nur ein Commit machen.
   
2. Die im vorherigen Absatz beschriebene Situation ist für die Programmierung noch relevanter. Während des Codetests kann ich eine Zeile 50 Mal ändern, während nur ein Commit ausgeführt wird.
   
3. Viele Bearbeitungs- und Schreibzyklen wurden außerhalb von Git durchgeführt (einige Kapitel wurden in Google Text & Tabellen oder Medium geschrieben, und stilistische Änderungen wurden in PDF vorgenommen).
   

Ich denke, dass all diese Faktoren die Besonderheit kompensieren, das Einfügen oder Löschen von Zeilen in Git zu berücksichtigen. Natürlich können meine Schätzungen ungenau sein und das reale Verhältnis wird 8: 1 oder 12: 1 betragen. Aber im Allgemeinen ist der Unterschied nicht zu groß und 10: 1 ist leichter zu merken.

14. August Update

Github Decagon hat ein Repository namens hofs-churn mit einem Bash-Skript erstellt, um auf einfache Weise zu berechnen, wie viel Code in Ihren Repositorys ausgearbeitet wurde. Er verwendete es auch, um eine Reihe von Repositories zu analysieren, wie React.js, Vue, Angular, RxJava und viele andere, und die Ergebnisse waren ziemlich interessant.