Fehler in Software müssen verhindert werden – dazu ist Software heutzutage zu wichtig. Also müssen Softwareteams testen. Aber reicht das aus?

Für ein Problem gibt es immer mehr als eine Lösung. Softwaretests verhindern, dass Fehler in der Software negative Auswirkungen haben. Tests verhindern keine Fehler: Sie finden Fehler, bevor sie zu Problemen führen.

Performancetests sind besonders schwierig: Das Benutzerverhalten muss simuliert werden, die zu erwartenden Benutzerzahlen müssen bekannt sein, und es muss ein Testsystem geben, das produktionsnahe Leistung erreichen kann. Diese Anforderungen sind oft unrealistisch. Bei neuen Features kann das Benutzerverhalten noch gar nicht bekannt sein. Ein System mit produktionsnaher Performance aufzubauen, ist oft zu teuer und zu aufwendig.

Alternativen

Wie kann ein Team ohne Tests Performanceproblem finden, bevor sie zu Problemen führen? Das Team kann eine neue Version nur auf einem Teil der Server deployen. Wenn es ein Performanceproblem gibt, können die Server mit der alten Version die Last abarbeiten. Die neue Version kann wieder aus der Produktion genommen werden – ohne dass es negative Auswirkungen gab. Dieses Vorgehen heißt Canary Releasing.

Für dieses Vorgehen muss das Monitoring passende Werte liefern, damit ein Problem frühzeitig erkannt wird. Ebenso müssen das Deployment und das Rollback automatisiert sein, um schnell und zuverlässig zu reagieren. Also lohnt sich neben Testen eine Investition in Monitoring und Deployment.

Bei Performance ist dieser Ansatz immer sinnvoll, weil Performancetests allein keine ausreichende Sicherheit bieten. Aber auch bei fachlichen Fehlern kann ein solches Vorgehen eine Ergänzung oder sogar der bessere Ansatz sein. Beispielsweise lassen sich alte und neue Version parallel betreiben. Die neue Version läuft "blind" – also ohne Auswirkungen auf die Daten –, und Ergebnisse werden verglichen.

Weitere mögliche Maßnahmen

Weitere mögliche Maßnahmen: Software kann öfter in Produktion gebracht werden. So erfolgen Änderungen in kleineren Schritten und damit mit geringerem Risiko. Das ist die Idee von Continuous Delivery. Oder die Software wird in mehrere unabhängig deploybare Module ("Microservices") aufgeteilt. Auch das verringert das Risiko eines Deployments, weil nur ein kleiner Teil des Systems betroffen ist.

Also sorgt erst eine Kombination von Tests und anderen Maßnahmen für qualitativ hochwertige Software.

tl;dr

Tests sind nur eine Möglichkeit, um Probleme mit Software zu verhindern. Es gilt, Handlungsalternativen zu kennen und die effektivste auszuwählen.

Unternehmen wie Facebook leben von Software und entwickeln sehr große und komplexe Projekte. Wenn Vorgehen und Technologien so komplexe Probleme lösen – dann sicher auch die vergleichsweise einfachen Probleme anderer Unternehmen.

Facebook nutzt für die Entwicklung PHP. Kent Beck ist ein Software-Guru, Erfinder von eXtreme Programming, hat viel Zeit bei Facebook verbracht und begründet auf Quora die Wahl damit, dass PHP ein lokales Optimum darstellt. Facebook kontrolliert den kompletten Stack einschließlich aller Tools wie HHVM oder Hack und hat eine große PHP-Entwickler-Community. Mittlerweile hat das Unternehmen auch schon viel Geld in einen eigenen PHP-Stack investiert. Eine Migration würde viel Geld kosten – und das bei unklaren Vorteilen.

Aber Facebooks Wissen und Kontrolle über den PHP-Stack ist einmalig. Aus Facebooks Entscheidung kann man also nicht ableiten, dass PHP vor allem für große Codebasen sinnvoll ist.

MonoRepo

Der Facebook-Code ist eine große monolithische Codebasis. Ein solches MonoRepo für allen Code hat zum Beispiel den Vorteil, dass ein Entwickler in einem Commit eine Bibliothek und alle abhängigen Projekte ändern kann. Dann müssen aber im Extremfall die gesamten 8 GByte Sourcecode erneut übersetzt werden. Dazu sind komplexe Optimierungen nötig.

Zweifellos lösen diese Ansätze die Herausforderungen bei Facebook. Andere Unternehmen sollten aber vorsichtig sein, diese Ideen einfach zu übertragen. Firmen wie Facebook haben eine unglaublich große Zahl an Entwicklern und Commits. Eine einzige große Codebasis, die jeden Tag zehntausende Commits hat, ist ungewöhnlich. So etwas ist nur ein Problem von Facebook oder anderen Firmen dieser Größenordnung. Gleichzeitig hat Facebook die Möglichkeit, hunderte Entwickler nur an Werkzeugen arbeiten zu lassen. Viele Projekte haben insgesamt nicht so viele Entwickler.

