6 Tage, um eine Zeile Code zu ändern (2015)

• Als die Auslastung des Werks um 10 % sank, wollte das Unternehmen statt Entlassungen vor der Hochsaison Lagerbestände aufbauen, und dafür begann eine Anfrage, die 3-Monats-Backlog-Grenze auf 4 Monate zu ändern
• Der IT-Verantwortliche ging davon aus, dass dafür nur ein fest codierter Wert in einer Kernroutine geändert werden müsse, doch zunächst waren ein Ticket, die Beschreibung der geschäftlichen Auswirkungen, Genehmigungen und eine Anpassung der Queue-Priorität nötig
• Der Programmierer änderte in Modul ORP572 in Zeile 1252 den Wert von MonthsOfBacklog von "3" auf "4" und bestand die Tests, doch im Code-Review wurde auch die Behebung bestehender Richtlinienverstöße zum Gegenstand der Änderung
• Der Umfang der Änderung wuchs durch begleitende Prozesse wie das Anlegen eines Datensatzes in der Parameters-Datei, das Entfernen von Debug-Befehlen, Warnungen zu nicht zugewiesenen Variablen, eine fest codierte Employee ID, Zugriffsrechte, Testumgebung, Testplan und Benutzerfreigaben
• Fachlich nötig war nur eine Änderung von 1 Zeile, 1 Byte, doch die gesamte Durchlaufzeit betrug 6 Tage, weil interne Prozesse und Richtlinien die tatsächliche Lead Time kleiner Änderungen stark verlängerten

---

Anfrage, die 3-Monats-Grenze auf 4 Monate zu ändern

• Präsident Philip sagte, das Werk sei zu 10 % unausgelastet, und wollte statt Entlassungen mehr Backlog produzieren, um vor der Hochsaison Lagerbestand aufzubauen
• Betriebsleiter Lee erklärte, dass nach Unternehmensrichtlinie nur ein Backlog für 3 Monate aufgebaut werden dürfe; würde die Grenze auf 4 Monate erhöht, gäbe es genug Arbeit
• IT-Leiter David meinte, in einer Kernroutine der Legacy-Software müsse wohl nur eine einzige Codezeile geändert werden, und bat darum, ein Ticket bei IT Services einzureichen
• IT-Managerin Judy wies der Anfrage Ticket# 129281 zu, sagte aber, dass der Abschnitt Business Impact und die Genehmigung eines Directors erforderlich seien
  • Als David die Möglichkeit von Entlassungen erwähnte, füllte Judy diesen Abschnitt selbst aus und stufte die Anfrage zur schnellen Bearbeitung hoch
  • Auch 2 Tage später stand die Anfrage in der Developer Queue noch als erste Enhancement-Anfrage hinter 14 Bug Reports
  • David markierte die Anfrage als dringend und wies an, sie direkt an Ed zu senden

Wie aus einer Ein-Zeilen-Änderung ein Prozessprojekt wird

• Ed änderte in Modul ORP572, Zeile 1252, die fest codierte Variable MonthsOfBacklog von "3" auf "4"
  • Die Unit-Tests bestanden, und er führte 2 Batch-Tests aus
  • Die Operations-Work-Queue stieg wie erwartet um 10 %
  • Die Änderung ging ins Code-Review und anschließend zu Homers User Acceptance Testing
• Die für das Code-Review zuständige Shirley beanstandete, dass eine fest codierte Variable gegen die Unternehmensrichtlinie verstoße, und verlangte, daraus einen Datensatz in der Parameters-Datei zu machen
  • Außerdem müssten 2 vorhandene Debug-Befehle, eine Warnung zu nicht zugewiesenen Variablen und eine fest codierte Employee ID vor dem Produktionseinsatz behoben werden
  • Da Ed ORP572 zugewiesen bekommen habe, müsse er auch bestehende Fehler verantworten, die gegen die neue Unternehmensrichtlinie verstießen
• Auch die Testumgebung wurde zum Verzögerungsfaktor
  • Homer war wegen Kontrolltests zum Monatsabschluss in der Buchhaltung nicht verfügbar, daher musste Marge verwendet werden
  • Ed hatte keinen Zugriff auf Marge, und Joe von IT Security sagte, ohne Davids Unterschrift könne er die Berechtigung nicht erteilen
