Software-Entwicklung

Diese Seite enthält Ansichten & Informationen zu einigen Aspekten von Software-Entwicklung.

Überblick

 

Einige Thesen / „Glaubenssätze“ zur Neuentwicklung, Weiterentwicklung und Wartung komplexer Software-Systeme
 
 
Gliederung
Vorbemerkung   Artikelanfang   ► Seitenanfang
 
Die nachfolgenden Thesen / „Glaubenssätze“ beziehen sich auf die Neuentwicklung, Weiterentwicklung und Wartung komplexer Software-Systeme, d.h. auf Arbeitszusammenhänge in der Software-Entwicklung und Software–Wartung, in denen Zig, Hunderte oder gar Tausende von Software-EntwicklerInnen über viele Jahre hinweg gemeinsam an einem (Gesamt-)Produkt arbeiten, das vielfältige Funktionen & Qualitäten haben soll und darauf ausgelegt ist, nach der Erstauslieferung über mehrere Releases hinweg verbessert & erweitert zu werden.
 
Die Thesen / „Glaubenssätze“ gründen zum einen auf meinen Erfahrungen als Entwickler und Manager im Bereich der Entwicklung & Wartung komplexer Software-Systeme, zum andern aber auch auf bestimmten „persönlichen Grundüberzeugungen“. Die Kennzeichnung als »Thesen« verdeutlicht, dass in den meisten Fällen keine Begründungen mitgeliefert werden. Die Kennzeichnung als »„Glaubenssätze“« verdeutlicht, dass mir einerseits bewusst ist, dass es sich nicht um unverrückbare Wahrheiten handelt, sondern um bestimmte Sichtweisen, dass ich andererseits aber von der Angemessenheit & Fruchtbarkeit dieser Sichtweisen durchaus überzeugt bin.
 
In den Thesen / „Glaubenssätze“ werden viele unterschiedliche Aspekte angesprochen. In dieser thematischen Breite spiegelt sich wieder, dass die Entwicklung & Wartung komplexer Software-Systeme ein komplexes Geschäft ist, bei dem viele unterschiedliche Aspekte eine wichtige Rolle spielen – einschließlich vieler Aspekte, die immer wieder gerne übersehen / ignoriert / ausgeblendet / verdrängt werden.
 
Einige der nachfolgenden Thesen / „Glaubenssätze“ sind in Zeiten von Agile & Scrum vielleicht zu allgemein geteilten Einsichten geworden. Viele andere dürften unter den EntscheidungsträgerInnen in der Software-Branche aber nach wie vor eine Minderheitenmeinung darstellen, vor allem, wenn es um die gelebte Praxis geht.
 
 
1 Thesen / „Glaubenssätze“ zum Aspekt „Qualität & Testen“ bei der Entwicklung & Wartung komplexer Software-Systeme  Artikelanfang   ► Seitenanfang
 
1.1 Qualität entsteht in der Entwicklung - oder nirgends. Qualitätsmanagement ist im Wesentlichen eine Aufgabe der Entwicklung selbst und sollte auch organisatorisch überwiegend dort verortet sein.
 
1.2 Testen ist grundsätzlich Aufgabe der Entwicklung, nicht Aufgabe separater Testteams. (Dass in Sonderfällen TesterInnen von außerhalb der Entwicklung sehr hilfreich sein können, wird nicht bestritten.)
 
1.3.1 Das wirksamste Mittel zur Erzielung und Aufrechterhaltung hoher Qualität sind von den EntwicklerInnen selbst verantwortete automatisierte Tests mit hoher Testabdeckung (möglichst >= 90%), wobei Testabdeckung immer als Source-Code-Abdeckung durch Tests zu verstehen ist.
 
1.3.2 Neben hoher Code Coverage ist bei den automatisierten Tests auch auf gute Data Coverage zu achten, d.h. auf die Berücksichtigung möglichst vieler potenziell kritischer Datenkonstellationen.
 
1.4 Qualität beschränkt sich nicht auf funktionale Korrektheit, sondern umfasst weitere Dimensionen wie Performance, BenutzerInnen-Freundlichkeit, Barrierefreiheit, Sicherheit, Wartbarkeit, Robustheit, Dokumentation etc. Wo immer möglich, sollte es auch für diese Qualitätsdimensionen automatisierte Tests geben.
 
1.5.1 Qualität entsteht kontinuierlich – oder gar nicht. Kontinuierlich lauffähigen Entwicklungssystemen kommt daher große Bedeutung zu.
 
1.5.2 Die Qualität von Neu- und Weiterentwicklungen profitiert – insbesondere unter den Aspekten der BenutzerInnen-Freundlichkeit und der Vermeidung von Regressionen – sehr davon, wenn lauffähige Zwischenstände bereits während der Entwicklung von PilotInnen auf höheren Schichten abgenommen werden. Außerdem hilft ein zeitnahes AnwenderInnen-Feedback dabei, konzeptionelle Fehler möglichst früh zu entdecken.
 
1.6.1 Gute (d.h. hinreichend ausführliche und hinreichend verständliche) Dokumentation ist von zentraler Bedeutung für die Qualität von Software-Produkten. Dies gilt sowohl für die interne technische Dokumentation als auch für die externe Dokumentation.
 
1.6.2 Die interne technische Dokumentation sollte ganz überwiegend von den EntwicklerInnen selbst erstellt werden. Auch zur Erstellung der externen Dokumentation sollten die EntwicklerInnen ihren (Rohfassungs-)Beitrag leisten.
 