Skaliert nicht

Also haben die meisten anderen Unternehmen weder die Möglichkeiten, solche Lösungen umzusetzen, noch die Probleme, die solche Lösungen erfordern.

Das gilt auch für die Technologien. Zwar bieten viele große Unternehmen wesentliche Teile ihrer Softwareinfrastruktur als Open-Source-Projekte an. Aber die Unternehmen haben direkten Zugriff auf deren Entwickler. Außerdem verdienen die Unternehmen nicht direkt mit den Projekten Geld. Sie haben oft kein so großes Interesse daran, die Nutzer der Projekte zufrieden zu stellen, wie Unternehmen, die von Open-Source-Projekten leben.

tl;dr

Große Unternehmen haben spezielle Probleme. Technologien oder Vorgehensweisen, die bei großen Unternehmen notwendig sind, müssen nicht unbedingt bei anderen Unternehmen vorteilhaft sein oder überhaupt funktionieren.

Ein wesentliches Design-Prinzip unter Node.js ist es, den Code getreu dem Motto "small is beautiful" in möglichst kleine, wiederverwendbare Packages zu strukturieren. Bei komplexeren Projekten kann das jedoch schnell unübersichtlich werden, wenn für jedes Package ein eigenes Git-Repository zu verwalten ist. Das Tool "Lerna" verspricht Abhilfe.

Wer unter Node.js oder allgemein in JavaScript ein komplexes Projekt entwickelt und seinen Code getreu dem vorgenannten Motto in viele kleine Packages strukturiert, landet recht schnell bei 50, 100 oder noch mehr Packages. Verwaltet man jedes davon in einem eigenen Git-Repository, artet das schnell in viel Konfigurationsarbeit aus: sei es, um Abhängigkeiten untereinander zu verwalten, Build-Prozesse zu organisieren oder das Deployment zu npm zu steuern.

Aus diesen Gründen strukturieren Entwickler bekannter Frameworks wie Angular[1], React[2], Meteor[3] und Ember[4] oder bekannter Tools wie Babel[5] und Jest[6] ihren Code mittlerweile in sogenannten Monorepositories[7], kurz Monorepos oder auch Multi-Package-Repositories. Die Idee: Statt jedes Package in einem eigenen Git-Repository vorzuhalten, bündelt man zusammengehörige Packages in einem einzelnen Repository.

Die Vorteile liegen auf der Hand: Zum einen muss man sich nicht mit mehreren Git-Repositories "herumschlagen", zum anderen lässt sich der Build-Prozess für alle Module stark vereinfachen und, wie wir gleich sehen werden, auch das Deployment zur npm-Registry. Ein Tool, das hierbei hilft, ist Lerna[8].

Installation

Ursprünglich Teil von Babel[9], ist Lerna mittlerweile ein eigenständiges Node.js-Package und kann wie gewohnt über den Package Manager npm als globale Abhängigkeit installiert werden:

$ npm install -g lerna

Anschließend kann das Tool über den Befehl lerna aufgerufen werden, wobei eine Reihe verschiedener Parameter zur Verfügung stehen:

• init: Initialisierung eines Multi-Package-Repositories
• bootstrap: Installation aller Abhängigkeiten der Packages
• publish: Veröffentlichen aller Packages auf npm
• updated: Überprüfen, welche Packages seit dem letzten Release geändert wurden
• import: Importieren eines Package aus externem Repository
• clean: Entfernen aller node_modules-Verzeichnisse in allen Packages
• diff: Vergleich von Packages mit vorigem Release
• run: Ausführen eines npm-Skripts in jedem Package
• exec: Ausführen eines Kommandozeilenbefehls in jedem Package
• ls: Auflisten aller Module

Initialisierung und Struktur

Ein Multi-Package-Repository definiert sich im Wesentlichen durch seine Struktur und über zwei globale Konfigurationsdateien: Zum einen über eine package.json-Datei, die Meta-Informationen für alle verwalteten Packages enthält, zum anderen über eine Konfigurationsdatei namens lerna.json, die wiederum Lerna-spezifische Meta-Informationen enthält. Die einzelnen Packages wiederum werden standardmäßig in einem Unterverzeichnis mit Namen packages einsortiert, sodass die Gesamtstruktur wie folgt aussieht:

multirepo/
  node_modules/
  packages/
    package1/
      node_modules/
      src/
      index.js
      package.json
    package2/
    package3/
    package4/
    package5/
    package6/
  package.json
  lerna.json

Diese Struktur kann man zwar manuell erzeugen. Alternativ steht aber auch wie oben schon erwähnt der Befehl lerna init zur Verfügung, der zumindest die beiden Konfigurationsdateien automatisch generiert:

$ git init multirepo
$ cd multirepo
$ lerna init