• Die Arbeit am Parameters-Datensatz weitete sich durch zusätzliche Anforderungen aus
  • Der Name MonthsOfDemand brauche einen besseren Namen, weil ausländische Programmierer ihn sonst schwer verstehen würden
  • Der neue Parameter-Datensatz musste einen Audit Trail haben, doch diese Richtlinie war nicht dokumentiert, und das Wiki war bei Updates 3 Monate im Rückstand
  • Ed änderte den Namen zu SelectedMonthsOfBacklogDemand und fügte Modul PAR634 hinzu, das diesen Datensatz und den Audit Trail verwaltet
• Tester Tony wies darauf hin, dass 129281 zwar auf Marge sichtbar sei, aber kein Test Plan existiere
  • Ed sagte, es reiche, die alte und die neue Methode auszuführen und die Zunahme der Gesamtsumme im Bericht WorkOrdersHours zu bestätigen, doch Tony verlangte wegen der Auswirkungen auf das gesamte Werk benutzerausgewählte Test Cases, Expected Results, dokumentierte Test Runs und ein User Sign-off
  • 2 Tage später wies Philip David an, Tony solle Eds Programm sofort in Produktion bringen
• Die gesamte verstrichene Zeit betrug 6 Tage, obwohl die Änderung am mission-critical code nur 1 Zeile bzw. 1 Byte umfasste
  • 24 Excedrin wurden verbraucht
  • Die genervt auf Hacker News verbrachte Zeit wird mit 14 Stunden angegeben

[GN⁺]

Hacker-News-Kommentare

• Der Kern liegt darin, dass der Reviewer verlangt hat: „Wenn wir das ändern, müssen auch andere ungelöste Probleme in der Codebase gleich mit behoben werden.“
  In so einem Fall sollte man zurückgeben: „Die Richtung, die Codequalität zu verbessern, ist gut, aber wenn wir Y ändern, brauchen wir Freigaben für X/Y/Z und das kostet noch ein paar Tage. Lassen Sie uns Ihren Punkt als Technical-Debt-Task erfassen und ihn je nach Priorität und Kapazität in einem Folge-PR behandeln. Konzentrieren wir uns jetzt darauf, was nötig ist, um diesen lokalen PR zu deployen.“
  Die wichtigste Lektion war, fokussierte PRs zu erstellen und zu lernen, dem Reviewer zu widersprechen, wenn er den Scope ausweiten will. Andere Engineers haben das meist pragmatisch aufgenommen. Das hat nichts mit der Zeilenzahl zu tun. Man kann das ganze File nur umformatieren, ohne die Logik zu ändern, oder nur ein paar Feature-Flags anpassen und damit große Auswirkungen haben. Man sollte immer nur eine fokussierte Änderung auf einmal machen.

  • Ich stimme nicht zu, dass „Wenn wir das ändern, müssen auch andere ungelöste Probleme behoben werden“ hier der Kernpunkt ist. Das Schlimmste ist, dass es 6 Tage dauerte, eine Zeile Code zu ändern, und fast die Hälfte davon verging, bevor überhaupt ein Engineer das Issue ansah.
    Wenn das wirklich so hohe Priorität hatte, dass die Firma Leute hätte entlassen müssen, falls es nicht sofort bearbeitet wird, dann hätten diese 2–3 Tage, bevor es überhaupt jemand anschaut, niemals passieren dürfen. In diesem Entwicklungsprozess scheint das aber der „schnelle Weg“ zu sein.
    Auch in den letzten 2 Tagen scheint nichts passiert zu sein, weil der Testplan als unzureichend bewertet wurde. „Wenn wir das ändern, müssen auch andere ungelöste Probleme behoben werden“ nahm hier nur 2 Stunden ein, und schon davor gab es in diesem Prozess mindestens 2–3 weitere Dinge, die man als Kernprobleme benennen könnte.
  • Normalerweise vermeide ich Verbesserungen, die nicht direkt mit der aktuellen Aufgabe zusammenhängen. Schon das Hinzufügen eines fehlenden Semikolons kann die Aufmerksamkeit eines übereifrigen Reviewers auf sich ziehen und einen in den Legacy-Fix-Kaninchenbau ziehen.
    Statt FIXME oder TODO stehen zu lassen, lege ich lieber still ein Issue an, damit ich es nicht vergesse. Dieser Teil des Reviews ist kaputt. Das Beheben von Technical Debt sollte nicht Bedingung für den Abschluss einer Aufgabe sein, sondern separat geplant werden.
  • Leute, die Scope Creep betreiben, verstehen den architektonischen Schaden nicht, den sie verursachen. Wenn man einen einzelnen Codeblock übermäßig stark kontrolliert, suchen sich die Leute Umgehungswege darum herum.
    Wenn sich solche Schichten ansammeln, wird der Code am Ende moralisch gleichwertig zu Atlanta, GA, das berüchtigt für seine vielen Ringstraßen ist.
  • Ich denke, die bessere Lösung ist, Regeln zu automatisieren.
    Wenn eine neue Regel hinzugefügt wird, sollte die Automatisierung an allen bestehenden Verstößen Ausnahme-Kommentare zur Regel anbringen und diese auch nachverfolgbar machen. Wenn Code, der dringend deployt werden muss, gegen die Regel verstoßen muss, fügt man einen Ausnahme-Kommentar hinzu und vermerkt den eigenen Namen als die Person, die das später behebt.
    Mit der Zeit kann man so eine Kultur aufbauen, in der solche Regelverstöße getrennt von der Feature-Entwicklung behoben werden.
  • Wenn so etwas passiert, fügt man einfach ein TODO-Ticket hinzu. Das hebt den Production-Blocker auf, und das System wird dadurch auch nicht schlechter.