1.6.3 Hauptamtliche Dokumentations-EntwicklerInnen sollten organisatorisch in ihrer Mehrheit zur Software-Entwicklung gehören, und der Erstellung von Dokumentation sollte dieselbe Wertschätzung entgegengebracht werden wie der Programmierung.
 
1.7 Qualität beginnt beim Design, gerade was die über funktionale Korrektheit hinausgehenden Qualitätsdimensionen betrifft. Ohne sorgfältige Designarbeit (mehr dazu unten) gibt es keine qualitativ hochwertige Software.
 
1.8 Qualität entsteht nicht zuletzt durch den entwicklungsbegleitenden Einsatz von Werkzeugen, die die Anwendung bzw. Einhaltung bestimmter qualitätssichernder Entwicklungsprinzipien erleichtern oder sogar vorgeben. Es ist daher sinnvoll, in erheblichem Umfang in die Entwicklung bzw. den Ankauf und in die Verbreitung solcher Werkzeuge zu investieren.
 
1.9 Fehlerbehebung und Weiterentwicklung sind verschiedene Dinge. Wenn stabile Qualität beim Kunden ernst genommen wird, dürfen Weiterentwicklungen nicht als Patches untergeschoben werden, sondern es muss klar unterschieden werden zwischen Fehlerbehebungen (einschließlich zwingend notwendiger Anpassungen an veränderte Rahmenbedingungen) zum einen und neuer Funktionalität zum andern. Fehlerbehebungen kommen als (gebündelte) Korrekturen / Patches zum Kunden, Neuentwicklungen auf eigenen (Zwischen-)Release-Schienen.
 
1.10 Qualität hat unbedingte Priorität vor Funktionsumfang, Termin- und Budgettreue. Dies gilt ohne Wenn und Aber, egal wie stark der Druck ist, zu einem bestimmten Termin eine bestimmte Funktionalität zu liefern. Wenn eine hinreichende Qualität nicht gewährleistet werden kann, muss die Lieferung unterbleiben.
 
1.11 Hohe Qualität entsteht nur dann, wenn alle Beteiligten ein starkes, unverrückbares Qualitätsbewusstsein haben. Ein solches Qualitätsbewusstsein muss in der gesamten Organisation (auf allen Hierarchie-Ebenen von oben bis unten) kontinuierlich gelebt werden.
 
 
2 Thesen / „Glaubenssätze“ zu den Regeln guter Praxis bei der Entwicklung & Wartung komplexer Software-Systeme (über das eben schon zum Thema „Qualität & Testen“ Gesagte hinaus)  Artikelanfang   ► Seitenanfang
 
2.1 Einfachheit ist das vielleicht wichtigste Gütekriterium guter, wartbarer, weiterentwickelbarer Software. Essentielle (in der Natur der zu bewältigenden Aufgabe begründete) Komplexität ist nicht vermeidbar, akzidentelle (in der Art der gewählten Lösung begründete) schon. Einfachheit bedeutet also insbesondere das ständige Bemühen um die Vermeidung akzidenteller Komplexität, d.h. das ständige Bemühen um eine möglichst einfache Art der Lösung.
 
2.2 Ein wesentlicher Aspekt von Einfachheit ist die Erarbeitung und Einhaltung einer geeigneten Schichten-Architektur. Insbesondere ist im Rahmen einer Schichten-Architektur zum einen darauf zu achten, dass die Schichten durch wohldefinierte Schnittstellen sauber voneinander getrennt sind, und zum andern, dass „tiefere Schichten“ die richtigen Angebote (insbesondere die angemessenen Abstraktionen) für „höhere Schichten“ bereithalten und so verhindert wird, dass essentielle, vielfach wiederverwendete „Basis“-Komponenten (wie z.B. UI- oder BO-Frameworks) auf Anwendungsebene programmiert werden, und das oft auch noch mehrfach in unterschiedlicher Ausprägung.
 
2.3.1 Ein weiterer wichtiger Aspekt von Einfachheit ist die Vermeidung von all zu viel generischen (dynamischen) und generierenden (Code- oder allgemeiner Entwicklungsartefakt-erzeugenden) Komponenten, vor allem in höheren Software-Schichten und nicht zuletzt deshalb, weil viele Qualitätssicherungsmaßnahmen bei generischen und generierenden Anwendungen nicht greifen.
 
2.3.2 Generische und generierende Programmierung kann sehr sinnvoll sein, aber auch die statische Ausprogrammierung einer überschaubaren, wohlbegrenzten Anzahl von Spezialfällen sollte nicht als Tabu angesehen werden.
 
2.4 Wenn komplexe Software-Systeme über viele Jahre weiterentwickelt werden sollen, muss Weiterentwickelbarkeit als eigenständiges Gütekriterium betrachtet werden, dem hinreichend Aufmerksamkeit entgegengebracht wird. Einfachheit im eben beschriebenen Sinne ist eine der wesentlichsten Faktoren für Weiterentwickelbarkeit.
 
2.5.1 Damit komplexe Software-Systeme einfach und weiterentwickelbar bleiben, müssen sie kontinuierlich refaktoriert werden. Dies bedeutet insbesondere, Erweiterungen nicht „schnell & schmutzig dranzustricken“, sondern durch - ggf. auch tiefer gehende - Umbauten sauber zu integrieren. Die dafür notwendige Entwicklungszeit muss eingeplant werden, auch wenn dies die Erstellung einer „ersten Fassung“ verzögert, denn mittel- und langfristig ist eine saubere Integration immer effizienter als eine trickreiche Ad-hoc-Lösung.
 
