Wie wirkt sich Bürokratie auf die Codequalität aus?

Ich interessiere mich für Geschichten, bei denen die Bürokratie einen direkten Einfluss auf das endgültige Ergebnis der Codequalität hat .

Ein Freund erzählte mir zum Beispiel, dass das Versionskontrollsystem an seinem früheren Arbeitsplatz so umfangreich war, dass Programmierer keine neuen "Module" (Stammverzeichnisse im Quellbaum) erstellen durften, ohne die VCS-Götter um Erlaubnis zu bitten. Das Ergebnis war, dass Programmierer nicht bereit waren, den zusätzlichen bürokratischen Schritt zu durchlaufen, und statt ihre Dienste ordnungsgemäß zu komponieren, wurden die nicht in Beziehung stehenden Funktionen auf die vorhandenen Module aufgeschichtet, selbst wenn die Funktionalität nur aus der Ferne mit der aktuellen Definition des Moduls oder dem Namen des Moduls zusammenhängt war übrigens in der Vergangenheit. (ganz zu schweigen vom Umbenennen eines Moduls ...)

Ich interessiere mich für ähnliche Geschichten über Büro-, Betriebs- oder sonstige Bürokratie, die sich möglicherweise unbeabsichtigt auf die Softwarequalität auswirken

Ich interessiere mich für Geschichten, bei denen die Bürokratie einen direkten Einfluss auf das endgültige Ergebnis der Codequalität hat.

Ich denke nicht, dass Bürokratie so viel Einfluss auf die Codequalität hat wie persönliche Dynamik und Büropolitik. Bürokratie hat mit Prozess zu tun. Wenn ein vorhandenes Verfahren nicht ordnungsgemäß durchgeführt wird (negativ oder ausgebeutet ... siehe weiter unten), es hat das Potenzial , zu sich negativ auf die Fähigkeit zur Lieferung oder reagieren auf plötzliche Veränderungen beeinflussen. Ein fehlender Prozess hat jedoch einen gewissen und signifikanten Einfluss auf die Codequalität. Genauer gesagt wirkt sich ein Prozess, der die Codequalität nicht regelt (auch als Prozess mit mangelnder Codequalität interpretiert), auf die Codequalität aus.

Das heißt, es ist nicht die Bürokratie selbst, sondern spezifische, mit der Qualitätssicherung zusammenhängende Lücken in der Bürokratie, die die Codequalität beeinflussen, wenn sie ausgenutzt werden (entweder versehentlich oder schändlich).

Persönliche Dynamik und Büropolitik sind jedoch viel häufiger Schuld an schlechtem Code. Persönliche Dynamik bedeutet in erster Linie mangelnde Berufsethik. Ich kaufe mir nicht wirklich das Argument, dass Leute schlechten Code schreiben, weil sie es nicht besser wissen oder nicht richtig geschult wurden . Ich habe Leute ohne CS-bezogene Abschlüsse gesehen, die anständigen Code geschrieben haben. Es ist eine Geisteshaltung und eine persönliche Angelegenheit, organisiert und akribisch zu sein.

Büropolitik spielt eine noch schrecklichere Rolle. Chefs, die das treiben, denken nicht, sondern codieren nur Mantras (obwohl es Zeiten gibt, in denen wir die Leichen später nur codieren und versenden und säubern müssen). Entwickler, die darauf bestehen, das zu liefern, was sie für den perfekten Code halten, obwohl es von entscheidender Bedeutung ist, etwas aus der Tür zu bekommen. Code-Reviewer, die ** Löcher sind; Feldkriege und so. Diese Dinge verstärken die problematische persönliche Dynamik. Die Kombination von beidem dringt durch einen Riss im Prozess (die Bürokratie) oder durch einen Mangel daran und führt zu einem Zusammenbruch der Code-Qualitätssicherung.

Eine Lücke in der Bürokratie könnte gelöst werden, wenn es eine Kultur der Obduktion und der kontinuierlichen Verbesserung gibt. Negative persönliche Dynamik und destruktive Büropolitik verhindern jedoch, dass derartige Korrekturen am Prozess vorgenommen werden, wodurch bestehende Probleme (einschließlich der Probleme im Zusammenhang mit der Codequalität) aufrechterhalten werden.

Bürokratie an sich ist selten der Schuldige für schlechte Codequalität. Eigentlich würde ich sagen, dass Codequalität und Bürokratie durch negative persönliche Dynamik und Büropolitik negativ beeinflusst werden.

Ich habe aufgehört, an bestimmten Modulen im Projekt zu arbeiten, weil der Code-Prüfer ein Smart A $$ war

Bei einem kürzlich durchgeführten Projekt hatten Qualitätsleute viele Anforderungen bezüglich formaler Komponententests (Rückverfolgbarkeit, Kodierungsregeln, formale Überprüfungen, ...). Die Codierer schreiben keine Unit-Tests mehr, sondern debuggen nur ihren Code. Dies ist die gleiche Aufgabe, die gerade umbenannt wurde, führt zu den gleichen technischen Ergebnissen, jedoch ohne den administrativen Aufwand.