• Stimmt. Der Code-Review-Prozess in den meisten Firmen ist voller Nörgelei und belangloser Kommentare.
  Ich habe früher einmal vorgeschlagen, solche Kommentare abzuschaffen und stattdessen durch statische Analysewerkzeuge zu ersetzen, um Feedback schneller zu machen. Als Antwort bekam ich, dass solche Code Reviews für alle nötig seien: weil sie Menschen bei Beförderungen helfen, ihnen das Gefühl geben, Codeprobleme verhindert zu haben, und weil obere Manager anhand der Anzahl der Reviewer-Kommentare gute Code-Review-Metriken sehen.

  • Ich mag es nicht, solche Tools übermäßig zu nutzen. Nicht selten wird der Code sogar schlechter, nur um dumme Tools zufriedenzustellen.
    Die eigentliche Lösung ist zu akzeptieren, dass nicht jeder Code so aussehen muss, als hätte ich ihn selbst geschrieben, und sich zu fragen: „Behandelt dieser Kommentar einen objektiven Fehler im Code?“ In vielen Fällen lautet die Antwort „nein“.
  • Hier gibt es manchmal wirklich ein Gefangenendilemma. Wenn ein Senior den PR eines Juniors reviewed, gibt es oft Dinge, die man verbessern könnte, die aber nicht wichtig sind.
    Wenn ein Variablenname nur etwas zu lang ist oder der Abstand zwischen Methoden uneinheitlich, sollte das idealerweise Feedback sein nach dem Motto: „Merk dir das fürs nächste Mal, falls es zum Muster wird.“ Aber aus Sicht des Reviewers werden Kommentare pro PR vielleicht als Maß dafür gesehen, wie viel Coaching geleistet wurde, oder man sorgt sich um Reaktionen wie: „Wer hat denn zugelassen, dass das gemergt wird?“ Also hinterlässt man am Ende doch einen Kommentar.
    Die Person im Review passt es dann an, weil sie sonst als wenig reaktionsfähig auf Feedback wirken könnte oder weil sie befürchtet, der Reviewer könnte bei Widerspruch eine schlechte Bewertung geben. Dann muss die aktualisierte Version erneut freigegeben werden und der Verzögerungszyklus beginnt von vorn.
  • In manchen Umgebungen stimmt das. Aber der Review-Prozess hilft auch dabei, gemeinsames Wissen und Verständnis über Änderungen und die Codebase aufzubauen.
  • Nörgelei existiert definitiv in der Realität. Vielleicht kommt sie von dem Gefühl, man müsse im Code unbedingt irgendetwas Falsches finden.
    Andererseits gibt es auch Probleme, die manche für Kleinigkeiten halten, die in Wirklichkeit überhaupt nicht klein sind. Das kann daran liegen, dass man das Problem nicht mit eigenen Augen sieht, es nicht versteht oder nicht in der Lage ist, Emotionen beiseitezulegen und den eigenen Code noch einmal neu zu betrachten.
    Wir alle haben schon an unserem eigenen Code gehangen und ihn vielleicht für den elegantesten der Welt gehalten. Aber manchmal muss man anerkennen, dass man falsch lag und dass der Code schwer lesbar ist, Fehler enthält und der Codebase schadet.
    Ich habe einmal in dem Code von jemandem, der senioriger war als ich, auf eine Race Condition hingewiesen, die real zu Problemen führen konnte, und wurde daraufhin als Nörgler bezeichnet. Für mich ist eine Race Condition ein grundlegendes Problem des geschriebenen Codes und muss behoben werden; für diese Person war es akzeptabel, weil sie noch nie erlebt hatte, dass es auf offensichtliche Weise kaputtging.
  • Statische Analysewerkzeuge und Peer Review erkennen unterschiedliche Arten von Problemen. Genauso wie statisch kompilierte Sprachen manche Bugs erkennen, die dynamische Sprachen nicht erkennen können, aber eben auch nicht alle.
    Ich mag Peer Review sehr und konzentriere mich normalerweise auf: „Dieser Code wird wahrscheinlich nicht so funktionieren wie erwartet“, „So wird die Implementierung blockiert oder deutlich teurer“, „Es funktioniert zwar, ist aber schwer zu verstehen und wird die Wartbarkeit verschlechtern; erwäge einen anderen Ansatz oder füge eine Erklärung hinzu“, und „Der Code ist okay, aber könnte besser lesbar sein oder besser funktionieren; das ist kein Grund, das Review scheitern zu lassen, aber es ist etwas, das man beim nächsten Code berücksichtigen kann“.

