Ist es typisch für große Softwareunternehmen, Code nicht zu dokumentieren oder umzugestalten? [geschlossen]

Ich habe bei einem großen Softwareunternehmen angefangen zu arbeiten und wurde einem Projekt zugewiesen, das mehr als eineinhalb Millionen Codezeilen umfasst. Es ist Teil einer Programmsuite, die an Kunden verkauft wird (kein internes Projekt), und der Quellcode kann auf Wunsch erworben werden (obwohl dies angesichts der damit verbundenen zusätzlichen Gebühren selten erscheint). Sie machen seit Jahren Software-Design und ihre aktuellen Produkte sollen auf absehbare Zeit fortgesetzt werden.

Zu meiner Überraschung fehlen die anderthalb Millionen Codezeilen fast vollständig in der Dokumentation. Darüber hinaus gibt es einige Bereiche des Codes, die unglaublich chaotisch zu befolgen sind oder die durch Refactoring viel einfacher zu verstehen sein könnten (zum Beispiel kam vor etwa 10 Jahren eine Verbesserung der Programmiersprache heraus, die große Teile des Codes stark machen würde sauberer, ganz zu schweigen von weniger anfällig für Fehler). Es scheint keine Bemühungen zu geben, dies zu korrigieren, und meine Angebote für die Teile, mit denen ich arbeite, stießen auf Widerstand, auf den ich nie wirklich eine klare Antwort bekommen habe.

Sind diese Praktiken in einem großen Unternehmen der Softwareindustrie üblich? Oder ist mein Unternehmen einzigartig in seinem Mangel an Refactoring und Dokumentation?

Nachtrag: Aufgrund einiger Kommentare möchte ich klarstellen, wonach ich suche. Ich verstehe, dass mein Unternehmen technische Schulden hat und das ist schlecht. Ich möchte nicht feststellen, ob es meinem Unternehmen aus diesem Grund schlechter geht oder nicht. Ich möchte nur wissen, ob dieser Mangel an Dokumentation und der Widerstand gegen Refactoring eine Tatsache in der Programmierwelt ist, die ich haben werde zu behandeln, wenn ich weiter daran arbeite.

Es gibt eine Reihe von Gründen, warum Unternehmen aus Sicht der technischen Verschuldung nicht in die "Verbesserung" ihrer Programme investieren:

1. Durch die Reduzierung der technischen Schulden werden der Software keine neuen Funktionen hinzugefügt. Es wird daher vom Management als nicht monetär angesehen (bis zu einem gewissen Grad zu Recht).

2. Die Art des Software-Geschäfts zeichnet First-to-Market aus, nicht das Beste.

Ich könnte weitermachen, aber alle anderen Gründe sind nur Varianten dieser beiden. Sie alle summieren sich im Grunde genommen zu kurzfristigem Denken und konzentrieren sich auf unmittelbare Gewinne anstatt auf langfristige Rentabilität.

Alle Unternehmen mit nicht trivialen, aktiven Softwareprojekten haben eine gewisse technische Verschuldung. Kein Unternehmen ist völlig schuldenfrei.

Jedes Softwareprojekt, an dem ich jemals gearbeitet habe, hat im Laufe der Zeit technische Schulden angehäuft - Jeff Atwood .

In Bezug auf die Dokumentation gilt: Je weniger vorhanden ist, desto besser. Dollar für Dollar erzielen Sie mehr Rendite, wenn Sie die Software einfacher zu bedienen und zu warten machen, als wenn Sie mehr Dokumentation dafür schreiben.

Es gibt einige informelle Umfragen zu technischen Schulden und wie Unternehmen damit umgehen. Alles was Sie tun müssen, ist nach ihnen zu suchen. Hier ist einer :

Oder dieser :

Es scheint ziemlich offensichtlich, dass Ihr Unternehmen nicht das einzige ist, das dieses Problem hat. Es kann nicht einmal in der Minderheit sein.

Weiterführende Literatur
Dritter internationaler Workshop zum Management technischer Schulden - Überblick über das
Management technischer Schulden in softwareabhängigen Systemen

