Entwicklung nachhaltiger Software

Dies ist der fünfte von sechs Teilen meiner Artikelserie über nachhaltige Software. Der vorige Teil findet sich hier, der erste hier.

Hierarchien

Wenn mit der eigentlichen Entwicklung begonnen wird, steht fest mit welcher Technologie das Projekt angegangen wird. Wahrscheinlich werden im Laufe des Projektes noch mindestens kleinere Ergänzungen der verwendeten Technologien vorkommen. Eine Lieferantin ist ebenfalls ausgewählt.

Falls diese Voraussetzungen mit Hilfe einer externen Beraterin geschaffen wurden, sollte nun darauf geachtet werden, dass die unabhängige Beraterin nicht in der Hierarchie über dem mit der Lieferung beauftragten Unternehmen steht. Dies ergibt sich oft automatisch, weil die Unabhängige die Grobplanung vorlegt, die dann von der Lieferantin im Detail umzusetzen ist. Für das beauftragende Unternehmen ist es aber am wertvollsten, wenn die Unabhängige und die Lieferantin auf Augenhöhe miteinander diskutieren und die Auftraggeberin die Argumente abwägen kann.

Entwicklungsplattform

Bevor die Entwicklerinnen anfangen Code zu schreiben, sollten wichtige Voraussetzungen geschaffen werden, die die langfristige Kontrolle über die zu entwickelnde Technologie für die Auftraggeberin sichern. Wenn man als Auftraggeberin nichts anderes vorgibt, wird die Softwareentwicklung i.d.R. auf Systemen der Lieferantin statt finden. Damit gibt man als Auftraggeberin einen sehr wichtigen Aspekt der Software-Ownership aus der Hand. Daher sollte hier vorgebeugt und darauf geachtet werden, dass die Entwicklung teilweise auf eigenen Systemen stattfindet.

Während der Software-Entwicklung werden den Entwicklerinnen zahlreiche einzelne Aufgaben gegeben. Die Umsetzung dieser Aufgaben schlägt sich in Änderungen des Programmcodes nieder und diese Änderungen werden in einer Softwareversionsverwaltung dokumentiert. Die Aufgaben werden in einem Ticket-System dokumentiert.

Diese beiden Systeme – Softwareversionsverwaltung und Ticketsystem – sollten in Besitz und unter Kontrolle der Auftraggeberin stehen. Denn hier lässt sich nachverfolgen, warum (Aufgabe) spezifische Änderungen (Versionsverwaltung) am Code vorgenommen wurden. Dies ist eine sehr wertvolle technische Dokumentation, die die Auftraggeberin haben muss, falls sie in der Lage sein möchte, die Lieferantin zu wechseln.

Wenn Entwicklerinnen den Code ändern, muss dieser (zumindest in professionellen Entwicklungsprozessen) noch für die Ausführung übersetzt und an bestimmte Stellen gebracht werden, wo erst Testerinnen und später Nutzerinnen das Ergebnis sehen. Dieser Prozess des “Deployments” sollte von der Lieferantin automatisiert werden und Teil der Entwicklungsplattform sein, die sich unter Kontrolle der Auftraggeberin befindet. Andernfalls stellt das “Deployment” eine weitere, potentiell signifikante Hürde für einen Lieferantinnenwechsel dar.

Meiner Erfahrung nach haben sich für all diese Systeme einfache integrierte Lösungen wie GitLab bewährt. Dies ist relativ einfach lokal zu installieren und zu warten, adressiert alle oben genannten Punkte und ist dabei nicht so überkomplex wie z.B. Atlassian Jira.

Es ist auch möglich, hierfür Cloud-Systeme zu verwenden. Idealer Weise sollten solche Systeme gewählt werden, wo sich die Daten exportieren lassen und auch auf lokalen Installationen funktionieren. Andernfalls begibt man sich in kaum auflösbare Abhängigkeit zum Cloudprovider. Auch letzteres kann eine valide Option sein, wenn man sein Unternehmen z.B. bereits vollständig in Abhängigkeit von Microsoft gebracht hat, und mit ein bisschen Unabhängigkeit in der Code-Ownership nichts mehr gewinnen zu können glaubt.

Agile Entwicklung

Wo man früher vor Beginn der Entwicklung detailliert festgelegt hat, wie das fertige Produkt aussehen soll (Pflichtenheft) geht man heute “agil” vor. Denn es hat sich gezeigt, dass vor Entwicklungsbeginn fast nie die nötigen Informationen vorliegen und fest definierte Produkte regelmäßig in der Umsetzung scheitern.

Statt dessen macht die Entwicklung kleine Schritte und stimmt sich immer wieder mit den künftigen Nutzerinnen ab, ob die Zwischenergebnisse sinnvoll aussehen und den Nutzerinnen tatsächlich Nutzen bringen, sowie, wie dann die nächsten kleinen Schritte aussehen sollen. Es muss für eine erfolgreiche Umsetzung also eine intensive Kommunikation zwischen Nutzerinnen und Entwicklerinnen geben (evtl. indirekte Kommunikation via z.B. User-Experience-Entwicklerinnen).