• „Julie: Kontaktiere Joe aus dem IT-Sicherheitsteam. Er wird dir die Berechtigung geben. In 2 Stunden.“ ist völlig unrealistisch. Dass das Sicherheitsteam so schnell antwortet, ist kaum vorstellbar

  • Eine Ausnahme wäre, wenn beim Ausführen von „npm install“ ein Sicherheitsalarm der Priorität P1 ausgelöst wurde
  • Unser Sicherheitsteam antwortet tatsächlich schneller. Es lehnt alle Anfragen automatisch ab, aber dafür sofort
  • Bei mir im Unternehmen ist die Erfahrung ganz anders. Wenn man ein Ticket einreicht, um jemandem Zugriff auf ein bestimmtes System zu geben, wird es meist innerhalb weniger Minuten bearbeitet, egal welche Priorität man vergibt
    Manchmal frage ich mich, ob Helpdesk-Mitarbeiter solche Tickets direkt nach Eingang an sich reißen, um ihre persönlichen Kennzahlen zu verbessern, weil sie sich so schnell schließen lassen
  • Es dauert Wochen, jemanden zu der AD-Gruppe hinzuzufügen, die für Bearbeitungsrechte im Wiki nötig ist

• Wie im Titel gesagt klingt 6 Tage für eine einzige Codezeile schrecklich
  Aber das System wurde auf einige Arten verbessert. Konfigurationen wurden nicht mehr hartkodiert, sondern über eine Parametertabelle steuerbar gemacht, und es gab nun auch eine Audit-Funktion, um diese Konfigurationsänderungen nachzuverfolgen
  Ich will damit keine Bürokratie verteidigen. Ich hasse diese Seiten großer Organisationen wirklich. Ich möchte nur darauf hinweisen, dass in diesen 6 Tagen zusätzlich zum ursprünglichen Ziel weiterer Wert geschaffen wurde
  Deshalb sollte man in Schätzungen einen gewissen Anteil an Nebenkosten einplanen, und wenn man Story Points vergibt, sollte man auch solche Prozesskosten berücksichtigen

  • Der einzige Grund, warum die Parametertabelle nützlich war, ist, dass es zu viele Hindernisse für Codeänderungen gab. Genauso wirkt auch das Audit für diese Einstellung unnötig. Früher war das ja im Code, also war die Versionsverwaltung bereits der Audit-Trail
    Am Ende bestanden die beiden Ergebnisse also aus dem „Erfolg“, zusätzliche Rituale rund um Codeänderungen zu vermeiden, und dem „Erfolg“, die Funktionalität zurückzuholen, die man durch den ersten „Erfolg“ verloren hatte, weil diese Änderung künftig nicht mehr im Code vorgenommen wird
  • Stimmt, aber dabei wurde auch etwas getan, das deutlich riskanter sein kann als die ursprüngliche Anfrage. In einer Situation mit unmittelbarer Störung oder einem echten Produktionsproblem einen hartkodierten Wert in einen Parameter auszulagern, halte ich für töricht. Es gibt viel mehr potenzielle Fallstricke
    Hier hätte man sagen sollen: „Es ist dringend, also bitte akzeptiert einen PR mit genau einer Zeichenänderung. Die gewünschten Verbesserungen habe ich als Ticket zur Nachverfolgung angelegt. Lasst uns zuerst das Produktionsproblem lösen und den Rest danach erledigen.“
    Der Reviewer hätte einfach „LGTM!“ sagen können. Wenn die meisten Engineers nicht zwischen Regeln und Leitlinien navigieren können, ist die Organisation verrückt, und genau hier zeigt sich der Wert von Seniorität
  • Schritt 1 ist, die echte Priorität zu bestimmen. Alle sollten wissen, wie stark sich Verzögerungen bei dieser Aufgabe auf die Arbeitsplätze von Menschen auswirken
    Wenn eine Woche Verzögerung keinen Arbeitsplatz betrifft, kann man dem Prozess folgen oder nur das Nötigste ändern. Wenn Menschen wegen der IT in unbezahltem Zwangsurlaub sind, dann sollten alle Beteiligten, die gebraucht werden, bis zur Lösung in einem Raum sein, physisch oder virtuell
    Dieser Kontext fehlt hier. Aber wenn Ed und die gesamte Genehmigungskette diesen Kontext nicht kannten, dann ist das ein Systemversagen. Wenn bekannt gewesen wäre, dass jemandes Miete davon abhängt, hätte ein Senior vermutlich vorgeschlagen, direkt ein zweites Ticket für die anschließende Korrektur anzulegen. Wenn nicht, ist auch das ein Problem, das das Management lösen muss
  • „6 Tage für eine einzige Codezeile“ war einfach eine Tatsachenbeschreibung. Die Teile, in denen das System nebenbei verbessert wurde, waren keine Muss-Anforderungen
  • Die Audit-Anforderung hätte sich wohl auch über die Versionshistorie der Datei erfüllen lassen, in der der hartkodierte Wert stand. Falls es keine Versionsverwaltung gab, wäre das ein noch viel größeres Problem gewesen