Dadurch wird zum einen das Modul Lerna als Abhängigkeit zu der package.json-Datei hinzugefügt (sofern dort noch nicht vorhanden) und zum anderen die Konfigurationsdatei lerna.json erzeugt. Zu Anfang sieht die Datei wie folgt aus und enthält die Versionsnummer der verwendeten Lerna-Bibliothek, eine Angabe darüber, unter welchem Verzeichnis die Packages liegen sowie eine Versionsnummer, die global für alle Packages gilt. Welche weiteren Konfigurationsmöglichkeiten es hier gibt, entnimmt man am besten der offiziellen Dokumentation[10].

{
  "lerna": "2.0.0-beta.38",
  "packages": [
    "packages/*"
  ],
  "version": "0.0.0"
}

Die Struktur der einzelnen Packages in einem Multi-Package-Repositories unterscheidet sich nicht von einem Package, das als Single-Package-Repository verwaltet wird. Das heißt beispielsweise, dass jedes Package weiterhin über seine eigene package.json-Datei verfügt und darüber zum Beispiel auch seine eigenen Abhängigkeiten definiert.

Für Abhängigkeiten hingegen, die nur während der Entwicklung benötigt werden (Eintrag "devDependencies" in package.json) ist es in den meisten Fällen sinnvoll, diese in der globalen package.json eines Multi-Package-Repositories anzugeben.

Das hat mehrere Vorteile: zum einen ist auf diese Weise sichergestellt, dass alle Packages die gleiche Version einer verwendeten Abhängigkeit haben. Zum anderen reduzieren sich dadurch sowohl die Installationszeit als auch der verwendete Speicherplatz für die entsprechende Abhängigkeit, da sie – logisch – nur einmal für alle Packages (und nicht einmal für jedes Package) installiert wird.

Bootstrapping und Deployment

Ein ebenfalls nützlicher Befehl ist lerna bootstrap. Dieser sorgt dafür, dass die Abhängigkeiten aller Packages installiert werden. Mit anderen Worten: Lerna ruft für jedes Package den Befehl npm install aus. Aber nicht nur das. Zusätzlich werden für alle Packages im Multi-Package-Repository, die als Abhängigkeit von einem anderen Package im Repository verwendet werden, symbolische Links erzeugt, was – Node.js-Entwickler werden das bestätigen – bei der Entwicklung enorm hilfreich ist. Zu guter Letzt wird dann noch für jedes Package der Befehl npm prepublish aufgerufen, wodurch die in den package.json-Dateien definierten "prepublish"-Skripte[11] ausgeführt werden.

Nimmt einem Lerna bis hierhin schon viel Arbeit ab, wird es bezüglich Deployment beziehungsweise Publishing noch besser. Der Befehl lerna publish sorgt dafür, dass die Versionsnummer für alle Packages, die sich seit dem letzten Release geändert haben, entsprechend hochgezählt wird. Dabei kann über einen kleinen Kommandozeilendialog ausgewählt werden, ob es sich um einen "Patch", einen "Minor Change", einen "Major Change" oder um einen "Custom Change" handelt (nett: Die jeweils neue Version wird in Klammern hinter der jeweiligen Auswahl angezeigt).

Aber nicht nur das: lerna publish sorgt weiterhin dafür, dass entsprechende Tags und Commits für die neue Version in Git erzeugt und alle Packages separat bei npm publiziert werden.

Fazit

Die Bibliothek Lerna hilft bei komplexen JavaScript-Projekten, die aus mehreren zusammengehörigen Packages bestehen, den Überblick zu behalten: Sie erleichtert die Konfiguration des Build-Prozesses, die Verwaltung über Git und das Publishing zu der npm-Registry. Als Empfehlung sollte jeder Node.js-Entwickler, der mit komplexen Projekten oder einer komplexen Package-/Repository-Struktur zu "kämpfen" hat, bei Gelegenheit mal einen Blick riskieren. Eventuell lohnt sich ja der Umstieg.

Fehler in Software müssen verhindert werden – dazu ist Software heutzutage zu wichtig. Also müssen Softwareteams testen. Aber reicht das aus?

Für ein Problem gibt es immer mehr als eine Lösung. Softwaretests verhindern, dass Fehler in der Software negative Auswirkungen haben. Tests verhindern keine Fehler: Sie finden Fehler, bevor sie zu Problemen führen.

Performancetests sind besonders schwierig: Das Benutzerverhalten muss simuliert werden, die zu erwartenden Benutzerzahlen müssen bekannt sein, und es muss ein Testsystem geben, das produktionsnahe Leistung erreichen kann. Diese Anforderungen sind oft unrealistisch. Bei neuen Features kann das Benutzerverhalten noch gar nicht bekannt sein. Ein System mit produktionsnaher Performance aufzubauen, ist oft zu teuer und zu aufwendig.

Alternativen

Wie kann ein Team ohne Tests Performanceproblem finden, bevor sie zu Problemen führen? Das Team kann eine neue Version nur auf einem Teil der Server deployen. Wenn es ein Performanceproblem gibt, können die Server mit der alten Version die Last abarbeiten. Die neue Version kann wieder aus der Produktion genommen werden – ohne dass es negative Auswirkungen gab. Dieses Vorgehen heißt Canary Releasing.