2.5.2 EntwicklerInnen sollten immer wieder aktiv dazu ermutigt werden, Weiterentwicklungen wann immer sinnvoll mit Refaktorierungen – ggf. auch tiefer gehenden - zu verbinden. (Damit kontinuierliche Refaktorierung – auch tiefer gehende – möglich wird, ohne dadurch die Stabilität zu gefährden, ist eine möglichst vollständige Testabdeckung durch automatisierte Tests (s.o.) erforderlich.)
 
2.6 Einfachheit und Weiterentwickelbarkeit wird nicht zuletzt durch die Bereitstellung und Verwendung wiederverwendbarer Software-Bausteine erreicht. Da sich auch Wiederverwendung erst mittel- und langfristig auszahlt, bedarf es auch auf diesem Gebiet entsprechender zeitlicher Einplanung und aktiver Förderung.
 
2.7 Auch über eine Schichten-Architektur (s.o.) hinaus ist eine möglichst gute Verkapselung von Implementierungen, eine möglichst saubere Trennung von „innen“ und „außen“, eine möglichst wohl überlegte Definition von Außenschnittstellen und eine möglichst vollständige Verhinderung des externen Zugriffs auf nicht nach außen freigegebene Entitäten (z.B. durch strikte Anwendung eines hinreichend mächtigen Paketkonzepts) eine wesentliche Voraussetzung für Einfachheit und Weiterentwickelbarkeit. Auch hier bedarf es wieder entsprechender zeitlicher Einplanung und aktiver Förderung, einschließlich der Ermunterung zu verkapselungssteigernden Refaktorierungsmaßnahmen.
 
2.8.1 Die Erstellung und Weiterentwicklung wohlgeschichteter und wohlverkapselter komplexer Software-Systeme erfordert einerseits das entsprechende Bewusstsein und die entsprechende Disziplin auf Seiten der (Anwendungs-)Entwicklung, andererseits aber auch die Verfügbarkeit geeigneter, mächtiger Konzepte zur Unterstützung von Schichtung und Verkapselung in der verwendeten Programmiersprache und Entwicklungsumgebung.
 
2.8.2 Schichtung und Verkapselung auf Ebene der Anwendung durch die parallele, nicht integrierte Nutzung unterschiedlicher Sprachen für unterschiedliche Schichten und unterschiedliche Zwecke erreichen zu wollen, ist kein geeigneter Weg, insbesondere weil in komplexen Szenarien eine solche Lösung allein schon aus Performance-, TCD- und TCO-Gründen nicht durchführbar ist. Sinnvoll ist vielmehr, auf Ebene der Anwendung hinreichend mächtige Abstraktionen für unterschiedliche Aufgabenstellungen anzubieten (und deren Nutzung ggf. auch mehr oder weniger sanft zu „erzwingen“), diese Abstraktionen aber in eine einheitliche Trägersprache einzubetten.
 
2.9 Was (mit einigermaßen erträglichem Aufwand) automatisiert oder durch Werkzeuge unterstützt werden kann, sollte auch automatisiert oder durch Werkzeuge unterstützt werden. Dies gilt nicht nur für die Qualitätssicherung, sondern auch für alle anderen Phasen und Aspekte von Entwicklung und Wartung. Es ist daher sinnvoll, in erheblichem Umfang in die Entwicklung bzw. den Ankauf und in die Verbreitung entwicklungs- und wartungsunterstützender Werkzeuge zu investieren.
 
2.10.1 Gute Software beruht auf gutem Design. Gutes Design ist das Ergebnis eines sorgfältigen, zeitintensiven Designprozesses, der idealerweise in einer Gruppe von 3 – 7 EntwicklerInnen und ArchitektInnen stattfindet. Die dafür notwendige Zeit ist einzuplanen. (Gutes Design und „Speed“ sind gegenläufige Anforderungen. Im Zweifelsfall ist gutes Design wichtiger als „Speed“.)
 
2.10.2 Gutes Design beruht – wenn es um die Weiterentwicklung komplexer Software-Systeme geht - wesentlich auf einer sehr genauen Analyse der „Einbettungsoptionen“ der neuen Funktionalität in das existierende Produkt, genauso aber auf einer möglichst genauen Kenntnis der Arbeitsanforderungen und Arbeitsbedingungen der AdressatInnen der zu entwickelnden Software-Lösung.
 
2.10.3 Die Ergebnisse von Designprozessen, einschließlich der wesentlichen verworfenen Alternativen und einschließlich der Gründe, die für und gegen bestimmte getroffene oder verworfene Designentscheidungen gesprochen haben, müssen so ausführlich schriftlich dokumentiert werden, dass das Designergebnis nachvollziehbar und reviewfähig wird.
 
2.11.1 Demos und Prototypen wird vielfach eine zu große Bedeutung eingeräumt. Prototypen haben ihren Sinn als Bestandteil der Entwicklung, um Machbarkeit und Sinnhaftigkeit bestimmter Teilaspekte zu überprüfen. Wenn weitreichende Entwicklungsentscheidungen aber im Wesentlichen davon abhängen, eine eindrucksvolle Demo, basierend auf einem schnell „zusammengezimmerten“ Prototypen, abzuliefern, dann läuft etwas verkehrt, insbesondere weil dann sorgfältige Designarbeit oft zu kurz kommt.
 
2.11.2 Prototypen sollten auch als Prototypen behandelt werden. Der Weg vom Prototyp zum Produkt sollte in der Regel so aussehen, dass das Produkt, aufbauend auf den mit dem Prototyp gewonnenen Erfahrungen, neu implementiert wird, und nicht so, dass das Prototyp-Coding direkt zum Produkt-Coding weiterentwickelt wird.
 