• Diese Geschichte ist ein Fall, in dem eine einzeilige Änderung an einem hartkodierten Wert tatsächlich gut ausgegangen ist
  Man kann sich ein Szenario vorstellen, in dem jemand die Anzahl der Backlog-Monate, um klug und clever zu wirken, als 2-Bit-Wert gespeichert hat. Also nur 0, 1, 2 oder 3. Beim Testen könnte das Problem unentdeckt bleiben, weil es sich mehrere Schichten tiefer in einem ungetesteten Subservice oder einem Low-Code-Automatisierungsdienst verbirgt
  Wenn man den Wert auf 4 ändert, könnte das Backlog auf 0 zurückfallen. Was dann passiert, weiß niemand. Der Dienst könnte alle Jobs in der Produktionswarteschlange abbrechen oder Kunden E-Mails schicken, dass ihre Aufträge storniert wurden
  Es sieht oberflächlich wie eine einfache Änderung aus, aber wenn eine Richtlinienänderung als dringendes Problem an das Softwareteam weitergegeben wurde, dann hätte das Management besser planen müssen, statt willkürlich an der Priorisierung von Issues zu rütteln

  • In der angeforderten Änderung ging es nicht um zusätzliche Tests oder Risikoreduzierung
    Im Gegenteil: Als „Kosten“ der Änderung wurde verlangt, mehrere angrenzende Teile zu refaktorieren, was das Risiko erhöht hat
  • Es gibt unzählige Wege, wie etwas schiefgehen kann. Die eigentliche Frage ist vielleicht, wo die Verantwortung landet, wenn es schiefgeht
    Schön wäre, wenn der große Boss sagt: „Ich entscheide, das Risiko bewusst einzugehen und es durchzudrücken, und ich trage auch die Folgen.“ Weniger schön ist es, wenn am Ende die Programmierer recht behalten
  • Ich denke, die richtigen Personen und Prozesse wurden grundsätzlich einbezogen. Aber man hätte viel Zeit sparen können, wenn man die Leads zusammengeholt und ein Meeting angesetzt hätte, um Wichtigkeit und Priorität der Arbeit abzustimmen
    Wenn es sich um ein zeitkritisches und wichtiges Update für Kernfunktionen handelte, hätte die verantwortliche Person im Betrieb die durchschnittliche Deploy-Zeit der Software kennen und statt einer bloß hohen Priorität in der normalen Entwicklungspipeline ein Team für eine beschleunigte Bearbeitung zusammenstellen müssen
  • Das erinnert mich an Knight Capital