Für dieses Vorgehen muss das Monitoring passende Werte liefern, damit ein Problem frühzeitig erkannt wird. Ebenso müssen das Deployment und das Rollback automatisiert sein, um schnell und zuverlässig zu reagieren. Also lohnt sich neben Testen eine Investition in Monitoring und Deployment.

Bei Performance ist dieser Ansatz immer sinnvoll, weil Performancetests allein keine ausreichende Sicherheit bieten. Aber auch bei fachlichen Fehlern kann ein solches Vorgehen eine Ergänzung oder sogar der bessere Ansatz sein. Beispielsweise lassen sich alte und neue Version parallel betreiben. Die neue Version läuft "blind" – also ohne Auswirkungen auf die Daten –, und Ergebnisse werden verglichen.

Weitere mögliche Maßnahmen

Weitere mögliche Maßnahmen: Software kann öfter in Produktion gebracht werden. So erfolgen Änderungen in kleineren Schritten und damit mit geringerem Risiko. Das ist die Idee von Continuous Delivery. Oder die Software wird in mehrere unabhängig deploybare Module ("Microservices") aufgeteilt. Auch das verringert das Risiko eines Deployments, weil nur ein kleiner Teil des Systems betroffen ist.

Also sorgt erst eine Kombination von Tests und anderen Maßnahmen für qualitativ hochwertige Software.

tl;dr

Tests sind nur eine Möglichkeit, um Probleme mit Software zu verhindern. Es gilt, Handlungsalternativen zu kennen und die effektivste auszuwählen.

Softwareentwicklung ist eine sehr wichtige Branche. Aber können wir die Welt verbessern? Und wenn ja, wie? Tatsächlich können wir einiges dazu beitragen!

Die Statistik[1] besagt, dass in der IT die Arbeitslosigkeit relativ gering ist. Oft ist das Gehalt auch sehr gut. Allerdings sind in unserer Branche einige Gruppen wie Frauen, Menschen mit Behinderung oder verschiedene ethnische Hintergründe unterrepräsentiert. Also haben nicht alle den gleichen Zugang zu einer solchen Karriere.

Aber es geht nicht nur darum: Teams mit einer höheren Diversifikation können Probleme besser lösen. Es gibt mehr Sichten auf das Problem, und so betrachtet das Team mehr Lösungswege. Die Software wird auf diese Weise vielseitiger, und das Team bringt Produkte hervor, die für breitere Schichten interessant sind oder Probleme lösen, die einer homogenen Gruppe gar nicht bewusst sind.

Genau da können wir alle unterstützen. Indem wir mehr und andere Leute an die Softwareentwicklung heranführen, profitieren wir auch selber. Man lernt viel darüber, wie man Wissen vermitteln kann. Man reflektiert das eigene Wissen. Und Fragen können einen dazu bringen, Dinge aus einer ganz anderen Perspektive zu sehen. Wissensvermittlung ist in unserem Beruf eine der wichtigsten Tätigkeiten. Und am Ende macht es auch Spaß, jemandem etwas beizubringen.

Es gibt viele Initiativen, die Treffen organisieren, in denen Menschen anderen Menschen etwas beibringen. Diese Initiativen gibt es in ganz Deutschland und mit unterschiedlichen Zielgruppen.

Kinder

Schon Kindern kann man etwas über Programmieren beibringen. Einige Initiativen sind:

• CoderDojo[2] bietet für Kinder und Jugendliche zwischen 7 und 17 Jahren die Möglichkeit, einen Einstieg in die Programmierung zu finden. Die konkrete Ausgestaltung variiert zwischen den verschiedenen Dojos.
• Devoxx4Kids[3] führt drei Workshops zu Internet of Things, Robotik und Programmierung für unterschiedliche Altersstufen durch.
• Die Hacker School[4] wendet sich mit verschiedenen Kursen an Kinder zwischen 11 und 18 Jahren.
• Der Teckids e.V.[5] hat verschiedene Initiativen, um Kinder unter anderem an Programmierung heranzuführen.
• Jugend hackt[6] ist ein Programm zur Förderung des Programmiernachwuchses im deutschsprachigen Raum mit dem Motto "Mit Code die Welt verbessern".
• Das Calliope-Projekt[7] hat als Ziel, jedem Schulkind in Deutschland ab der 3. Klasse einen spielerischen Zugang zur digitalen Welt zu ermöglichen. Dazu bieten es Hardware, Software und weitere Materialien an.
• CodeWeekEU[8] bietet sehr viele unterschiedliche Angebote – meistens für Kinder.

Unterrepräsentierte Gruppen

Wie schon erwähnt, sind viele Gruppen in unserer Branche unterrepräsentiert. Es gibt einige Initiativen, die sich zum Ziel gesetzt haben, das zu ändern:

• RailsGirls[9] bietet typischerweise eintägige Workshops für Frauen an, um den Einstieg die Web-Entwicklung mit Ruby on Rails zu erlernen. Sie veranstalten unter anderem auch den RailsGirls Summer of Code[10]. Es gibt auch einige beeindruckende Erfolgsgeschichten[11].
• Unicorns in Tech[12] ist ein Netzwerk für LGBTI (Lesben, Schwule, Bisexuellen, Trans- und Inter-Menschen) in der IT.
• Refugees on Rails[13] hat als Ziel, Flüchtlingen Ruby on Rails beizubringen.
• Die DjangoGirls[14] haben ein ähnliches Angebot wie die Rails Girls mit dem Python-Webframework Django.
• Bei der ClojureBridge[15] steht die Vermittlung der JVM-basierten funktionalen Progammiersprache Clojure an unterrepräsentierte Gruppen im Mittelpunkt.
• Die ScalaBridge[16] bietet Workshops für Frauen in der JVM-Programmiersprache Scala an.
• Die Women Who Go[17] organisieren Meetups für Frauen, die an der Programmiersprache Go interessiert sind.
• Die informatica feminale[18] ist ein internationales Sommerstudium für Frauen in der Informatik.
• CodeGirls[19] in Leipzig bieten Unterstützung bei allem, was mit Webentwicklung und -design zu tun hat.
• codebar[20] unterstützt Unterrepräsentierten beim Erlernen des Programmierens.
• Women who Code[21] hilft Frauen bei der Karriere in der Softwareentwicklung

Weitere Initiativen

Es gibt auch Initiativen, die sich ganz allgemein zum Ziel gesetzt haben, Wissen über Softwareentwicklung weiter zu verbreiten:

• Die NodeSchool[22] vermittelt Wissen zur Webentwicklung mit Workshop.
• Hackerspaces[23] laden dazu ein, voneinander zu lernen und gemeinsam Projekte anzugehen.
  
• Heart of Code [24]ist ein Hackerspace für Frauen in Berlin.
• HAEQS[25] ist ein queer-feministischer Hackerspace ebenfalls in Berlin.
• Die OpenTechSchool[26] führt verschiedenen Workshops und andere Formate wie Co-Learning-Treffen durch, um verschiedene Technologien im Softwarebereich zu lernen.
• freeCodeCamp[27] bietet kostenlose Online-Kurse, um Programmieren zu lernen.

Und nun?

Jeder kann helfen. Es gibt verschiedene Möglichkeiten:

• Man kann selber an den Initiativen teilnehmen – als Coach aber auch, um selbst etwas zu lernen.
• Und man kann andere auf die Initiativen aufmerksam machen.

Tatsächlich gibt es einige, die durch solche Initiativen eine Karriere im Bereich Softwareentwicklung gestartet haben. Mitmachen und mithelfen lohnt sich also!

PS: Danke an meine innoQ-Kollegen Pedro LaFuente Blanco, Lucas Dohmen, Christoph Iserlohn, Christine Koppelt, Ute Mayer, Stefan Tilkov und Daniel Westheide für die Hinweise auf einigen der Initiativen. Ohne sie wäre der Beitrag vermutlich nur halb so lang.

PPS: Unter ewolff.github.io/bildungsinitiativen/[28] findet sich die Liste der Initiativen auch auf GitHub. Jeder kann unter github.com/ewolff/bildungsinitiativen/[29] den Quellcode der Website einsehen und selbst Änderungen als Pull Request einreichen – man kann sogar im Browser Ergänzungen vornehmen. Wenn also eine Initiative fehlt: Gerne dort eintragen – oder unter dem Artikel einen Kommentar hinterlassen.

tl:dr

Initiativen u.a. für Kinder und unterrepräsentierte Gruppen ermöglichen einen einfacheren Zugang zu einer Karriere in der Softwareentwicklung und stärken unsere Branche. Daher: Mitmachen und das Wissen um die Initiativen weiterverbreiten!

Selbstbestimmte Teams sind produktiver, diese Erkenntnis ist alles – nur nicht neu.

Immer wieder beschäftige ich mich mit Ansätzen und Organisationsformen, um besser verstehen zu können, was uns eigentlich oft daran hindert, eine Veränderung (wie Agilität) erfolgreich und nachhaltig umzusetzen. Dabei bin über den sogenannten soziotechnischen Ansatz gestolpert, der bereits in den 50er-Jahren entwickelt wurde. Dieser gründet sich auf der Erkenntnis, dass soziotechnische Systeme vor allem deswegen langfristiger und nachhaltiger ausgerichtet sind, da sie die Organisation ganzheitlich betrachten, das heißt sowohl den menschlichen/sozialen Aspekt als auch den technischen/wirtschaftlichen.

Mittels unterschiedlicher Forschungen und empirischen Untersuchungen konnte man nachweisen, dass teilautonome, selbstbestimmte Arbeitsgruppen produktiver sind, wenn ihnen die Verantwortung für größere, zusammenhängende Aufgaben übertragen werden und sie diese dann selbstorganisierend bearbeiten können. Im Vergleich dazu schnitten die Gruppen schlechter ab, bei denen die Aufgaben erst in kleinere Funktionen untergliedert und diese dann an einzelne Mitarbeiter übergeben wurden, die dann auch lediglich für diesen Funktionsteil zuständig waren (Stichwort: Taylorismus). Weiterhin wurde erkannt, dass bei den teilautonomen und selbstbestimmt arbeitenden Gruppen eher Generalisten benötigt werden, die sich gegenseitig vertreten können.

