Suchen

Technische Schuld mit Hilfe von Open Source abwenden

| Redakteur: Sebastian Gerstl

Technische Schuld ist häufig ein verstecktes Problem der Softwareentwicklung: Leichte Abänderungen von der ursprünglichen Planung können lange Zeit später durch erhöhten Pflegeaufwand und Nachbesserungen erhebliche Kosten verursachen. In einem Whitepaper legt die Linux Foundation nun eine Strategie dar, wie mittels Open-Source-Entwicklung diese verdeckte Gefahr überwunden werden kann.

Firma zum Thema

Softwareableger können im Laufe der Zeit mehr und mehr technische Schuld anhäufen, die nicht nur Zeit, sondern wie finanzielle Schulden auch durch 'Zinsen' höhere Kosten verursachen. Mit einer Open-Source-Strategie kann diese Schuld allerdings verteilt und besser gemanagt werden.
Softwareableger können im Laufe der Zeit mehr und mehr technische Schuld anhäufen, die nicht nur Zeit, sondern wie finanzielle Schulden auch durch 'Zinsen' höhere Kosten verursachen. Mit einer Open-Source-Strategie kann diese Schuld allerdings verteilt und besser gemanagt werden.
(Bild: gemeinfrei / Pixabay )

Wenn in einem Entwicklungsprojekt durch nachträgliche Änderungen einmal von den ursprünglichen Anforderungen abgewichen wird, sind die daraus resultierenden Folgekosten und Konsequenzen nur schwer zu überschauen. Das Resultat ist häufig ein mit zusätzlichen Fehlern behafteter Quellcode, dessen Pflege und Wartung auch nach eigentlich abgeschlossener Entwicklung erheblichen Zeit- und Kostenaufwand verursacht. Mit diesem in der Softwareentwicklung als Technische Schuld ('engl. technical debt) umschriebenen Problem haben viele Unternehmen zu kämpfen, in der IT oder der Embedded-Entwicklung, aber auch in der fertigenden Industrie. Genauso wie finanzielle Schulden die Zahlung von Zinsen beinhalten, führt technische Schulden zu einer eigenen andere Art von Zinsen, die die Unternehmen letztendlich zwangläufig begleichen müssen.

Ein von der Linux Foundation herausgegebenen Whitepaper hat sich nun nicht nur der Erkundung der Ursachen und Folgen von Technischer Schuld verschrieben. Die Autoren, Dr. Ibrahim Haddad und Dr. Cedric Bail, M.Sc., legen in ihrer Studie dar, wie mit einer Open-Source-Strategie die Auswirkungen von technical debt minimiert und das Problem in einem größeren Maßstab bewältigt werden können.

Die Definition technischer Schuld

Frei ausgelegt kann bereits ein proprietärer Code an sich schon die Ursache technischer Schuld darstellen, denn:

  • Eine einzige Organisation bzw. ein einziges Unternehmen hat ihn entwickelt;
  • Folglich liegt es alleine in der Verantwortung dieser Organisation, den Quellcode zu warten und zu pflegen, bzw. für dessen Sicherheit und Stabilität zu sorgen; und
  • In einigen Fällen ist die Organisation von der Fähigkeit eines einzelnenPartners abhängig, den Code zu pflegen und die genannte Schuld zu tragen.

Die folgenden Symptome können auf technische Schuld hinweisen:

  • Langsamere Freigabekadenz: Die Zeit zwischen der Lieferung neuer Funktionen nimmt zu.
  • Erhöhte Einarbeitungszeit für neue Entwickler: Neue Entwickler werden aufgrund der Code-Komplexität, bei der nur Insider mit der Code-Basis vertraut sind, stark eingebunden. Die zweite Manifestation dieses Symptoms ist die Schwierigkeit, Entwickler zu halten oder neue Entwickler einzustellen.
  • Erhöhte Sicherheitsprobleme: Wenigstens in neuen Versionen oder Ablegern existieren mehr Sicherheitsprobleme als im Hauptzweig.
  • Verstärkter Aufwand für die Pflege der Codebasis: Wartungsaufgaben werden zeitaufwendiger, da der zu wartende Codekörper größer und komplexer wird.
  • Fehlanpassung an den Upstream-Entwicklungszyklus: Es wird immer schwieriger, mit den Upstream-Entwicklungs- und Release-Zyklen Schritt zu halten und auf diese abgestimmt zu sein.

Die Folgen technischer Schuld

Die Schaffung und das Tragen technischer Schulden wird mehrere negative Auswirkungen auf die Entwicklungsbemühungen haben, darunter unter Anderem:

  • Die höheren Kosten der Codepflege.
  • Langsamere Innovations- und Entwicklungszyklen.
  • Zahlung von "Schuldzinsen". Soll heißen: Die Zahlung der technischen Schulden erfolgt in Form von zusätzlicher Entwicklung, die notwendig ist, um mit dem Hauptzweig, der Konkurrenz und dem Rest der Welt Schritt zu halten.
  • Möglicherweise fehlen neue Funktionen im Hauptzweig oder alle neuen Entwicklungen müssen intern in den abgezweigten Ableger zurückportiert werden.
  • Doppelte Arbeit mit dem Hauptzweig, die dadurch entsteht, dass die Diskrepanz zwischen dem internen und dem öffentlichen Zweig zu groß wird.
  • Schlimmstmögliche Konsequenz sind die Auswirkung auf die langfristige Wartbarkeit der Code-Basis: Unternehmen haben dann schwer damit zu kämpfen, ihren Fork vom Hauptzeig stabil zu halten.

In vielen Fällen ist technische Schuld kurzfristig nicht zu vermeiden. Technische Schulden zu tragen ist meist eine Entscheidung, die Entwickler ständig treffen müssen. Das langfristige Ziel jeder technischen Anstrengung sollte daher die Minimierung und Eliminierung jeglicher technischer Schulden sein, die sich aus irgendeiner Entwicklungsarbeit ergeben. Mit geeigneten Richtlinien, Prozessen, Schulungen und Werkzeugen können Unternehmen dazu beitragen, die technischen Anstrengungen zur Verringerung der technischen Verschuldung zu mildern und zu lenken.

Technische Schuld mit einer Open-Source-Entwicklungsstrategie vermeiden

Open Source als Entwicklungsstrategie kann eine wichtige Rolle Spielen, viele der oben genannten Probleme zu vermeiden. Die Abstimmung interner Entwicklungsbemühungen mit vorgelagerten Open-Source-Projekten kann sich direkt positiv auf die Höhe der Technikschulden auswirken, die ein Unternehmen trägt, z.B. indem Aktualität mit anderen Teams oder öffentlich einsehbaren Projekten jederzeit abgeglichen werden kann.

Indem die Last der technischen Schuld - und die daraus resultierenden 'Zinsen' - auf mehrere Schultern verteilt werden, sodass sie nicht mehr rein intern getragen werden muss, lassen sich der resultierende Mehraufwand und die aus der Wartung und Pflege entstehenden Zusatzkosten reduzieren. Das kostenlose, registrierungsfreie Whitepaper der Linux Foundation hält hierfür einige empfehlenswerte Vorgehensweisen parat, darunter:

  • Planen Sie immer, nach einer Abweichung vom Hauptcode sich wieder mit dem Hauptzweig zusammenzuschließen. Forks und und Seitenäste sind in Ordnung, solange der Plan besteht, diese wieder mit dem ursprünglichen Upstream zu vereinen.
  • Stellen Sie sicher, dass der gesamte Code ordnungsgemäß dokumentiert wird, damit er von den vorgeschalteten Prüfern besser verstanden wird und höchstwahrscheinlich zu einem schnelleren Abnahmezyklus beiträgt.
  • Veröffentlichen Sie Ihren Release frühzeitig, und bleiben Sie bei Änderungen schnell am Ball. Bauen Sie nicht erst eine riesige Code-Basis auf, ehe Sie sich für einen Upstream entscheiden. Tauschen Sie Design und frühen Code mit anderen aus und reichen Sie große Open-Source-Kontributionen in kleineren, unabhängigen Patches nach, die stets aufeinander aufbauen.
  • Behalten Sie auch den Code im Blick, den Sie in Ihrem Release nicht eingebaut haben, und bewerten Sie diesen regelmäßig neu. Wenn Sie bemerken, dass ihr intern verwendeter Code sich aufbläht kann es angemessen sein, frühere Entscheidungen neu zu hinterfragen und gegebenenfalls wieder zu einer Entwicklung des Hauptzweiges zurückzukehren.

Weiter Hintergründe, mögliche Ursachen und Auswirkungen technischer Schuld und Strategien im Umgang damit unter Berücksichtigung einer Open-Source-Entwicklung finden Sie im (englischsprachigen) Whitepaper Technical Debt and Open Source Development der Linux Foundation.

(ID:46764814)