• Code-Reviews beginnen mit guten Absichten. Aber irgendwann etabliert sich ein Gatekeeper und fängt an, alles aus belanglosen Gründen abzulehnen
  Die Person sagt von sich, sie wolle die „Codequalität“ schützen. Aber es gibt kaum etwas Schlimmeres, als fehlerhaften Code mit einem fertigen Fix lange liegen zu lassen oder Features so zu verzögern, dass sie niemand nutzen kann
  Ich empfehle einen Prozess, in dem Kommentare erlaubt sind, Reviewer aber keinen Commit blockieren können. Man sollte darauf vertrauen, dass jede Entwicklerin und jeder Entwickler sorgfältig vorgeht und zum Task passende Änderungen vornimmt. Man kann zusätzlich CI einsetzen, und je nach Team kann das alles ziemlich gut funktionieren

  • Dann sollte die Engineering-Leitung diese Person stoppen. Dysfunktion zeigt sich auf viele Arten, und übertriebener Review-Eifer ist eine davon
    Den Prozess so zu ändern, dass man pathologische Reviewer ignorieren kann, ist bestenfalls eine halbe Maßnahme
    Beim Thema Blockieren bin ich zwiegespalten. Ich verstehe, dass ein großes rotes Blocker-Symbol frustrierend ist, deshalb setze ich in vielen Fällen eher eine „weiche Blockade“, indem ich Änderungen anfordere, ohne hart zu blockieren. Aber wenn ein PR völlig entgleist ist, meist bei Junior-Entwicklern, halte ich eine klare Botschaft für angemessen
  • Dieser Ansatz funktioniert gut, wenn Testabdeckung und Testqualität hoch sind. Das entsteht aber nicht auf magische Weise nur dadurch, dass man Entwickler in dem Tempo arbeiten lässt, das Manager gerade verlangen
  • Ich hasse die Regel „Jede Codeänderung braucht einen Reviewer“. Sie ist ein massiver Störfaktor und führt nicht zwangsläufig zu besserem Code