Diese gegenseitige Vertretung trug dazu bei, dass alle voneinander lernen konnten, wodurch sich auch nachweislich die intrinsische Motivation erhöhte. Außerdem wurden diese Gruppen dadurch in die Lage versetzt, ständig (kleine) Verbesserungen bezüglich der Umsetzung der Aufgaben vorzunehmen. Der organisatorische Nutzen davon war (neben der eben angesprochenen höheren Motivation und größeren Zufriedenheit der Mitarbeiter) vor allem auch eine größere Flexibilität, Qualität, Innovationsfähigkeit und eben auch Produktivität.

Und die IT?

Dies wurde, wie gesagt, vor circa 70 Jahren erkannt. Zu dieser Zeit steckte die IT noch in den Kinderschuhen, vor allem aber die Softwareentwicklung in Teams. Und obwohl "wir" damals eine neue Disziplin begründeten und keine echten Altlasten hatten, waren wir dennoch der Ansicht, dass es sinnvoller wäre, tayloristisch vorzugehen. Das heißt, die Arbeit sollte funktional untergliedert und an einzelne Mitarbeiter übergeben werden, wie das unter anderem bei einem linearen Vorgehen zum Beispiel nach Wasserfall üblich ist. Das heißt, unser Verständnis, wie Arbeit zu bewältigen ist, basiert(e) auf Überlegungen aus dem Ende des vorletzten/Beginn des letzten Jahrhunderts.

Heutzutage, unter anderem mit dem Siegeszug der Agilität, fällt uns "plötzlich" ein, dass die Übergabe von größeren zusammenhängenden Aufgaben an selbstorganisierende Teams viel erfolgreicher sei. Ich frage mich, wieso haben wir 50 Jahre benötigt – das Agile Manifest ist ja mittlerweile auch schon 16 Jahre alt – bis wir das erkannt haben?

Ständiges Lernen ist gerade in der IT-Branche wichtig. Ständig gibt es neue Technologien. Was sollen wir also lernen und anders machen? Sind Technologien wirklich entscheidend?

Die Arbeit in der IT-Branche ist auch deswegen interessant, weil es ständig etwas zu lernen gibt. Wir lernen viel von den großen der Branche – beispielsweise bei der Cloud von Amazon oder bei Microservices von Netflix. Aber setzten wir wirklich das Wichtigste um?

• Durch die Cloud können Amazons Teams Skalierbarkeit viel einfacher umsetzen und aus einem umfangreichen Technologie-Schatz auswählen. Das war schon Thema eines anderenBlog-Beitrags [1]. So können kleine Teams überhaupt produktiv Software entwickeln. Wie die Teams ihre Ziele erreichen, bleibt weitgehend ihnen überlassen. Sie können eine der Datenbanken aus der Cloud nutzen. Dann müssen sie sich um Backup oder Disaster Recovery nicht kümmern. Oder sie installieren eine eigene Datenbank. Das kann zu technischen Vorteilen führen – dann müssen die Teams aber auch den Betrieb übernehmen. Wofür sie sich entscheiden, ist ihnen überlassen.
• Ebenso ermöglichen Microservices den Teams eine weitgehend unabhängige Entwicklung und eigene Technologie-Entscheidungen, weil jeder Microservice andere nutzen kann. Außerdem ist das Deployment unabhängig, sodass sich neue Features unabhängig von anderen Teams in Produktion bringen lassen. So können die Teams vieles selbst entscheiden und umsetzten.

Die Amazon-Cloud und Microservices sind also technische Maßnahmen, um Selbstorganisation zu ermöglichen.

Technologie ermöglicht Organisationsänderungen

Viele Unternehmen nutzen Cloud und Microservices – aber nur als Technologie. So bringen die Ansätze nicht den vollen Nutzen. Schlimmer: Es werden die Auswirkungen moderner Organisation kopiert, die Organisation selbst wird aber nicht modernisiert. Das reduziert den Nutzen und wird die Adaption weiterer Technologien verkomplizieren.

Das Wissen darüber, wie erfolgreiche moderne Organisationen funktionieren, ist gut beschrieben. Eric Schmidt war lange CEO von Google und hat in seinem Buch "How Google Works" die wesentlichen Eckpunkte dargestellt. Es beschreibt Strategie, Kultur, aber auch den Einstellungsprozess. Ein wesentlicher Punkt: Manager ermöglichen und fördern Selbstorganisation.

Manchmal heißt es, dass diese Ansätze auf andere Unternehmen nicht passen, weil Google, Amazon oder Netflix ja Start-ups sind. Tatsächlich sind diese Unternehmen gemessen am Umsatz, an der Mitarbeiterzahl, am Gewinn und auch an ihrem Alter keine Start-ups mehr. Google beziehungsweise Alphabet ist nach Börsenkapitalisierung das zweitgrößte Unternehmen der Welt.