Das bedeutet, die Auftraggeberin muss, um den Erfolg des Projektes nicht zu gefährden, die künftigen Nutzerinnen teilweise freistellen, falls es sich um Kolleginnen handelt, oder regelmäßige systematische Evaluationen mit Testnutzerinnen organisieren, falls es sich um ein digitales Produkt für seine Kundinnen handelt.

Da das Projekt am Anfang nicht detailliert definiert ist, lässt sich auch kein Festpreis vereinbaren. Statt dessen verhandelt man wie hoch die laufenden Kosten der Entwicklung sind. Außerdem sollte die Lieferantin eine Indikation geben, wie groß sein Aufwand für die ersten Schritte ist, bis man Nutzerinnen etwas sinnvolles (einen minimalen Prototypen) zeigen kann.

KISS & technologische Abhängigkeiten

Bei der Umsetzung selbst, sollte darauf geachtet werden, alles so einfach wie irgend möglich zu halten. Dies ist als das KISS– (Keep It Simple Stupid) Prinzip bekannt. Technologinnen neigen dazu, komplexe Technologien einzusetzen, die (noch) nicht zwingend notwendig sind (YAGNI-Prinzip: You Ain’t Gonna Need It). Das kann langfristig erhebliche unnötige Kosten verursachen.

Möglichst viel Funktionalität sollte mit möglichst “tiefen” Schichten der gewählten Technologie umgesetzt werden. Im Zuge der fortschreitenden Entwicklung der Software-Ökosysteme, wird auch immer mehr Funktionalität in solch “tiefere” Schichten übernommen. Dies kommt oft erst stark verzögert bei den Lieferanten an, die wie gewohnt mit den “höheren” Schichten ihrer Frameworks arbeiten. Die “tieferen” Schichten haben den immensen Vorteil, dass sie viel stabiler sind und langfristig geringere Kosten verursachen.

Jede zusätzliche technische Abhängigkeit (zusätzliche “höhere” Schicht) birgt das Risiko, dass die Lebensdauer dieser Abhängigkeit kleiner ist, als die des Projektes, in dem sie verwendet wird. Wenn eine Abhängigkeit ihr Lebensende erreicht, “erbt” das Projekt diese Abhängigkeit: es müssen evtl. signifikante Ressourcen investiert werden, um diesen Teil der Software sicher (oder überhaupt) weiter betreiben zu können.

In der Softwareentwicklung taucht immer mal wieder das Problem auf, dass ein Programm zu langsam läuft. Eine einfache Lösung, die aufgrund ihrer Einfachheit meist angestrebt wird, besteht darin, der Software mehr Hardwareressourcen zur Verfügung zu stellen. In vielen Fällen lässt sich aber die Software mit überschaubarem Aufwand so verbessern, dass keine andere Hardware nötig ist. Zu erkennen, wann Softwareverbesserung und wann stärkere Hardware sinnvoll ist, erfordert einige Erfahrung.

Die in diesem Abschnitt erörterten Punkte sind der Hauptgrund dafür, dass in dieser Art wirtschaftlich nachhaltig entwickelte Software auch ressourcenschonender ist und damit zur ökologischen Nachhaltigkeit beiträgt.

Die Berücksichtigung dieser Punkte erfordert signifikantes technisches Knowhow auf Seiten des auftraggebenden Unternehmens. Denn zahlreiche technische Entscheidung müssen auf Konsistenz mit diesem Ziel der Einfachheit geprüft werden. Wenn dieses Knowhow nicht vorhanden ist oder zugekauft wird, besteht die beste Strategie darin, möglichst breit genutzte und aktuell weiterentwickelte Technologien einzusetzen.

Abschluss der Entwicklung

Agile Entwicklung ist ein Prozess ohne eingebautes Ende. Es finden sich erfahrungsgemäß immer neue Features von denen (mindestens einzelne) Nutzerinnen meinen, das wäre doch auch noch nützlich. Doch der zusätzliche Nutzen nimmt ab, je länger die Entwicklung dauert. Er kann sogar insgesamt negativ werden, wenn das Produkt für Nutzerinnen dadurch zu komplex wird.

Und selbst wenn das nicht der Fall ist: die Entwicklung kostet Geld und die Wartung ebenso. Und die Kosten von beidem steigen nicht-linear (sondern exponentiell, wenn auch zunächst flach), mit zunehmender Dauer der Entwicklung. Denn je länger die Entwicklung dauert, desto komplexer wird das System in der Regel und desto schwieriger wird somit das Hinzufügen weiterer Features und die Wartung des Systems.

Daher ist die Investition der Auftraggeberin lohnender, je früher der Abschluss geschafft wird. Sollte sich kein guter Abschluss abzeichnen, kann es sinnvoll sein, für weitere Features jeweils eigene Business Cases zu rechnen, damit die Entwicklung nicht ausufert.

Ist der Abschluss geschafft, geht das Projekt in den Dauerbetrieb. Worauf Auftraggeberinnen hier achten sollten, wird im nächsten Teil dieser Serie besprochen.

Leave a Reply

Your email address will not be published. Required fields are marked *