• Das ist eine metabezogene Geschichte über Fabrikarbeiter und Softwareentwickler.
  Die Führung dieses Unternehmens ist bereit, Fabrikarbeiter wegen einer Unterauslastung von 10 % zu entlassen. Man könnte die Produktivität durch das Anpassen einiger Variablen steigern, aber am Ende bleiben nur die Alternativen volle Auslastung oder Arbeitslosigkeit. Wahrscheinlich ist das möglich, weil diese Arbeiter austauschbar sind, in der Hochsaison wieder eingestellt werden können und der Gewinn pro Mitarbeiter keine Ineffizienz erlaubt.
  Ich arbeite als Softwareentwickler. Bei uns würde man erst darüber nachdenken, jemanden rauszuwerfen, wenn die Unterauslastung weit über 90 % liegt. Viele Leute arbeiten nur 4 Stunden pro Woche. Niemand überwacht unsere Zeit minutengenau oder unsere Toilettenpausen.
  Wir befinden uns gerade in einer Phase der massiven Kapitalisierung von Software. Das wird nicht ewig so bleiben. Irgendwann wird die wesentliche Infrastruktur der IT-Welt aufgebaut sein und die Branche in einen Wartungsmodus übergehen. Die meisten von uns werden dann nicht mehr gebraucht, austauschbar werden, und der Gewinn, den wir im Wartungsmodus erzeugen, wird im Vergleich zu heute verschwindend gering sein.
  Fabrikarbeiter werden normalerweise innerhalb von Minuten oder Stunden entlassen, wenn ihre individuelle Produktivität als zu niedrig wahrgenommen wird. Ich denke, dass so etwas noch zu unseren Lebzeiten auch bei Softwareentwicklern beginnen wird.

  • „Diese Arbeiter sind austauschbar und können in der Hochsaison wieder eingestellt werden“ – genau das ist der Unterschied. Eine Fabrik ist ein System von Prozessen, das darauf ausgelegt ist, Entscheidungsfindung und Variabilität aus jeder einzelnen Person herauszunehmen.
    Du solltest auch für dein eigenes Skillset einschätzen, inwieweit das dort möglich ist.
    Dem Grundgedanken, dass die massive Kapitalisierung von Software nicht ewig andauern wird, stimme ich zu. Nicht jedes Unternehmen braucht ständig Ingenieure, die neue Software entwickeln. Es ist eher ein kreatives Geschäft mit Boom- und Flautenphasen, wie die Filmproduktion. Wenn man sich für Entwicklung statt für IT entscheidet, muss man dieses Risiko akzeptieren. Ich weiß nur nicht, warum gerade jetzt der Höhepunkt sein sollte.