Außerdem konkurrieren diese Unternehmen mittlerweile mit klassischen Unternehmen. Im Bereich autonom fahrender Autos steht die klassische Autoindustrie beispielsweise mit Google im Wettbewerb. Also sollten auch wir Techniker mehr Wert auf den kulturellen Wandel legen – viel mehr als auf neue Technologien.

tl;dr

Nicht die neusten Technologien, sondern eine andere Organisation ist Kern erfolgreicher Unternehmen und von Microservices, Cloud usw. Die Organisation sollte kopiert werden – nicht nur die Technologien.

PS: Danke an den innoQ-Kollegen Michael Vitz für die Diskussion über eine frühe Version des Blog-Beitrags.

Neulich nach dem Yoga erzählt eine Teilnehmerin lautstark davon, dass ihr Sohn jetzt tatsächlich Informatik studieren würde.

Ich brauchte erst eine ganze Zeit, bis mir klar war, dass ihre Lautstärke nicht daher kam, dass sie darauf super stolz sei, sondern dass sie es ganz furchtbar finde, dass ihr Sohn jetzt Informatiker werden möchte.

Wir sind in dieser Yogaklasse eine sehr kleine Gruppe (maximal 6 Personen), und die meisten wissen, dass ich ITlerin bin. Diese Teilnehmerin hatte das aber anscheinend verdrängt. Natürlich schauten mich jetzt alle anderen an. Erst mal drückte ich meine Begeisterung aus: "Das ist ja super, wir brauchen eh mehr ITler." Dann fragte ich nach, was denn so furchtbar wäre. Sie antwortete zunächst mit einem Beispiel, das nicht auf meine Frage einging, sondern ihren Unglauben auf eine für mich lustige Art untermauerte:

"Dann waren wir in der Stadt, und mein Sohn wollte unbedingt noch ein Mathematikbuch für das Studium kaufen. Als ich das Buch gesehen habe – ein richtig richtig dickes Buch –, hatte ich schon meine Zweifel. Das schaut der sich ja im Leben nicht an. Zu Hause dann, das Buch war noch eingeschweißt, habe ich mir genau gemerkt, wo er das Buch hingelegt hat. Ich war mir sicher, dass es auch in zwei Monaten exakt an der Stelle (und eingeschweißt) liegen wird. Aber nicht zu fassen, bereits am Abend war das Buch ausgepackt, und er schaute tatsächlich ausgiebig in das Buch. Das ist doch schrecklich!"

Ich kam wieder auf meine Frage zurück, was denn so schrecklich wäre? Die Hauptantwort war, dass er wohl gerne Computerspiele spielt und jetzt mit dem Studium dann ja nur noch in den Monitor starren und sich nicht mehr mit anderen Menschen auseinandersetzen würde. Mein Einwand, dass er seinem Hobby Computerspiele vermutlich auch bei einer anderen Studienwahl weiter frönen würde. Dass auch bei vielen anderen Studiengängen die Arbeit am Rechner unvermeidbar wäre, ließ sie nicht gelten.

Allerdings hörte sie mir staunend zu, als ich meinte, dass ITler üblicherweise im Team und nicht alleine arbeiten würden. Womit sie dann zu ihrer eigentlichen Sorge kam – ob er denn mit diesem Studiengang eine Chance auf einen Job hätte? ...

Dieses Gespräch hat mich wieder einmal darin bestätigt, wie schlecht "wir" im Vermarkten und damit im Aufbau einer guten (!) Reputation [1] sind. Und obwohl sich besagter Sohn für die IT entschieden hat, ist es ja nicht so, dass die Studienzahlen für IT durch die Decke gehen und dieses Missverständnis ein Generationenproblem ist. Aus diesem Grund sind Aktionen wie die Münchner Erklärung [2] (auch die Initiative dazu auf der letzten OOP [3]) wichtig, aber lange nicht ausreichend. Das heißt, "dieser Weg wird kein leichter sein".

Bislang gibt es für das Teilen von Inhalten zwischen mobilen Webanwendungen keinen einheitlichen Ansatz. Doch dies könnte sich bald ändern, denn bei der Web Incubator Community Group [1] macht man sich bereits Gedanken über entsprechende Web APIs: Über die Web Share API [2] soll das Teilen von Inhalten möglich sein, über die Web Share Target API [3] das Empfangen von Inhalten.

Beide genannten APIs befinden sich derzeit in einem noch frühen Stadium und werden noch in keiner offiziellen Version der großen Browser unterstützt. Allerdings lässt sich zumindest die Web Share API über den sogenannten Origin Trial von Google testen (der im Allgemeinen dem Chrome-Entwicklerteam dazu dient, Entwickler-Feedback bei der Implementierung neuer APIs zu bekommen). Registriert man sich dort, erhält man ein spezielles Token, nach dessen Einbau in die eigene Webanwendung die API auf Android-Geräten über Chrome Beta [4] geprüft werden kann:

Offiziell soll die Web Share API dann mit Version 55 Einzug in Chrome erhalten.

Die Web Share API

Wie bereits gesagt ist das Ziel der Web Share API [5], einen einheitlichen Weg zu schaffen, über den Inhalte (im folgenden "Ressourcen" genannt) zwischen mobilen Anwendungen geteilt werden können. Die API ist in seiner aktuellen Form relativ übersichtlich, zumal nur die beiden Interfaces Navigator und WorkerNavigator um eine Methode share() erweitert werden sollen. Feature Detection könnte daher beispielsweise wie folgt aussehen:

if(navigator.share === undefined) {
  console.error('Web Share API wird nicht unterstützt.');
} else {
  console.log('Web Share API wird unterstützt.');
}

Als Parameter erwartet die Methode share() ein Objekt vom Typ ShareData, das wiederum drei Eigenschaften haben kann:

• title: Titel der Ressource, die geteilt wird
• text: Text, über den sich eine zusätzliche Beschreibung der Ressource angeben lässt
• url: URL zu der Ressource, die geteilt wird
  

Außerdem ist geplant, auch die Angabe von Bilddaten beziehungsweise Blobs zu ermöglichen. Alle Eigenschaften sind optional, allerdings muss mindestens eine im Objekt enthalten sein.

let shareData =
{
  title: document.title,
  text: 'Die erste mit der Web Share API geteilte Ressource.',
  url: window.location.href
}

Als Rückgabewert erhält man von der Methode share() ein Promise-Objekt, auf dem sich wie gewohnt Callback-Funktionen definieren lassen:

navigator
  .share(shareData)
  .then(() => {
    console.log('Erfolgreich geteilt');
  })
  .catch(error => {
    console.log('Fehler beim Teilen: ', error)
  });

Die über then() angegebene Callback-Funktion wird aufgerufen, wenn der Nutzer eine Anwendung (bzw. "Share Target") ausgewählt hat, zu der die Ressource geteilt werden soll und die Ressource von dieser Anwendung ohne Fehler akzeptiert wurde. Im Fehlerfall wird entsprechend die über catch() definierte Callback-Funktion aufgerufen, wobei Fehler beispielsweise dann auftreten, wenn

1. die geteilte Ressource beziehungsweise im ShareData-Objekt übermittelte Daten fehlerhaft sind,
   
2. keine passende Anwendung gefunden wurde, die die Ressource entgegennimmt,
   
3. der Nutzer keine Anwendung auswählt beziehungsweise die Auswahl abbricht oder
   
4. die Ressource nicht erfolgreich zu der ausgewählten Anwendung übermittelt werden konnte.

"Share Targets" können zum einen vorhandene Dienste wie die Zwischenablage sein, zum anderen native Anwendungen wie Facebook oder Twitter, aber auch andere Webanwendungen, und zwar solche, die sich über die Web Share Target API für das Empfangen geteilter Inhalte registriert haben.

Die Web Share Target API

Während die Web Share API es ermöglichen soll, Inhalte zu teilen, soll es über die Web Share Target API [15] möglich sein, (von anderen Anwendungen) geteilte Inhalte entgegenzunehmen. Als Voraussetzung muss der jeweilige Browser dabei sowohl die Service Worker API [16] als auch die Web App Manifest API [17] unterstützen.

Eine Anwendung, die geteilte Inhalte entgegennehmen soll (wie gesagt auch "Share Target" genannt), registriert sich entweder über die Methode addEventListener() oder über den Event-Handler onshare für das share-Event:

navigator.actions.addEventListener('share', handler);

Empfangene Events sind vom Type ShareEvent und ermöglichen wiederum den Zugriff auf das jeweilige ShareData-Objekt:

const handler = event => {
  let shareData = event.data;
  console.log(shareData.title);
  console.log(shareData.text);
  console.log(shareData.url);
}

Die Daten innerhalb des SharedData-Objekts können je nach Zielanwendung unterschiedliche Verwendung finden, beispielsweise ließe sich bei einem E-Mail-Client als "Share Target" der Inhalt der Eigenschaft title als Betreff der E-Mail und die Kombination aus text und url als Inhalt der E-Mail verwenden, während bei einem Text Messenger der Inhalt von title ignoriert und dagegen nur eine Kombination aus text und url verwendet werden könnte:

const emailHandler = event => {
  let data = event.data;
  let subject = data.title;
  let content = `${data.text} ${data.url}`;
  composeEmail(subject, content);
}
const textMessengerHandler = event => {
  let content = `${data.text} ${data.url}`;
  composeMessage(content);
}

Fazit

Die Web Share API und die Web Share Target API definieren Schnittstellen zum Teilen von Inhalten zwischen mobilen Anwendungen. Derzeit werden beide APIs noch von keinem Browser unterstützt, die Web Share API lässt sich aber wie geschildert in Chrome Beta unter Android testen.