2.12.1 Reviews haben eine große Bedeutung für die Erstellung guter Software, und zwar auf allen Stufen des Entwicklungsprozesses (vom Design über die Implementierung (einschließlich Tests) bis zur Wartung) und mit ganz unterschiedlicher Granularität (vom grobgranularen Gesamt-Design-Review bis zur feingranularen Code Inspection). Reviews aller Art und unter Beteiligung von Menschen, die unterschiedliche Perspektiven einbringen, sollten aktiv gefördert und die dafür benötigte Zeit von vornherein eingeplant werden.
 
2.12.2 Reviews dürfen nicht als formale Pflichtveranstaltung betrachtet und durchgezogen werden, sondern sollten zu einer lebendigen, offenen inhaltlichen Diskussion führen.
 
2.13.1 Die Weiterentwicklung komplexer Software-Systeme erfordert einerseits die Bereitschaft zu kontinuierlicher, auch tiefer gehender Refaktorierung, andererseits aber auch die Gewährleistung der kontinuierlichen Verfügbarkeit eines lauffähigen, stabilen Systems.
 
2.13.2 Die richtige Mischung aus Sorgfalt und Mut zum Risiko ist eine der wesentlichen Voraussetzungen, um diesen (und ähnlichen) eigentlich gegenläufigen Ansprüchen zugleich gerecht werden zu können.
 
2.13.3 Aufgabe von ManagerInnen ist es, die EntwicklerInnen immer wieder sowohl für die Bedeutsamkeit sorgfältigen Arbeitens zu sensibilisieren als auch zum (natürlich möglichst kontrollierten ;-) Eingehen bestimmter Risiken zu ermutigen.
 
2.14.1 Software-Entwicklung lebt einerseits davon, dass sich einzelne EntwicklerInnen (und ebenso auf der nächst höheren Ebene einzelne Entwicklungsgruppen) kontinuierlich über einen etwas längeren Zeitraum für bestimmte Teilbereiche wirklich zuständig und verantwortlich fühlen. Andererseits ist es eine wichtige Voraussetzung für die langjährige Weiterentwickelbarkeit komplexer Software-Systeme (an denen Zig, Hunderte oder gar Tausende von Menschen parallel arbeiten), dass sich alle EntwicklerInnen auch mit dem guten Funktionieren des „großen Ganzen“, des komplexen Software-Systems (bzw. größerer Teilsysteme) insgesamt, identifizieren.
 
2.14.2 Diesem Spannungsverhältnis zwischen lokaler und globaler Zuständigkeit und Verantwortung sollte nicht auszuweichen versucht werden, sondern es sollte immer wieder bewusst reflektiert werden. Im Zweifelsfall ist ein etwas zu Viel in Richtung „my baby approach“ (d.h. Priorität lokaler Zuständigkeit und Verantwortlichkeit) besser als ein zu Viel in Richtung „heute hier mitarbeiten, morgen dort“ (d.h. Priorität globaler Zuständigkeit und Verantwortlichkeit).
 
2.15.1 Das Spannungsverhältnis zwischen lokaler und globaler Zuständigkeit äußert sich insbesondere auch auf der Ebene des Codings. Auch hier ist bewusst darauf zu achten, dass einerseits den EntwicklerInnen genügend Freiraum gewährt wird, ihren eigenen Programmierstil auszuprägen und beizubehalten, andererseits aber auch alles Coding bestimmten Standards genügt, die sicherstellen, dass sich im Bedarfsfall fremdes Coding auch Dritten, die das Coding nicht selbst geschrieben haben, möglichst leicht erschließt.
 
2.15.2 „Schöner“ Programmierstil ist nicht „nice to have“, sondern essenziell für die Erreichung von Zielen wie Einfachheit, Erweiterbarkeit und Wartbarkeit. Es gibt nicht den einen guten Programmierstil (obwohl es natürlich auch hier Regeln guter Praxis gibt), aber es ist wichtig, dass alle EntwicklerInnen überhaupt einen in sich konsistenten Programmierstil ausprägen. Ein Programm, dass keinen erkennbaren Stil hat, ist schwerer zu lesen und zu verstehen als ein Programm, das einem Stil folgt, auch wenn es ein anderer ist als mein eigener.
 
2.16 Ganz generell gilt, dass es in fast allen Aufgabenfeldern nicht die eine, für alle Bereiche gültige beste Lösung gibt und dass es daher sehr sinnvoll ist, gruppen- und/oder bereichslokale Regeln guter Praxis auszuprägen. Diese sollten allerdings einerseits verträglich sein mit globalen Rahmensetzungen (ja, derer bedarf es auch, wenn auch lange nicht so stark & strikt, wie oft angenommen wird) und andererseits auch hinreichend individuellen Gestaltungsspielraum lassen. Die für die Identifizierung, inhaltliche Präzisierung, mediale Aufbereitung und wissensmäßige Verbreitung lokaler Regeln guter Praxis notwendige Zeit ist einzuplanen.
 
2.17.1 Um zu einem vernünftigen Ausgleich zwischen individueller und kollektiver Zuständigkeit und Verantwortlichkeit beizutragen, sollte Teamarbeit in allen Phasen und auf allen Ebenen aktiv gefördert und die dafür benötigte Zeit von vornherein eingeplant werden.
 
2.17.2 Eine besondere Form der Teamarbeit ist das Implementieren in Zweierteams (neudeutsch „Pair Programming“, früher „Vier-Augen-Prinzip“). Diese Form der Zusammenarbeit sollte aktiv gefördert werden, aber wenn irgend möglich auf freiwilliger Basis und unter Beachtung der Tatsache, dass sich manche Menschen mit solchen Formen stunden- und tagelanger enger (auch körperlich enger) Zusammenarbeit schwer tun.
 