• Aus persönlicher Erfahrung: Ich habe einige Jahre in einem Team mit formalen Code-Reviews gearbeitet und bin dann in ein Team bzw. Unternehmen ohne Code-Reviews gewechselt. Jeder konnte frei in jeden Branch committen und mergen.
  Beim Eintritt hatte ich gemischte Gefühle, aber in der Praxis war es sehr erfrischend und vermittelte ein Gefühl von Eigenverantwortung, sodass ich schon nach wenigen Tagen produktiv war.

  • Ich habe früher in einem Team gearbeitet, das „katholische Code-Reviews“ machte, also push and pray.
    Gemessen an den Zielen des Teams hat ein Ansatz ohne Code-Reviews sehr gut funktioniert. Es war eine Forschungs- und Entwicklungsgruppe, deren Hauptziel darin bestand, Führungskräften „coole neue Features“ vorzuführen. Es gab viele kurzfristig hereinkommende Anfragen, aber auch viel Wegwerfcode.
    Nach einer Demo sagte ein Manager dann: „Sieht gut aus, aber hat keinen Business Case“, und das Repository wurde nie wieder angefasst. Natürlich wurde manches von dem, was wir gebaut hatten, gelegentlich doch zu einem Produkt, und dann war ein nachgelagertes Team dafür verantwortlich, den hingekritzelten Code auf Produktionsqualität zu bringen. Diese Leute hassten uns mit brennender Leidenschaft.
  • Ich habe gesehen, dass das in einem kleinen Team mit hohem Vertrauen und etwa 80 % Testabdeckung sehr gut funktioniert. Es war ein Prozess ohne PRs: Wenn die Tests durchliefen, die UX-Demo für Stakeholder – falls relevant – erfolgreich war und man selbst zufrieden war, wurde nach master gemergt.
    Neue Teammitglieder bekamen für die ersten 2–3 Monate einen Mentor zugeteilt, der neben ihnen saß, häufig Pairing machte und ihren Code ansah.
    Es war ein Projekt mit einer Laufzeit von 2,5 Jahren, ging im 20. Monat live, blieb im Zeit- und Budgetrahmen und lieferte mehr Funktionen als ursprünglich vorgesehen. An vielen Tagen diskutierten wir 2–3 Stunden vor dem Whiteboard. Das war informell, und nicht immer waren alle dabei.
    Merkwürdigerweise gab es während dieses Projekts drei verschiedene PMs. Es gab die strikte Regel, außerhalb der Stand-ups keine E-Mails oder sonstige Kontaktaufnahme zu nutzen, und zwei von den dreien konnten in diesem Setup „arbeiten“. Der CIO des Flughafens merkte erst nach zwei Jahren, dass wir gar keinen PM brauchten.
    Es gab die Regel, dass man für jede neue Arbeit an der Codebasis mit mindestens einem anderen Entwickler sprechen musste. Wir saßen in einem großen privaten Büro mit riesigen Whiteboards nur wenige Fuß voneinander entfernt. Stories wurden mit Indexkarten auf einem eigenen Whiteboard verwaltet, und wenn man das Wesentliche dort nicht erklären konnte, musste es in kleinere Teile zerlegt werden.
    Jeder baute seine Maschine selbst und konnte so viele Monitore nutzen, wie er wollte. Es ging um das Abrechnungs- und Gebührensystem eines großen internationalen Flughafens, und der Leiter der Buchhaltung, ein Direktor und andere Benutzer waren nur ein paar Bürotüren entfernt. Sie fehlten fast nie bei den Stand-ups und hatten eine Politik offener Türen für Fragen in Echtzeit.
    Stand-ups waren normalerweise keine Statusberichte, sondern informelle Diskussionen, Demos und Fragen-und-Antworten-Runden. Für Statusupdates musste man nur auf die Karten am Whiteboard schauen.
    Das fertige System verbesserte den Umsatz ab dem ersten Monat und danach jeden Monat um 8 %. Der Finanzdirektor musste das vor dem Vorstand der Flughafenbehörde erläutern. Abrechnungsstreitigkeiten und Abstimmungen mit den Fluggesellschaften sanken von 9 Tagen pro Monat auf 1 Tag, und der monatliche Aufwand für die Rechnungsstellung sank von 18 Tagen auf 5 Tage. Die Hauptnutzung konnte von einer Senior-Buchhalterin auf eine einzelne Junior-Buchhalterin mit drei Jahren Berufserfahrung übergehen.
    Im ersten Jahr gab es 6 Produktionsbugs und 0 falsche Rechnungen. Danach habe ich keine Daten mehr. Ein früherer Versuch, das System neu zu schreiben, war nach 3 Jahren gescheitert.
  • Ehrlich gesagt klingt das aus Sicht von Sicherheit und Auditierbarkeit wie ein Albtraum. Für eine Agentur oder etwas Ähnliches mit kleinen Projekten könnte es aber funktionieren.

• Ein Code-Review-Prozess, der Änderungen in Teams mit hoher Änderungsrate und ständiger Bewegung als Geisel hält, bis sie zum Muster passen, ist dysfunktional.
  Eine Politik des „Upgrades unterwegs“ hinterlässt einen langen Schweif halb abgeschlossener Übergänge und macht es für neue Entwickler schwerer, sich in die Codebasis einzuarbeiten. Da es keine Garantie gibt, dass der Produktfokus regelmäßig durch alle Teile der Codebasis geht, wird der Übergang nie abgeschlossen. Manche Produktbereiche bleiben jahrelang unangetastet.
  Wenn der Wechsel auf eine neue Richtlinie wichtig ist, sollte man ihn als ein konzentriertes Einzelprojekt herausschneiden und umsetzen; wenn nicht, dann ist er nicht wichtig.

  • Genau. Es ist schrecklich, dass das Management die Planung faktisch aufgegeben hat.
    Man hofft darauf, dass ungeplante Arbeitszeitbomben überall in der Codebasis durch zufällige, nicht zusammenhängende Arbeit ausgelöst werden.
    Wenn der neue Standard wichtig ist, sollte man den Code aktualisieren, und wenn nicht, dann nicht. Sich auf Zufälligkeit zu verlassen und dringende Arbeit dadurch zu verzögern, ist kein Plan.

• Das als Problem von Code-Reviews zu lesen, ist falsch. Das Problem ist, dass das Unternehmen einen Prozess aus internen Hürden über Prinzipien gestellt hat.
  Jeder Prozess braucht Auswege. Wenn eine Änderung eine Entlassung verhindern soll, sollten alle Auswege ausgelöst werden.