- 2007, 2000 Zeilen Code

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• Anfang 1982 konzentrierte sich das Lisa-Softwareteam auf die letzten Arbeiten, um die Software innerhalb der nächsten sechs Monate zu veröffentlichen.

• Einige Manager hielten es für eine gute Idee, jede Woche die von den einzelnen Ingenieuren geschriebene Code-Menge zu verfolgen, und erstellten ein Formular, das jeden Freitag eingereicht werden musste. Dieses Formular enthielt ein Feld für die Anzahl der in dieser Woche geschriebenen Codezeilen.

• Bill Atkinson, Autor von Quickdraw und wichtiger Designer der Benutzeroberfläche, hielt die Anzahl der Codezeilen für eine törichte Methode, die Produktivität in der Softwareentwicklung zu messen, da sie nur dazu ermutige, unordentlichen, aufgeblähten und fehlerhaften Code zu schreiben.

• Atkinson hatte kürzlich daran gearbeitet, die Bereichsberechnungsmaschine von Quickdraw zu optimieren, und schrieb die Bereichs-Engine mit einem einfacheren und allgemeineren Algorithmus vollständig neu. Nach einigen Anpassungen wurden Bereichsoperationen dadurch fast sechsmal schneller.

• Diese Neufassung sparte nebenbei etwa 2000 Zeilen Code ein.

• In der Abschlussphase dieser Optimierungsarbeit musste er zum ersten Mal das Management-Formular ausfüllen. Als er beim Feld für die Anzahl der Codezeilen ankam, dachte er kurz nach und trug dann die Zahl -2000 ein.

• Es ist nicht sicher, wie die Manager reagierten, aber einige Wochen später hörten sie auf, von Atkinson das Ausfüllen des Formulars zu verlangen, und er fügte sich dem gerne.

Meinung von GN⁺

• Dieser Artikel vermittelt eine wichtige Lektion: In der Softwareentwicklung steht die Menge an Code nicht für echte Produktivität. Die Leistung anhand der Anzahl der Codezeilen zu messen, ist nicht nur ineffizient, sondern kann mitunter sogar kontraproduktiv sein.
• Das Beispiel von Bill Atkinson unterstreicht die Bedeutung von Softwareoptimierung. Mit weniger Code schnellere Leistung zu erreichen, ist eines der Grundprinzipien des Software Engineering.
• Diese Geschichte hilft zu verstehen, warum moderne Entwicklungspraktiken wichtig sind, insbesondere Ansätze wie agile Methoden und Continuous Integration/Deployment (CI/CD). Diese Methoden legen mehr Wert auf Qualität, Wartbarkeit und User Experience als auf die Menge an Code.
• In der Branche werden verschiedene Tools und Metriken verwendet, um Codequalität zu messen und zu verbessern. Dazu gehören zum Beispiel statische Codeanalyse-Tools, Code-Review-Prozesse und die Nachverfolgung der Testabdeckung.
• Der Artikel erinnert Entwickler daran, wie wichtig es ist, sich auf Qualität statt auf Code-Menge zu konzentrieren, unnötige Komplexität zu vermeiden und die Performance zu optimieren.

[GN⁺]

Hacker-News-Kommentare

• Konflikt zwischen Microsoft und IBM über die Anzahl der Codezeilen

  • In der PBS-TV-Reihe "Accidental Empires" gibt es eine Szene, in der Steve Ballmer seine Erfahrungen aus der gemeinsamen Entwicklung von OS/2 schildert. Microsoft ging die Arbeit demnach mit der Haltung eines kleinen Unternehmens an, während sich IBM intern darauf konzentrierte, die Anzahl der Codezeilen (in Tausenderzeilen, KLoC) als Maß für die Produktivität von Programmierern zu verwenden. Ballmer kritisierte, dass IBM eher an der Menge als an der Qualität des Codes interessiert gewesen sei.