2.18 Wenn irgend möglich, sollten Entwicklung und Wartung in einer Hand liegen. Richtig praktiziert, fördert dies einen Entwicklungsstil, der zu wartungsarmen Produkten führt, lässt Know-how-Engpässe in bestimmten Produktbereichen seltener entstehen und – besonders wichtig – sorgt dafür, dass EntwicklerInnen zumindest über die Wartung ein direktes AnwenderInnen-Feedback zu den von ihnen entwickelten Software-Produkten erhalten.
 
2.19 Egal ob Entwicklung und Wartung in einer Hand liegen oder getrennt sind: Hohe Wartungslast ist immer ein ernst zu nehmendes Problem, und es erfordert eine kontinuierliche Aufmerksamkeit & Anstrengung gerade auch der Entwicklung, die Wartungslast so gering wie möglich zu halten (nicht nur durch möglichst fehlerarme Implementierungen, sondern auch durch verständliche Konzepte, durch Berücksichtigung von Wartbarkeit – einschließlich spezifischer Wartungswerkzeuge - schon im Design, durch robuste Implementierungen, durch gute Fehlermeldungen und Hinweise, …).
 
2.20 Grundlegende Neuerungen („revolutionäre Innovation“) gibt es natürlich, und es ist auch wichtig, den Versuch der Hervorbringung grundsätzlich neuer Ansätze zu fördern. Dennoch ist revolutionäre Innovation deutlich seltener als die Ausarbeitung, Weiterentwicklung und geschickte Kombination des bereits Bestehenden („evolutionäre Innovation“). Dementsprechend sollten Investitionen in evolutionäre Innovation, d.h. in die kontinuierliche Verbesserung des Bestehenden, nicht vernachlässigt werden gegenüber Investitionen in revolutionäre Innovation, d.h. in den Versuch, umwälzende Neuerungen hervorzubringen.
 
2.21 Die langjährige evolutionäre Weiterentwicklung komplexer Software-Systeme, die massiv genutzt werden, erfordert eine starke Beachtung von Kompatibilitätsfragen. Beide hier denkbaren Extreme – einerseits absolut strikte, 100%-ige Kompatibilität, andererseits ein relativ laxer, unreflektierter Umgang mit der Kompatibilitätsproblematik – sind kontraproduktiv. Sinnvoll ist vielmehr eine verbindliche Zusicherung weitestgehender Kompatibilität, die es aber erlaubt, bei Bedarf auch Umbauten durchzuführen, die nicht 100% kompatibel sind, allerdings nur unter der Voraussetzung, dass die Inkompatibilitäten penibel dokumentiert werden, die dadurch verursachten Anpassungsarbeiten möglichst gut unterstützt (und so weit wie möglich automatisiert) werden und der Anpassungsaufwand insgesamt prognostizierbar ist und vertretbar bleibt.
 
2.22 Kreativität und Innovation kann nicht verordnet, sondern nur durch die Schaffung entsprechender Rahmenbedingungen gefördert werden. Eine wichtige Voraussetzung für Kreativität und Innovation, gerade auch im Bereich evolutionärer Innovation, ist eine Mischung aus tiefer Produktkenntnis sowie Gestaltungsfreiheit und Eigenverantwortlichkeit auf der Ebene der einzelnen EntwicklerInnen bzw. der einzelnen Entwicklungsgruppen.
 
2.23.1 Relativ „freischwebende“, von der konkreten Produktentwicklung weitgehend entkoppelte Teams, die sich aus übergreifender Perspektive mit Innovation, Solution Management, Produktdefinition und Architektur beschäftigen, sind durchaus sinnvoll, sollten aber nicht den Blick dafür verstellen, dass Innovations-, Produktdefinitions- und Architekturarbeit zu einem erheblichen Teil innerhalb der Entwicklung selbst stattfinden muss und dass die Rahmenbedingungen so sein sollten, dass dies auch erwünscht ist und angestrebt wird.
 
2.23.2 Damit die Arbeiten in entwicklungsunabhängig aufgestellten Solution-Management-, Produktdefinitions- und Architektur-Bereichen und die Arbeiten in der Entwicklung selbst sinnvoll miteinander harmonieren können, bedarf es der richtigen Balance zwischen strategischen Top-down-Vorgaben und Bottom-up-Freiheiten in der konkreten Entwicklungsplanung.
 
2.24 EntwicklerInnen sollten nie vollständig verplant werden. Egal wie dringend die anstehenden Entwicklungsarbeiten sind / erscheinen, sollte EntwicklerInnen immer (mindestens) 20% ihrer Arbeitszeit zur freien Verfügung verbleiben. Dieser Freiraum kann einzeln oder in kleinen Gruppen für Abrundungs- und Refaktorierungsarbeiten, für evolutionäre Weiterentwicklungen oder auch für die Erstellung von Konzepten und/oder Prototypen revolutionärer Innovation genutzt werden.
 
2.25 Bei der Weiterentwicklung komplexer Software-Systeme ist jedes Release mit ganz erheblichen Grundkosten befrachtet. Diese betreffen Entwicklung, Produktion und Wartung auf Seiten der Software-HerstellerInnen, aber auch Einführungskosten auf KundInnen-Seite. Daher sollte auf hinreichend lange Release-Entwicklungs-Zyklen geachtet werden (z.B. zwischen 9 und 18 Monaten).
 