Eine Perspektive, von der ich glaube, dass sie (noch) nicht in anderen Antworten behandelt wurde, sind die Kosten für Änderungen in drei Bereichen:

1. testen
2. Wiedereinweisung
3. Opportunitätskosten

Ein Unternehmen mit einem großen Produkt muss alle Änderungen testen. Diese Testverfahren müssen über mehrere Achsen verfolgt werden: unterschiedliche Plattformen, unterschiedliche Workloads, unterschiedliche Perspektiven (Leistung, Funktionalität, Benutzerfreundlichkeit, Abwärtskompatibilität).

Die Leute, die in den Bereichen des Codes arbeiten, die Sie ändern, müssen sich dann auch erneut mit dem Code vertraut machen, und es wird besonders umständlich, wenn mehrere Versionen unterstützt werden ("Entschuldigung, welche Version ist das? Ahh, das ist die neue Code und Sie müssen mit Bob dafür sprechen "). In ähnlicher Weise führt das Ändern von Code, um ihn hübsch zu machen, dazu, dass Dinge wie Änderungsprotokolle (Unterschiede, Patches usw.) sehr kompliziert zu lesen sind ... und Probleme bis zu einem bestimmten Zeitpunkt zurückverfolgt werden, als der Fehler eingeführt wurde kann sehr herausfordernd sein, wenn etwas im Codeverlauf alles ändert. Wenn ein Fehler seit langem besteht (diese Dinge passieren), kann er in mehreren unterstützten Versionen Ihres Codes auftreten. Jetzt müssen Sie den alten und den neuen Code auf möglicherweise sehr unterschiedliche Weise beheben.

Schließlich muss oft die Entscheidung getroffen werden, wo Zeit und Geld ausgegeben werden sollen. Dies ist mehr als nur Ihre Zeit, sondern vielmehr das, was Sie lieber mit Ihrer Zeit tun sollten (und welche Auswirkungen dies auf nachgelagerte Ressourcen hat). Wäre es vorzuziehen, die Zeit Ihres Entwicklerteams mit Funktionen zu verbringen, die mehr Umsatz bringen, neue Marktanteile gewinnen und Gewinn generieren können, oder sollte die Zeit / das Geld für Dinge ausgegeben werden, die Endbenutzer nicht bemerken, kann sie nicht eingesetzt werden Marketingmaterial ("Hey, unser bestehender Code ist scheiße, aber wir haben es besser gemacht") und ist reine Kosten (kein Gewinn).

Fazit: Geld . Immer (na ja, fast immer).

Ja. Basierend auf den rund 50 Unternehmen, denen ich als Mitarbeiter oder Berater persönlich begegnet bin, und den rund 200 Unternehmen, die ich über Kollegen kenne.

Die Art des von Ihnen beschriebenen Produkts (1,5 Millionen Zeilen) hat Jahre gedauert, und viele der ursprünglichen Entwickler sind weitergezogen (oder wurden Manager).

Die Geschäftsleitung und die großen Stammkunden wollen nur kleine, schrittweise Änderungen: Sie wollen Stabilität. Was wir Techniker für Verbesserungen halten, sind in ihren Augen Risiken. Selbst wenn wir zeigen können, dass sich die neue Version immer noch genauso verhält wie die alte, sehen sie ein Risiko, da das alte System genau die von Ihnen beschriebene Eigenschaft aufweist: Es ist nicht dokumentiert. Für sie könnte es undokumentiertes Verhalten geben, auf das sich Kunden verlassen.

Aus ihrer Sicht: Es ist nicht kaputt, also reparieren Sie es nicht. Sie sehen auch, dass es eine entsprechende Unternehmenskultur gibt. Die Leute, die sich Ihren "Verbesserungen" widersetzen, haben wahrscheinlich dasselbe getan wie Sie, als sie angefangen haben.

Erwarten Sie nicht, "zu gewinnen". Dies ist ein kulturelles Problem und kann nur durch Änderungen auf CEO-Ebene geändert werden.