Es gibt drei entscheidende Unterschiede zwischen Programmierung und Software-Engineering: Zeit, Umfang und die damit verbundenen Entscheidungen. Im Software-Engineering müssen sich Entwicklungsteams stärker mit dem Ablauf der Zeit und der Notwendigkeit von Veränderungen auseinandersetzen.
Kurz & knapp
- Veränderungen in Funktionalität, Effizienz, Datensicherheit und anderen Aspekten sind für langlebige Softwareprojekte unabdingbar. Der Umgang mit diesen Veränderungen ist entscheidend für die Nachhaltigkeit.
- Fachwissen und gemeinsam definierte Standards tragen erheblich zum Wert und zur Effizienz einer wachsenden Organisation bei.
- Wissensaustausch, gemeinsam festgelegte Praktiken und Plattformen ermöglichen die Entwicklung stabiler, sicherer und effizienter Software, ohne dass “das Rad jedes Mal neu erfunden werden muss”.
In einer Software-getriebenen Organisation liegt der Schwerpunkt auf Leistungsumfang und Effizienz, sowohl für die produzierte Software als auch für die Organisation, die sie produziert. Software-Ingenieurinnen und Ingenieure müssen tagtäglich komplexe Entscheidungen treffen, die Einfluss auf die Wertschöpfung von Unternehmen haben – und die oft auf unscharfen Anforderungen und erfahrungsbasierten Schätzungen beruhen.
Programmierung vs. Software-Engineering
In der Softwarebranche gibt es die Aussage, dass Software-Engineering „zeitlich integrierte Programmierung“ ist. Programmierung ist also ein wichtiger Teil des Software-Engineerings, da sie den Prozess der Erstellung neuer Software darstellt. Die Hinzufügung der Zeit fügt der Programmierung jedoch eine neue Dimension hinzu, wodurch sich das Software-Engineering von der Programmierung unterscheidet – insbesondere auch im Enterprise-Bereich.
Eine Möglichkeit, die Auswirkungen der Zeit auf ein Programm zu verstehen, besteht darin, die erwartete Lebensdauer des Programmcodes zu berücksichtigen. Die Lebensdauer von Code kann von wenigen Minuten bis zu mehreren Jahrzehnten reichen. Kurzlebige Systeme sind im Grunde “nur” Programmierprobleme, während langlebige Systeme eine kontinuierliche Anpassung an Veränderungen erfordern.
Diese Unterscheidung ist der Kern bei der Nachhaltigkeitsbetrachtung von Software. Ein Softwareprojekt ist dann nachhaltig, wenn es während der gesamten erwarteten Lebensdauer der Software auf wichtige technische oder geschäftsbezogene Änderungen reagieren kann. Wenn eine Organisation grundsätzlich nicht in der Lage ist, auf Änderungen in der zugrunde liegenden Technologie oder Produktausrichtung zu reagieren, geht sie ein hohes Markt- und Wettbewerbsrisiko ein.
Skalierung in der Softwareentwicklung
Ein wichtiger Aspekt des Software Engineerings ist die Projektgröße: Wie viele Personen sind beteiligt, und welche Rolle spielen sie bei der Entwicklung und Wartung im Laufe der Zeit? Eine Programmieraufgabe ist oft eine individuelle Leistung, während eine Softwareentwicklungsaufgabe Teamarbeit erfordert. Diese Unterscheidung zwischen Software-Engineering und Programmierung hat sowohl zeitliche als auch personelle Auswirkungen. Die Zusammenarbeit im Team bringt neue Herausforderungen mit sich, bietet aber auch ein größeres Potenzial, nachhaltigere und werthaltigere Systeme zu entwickeln, als es eine einzelne Programmiererin oder ein Programmierer könnte.
Die Teamorganisation, die Projektzusammensetzung sowie die Richtlinien und Praktiken eines Softwareprojekts tragen alle zur Komplexität der Softwareentwicklung bei. Wenn eine Organisation wächst und ihre Projekte expandieren, muss sie bei der Softwareproduktion effizienter werden.
Die Notwendigkeit des Wandels
Die Diskussion über die Zeit und die Notwendigkeit, auf Veränderungen zu reagieren, impliziert die Annahme, dass Veränderungen notwendig sind. Änderungen an Funktionalität und Effizienz, aber auch Themen wie Data Privacy und Security tragen alle zur Notwendigkeit von Veränderungen bei. Langfristig angelegte Projekte, die nicht in diese Nachhaltigkeit investieren, sind mit erheblichen Risiken verbunden. Unternehmen müssen in der Lage sein, auf diese Probleme zu reagieren und die damit verbundenen Chancen zu nutzen. Veränderung ist also nicht per se als positiv zu bewerten, aber die Fähigkeit auf Veränderung zu reagieren ist entscheidend.
Skalierbare Richtlinien
Welche Art von Maßnahmen führt zu Kosteneinsparungen, wenn eine Organisation expandiert? Und was noch wichtiger ist: Welche Richtlinien können implementiert werden, die einen hohen Mehrwert bieten, wenn das Unternehmen wächst? Es hat sich gezeigt, dass Fachwissen und gemeinsam definierte Standards einen erheblichen Wert haben, wenn ein Unternehmen wächst. Wenn Ingenieurinnen und Ingenieure z. B. in gemeinsamen Foren diskutieren und Fragen beantworten, verbreitet sich das Wissen, und es entstehen neue Experten. Wissen verbreitet sich viral, und es ist von unschätzbarem Wert, häufige Stolpersteine für das Entwicklungsteam aus dem Weg zu räumen.
Gemeinsam definierte Standards manifestieren das gemeinsam erarbeitete Wissen schließlich in wiederverwendbaren Code. Programme werden von Projekt zu Projekt und von Version zu Version stabiler, sicherer und effizienter: „Das Rad muss nicht jedesmal neu erfunden werden.“
Abwägungen und Kosten
Wenn man weiß, wie man programmiert, wie lange die zu pflegende Software betrieben werden soll und wie das Unternehmen mit immer mehr Ingenieurinnen und Ingenieuren neue Funktionen entwickelt und pflegt, bleibt nur noch die Aufgabe, gute Entscheidungen zu treffen. Dies scheint offensichtlich: In der Softwareentwicklung, wie auch im Leben, führen gute Entscheidungen zu guten Ergebnissen. Die Auswirkungen dieser Beobachtung werden jedoch leicht übersehen.
Innerhalb einer Organisation gibt es eine starke Abneigung gegen das Argument “weil ich es gesagt habe” oder “weil alle anderen es so machen”. Es ist wichtig, dass es für jedes Thema eine Entscheiderin oder einen Entscheider gibt und klare Eskalationswege, wenn Entscheidungen falsch zu sein scheinen. Aber das Ziel ist Konsens, nicht Einstimmigkeit. Es ist in Ordnung und wird erwartet, dass es einige Fälle gibt, in denen gesagt wird: “Ich stimme nicht mit Ihren Maßstäben/Bewertungen überein, aber ich verstehe, wie Sie zu dieser Schlussfolgerung gekommen sind”.
Wann immer es effizient ist, sollte die Organisation in der Lage sein, ihre Arbeit zu erklären, wenn sie zwischen den allgemeinen Kosten für zwei technische Optionen entscheidet. Was ist mit Kosten gemeint? Hier geht es nicht nur um Geld. “Kosten” bedeutet meistens “Aufwand” und kann einen oder alle der folgenden Faktoren umfassen: Finanzielle Kosten (z. B. Geld), Ressourcenkosten (z. B. CPU-Zeit), Personalkosten (z. B. technischer Aufwand), Transaktionskosten (was kostet es, etwas zu unternehmen?), Opportunitätskosten (was kostet es, nicht zu handeln?)
Zusätzlich zu den oben genannten Kosten (bzw. der Einschätzung der Organisation) gibt es Vorurteile: Status-quo-Voreingenommenheit, Verlustaversion und andere. Bei der Bewertung der Kosten müssen alle zuvor aufgeführten Kosten berücksichtigt werden: Das Wohlergehen einer Organisation hängt nicht nur davon ab, ob Geld auf der Bank ist, sondern auch davon, ob sich ihre Mitglieder wertgeschätzt und produktiv fühlen. In hochkreativen Bereichen wie der Softwareentwicklung sind die finanziellen Kosten in der Regel nicht der begrenzende Faktor – die Personalkosten sind es in der Regel. Effizienzgewinne durch zufriedene, konzentrierte und engagierte Ingenieurinnen und Ingenieure können leicht andere Faktoren überwiegen – aus dem einfachen Grund, weil Konzentration und Produktivität so unterschiedlich sind und ein Unterschied von 10 bis 20 Prozent leicht vorstellbar ist.
Abwägen von Zeit und Maßstab bei der Entscheidungsfindung
Zeit und Umfang überschneiden sich oft bei softwaretechnischen Entscheidungen, aber häufig geraten sie auch in Konflikt. Ein solcher Konflikt entsteht zum Beispiel bei der Entscheidung, ob ein Programmfeature in einer Standardsoftware zentral hinzugefügt oder nur in einer lokalen Installation (z. B. für ein einziges Projekt) umgesetzt werden soll. Die lokale Umsetzung kann Geschwindigkeitsvorteile und eine bessere Kontrolle über Änderungen bieten. Allerdings kann sich dieser Ansatz auch negativ auf die Skalierbarkeit, Wiederverwendbarkeit und Nachhaltigkeit auswirken.
Es gibt keine pauschale Antwort auf dieses Dilemma. Faktoren wie Projektdauer, Umfang und mögliche Auswirkungen auf andere Projekte sollten bei diesen Entscheidungen berücksichtigt werden. Letztendlich ist es wichtig, ein Gleichgewicht zwischen Anpassung und Wiederverwendbarkeit zu finden.
mgm A12: Erkenntnisse in Software manifestieren
Werden all diese Aspekte von Zeit, Umfang und Veränderung konsequent zu Ende gedacht, können sie auch in Form von Software manifestiert werden, die in allen Unternehmensprojekten gemeinsam genutzt wird. Die industriellen Perspektiven von Serienfertigung, Skalierung und Qualität zeigen sich dann in den Konzepten von Frameworks, Komponenten und Vorgehensmodellen – bis hin zu übergreifenden Plattformideen. Eine solche Plattform bietet den Entwicklungsteams eine gemeinsame, projektübergreifende und nachhaltige Basis für ihre Arbeit. Bei mgm nennen wir diese Plattform A12: Wir nutzen sie selbst in unseren Projekten und stellen sie auch unseren Kunden zur Verfügung.