2.26 Die Weiterentwicklung komplexer Software-Systeme erfordert einen langen Atem. Insbesondere müssen auch längerfristige Entwicklungsvorhaben (Entwicklungsdauer 2 – 5 Jahre) möglich sein (idealerweise mit bereits sinnvoll nutzbaren Zwischenlieferungen, aber das geht leider nicht immer), und die Prioritäten dürfen nicht relativ kurzfristig immer wieder neu definiert werden.
 
2.27.1 Entwicklungsplanungen, von denen „eigentlich“ jedeR weiß, dass sie unrealistisch sind, sollten unterbleiben. Es ist nicht zielführend, große Entwicklungen in wenigen Monaten „aus dem Boden stampfen“ zu wollen, obwohl den zuständigen EntwicklerInnen klar ist, dass dafür mit hoher Wahrscheinlichkeit ein deutlich längerer Entwicklungszeitraum benötigt werden wird.
 
2.27.2 Software-Entwicklung unter starkem Zeitdruck führt insbesondere zu schlechtem Design, zu unzureichender Schichtung und Verkapselung, zur Verstetigung von Übergangslösungen und zu entsprechend instabilen Implementierungen.
 
2.28 Multicore-Hardware (demnächst wahrscheinlich auch Manycore-Hardware) ist eine Realität, der wir uns stellen müssen. Die Vorstellung, Parallelität ausschließlich auf Ebenen unterhalb der Anwendungsentwicklung (z.B. nur auf Datenbank- und Betriebssystem-Ebene) zu nutzen, ist meines Erachtens nicht ausreichend. Auch die Anwendungsentwicklung wird nicht darum herumkommen, sich mit (semantischen) Fragen der Parallelisierbarkeit zu beschäftigen, um so tieferliegenden Schichten (die sich um die technischen Aspekte der Parallelisierung kümmern) entsprechende „Parallelisierungs-Hinweise“ geben zu können.
 
 
3 Thesen / „Glaubenssätze“ zu „sozialen Aspekten“ bei der Entwicklung & Wartung komplexer Software-Systeme  Artikelanfang   ► Seitenanfang
 
3.1.1 Es ist sinnvoll, Firmen und Behörden und ihre Untergliederungen im Allgemeinen und Software-entwickelnde Einheiten im Besonderen primär als soziale Organisationen und Software-Entwicklung primär als soziales Handeln zu begreifen, wenn verstanden werden soll, „wie Software-entwickelnde Einheiten als Unternehmungen wirklich funktionieren“.
 
3.1.2 Viele Aspekte des „Verhaltens“ von Organisationen und ihren Untergliederungen (bis hin zur Team- und Projektebene) lassen sich aus einer (rein) zweckrationalen Perspektive heraus nicht verstehen, sondern werden erst aus einer systemfunktionalen Betrachtungsweise heraus verständlich.
 
3.1.3 Um die Güte von Entscheidungen und Veränderungsprozessen innerhalb von Software-entwickelnden Einheiten zu verbessern, wäre es sinnvoll, die Funktionsweisen Software-entwickelnder Einheiten als Organisationen zunächst einmal möglichst genau zu beobachten und zu beschreiben und auf dieser Grundlage dann zu verstehen zu versuchen. Insbesondere wäre es sinnvoll, die (intendierten und nicht intendierten, positiven und negativen) Wirkungen von Entscheidungen / Veränderungen / Einflussfaktoren nachzuverfolgen und festzuhalten.
 
3.2 Allen Handlungen wohnt ein gewisses Maß an Inszenierung inne, und aus einer bestimmten Perspektive heraus ist es gar nicht möglich, den „inszenatorischen Aspekt“ von Handlungen sauber vom „inhaltlichen Kern“ von Handlungen zu unterscheiden. Dennoch zeichnen sich gerade institutionell eingebettete Handlungen oft durch ein relativ starkes Auseinanderklaffen von „Inszenierung“ und „inhaltlichem Kern“ aus. Ein solches Auseinanderklaffen ist zu vermeiden, da es die Glaubwürdigkeit von Handlungen und Akteuren zu diskreditieren geeignet ist.
 
3.3 Wenn wir verstehen wollen, wie Organisationen / Institutionen / Unternehmen funktionieren, und wenn wir gezielt Einfluss nehmen wollen auf deren Funktionsweisen, dann ist es nicht ausreichend, immer wieder primär am Verhalten der ManagerInnen gegenüber ihren MitarbeiterInnen anzusetzen. So wichtig ein reflektiertes Verhalten von Führungskräften ist: noch wichtiger ist es, zu verstehen, wie Gruppen, in denen ganz unterschiedliche Rollen ausgeprägt sind, funktionieren, sowohl in ihrem „Binnenleben“ als auch in ihrem Zusammenspiel mit anderen Gruppen (sei es entlang hierarchischer Strukturen, sei es quer zu diesen). Dies gilt gerade auch in Zeiten von Agile & Scrum, wo es um ein komplexes Zusammenspiel zwischen People Managern, Scrum Mastern, Product Ownern, ArchitektInnen, Wartungs-/Support-Zuständigen und schließlich den verschiedenen Typen von EntwicklerInnen in einem Scrum-Team geht.
 
3.4 Eine Matrixorganisation schafft in der Regel mehr Probleme, als sie löst. Matrixorganisationen sollten daher nicht als Default-Organisationsform angesetzt werden, sondern wohlbegründeten Ausnahmefällen vorbehalten bleiben.
 
3.5 Die direkten und indirekten Kosten von Reorganisationen (Arbeitsausfall durch Verunsicherung über bevorstehende Veränderungen, Frust über bestimmte Veränderungen, Auflösung etablierter Interaktions- und Arbeitsbeziehungen, Etablierung neuer Interaktions- und Arbeitsbeziehungen, Gewöhnung an neue Verhältnisse) werden oft unterschätzt. Insbesondere wenn Reorganisationen in relativ kurzen Zeitabständen aufeinander folgen und bis auf die unteren Ebenen durchschlagen, geht das stark zu Lasten der Effizienz.
 