• Links zu früheren Diskussionen

  • Diskussionen über die Verwendung der Anzahl von Codezeilen als Produktivitätskennzahl tauchen häufig auf. Es werden Links bereitgestellt, die verschiedene Debatten von 2010 bis 2022 zeigen.

• Codezeilen als Produktionskennzahl zu verwenden, ist äußerst töricht

  • Es wird von Erfahrungen berichtet, bei denen ein 20 Jahre alter Bug mit einer einzigen Codezeile behoben wurde oder ein drei Jahre alter Fehler mit order by gelöst wurde, und die Frage aufgeworfen, wie sich der Einfluss einer einzelnen Zeile messen lassen soll. Außerdem wird die Erfahrung geteilt, dass schlechte Programmierer mehr Code schreiben, und ein Fall vorgestellt, in dem ein Microsoft-Entwickler 33.000 Zeichen IBM-Code auf 220 Zeichen umschrieb. Dadurch entstand die absurde Situation, dass Microsofts Arbeit als "negativ" bewertet wurde.

• Einfache Fragen haben manchmal die größte Wirkung

  • Eine einfache Frage dazu, wie eine Funktion umgesetzt werden soll ("Wie soll X behandelt werden?"), kann zu der Entscheidung führen, diese Funktion gar nicht erst zu bauen, was sämtliche Kosten für den Versuch einspart. Solche Beiträge lassen sich nicht in Zahlen messen und können manchmal Feinde schaffen, dennoch wird denjenigen Respekt gezollt, die es trotzdem tun.

• Geteilte Erfahrungen mit Code-Optimierung zu Beginn der Karriere

  • Es wird die Erfahrung geteilt, ein C-Programm mit mehr als 10.000 Zeilen auf weniger als 500 Zeilen optimiert zu haben. Unter der naheliegenden Annahme, dass der vorherige Entwickler möglicherweise nicht wusste, wie man Funktionen verwendet oder Variablendaten an SQL-Abfragen übergibt, wurde entdeckt, dass dieselbe SQL-Anweisung wiederholt inline geschrieben worden war. Der doppelte Code wurde ersetzt, indem die SQL-Aufrufe in Funktionsaufrufe umgeschrieben wurden und die geänderten Bind-Werte aus einem Array geholt wurden, um die Funktion innerhalb einer Schleife aufzurufen.

• Mangel an klarer Richtung zu Beginn eines Projekts

  • Zu Beginn eines Projekts kennt man die genaue Richtung manchmal nicht. Während man sich in das Projekt vertieft, versteht man das Problem und die gewünschte Lösung besser, sodass sich große Teile entfernen und durch kleinere, bessere Lösungen ersetzen lassen. Entwickler, die alles in 64 KB ROM unterbringen mussten, standen in solchen Situationen unter starkem Druck, den Code kleiner zu machen.

• Gedankenexperiment dazu, das Entfernen von Code als Kennzahl zu verwenden

  • Es wird ein Gedankenexperiment vorgeschlagen: Wenn ein Manager diesen Artikel liest und dann vereinfachend beschließt, die Anzahl entfernter Codezeilen als Messgröße zu verwenden, würde sich die Situation dadurch verbessern oder verschlechtern?

• Bill Atkinson und Atkinson Dither

  • Es wird ein Link zu Bill Atkinson und seiner Technik Atkinson Dither bereitgestellt.

• Wahrnehmung der Anzahl von Codezeilen

  • Es wird infrage gestellt, ob man beim Schreiben von Code "hinzugefügte Zeilen - entfernte Zeilen" verwenden sollte. So wie ein 10-km-Lauf, der am selben Ort beginnt und endet, nicht als 0-km-Lauf bezeichnet wird, gelte dasselbe auch für die Anzahl der Codezeilen.

• Die Rolle als Angestellter

  • Es wird die Lehre geteilt, dass man selbst dann, wenn man so klug wie Einstein ist, immer noch Angestellter ist und als solcher Aufgaben hat, die erledigt werden müssen.