3.6 Kontinuierliche enge Zusammenarbeit über mehrere Standorte hinweg ist in der Regel nicht sinnvoll. Die Bedeutung direkter, persönlicher Kommunikation von Angesicht zu Angesicht und ebenso die Möglichkeit, sich kurzfristig in kleinen Gruppen vor einem Whiteboard zu treffen, um offene Fragen zu diskutieren, wird oft stark unterschätzt. Kommen bei Standort-übergreifender Zusammenarbeit auch noch größere Zeitzonen-Unterschiede hinzu, wird die Arbeit noch ineffizienter. Projekte oder Bereiche mit
 
3.7 Regelmäßige, inhaltlich relativ ausführliche Meetings auf den verschiedenen Ebenen der Organisation (Projekt, Team, Abteilung) sind von großer Bedeutung, um alle MitarbeiterInnen auf einem gemeinsamen Informationsstand zu halten und dadurch auch einen Beitrag zur Ausbildung einer Projekt-/Team-/Abteilungs-Identität zu leisten. Allerdings empfinden viele EntwicklerInnen regelmäßige Treffen oft auch als „nervig“, weil sie das Gefühl haben, dass solche Treffen sie von ihrer „eigentlichen“ Entwicklungsarbeit abhalten. Diesem Widerspruch gilt es sich immer wieder neu zu stellen und immer wieder neu die richtige Balance zu finden zwischen einem Zuviel und einem Zuwenig an regelmäßigen Treffen. Im Zweifelsfall ist ein Zuviel an Information und Treffen aber weniger schädlich als ein Zuwenig.
 
3.8.1 Wenn all zu stark auf den individuellen Beitrag Einzelner zum Teamerfolg abgehoben wird, leidet darunter der (zukünftige) Teamerfolg. So richtig es ist, dass es erhebliche Unterschiede in den Fähigkeiten der MitarbeiterInnen gibt und dass sich dies auch in unterschiedlich großen Beiträgen zum Teamerfolg niederschlägt: Ohne die „durchschnittlichen“ Beiträge „gewöhnlicher“ MitarbeiterInnen können auch überdurchschnittliche Beiträge von „ÜberfliegerInnen“ keine Wirkung entfalten.
 
3.8.2 Ein Talent Management in der Form, wie es die meisten größeren Firmen praktizieren, ist kontraproduktiv. Es ist nicht hilfreich, einen kleinen Prozentsatz der MitarbeiterInnen als besonders leistungsfähig und leistungswillig einzuordnen (in diesem Zusammenhang wird oft von „Top Performern“ oder „Top Talents“ oder „Top Achievern“ gesprochen) und die große Mehrheit der MitarbeiterInnen als „DurchschnittsleisterInnen“ (und einige sogar als „SchlechtleisterInnen“) zu kategorisieren, denn erstens wiegt die durch ein solches Talent Management bedingte Demotivation vieler „DurchschnittsleisterInnen“ viel schwerer als eine dadurch bewirkte Motivation der „Top-Kaste“ (weil nämlich auch die „Top-Leute“ ohne hochmotivierte „DurchschnittsleisterInnen“ nur wenig zustande bringen können), und zweitens wird durch ein solches selektierendes Talent Management eine Konkurrenz um die wenigen freien Plätze in der Top-Kategorie befördert, die sich negativ auf eine kooperative kollegiale Zusammenarbeit und damit auf den Teamerfolg auswirkt.
 
3.8.3 Besonders fragwürdig sind „Low Performer“-Runden (euphemistisch auch als „Improver“-Runden bezeichnet), bei denen es darum geht, die 5–10% (vermeintlich) „schwächsten“ MitarbeiterInnen zu „identifizieren“ und einer „besonderen Behandlung“ zuzuführen.
 
3.8.4 ManagerInnen haben sehr wohl die kontinuierliche Aufgabe, darauf zu achten, dass ihre MitarbeiterInnen weder über- noch unterfordert sind, dass unterforderte MitarbeiterInnen neue, herausfordernde Aufgaben übertragen bekommen und überforderten MitarbeiterInnen bei der Bewältigung ihrer Aufgaben geholfen wird oder sie neue Aufgaben mit anderen, sie nicht überfordernden Anforderungen übertragen bekommen. (Genauso haben alle MitarbeiterInnen selbst die kontinuierliche Aufgabe, darauf zu achten, dass sie in ihrer Arbeit weder über- noch unterfordert sind.) Es ist sehr wohl sinnvoll, ManagerInnen (und MitarbeiterInnen) darin zu stärken (z.B. durch entsprechende Weiterbildungsmaßnahmen), dieser Verantwortung gerecht werden zu können und auch tatsächlich gerecht zu werden. Es ist aber nicht sinnvoll, diese zentrale Aufgabe von ManagerInnen (und MitarbeiterInnen) durch weitgehend formalisierte Prozesse lösen zu wollen.
 
3.9.1 Dementsprechend ist auch ein formalisiertes Performance Management nicht hilfreich. Regelmäßige Gespräche zwischen ManagerInnen und ihren MitarbeiterInnen sind wichtig, und es muss auch darauf geachtet werden, dass solchen Gesprächen die ihnen angemessene Bedeutung beigemessen wird, dass für solche Gespräch die notwendige Zeit aufgebracht wird und dass in diesen Gesprächen auch wirklich die relevanten Inhalte angesprochen werden, auch wenn dies manchmal schmerzhaft sein kann. So wenig wie beim Talent Management ist es aber auch beim Performance Management sinnvoll, einem formalisierten Prozess zu folgen. Insbesondere ist es nicht sinnvoll, alle MitarbeiterInnen regelmäßig zu benoten, z.B. indem sie in verschiedenen Dimensionen auf irgendwelchen Skalen (z.B. zwischen ++ und --) eingeordnet werden.
 
3.9.2 „Management by Objectives“, d.h. ein Ansatz, der davon ausgeht, dass jährliche Zielvereinbarungen zum einen sowie die vergütungsrelevante Bewertung von Zielerreichungen zum andern die zentralen Instrumente im Führungshandeln sind, ist kein geeignetes Führungsmodell für „WissensarbeiterInnen“, von denen gerade erwartet wird, dass sie sich schnell und flexibel auf veränderte Situationen einstellen.
 
3.9.3 Leistungsbewertungen sind letztlich immer subjektive Leistungseinschätzungen. Alle Versuche zur „Objektivierung“ von Leistungsbewertungen sind letztlich „Scheinobjektivierungen“. Dem Rechnung zu tragen heißt einerseits, sich mit der nicht hintergehbaren Subjektivität von Leistungsbewertungen bewusst auseinanderzusetzen und Leistungsbewertungen nicht objektiver erscheinen zu lassen, als sie es de facto sind, und andererseits, Leistungsbewertungen nicht überzubewerten und auf ein Mindestmaß zu beschränken.
 
3.10 „Pay for Performance“ darf nicht zur Ideologie überhöht werden. Auch wenn es durchaus angemessen ist, in einem gewissen Rahmen Gehaltsunterschiede zu machen, die abhängig sind von der Leistungseinschätzung des/der Personalverantwortlichen, darf dies weder bei den fixen noch bei den variablen Vergütungsbestandteilen dazu führen, den Aspekt einer angemessenen Teilhabe aller MitarbeiterInnen am Firmenerfolg zu vernachlässigen.
 
3.11.1 Der Nutzen von MitarbeiterInnen-Befragungen, die auf standardisierten Fragebögen beruhen und bei denen die MitarbeiterInnen im Wesentlichen entlang vorgegebener Dimensionen eine Einschätzung vornehmen, wird vielfach überschätzt. Hilfreicher wären in vielen Fällen offene Interviews, bei denen MitarbeiterInnen von sich heraus und in ihren eigenen Worten Perspektiven und Einschätzungen entwickeln können.
 
3.11.2 Es muss strikt getrennt werden zwischen Feedback-Instrumenten zum einen und Kontroll-/Bewertungs-Instrumenten zum andern. So ist es z.B. nicht sinnvoll, aus MitarbeiterInnen-Befragungen (gleich welcher Art) einerseits Anregungen für Verbesserungen ableiten zu wollen, andererseits die Ergebnisse solcher Befragungen zugleich aber auch zur Grundlage von Bewertungen, z.B. von ManagerInnen, zu machen. Werden Feedback-Instrumente zugleich auch als Kontroll-/Bewertungs-Instrumente genutzt, wird „taktisches“ Feedback gegeben (welches je nach Konstellation sowohl „zu gut“ als auch „zu schlecht“ ausfallen kann), und die Feedback-Ergebnisse sind kaum mehr „neutral“ auswertbar.
 
3.12.1 Eine kontinuierliche Weiterbildung aller MitarbeiterInnen ist von elementarer Bedeutung für Software-entwickelnde Einheiten. Die Budgets für interne und vor allem auch externe Weiterbildung sind dabei die verlässlichsten Indikatoren dafür, wie ernst das Thema „Weiterbildung“ wirklich genommen wird.
 
3.12.2 Alle MitarbeiterInnen sollten mindestens zwei Wochen pro Jahr an individuell ausgewählten Weiterbildungen teilnehmen, davon mindestens eine Woche pro Jahr an externen Weiterbildungen (um auf diese Weise einen gewissen Zufluss frischer Ideen von außen zu unterstützen). Zentrale Weiterbildungsveranstaltungen mit hohen TeilnehmerInnen-Zahlen (z.B. zentrale Informationstage oder zentrale Weiterbildungsveranstaltungen zu Qualitätsfrage) sind absolut sinnvoll und begrüßenswert, sollten aber nicht auf diese mindestens zwei Wochen individuell ausgewählte Weiterbildungsmaßnahmen pro Jahr angerechnet werden. Zusätzlich sollten auch auf der Ebene der Projekte, Teams, Abteilungen regelmäßig lokale Weiterbildungsmaßnahmen organisiert werden.
 
3.13 Im Hinblick auf Motivation, Kreativität und Effizienz ist es von großer Wichtigkeit, den einzelnen MitarbeiterInnen (aber auch den Teams auf unterer Ebene) möglichst viel Vertrauen entgegenzubringen, möglichst große Gestaltungsspielräume zu belassen, möglichst viel Verantwortung zu übertragen. Dies darf nicht immer wieder nur verlautbart, sondern muss in der gelebten Praxis auch umgesetzt werden. Kontrollmaßnahmen sowie formale Regelungen, die geeignet sind, Spielräume einzuschränken (wie dies z.B. für viele unternehmensinterne „Policies“ gilt), sollten auf das absolut unvermeidliche Maß zurückgefahren werden.
 
3.14 Bei der Gestaltung der Arbeitsbedingungen sollte alles dafür getan werden, Demotivation zu vermeiden und die intrinsische Motivation zu fördern, anstatt immer wieder stark auf extrinsische Motivationsfaktoren zu setzen.