Kaufen oder selber machen?

Entwicklungsteams stehen regelmäßig vor der Frage, ob ein Stück Software eingekauft oder selbst gemacht werden sollte. Diese Frage stellt sich sogar nicht nur Softwareentwicklern sondern jedem Menschen. Mache ich etwas selbst oder lasse ich es einen Experten machen? Bin ich der Experte oder ist der andere der Experte? Investiere ich Zeit und spare Geld oder investiere ich Geld und spare Zeit? Soziologie und die eigene Weltanschauung spielen bei der Beantwortung dieser Fragen und bei Entscheidungen eine große Rolle.

Um in der Welt der Softwareentwicklung zu bleiben, ist hier ein kleines Beispiel. Es geht um ein Web-Template. Es kann entweder ein fertiges Template gekauft werden oder man kann das Template selber bauen. Zunächst können einmal die Vor- und Nachteile beider Alternativen gegenübergestellt werden.

Kaufen

Vorteile

  • Das Template ist bereits fertig und kann sofort verwendet werden. Bei Bedarf kann es noch ein wenig angepasst werden, aber es ist bereits vollständig und umfangreich.
  • Das Template ist professionell gestaltet. Design, Layout und Look & Feel sind konsequent und kongruent.

Nachteile

  • Manche Komponenten sind nicht gut genug. Es gibt bessere Lösungen für Inputs, Tabellen und Charts.
  • Das Template ist schwergewichtig. Es enthält viele Komponenten und Funktionen, die gar nicht gebraucht werden.

Selber bauen

Vorteile

  • Ein eigenes Template ist maximal flexibel. Es können beliebige Komponenten verwendet werden.
  • Ein eigenes Template ist leichtgewichtig. Es enthält nur genau die Funktionen und Komponenten, die benötigt werden.

Nachteile

  • Ein eigenes Template muss erstmal entwickelt werden. Es entsteht Basisaufwand, der leicht unterschätzt wird.
  • Ein eigenes Template ist lange unvollständig. Vor allem wenn die Lösung in Design, Layout, Responsiveness und Look & Feel vergleichbar sein soll.

In dieser Gegenüberstellung kann der Begriff “Template” durch “Lösung” ersetzen werden. Das Schema bleibt gleich.

Eigene Meinung

Um maximal produktiv zu sein, würde ich jederzeit Geld in Zeit eintauschen. Um Zeit zu sparen bin ich bereit Geld zu investieren. Natürlich muss der Preis verhältnismäßig sein, aber darum geht es hier nicht. Die Nachteile einer gekauften Lösung sind schnell kompensiert. Unzulängliche Komponenten können durch bessere ersetzt werden. Nicht verwendete Funktionen können entfernt und das Template somit leichtgewichtiger gemacht werden. Diese Anpassungen sind unkompliziert und schnell. Es war schon immer leichter Dinge wegzulassen, als sie neu zu schreiben. Dadurch werden die Vorteile der Eigenentwicklung relativiert.

Wir sollten anfangen, an unseren USPs zu arbeiten statt uns an 0815-Basisentwicklung aufzuhalten. Wir neigen schnell dazu alles selber machen zu wollen. Manche Dinge müssen leider aus technischen, fachlichen und rechtlichen Gründen selbst gemacht werden. Da können dann keine fertigen Lösungen verwendet werden. Aber es gibt auch viele andere Dinge, bei denen von fertigen Lösungen profitiert werden könnte. Oft wird dort dann allerdings auch gerne auf den Produktivitäts-Boost verzichtet und die Lösung ebenfalls selbst gebaut.
Das ist das klassische Not Invented Here Syndrome. Man glaubt, dass die Eigenentwicklung besser, kontrollierter und schneller erfolgt als die bestehende. Verhaltensforscher führen viele Gründe für die Abneigung gegenüber Bestehendem an. Die prominentesten Gründe sind Mangel an Verständnis der bestehende Lösung und die Unwilligkeit, die Arbeit anderer anzuerkennen oder zu schätzen. Leslie Hannah führt dieses soziale Phänomen sogar auf eine Form des Tribalismus zurück.

Entscheidung

Am Ende des Tages steht eine Entscheidung. Entscheidungen müssen uns in die Lage versetzen, schnell und gut handeln zu können. Natürlich können wir alles mögliche entscheiden, aber wenn wir das Entschiedene nicht umsetzen können, ist die Entscheidung hinderlich und lähmend. Die Entscheidung “Kaufen” oder “Selber bauen” kann also nicht sinnvoll von oben entschieden werden. Deswegen müssen diejenigen, die viel mit dem Ergebnis arbeiten werden, auch aktiv mitentscheiden. Diejenigen, die wenig oder gar nicht mit dem Ergebnis arbeiten, dürfen auch nur wenig mitentscheiden. Was aber sehr wohl vorgegeben werden kann, sind Anforderungen und Budget. In diesem Kontext ist es dann die Verantwortung der Entwickler, die Ressourcen nicht zu verschwenden und die beste technische Lösung zu finden.

Advertisements

STP LabsDay 2018

Innovation wird heutzutage sehr groß geschrieben und deswegen veranstaltet STP regelmäßg den STP LabsDay. Am vergangenen Donnerstag und Freitag (26. und 27. April 2018) habe ich wieder an diesem internen 24h-Hackathon teilgenommen. Während der Arbeitszeit haben wir an diesen zwei Tagen die Gelegenheit, eine neue Idee auszuprobieren. STP übernimmt an beiden Tagen komplett die Verpflegung und Marketing hat uns wieder mit einem stylischen Geschenk überrascht. Beste Voraussetzungen für zwei Tage Innovationsarbeit.

Aktuell beschäftigt mich das Thema “Intelligent Cloud & Intelligent Edge”, sodass ich in diesem Jahr unbedingt etwas mit Cloud und Web machen wollte. Aber nicht einfach nur das nächste Angular oder Aurelia Projekt. Ich wollte Bleeding Edge Web Technologien ausprobieren. Es musste also unbedingt eine Progressive Web App sein, am besten in Verbindung mit Push Notifications. Ein Use Case ist mir auch sofort eingefallen: Kundenbenachrichtigung, egal ob der Kunde ein Gläubiger oder ein anderer Mandant ist. Das Projekt Mandate Updates hatte begonnen. Glücklicherweise konnte ich einen meiner Kollegen für dieses Szenario und die erwähnten Technologien begeistern und somit einen Partner für mein LabsDay-Projekt gewinnen. Es gibt nämlich nur eine einzige LabsDay-Regel: man muss mindestens zu zweit sein.

Am Donnerstag um 11 Uhr ging es endlich los. Nachdem wir uns über den Umfang des Projekts im Klaren waren, haben wir uns aufgeteilt. Mein Kollege hat sich auf das mit Azure Active Directory gesicherte Backend in Form einer ASP.NET Core 2 Web API gestürtzt, während ich versuchte, den PushManager mit dem ServerWorker zu verbinden. Der Anfang fiel uns beiden leicht und wir kamen gut voran. Nachmittags konnte unsere PWA sich bereits auf Datenänderungen im Backend registrieren und wurde asychron benachrichtigt, wenn eine solche Datenänderung stattgefunden hatte. Die erste angezeigte Toast Push Notification war etwas ganz besonderes für mich. Wir brauchten nichts installieren und die Seite musste noch nicht einmal offen sein und wir wurden trotzdem asynchron informiert. Super. Jetzt hatten wir allerdings die ersten Schwierigkeiten. Solange die Seite offen ist, wollten wir keine Toast Notification sehen, sondern die Seite soll sich einfach aktualisieren. Ungefähr drei Stunden und 20 Zeilen ServiceWorker-JavaScript-Code später hatten wir das Problem gelöst. Danach wollten wir das bis jetzt noch unabhängige System in unser ERP-System LEXolution.KMS integrieren. Glücklicherweise hatte ich vor ein paar Monaten LEXolution.KMS bereits in die Cloud portiert und als KMSX mit Azure Active Directory Authentication gehostet. Mit Azure Active Directory konnten wir uns also an KMSX anmelden und ebenfalls ein JWT Access Token für unsere Mandate Updates API erhalten. Bis spät in die Nacht haben wir KMSX um die Mandate Updates Funktion erweitert. Sobald der Sachbearbeiter jetzt in LEXolution.KMS bei der Akte einen Text hinterlegt, wird dieser automatisch in alle Browser gepusht, die sich im Vorfeld für Benachrichtigungen bei dieser Akte registriert hatten. Dafür kann der Sachbearbeiter zu jeder Akte eine eindeutige URL ermitteln, die der Mandant im Browser besuchen und dort sämtliche Benachrichtigungen zu dieser Akte einsehen kann. Kommen neue Benachrichtigungen hinzu, wird die Seite automatisch aktualisiert oder es wird eine Toast Notification gezeigt. Nach einem Klick auf diese Notification kann der Mandant wieder direkt alle Akten-Benachrichtigungen sehen. Wir hatten es geschafft, unser Szenario war implementiert.

Am nächsten Morgen habe ich meinen Kollegen bereits in der Bahn getroffen. Dort konnten wir uns im Rahmen eines Daily Scrums direkt abstimmen, ohne wertvolle Präsentationsvorbereitungszeit zu verlieren. Wieder im Büro angekommen hatten wir noch vier Stunden Zeit, bis wir unser Projekt präsentieren würden. Zuallererst haben wir nochmal unsere Push Notifications getestet und zwar mit dem Handy meines Kollegen. Es funktionierte alles hervorragend. Obwohl alle Anwendungen auf seinem Smartphone geschlossen waren, wurde meine KMSX-Aktenänderung direkt in Form einer Push Notification auf seinem Handy anzeigt. Anschließend widmete sich mein Kollege der Integration von Mandate Updates in ein weiteres Software System der STP. Ich fing an die Präsentation vorzubereiten und die Demo zu planen. Plötzlich funktionierten meine Push Notifications nicht mehr. Sie wurden einfach nicht mehr angezeigt, sobald ich den Browser geschlossen hatte. Nach einiger Zeit habe ich dann bei einer Internet Recherche herausgefunden, dass Push Notifications nicht mehr dispatched werden können, wenn alle Browser-Fenster geschlossen sind. Wahrscheinlich hatte ich bei allen vorherigen Versuchen irgendwo noch ein Chrome-Fenster im Hintergrund offen, sodass die Notifications verarbeitet werden konnten. Dieser Unterschied zwischen Desktop und Mobile ist wirklich bemerkenswert. Irgendwie haben wir es dann noch geschafft unsere Präsentation vorzubereiten und auch noch etwas Essen zu gehen.

Anschließend haben alle Teams ihre Ergebnisse präsentiert. STP hatte zu dieser Präsentation wieder einen Kunden und alle Vorstände eingeladen. Während der Präsentation gingen unsere Push Notifications anfänglich wieder nicht, wurden dann aber mit etwas Verspätung doch noch angezeigt. Mandate Updates war ein voller Erfolg und wurde sogar mit dem Kundenpreis ausgezeichnet. Natürlich wird Mandate Updates mit asynchronen Push Notifications die Kommunikation mit Telefon und E-Mail nicht ablösen, aber es erweitert diese. Mit Mandate Updates bekommen Sie einen neuen Kanal zu Ihren Mandanten.

Mein Kollege und ich hatten viel Spaß bei der Umsetzung und wir haben beide eine Menge gelernt. Ich bin mir sicher, dass alle Teams eine Menge gelernt haben. Herzlichen Glückwunsch auch an 1nicerUploader und Time Rocket, die den “leider geil”- und den Vorstands-Preis gewonnen haben. Sieben Teams sind insgesamt gestartet und auch wenn nur drei Teams mit einem Preis ausgezeichnet werden konnten, alle STP-LabsDay-2018-Projekte haben die gesamte Firma deutlich motiviert und inspiriert. Ein großartiges Event!

Pair Programming Compatibility

Vor einiger Zeit habe ich über einige nachteilige Effekte beim Pair Programming geschrieben. Dabei habe ich verschiedene Symptome, Personas und Verbesserungsmöglichkeiten vorgestellt.
Trotzdem hat mich Pair Programming weiterhin beschäftigt. Ich bin das Gefühl nicht losgeworden, noch nicht genug über diese Form der Zusammenarbeit gelernt zu haben. Also habe ich wieder viele Pairs beobachtet und meine Beobachtungen mit Kollegen und Freunden diskutiert. Ich habe versucht echte Indikatoren für erfolgreiche oder problematische Pair Programming Konstellationen zu finden. Im Laufe des Jahres sind mir einige zusammenhängende Faktoren und Muster immer wieder aufgefallen, die ich im folgenden beschreiben möchte. Das hier ist das Pair Programming Compatibility-Modell.

Manchmal läuft Pair Programming richtig gut und manchmal klappt es überhaupt nicht. Das eine Mal ist es sehr hilfreich zu zweit zu arbeiten und man ist richtig produktiv. Ein anderes Mal ist es ganz anders und sehr anstrengend. Jeder, der öfters im Pair arbeitet, kennt das. Doch warum kommt uns Pair Programming in manchen Situationen effektiver vor als in anderen?
Meines Erachtens kann das auf drei Aspekte reduziert werden, die ich im folgenden Schaubild als Dimensionen dargestellt habe: Leicht-Schwer, Homogen-Heterogen, Monoton-Kreativ. Nach meiner Erfahrung ist Pair Programming sehr effektiv, wenn sich Aufgabe, Team und Vorgehen jeweils in der Mitte dieser Spektren, also in Balance, befinden (grüne Zonen). Sobald sich eine Dimension einem Extrempunkt annähert, merken die Beteiligten recht schnell, dass etwas nicht ganz stimmig ist und Pair Programming irgendwie nicht funktioniert (rote Zonen). Natürlich kann man dann auch Pair Programming machen, aber meiner Meinung nach überwiegen dann die negativen Effekte, die dem Unternehmen schaden.

Die erste Dimension bezieht sich auf die Aufgabe oder Anforderung. Ist diese sehr leicht, könnte ein einzelner Entwickler die Aufgabe wegen geringer Fehleranfälligkeit genauso gut aber wesentlich schneller lösen. Ist die Aufgabe auf der anderen Seite sehr schwer, ist erhöhte Konzentration und Ruhe nötig, die Entwickler meistens nur alleine finden.

Die zweite Dimension bezieht sich auf das Team, also die zwei Entwickler, die zusammen Pair Programming machen. In einem sehr homogenen Team bleiben hilfreiche Ideen und Impulse eines Andersdenkenden aus und soziales Faulenzen entsteht. In einem sehr heterogenen Team besteht viel Erklärungsbedarf und es entstehen viele Diskussionen, die Zeit und Energie kosten.

Die dritte Dimension bezieht sich auf die Umsetzung der Aufgabe durch das Team. Wenn es sich dabei um eine sehr monotone Tätigkeit handelt, gibt es wenig Potential für Verbesserung. Die Tätigkeit kann dann schneller alleine realisiert werden. Wird auf der anderen Seite sehr kreativ gearbeitet, müssen oft viele verschiedene Dinge überlegt, recherchiert und ausprobiert werden, was zu zweit eher hinderlich ist.

Wenn Aufgabe, Team und Vorgehen sich um die Mittelpunkte der erwähnten Aspekte bewegen, ist Pair Programming meiner Meinung nach optimal geeignet. Im oberen Schaubild wäre das die Überlagerung der grünen Zonen, die im dreidimensionalen Raum eine Kugel bilden. In diesem Bereich wollen wir arbeiten. Wenn die Aufgabe aber sehr einfach, das Team sehr homogen und das Vorgehen sehr monoton ist, ist Pair Programming meines Erachtens Verschwendung von Entwicklungsenergie. Willkommen in der Zone der Verschwendung.
Wenn die Aufgabe sehr schwer, das Team sehr heterogen und das Vorgehen sehr kreativ ist, dann ist Pair Programming nach meiner Erfahrung hinderlich, störend und bremst Lösungsfindungen zu stark aus. Willkommen in der Zone der gegenseitigen Behinderung.

Man rechnet ja gerne mit der doppelten Bearbeitungszeit im Worst Case, wenn man eine Aufgabe zu zweit bearbeitet. In der Zone der Verschwendung ist das auch so. In der Zone der gegenseitigen Behinderung kommt zu der doppelten Zeit durch zwei Bearbeiter noch der Effekt dazu, dass die Arbeit durch gegenseitige Behinderung ja auch noch langsamer erfolgt. Und wenn die Bearbeitung dann nur noch halb so schnell erfolgt, dann dauert sie doppelt so lange. Es wird also im Durchschnitt die vierfache Zeit gebraucht. Die Implementierung wird aber nur marginal besser. Das danach eine vergleichbare Aufgabe bearbeitet werden muss, die auch parallel hätte bearbeitet werden können, verdoppelt die Durchlaufzeit nochmal.

Nachteile vs. Vorteile

Es gibt natürlich viele Gründe, warum man Pair Programming macht. Mehr Qualität, man lernt dazu, man fühlt sich nicht so einsam bei der Arbeit oder weiß nicht an was man arbeiten soll. Alle diese Gründe sind gut und wichtig, aber nicht alle sind in einem professionellen Umfeld auch angemessen. Um das Ziel, das hinter diesen Gründen steht, zu erreichen, müssen bestimmte Voraussetzungen erfüllt sein. Qualität ist wichtig, aber nach meiner Erfahrung arbeitet nicht jedes Pair qualitativer. Nur Pairs, die sich gegenseitig ergänzen und ersetzen können, also nicht zu homogen und nicht zu heterogen sind, erreichen gemeinsam mehr. Zu ungleiche oder zu gleiche Pairs erreichen sogar eher das Gegenteil. Genau wie die Leistungsfähigkeit nimmt auch die Konzentrationsbereitschaft im Team durch Social Loafing ab, sodass komplizierte Aufgaben nicht geeignet umgesetzt werden können. Lernen ist auch sehr wichtig und wenn es nur um Know-How-Transfer gehen würde, wäre das auch kein Problem. Aber es geht ja noch um viel mehr: Guten Code, Inhalte, Funktionen und Termine einhalten. Know-How-Transfer durch Pair Programming ist möglich aber nach meiner Erfahrung ineffizient und uneffektiv. Es gibt didaktisch sinnvollere Methoden um zu lernen, wie beispielsweise Coding Dojos und Supervised Learning. Wenn man dennoch mit Pair Programming lernen will, müsste man konsequenterweise Themen-spezifisch pairen: Für Domänen-Know-How mit Domänen-Experten, für Architektur-Know-How Pairing mit den Architekten und für Coding-Know-How mit den Entwicklern. Je ungleicher die Wissensstände der Personen sind, desto mehr lernt die Person beim Pair Programming auf Kosten der anderen Vorteile von Pair Programming, was die Umsetzung hindert und in der Regel zu schlechteren Lösungen und längerer Bearbeitung führt.

Die negativen Effekte von Pair Programming in den roten Zonen, wie beispielsweise wenig Konzentration, anstrengende Diskussionen, soziales Faulenzen und vierfache Bearbeitungszeiten, sind nicht zu unterschätzen. Deswegen müssen wir lernen zu erkennen, ob wir uns gerade in der Zone der Verschwendung oder in der Zone der gegenseitigen Behinderung befinden. Wenn wir uns in einer dieser roten Zonen wiederfinden, ist es unsere Verantwortung als professionelle Entwickler gegenzusteuern und Pair Programming vielleicht sogar abzubrechen. Weiterhin ist es eine große Gefahr, sich an Pair Programming zu gewöhnen, da uns die beschriebenen Zonen nicht mehr auffallen oder, noch schlimmer, egal werden. Abhängig von Aufgabe, Team und Vorgehen macht manchmal Pair Programming und manchmal alleine arbeiten Sinn. Wenn wir dann zu zweit arbeiten hilft uns das Wissen über die Zonen des Pair Programming Compatibility-Modells um Effizienz- und Effektivitätsverluste rechtzeitig zu erkennen und auszugleichen.

 

STP LabsDay 2017

Am vergangenen Donnerstag und Freitag (6. und 7. April 2017) habe ich wieder am STP LabsDay teilgenommen. STP veranstaltet diesen firmeninternen 24h-Hackathon jährlich und es ist jedesmal eine perfekte Gelegenheit während der Arbeitszeit eine neue Idee auszuprobieren. Dieses Jahr hat unsere Marketing-Abteilung alle Teilnehmer mit einem schicken Polo-Shirt und einem coolen Bluetooth-Kopfhörer ausgestattet. Außerdem übernimmt STP die komplette Verpflegung an beiden Tagen. Beste Voraussetzungen für zwei Tage Innovationsarbeit.

Schon im Herbst letzten Jahres hatte ich RethinkDB auf meine ToDo-Liste gesetzt aber seit dem nicht die Zeit gefunden, mich mit dieser Datenbank zu beschäftigen. Das Interessante an RethinkDB ist, dass diese Datenbank nicht nach Änderungen gefragt werden muss, sondern diese direkt in die Clients pushen kann. Ein ziemlich coole Sache, die die Entwicklung von echtzeitfähigen Anwendungen unterstützt. Also habe ich mit einem Kollegen aus meinem Team am STP LabsDay teilgenommen. Im Rahmen unseres Projekts wollten wir Daten, die in LEXolution.KMS entstehen, also der Software, die wir täglich entwickeln, in Echtzeit im Browser anzeigen. “Echtzeit KMS-Logs im Browser” war unser Arbeitstitel.

Am Donnerstag um 11 Uhr ging es los. Nachdem wir uns über den Umfang des Projekts im Klaren waren, hat mein Teamkollege sich der Erweiterung von KMS angenommen, während ich mich in RethinkDB-Tutorials gestürzt habe. Dank Docker hatte ich ohne Aufwand eine RethinkDB-Testumgebung zur Verfügung. Da wir noch nicht wussten wie und welche Daten wir aus KMS in die RethinkDB schreiben müssen, hat mein Kollege KMS so erweitert, dass beliebige Datenquellen und Datensenken angebunden werde können, ohne dass KMS selbst angepasst werden muss. Dadurch hatten wir eine perfekte Entkopplung auf fachlicher, technischer und zeitlicher Ebene. Er war um ca 16 Uhr fertig. Bei mir lief es nicht so gut. Zwar hatte ich ein gutes Verständnis von RethinkDB aufgebaut aber schnell gemerkt, dass es die Änderungen nicht ohne Weiteres in Browser-Clients pushen kann. Für die asynchrone Kommunikation über das Web müsste entweder eine Menge Websocket-Code programmiert oder die RethinkDB-Erweiterung Horizon eingesetzt werden. Also habe ich noch Horizon lernen müssen. Horizon ermöglicht die Entwicklung von echtzeitfähigen Web-Apps auf eine Art und Weise, die mich sehr an Meteor erinnert. Mit Horizon habe ich dann einen Webserver entwickelt, der meine RethinkDB mit einem Browser-Frontend verknüpft. In der Vergangenheit habe ich viel mit Aurelia gearbeitet, sodass ich auch hier gerne Aurelia eingesetzt hätte um eine hübsche Oberflächliche im Browser zu gestalten. Leider waren alle Horizon-Beispiele entweder in Angular oder React. Von Angular halte ich nicht viel, also habe ich auch noch React gelernt. Der ReactComponent.render-Ansatz hat mich sehr an Control.OnPaint erinnert. Schließlich hatte ich eine echtzeitfähige React-App, die über Horizon mit der RethinkDB kommunizieren konnte. Neue Einträge in der Datenbank erschienen automatisch im Browser. Endlich. Mittlerweile war es 20 Uhr und alle LabsDay-Teams haben sich zum gemeinsamen Abendessen im Besprechungsraum getroffen.

Nach dem Essen habe ich mir das Speichern der Events, die in KMS passieren, in der RethinkDB vorgenommen. Mein Teamkollege hatte nach seinem Erfolgserlebnis seinen KMS-Agenten mittlerweile sogar dokumentiert. Für die Kommunikation zwischen seinem Endpunkt und meiner RethinkDB habe ich einen Message Bus als Infrastruktur-Komponente mit EasyNetQ auf RabbitMQ installiert, den Labs Service Bus. Jetzt brauchte ich nur noch eine Komponente, die auf die Events wartet, die der KMS-Agent im Auftrag von KMS auf dem Bus veröffentlicht und diese dann in die RethinkDB einfügt. Dazu habe ich in der Solution des KMS-Agenten pro Event eine Assembly mit dem .NET Standard 1.4 und jeweils einer Klasse “Message” angelegt. Diese Messages, Akte angelegt und Zeiteintrag erfasst, gehören logisch dem KMS-Agenten, der KMS am Labs Service Bus vertritt. In meiner Komponente, die auf diese Events hören soll, habe ich diese .NET Standard-Assemblies referenziert und entsprechende Event Handler implementiert. Zum ersten Mal konnte ich jetzt in KMS einen Zeiteintrag erfassen und augenblicklich erschien in meiner React-App die Zeile “5 Stunden Aktendurchsicht erfasst”. In diesem Moment hatte ich eine Idee für einen Namen für meine App. Meine Vision war es alle Vorgänge und Aktivitäten innerhalb einer Kanzlei im Echtzeit hier anzuzeigen. In einer aktiven Kanzlei würden dann ganz viele verschiedene Ereignisse durch den Browser scrollen. Ich würde den Herzschlag der Kanzlei visualisieren: LEXolution.Pulse war geboren.

Mittlerweile war es kurz vor 23 Uhr und ich war ziemlich müde. Nachdem ich noch Icons und ein Logo eingebaut hatte, fuhr ich nach Hause. Auf dem Heimweg sind mir dann noch viele andere KMS-Aktionen eingefallen, die ich auch noch anzeigen wollte. In dieser Nacht habe ich schlecht geschlafen, wahrscheinlich vor Aufregung.

Am nächsten Morgen bin ich wie gewohnt ins Fitnessstudio gefahren und habe den Tag in Gedanken durchgeplant. Ich würde noch genug Zeit haben, weitere KMS-Vorgänge zu visualisieren. Als ich dann im Büro angekommen war, war mein Teamkollege bereits da. Wir hatten bis um 11 Uhr Zeit, da ab diesem Zeitpunkt der Hackathon endet und die Präsentationsvorbereitung beginnt. Nachdem ich unser verteiltes System wieder in Betrieb genommen hatte, habe ich es geschafft noch zwei weitere KMS-Aktionen in LEXolution.Pulse zu visualisieren: Rechnung abgeschloßen und Zahlungseingang gebucht. Just in time.

Anschließend haben wir unsere Präsentation vorbereitet und um 13 Uhr mit allen LabsDay Teams zur Ergebnispräsentation getroffen. Bei der Präsentation waren Interessenten aus allen Abteilungen, unsere Vorstände und sogar ein Kunde anwesend. Unsere Präsentation verlief sehr gut. Die der anderen Teams auch. Es ist immer wieder erstaunlich zu sehen, was innerhalb von 24 Stunden umgesetzt werden kann. Nachdem alle Teams präsentiert hatten, wurden wieder die drei Preise verliehen. Eigentlich geht es ja nicht um Preise, sondern um unsere Idee und das Ausprobieren von neuen Technologien. Obwohl alle Teams beeindruckende Ergebnisse präsentiert haben, würden zwei ohne Preis nachhause gehen. Leider wurde unser Projekt dieses Jahr nicht mit einem Preis ausgezeichnet. LEXolution.Pulse wurde zwar sehr gelobt, aber die Preise gingen an LEXolution.RenoJane, Abonnieren mit PayPal und DMS-Importer-Android-App. Herzlichen Glückwunsch an meine Kollegen aus diesen Teams. Eure tollen Projekte haben die Preise wirklich verdient.

Mein Teamkollege und ich sind trotzdem sehr stolz auf LEXolution.Pulse. Wir hatten viel Spaß und konnten während der Arbeitszeit an einer eigenen Idee arbeiten. Ich habe gehört, Google Mail wäre auch so entstanden. Für mich war der LabsDay ein voller Erfolg. Ich konnte Erfahrung mit RethinkDB, Horizon, React und .NET Standard sammeln und habe viel gelernt. Wie auch immer es jetzt mit LEXolution.Pulse weitergeht, ich bin mir sicher, dass der STP LabsDay 2017 und seine großartigen Projekte unsere gesamte Firma motiviert und inspiriert haben.

 

Abends zuhause war ich ziemlich erschöpft. Endlich konnte ich RethinkDB von meiner ToDo-Liste streichen. Der nächste Punkt ist…

Die größte Herausforderung unserer Zeit

Wenn ich Sie jetzt fragen würde “Was ist die größte Herausforderung unserer Zeit?”, was würden Sie antworten? Wahrscheinlich beschäftigen wir uns alle mit den unterschiedlichsten Dingen. Wir setzen wahrscheinlich auch alle unterschiedliche Schwerpunkte und Prioritäten in unserem Leben. Aber ich glaube ein Thema ist dabei besonders wichtig. Je nachdem wie erfolgreich wir uns mit diesem Thema auseinandersetzen bestimmt, wie viel Erfolg, Freude und Erfüllung wir erleben. Ich habe mir die eingangs gestellte Frage auch gestellt und beantwortet: Ich bin der Meinung, die größte Herausforderung unserer Zeit ist,

wie wir unsere Zeit einteilen, um eine gute Balance zwischen
Arbeit, Hobbies, Familie & Freunde und Gesundheit zu finden.

Vielleicht erinnern diese Punkte uns an die fünf Grundbedürfnisse, insbesondere an physiologische, soziale und individuelle Bedürfnisse. Aber während da der Fokus auf was uns wichtig ist und was wir brauchen liegt, geht es bei den vier genannten Kategorien um wo wir Zeit investieren müssen. Unsere Bedürfnisse bestimmen diese Punkte und priorisieren sie. Wenn wir uns dann mit den genannten Aspekten beschäftigen, tragen wir zu der Befriedigung unserer Bedürfnisse bei.

Es gibt Dinge, die nicht eindeutig einer Kategorie zugeordnet werden können, oder die alle Kategorien betreffen. Hier soll es aber eher um die Punkte gehen, die gegenseitig um unsere Zeit konkurieren. Um zwischen diesen eine Balance zu finden, müssen wir die uns zur Verfügung stehende Zeit einteilen. Unsere Tage haben 24 Stunden. In einer Woche arbeiten wir in der Regel 5 Tage und haben dann 2 Tage Wochenende. Was machen wir damit? Ein einfaches Rechenbeispiel könnte so aussehen:

168 Stunden pro Woche
– 56 Stunden schlafen (7 * 8 Stunden)
– 3 Stunden Sport (3 * 1 Stunden)
– 7 Stunden Körperhygiene (7 * 2 * 0.5 Stunden)
– 3.5 Stunden Frühstück (7 * 0.5 Stunden)
– 3.5 Stunden Abendessen (7 * 0.5 Stunden)
– 2 Stunden Mittagessen am Wochenende (2 * 1 Stunden)
– 40 Stunden im Büro (5 * 8 Stunden)
– 5 Stunden Mittagspause (5 * 1 Stunden)
– 5 Stunden Büro An- und Abfahrt (5 * 2 * 0.5 Stunden)
= 43 restliche Stunden für Mitmenschen und Hobbies

Ich könnte hier jetzt weiter rechnen und die bestehende Zeit noch auf Familie, Freunde und Hobbies aufteilen. Aber es geht mir hier nicht um ein Rezept für ein ausgeglichenes Leben. Ich glaube es gibt dafür kein allgemeines Rezept, zumindest kenne ich keins. Wenn wir eine Balance zwischen Arbeit, Hobbies, Familie & Freunde und Gesundheit erreichen wollen, müssen wir eine persönliche Zeitplanung für unser Leben vornehmen. Wenn wir es nicht tun und nicht versuchen unsere Zeit einzuteilen, dann werden eine oder mehrere Kategorien zu kurz kommen. Die darunter liegenden Bedürfnisse werden dann nicht befriedigt und wir werden zunehmend unglücklicher. Zeit ist unser bestes Werkzeug, deswegen lasst es uns weise nutzen.

Das ist die größte Herausforderung unserer Zeit.

 

Zeit ist das Element, in dem wir existieren. Wir werden entweder von ihr dahin getragen oder ertrinken in ihr.
~Joyce Carol Oates

 

 

The Dark Side of Pair Programming

Pair Programming bezeichnet das Entwickeln von Software zu zweit. Das hat laut [1] viele Vorteile: Die Qualität der Software wird verbessert, Fehler werden früh erkannt, man hat mehr Spaß an der Arbeit, Wissen verbreitet sich im gesamten Team und die Kommunikation im Team verbessert sich. Doch all das funktioniert nicht automatisch. Man bekommt diese Vorteile nicht automatisch wenn man zu zweit vor dem Computer sitzt. In [2] werden beispielsweise häufige Schwierigkeiten beim Pairing beschrieben.

Probleme

In diesem Blogpost möchte ich von meinen negativen Erfahrungen und Beobachtungen mit Pair Programming berichten. Zu jedem Punkt möchte ich auch Maßnahmen vorschlagen, die zu einer Verbesserung führen können.

  Zeit-intensiv

Pair Programming kostet Zeit. Das ist besonders bei heterogenen Pairs der Fall. Man bremst sich aus indem man erklärt und diskutiert. Viele Diskussionen neigen dazu abzudriften und zu längeren Grundsatzdiskussionen zu werden. Das ist sehr frustrierend, weil man beschäftigt sich viel mit sich selbst und mit Meinungen, statt mit den Problemen, die man eigentlich lösen will.
Mitigation: Man sollte größere Diskussionen verschieben und besser in der Retrospektive diskutieren. Außerdem könnte man versuchen homogenere Pairs zu bilden. Man könnte hier auch einen dritten Programmierer dazu nehmen (Mob Programming [3]), nicht um mitzudiskutieren, sondern um schonmal weiter arbeiten zu können, während zwei sich zum diskutieren ausklinken.

  Kontext-Switches

Wenn beide Pairing Partner kreativ sind, haben auch beide viele Ideen, die sie ausprobieren wollen. Besonders wenn einer von der Idee des anderen nicht überzeugt ist, aber keine Gegenargumente hat und auch keine Diskussion anfangen möchte, wird er die Idee ausprobieren lassen. Oder wenn einer googeln und der andere dekompilieren will. Das Ausprobieren einer eigenen Idee muss in beiden Fällen dann erstmal warten. Man bremst sich auch hier wieder gegenseitig aus. Unterschiedliche Lösungsansätze können nicht gleichzeitig verfolgt werden sondern müssen synchronisiert werden. Das führt in kreativen Phasen zu viel teurem Hin und Her, weil man muss ja wieder reverten oder den Branch wechseln.
Mitigation: Man sollte in diesen Fällen einen zweiten Computer am selben Schreibtisch benutzen. Dann könnte das Ausprobieren von Ideen besser parallelisiert werden.

  Anstrengend

Durch Erklärungen, Diskussionen und Vorschläge steigt die Lautstärke im Büro. Das kann in Großraumbüros das Arbeiten anderer, auch Pairs, stören. Außerdem neigen Pairs dazu, sich gegenseitig unter Druck zu setzen, sodass sich beispielsweise keiner mehr traut kurz aufzustehen oder eine kreative Pause einzulegen. Ich finde es gut, das Pair Programming in vielen Fällen Prokrastination verhindert, aber schlecht, wenn man keine Zeit oder Ruhe mehr zum Nachdenken hat. Wenn einer sich tief reindenken will, wird das massiv erschwert, wenn der andere ihn durch den Code hetzt, erklärt und diskutiert.
Mitigation: Man sollte regelmäßige Pausen fest einplanen, zum Beispiel mit dem Pomodoro-Timer [4]. Zum Nachdenken könnte man sich auch kurzzeitig in ein anderes Büro zurückziehen.

  SOZIALE REIBUNG

Unterschiedliche Ansichten und Vorlieben führen häufig dazu, dass man sich gegenseitig kritisiert und verletzt. Das führt zu persönlichen Spannungen und häufig auch zu Kompromissen, mit denen keiner richtig zufrieden ist. Man hat dann den Eindruck, beide Pairing Partner würden in unterschiedliche Richtungen ziehen. Und wenn man erstmal unglücklich ist, wird alles noch viel schlimmer.
Mitigation: Wir sollten uns neu bewusst machen, worum es eigentlich geht. Es geht um die Bedürfnisse und Interessen des Kunden und nicht um unsere eigenen. Das ist Kundenorientierung. Oft fehlt uns die richtige Perspektive, wenn wir über Code diskutieren und beleidigt sind, wenn er zu Recht oder zu Unrecht kritisiert wird. Wir sollten uns etwas weniger wichtig nehmen [5]. Dan North empfiehlt die emotionale Verbindung, die wir oft zu unserem Code haben, auf die Bedeutung der Software für die Nutzer zu verlagern [6].

Let’s care less about the beauty of the code and more on the impact on success and happiness of the users. Software is the means to the end. As little software as needed to get there.
~ Dan North

  Soziales Faulenzen

Laut Agile Alliance [2] ist das größte und häufigste Problem, dass Entwickler während der Pairing Sitzung nicht gleichermaßen engagiert arbeiten. Das kann dazu führen, das sich einer zurücklehnt, passiv wird und mit den Gedanken zunehmend woanders ist. Spätestens wenn er das Handy zückt hat er sich abgemeldet. Aber selbst wenn beide aktiv bleiben, gibt es einen Leistungsabfall der beteiligten Personen [7]. Sobald die Leistung des Einzelnen nicht mehr sichtbar ist, sondern nur noch die der Gruppe, sinkt die Leistung des Einzelnen in einer Zweiergruppe auf 93%. Je mehr Personen beteiligt sind, desto weniger investieren diese in die Erreichung des gemeinsamen Ziels und verlassen sich zunehmend auf die Gruppe. Verantwortung wird weniger übernommen, sodass man sich hinter Beschlüssen der Gruppe versteckt. Außerdem trifft die Gruppe risikoreichere Entscheidungen weil niemand die ganze Schuld trägt. Beim Pair Programming führt das dazu, dass beide Entwickler oberflächlicher arbeiten. Man fühlt eine trügersiche Sicherheit, da der andere die Lösung auch gut findet und keine Probleme sieht.
Mitigation: Um die Pairing Partner an gleichmäßiges Engagement zu erinnern, kann ein Tool wie der Pair Activity Monitor unterstützen. Das Tool stellt Tastatur- und Mausaktivität beider Pairing Partner gegenüber. Dadurch wird ein großer Teil der Leistung wieder sichtbar. Metriken wie Tastaturanschläge oder Lines Of Code sind zwar keine aussagekräftigen Indikatoren für Software-Qualität, aber sie eignen sich hervorragend um Leistungdifferenzen innerhalb eines Pairs zu visualisieren. Gute Ideen und gedankliche Leistung werden davon natürlich nicht berücksichtigt. Diese sollten explizit einer Person zugeschrieben und entsprechend erwähnt werden.

Personas

Neben den oben beschriebenen negativen Erfahrungen mit Pair Programming sind mir im Laufe der Zeit verschiedene immer wiederkehrende Verhaltensweisen aufgefallen. Auch bei mir selber. Diese Verhaltensweisen, die ich alle als störend empfinde, möchte ich hier in Form von Personas einmal zusammenfassen. Damit sind keine bestimmten Personen, sondern archetypische Charaktere gemeint.

  • Der Abgelenkte
    spielt mit dem Handy, ist gedanklich woanders und lenkt andere mit Fragen oder Geschichten ab.
    Mitigation: Driver-Navigator-Balance, stehend am Whiteboard denken/lösen
  • Der Zuschauer
    schaut einfach nur zu und sagt nichts. Hat auch keine Ideen und kein Interesse.
    Mitigation: Driver-Navigator-Balance, nach Meinung fragen, abholen wenn abgehängt
  • Der Neue
    kennt sich noch nicht gut aus, traut sich noch nicht zu sagen was er denkt. Er fragt lieber viel.
    Mitigation: Ego Suspension
  • Der Bedachte
    lässt sich viel Zeit, denkt mehr und schreibt weniger.
    Mitigation: am Whiteboard denken/lösen (Versuchung abzuhängen ist geringer)
  • Der Eigensinnige
    macht alles selbst und lässt niemanden an die Tastatur. Er entscheidet alleine oder hat schon entschieden.
    Mitigation: Driver-Navigator-Balance, zweiter PC, Ego Suspension, Vorhaben klar kommunizieren und erst dann coden
  • Der Lehrer
    redet viel und erklärt alles über-ausführlich.
    Mitigation: Verständnis äußern, weiter arbeiten, Ego Suspension
  • Der Wichtige
    wird andauernd von irgendjemand gefragt oder geholt. Er weiß viel und hat viel Erfahrung.
    Mitigation: geheimes Büro/Besprechungszimmer
  • Der Überzeugte
    beharrt auf seinem Standpunkt und seiner Sicht der Dinge. Es ist extrem schwer ihn zu überzeugen.
    Mitigation: Ego Suspension
  • Der Hetzer
    braucht keine Ruhe und scheucht den Partner durch den Code (“scroll nochmal nach oben”, “nochmal zurück”), obwohl der gerade etwas anderes nachsehen will. Besonders beim Debuggen.
    Mitigation: Driver-Navigator-Balance, Vorhaben klar kommunizieren und erst dann loslegen
  • Der Alternative
    raucht viel und duscht selten. Sein Tisch und seine Tastatur sind versifft. Er will immer an seinem PC pairen.
    Mitigation: zweiter PC, mehr Abstand

Auch ich erkenne mich von Zeit zu Zeit in einer der beschriebenen Personas wieder. Dabei ist es mir doch wichtig zu einem effizienten und produktiven Arbeitsumfeld beizutragen. Wir müssen uns immer wieder neu daran erinnern und versuchen, möglichst wenig soziale Reibung zu erzeugen und stattdessen gute und engagierte Pairing Partner sein.

Fazit

Gute und konstruktive Pairs sind nicht selbstverständlich. Ich habe einige Probleme und nachteilige Verhaltensweisen beschrieben, die die eingangs erwähnten Vorteile sehr schnell zunichtemachen. Wir müssen uns fragen: Bekommen wir die Vorteile wirklich? Wenn nicht, ist Pair Programming teure Zeit- und Energieverschwendung.

Wenn Pairs sich viel mit sich selbst beschäftigen, nicht gleichermaßen engagiert arbeiten oder die Effekte des sozialen Faulenzens deutlich werden, sollte sich etwas ändern. Und wenn es nicht möglich ist gute Pairs zu bilden, dann ist es sinnvoller nicht zu pairen. Da man die Vorteile nicht hat, gibt es auch keinen Grund mit angezogener Handbremse zu fahren. So ist man wenigstens schneller fertig. Wenn wir aber pairen, dann wollen wir gute Pairing Partner sein um gemeinsam mehr zu erreichen, als wir alleine erreicht hätten.

Don’t try to be right. Try to be helpful. Try to be useful.
~ James Wells

 

 

 

Links

[1] https://www.it-agile.de/wissen/agiles-engineering/pair-programming/
[2] https://www.agilealliance.org/glossary/pairing/
[3] http://mobprogramming.org/
[4] https://en.wikipedia.org/wiki/Pomodoro_Technique
[5] http://www.johnniland.com/suspension-of-ego/
[6] http://dotnetrocks.com/?show=1118
[7] https://en.wikipedia.org/wiki/Social_loafing

Bugs, Problem der Entwickler?

Eigentlich ist ein Bug

“an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.” (Wikipedia)

Also auf die Software bezogen, erstmal unabhängig von der Ursache. Weil die Entwickler dann analysieren und SM, PO, PM, BA und QS nicht viel machen können, wird Bug oft gleichbedeutend mit “Fehler der Entwickler” verstanden, obwohl die eigentliche Ursache noch gar nicht klar ist. Eventuell gab es implizite Anforderungen, die verloren gegangen sind, oder etwas wurde nachträglich anders gestaltet. Bevor die genaue Ursache bekannt ist (fehlerhafte Entwicklung, mangelnde Spezifikation, keine QS, …) betrifft ein Bug alle am Produkt arbeitenden Personen. Jeder sollte sich fragen, was er hätte tun können, um diesen Bug zu vermieden. Die falsche Vorstellung, dass ein Bug erstmal ein Entwicklungsfehler ist, führt oft zu heimlicher Schuldzuweisung, Frustration und Rechtfertigung der Entwickler. Zusammengefasst, einer kontraproduktiven Fehlerkultur. Wenn sich diese falsche Vorstellung manifestiert, kann es helfen, die Namen der Artefakte und damit deren verstandene Bedeutung zu ändern. Wundern Sie sich aber nicht, wenn das auf Widerstand stösst. Immerhin ist es für viele Nicht-Entwickler eine komfortable Situation per Default “nicht schuld zu sein” und die Verantwortung bei den Entwicklern zu wissen.

Weniger (be)wertend

Bug oder Defekt zu einer Story ist zu sehr wertend (“schlecht”, “falsch”). Das unterstützt und vereinfacht Schuldzuweisung bewusst oder unbewusst. Zwar kann man sagen, das sind “fachliche” Defekte, aber eigentlich ist das immer ein “Problem” mit dem Produkt der Entwickler. Und damit überträgt sich das wertende auf die Arbeit der Entwickler. Die Entwickler können schuld sein, dann wäre diese Sichtweise richtig. Die Entwickler können aber auch nicht Schuld sein, dann wäre es die falsche Sichtweise. Die Ursachen eines Bugs oder Defektes sind vielfältig, warum haben wir also ein Wort gewählt, das implizit die Entwickler “beschuldigt”, ob wir das wollen oder nicht? Sinnvoll wäre ein wertfreier Begriff wie Verbesserung oder Erweiterung, der sich auf alles anwenden lässt. Schließlich wäre die einzig zielführende Reaktion eine Anpassung, egal was die Ursachen sind.

Unterscheidung CR und Bug

Unter einen solchen neutralen Begriff würde auch der CR fallen. Man hätte statt zwei also nur noch ein Artefakt. Angeblich ist die Unterscheidung aber für die Messung und Begründung der internen Wirtschaftlichkeit wichtig. Kein Wunder also, dass alles Bugs und Defekte sind ;). UserStory ist neutral genug. Man könnte trotzdem ein neutrales Artefakt Anpassung haben und für die Unterscheidung verschiedene Eigenschaften wählen. Welche Eigenschaften sollte es geben?

Was wir nicht wollen sind Schuldfragen und Verantwortlichkeit der Mehrarbeit:

  • Entwickler-Schuld
  • BA-Schuld
  • Kunde-Schuld
  • Ungewiss-wer-Schuld-ist

Besser wären verschiedene Bezeichnungen für verschiedene Dinge:

  • Technischer/semantischer Fehler (es funktioniert nicht oder falsch (Rechtschreibfehler))
  • Übersehene Anforderung (es steht auf der Story)
  • Neue Anforderung (es steht nicht auf der Story)

Oder einfach nur

  • Auf Kosten des Teams
  • Auf Kosten des Kunden

Weniger abstraktes, mehrdeutiges, unklares und vorallem weniger Schuldzuweisung, Frustration und Rechtfertigung. Softwareentwicklung betrifft das gesamte Produktteam und nur gemeinsam ist es stark.

STP LabsDay 2015

Am Donnerstag und Freitag letzte Woche, dem 1. und 2. Oktober, habe ich am zweiten STP LabsDay teilgenommen. Die Firma für die ich arbeite veranstaltet diesen 24-Stunden-Hackathon jedes Jahr. Zusammen mit meinem Partner habe ich ‘einen’ alternativen Client für das STP KMS entwickelt, der im Browser und auf möglichst vielen Geräten läuft. Unser Ziel war es dabei nur eine Codebasis zu haben, plattformunabhängig.

Um dieses Ziel zu erreichen kamen entweder C# oder JavaScript in Frage. Mit Xamarin kriegt man C# auf Windows, Android, iOS und Mac und mit Silverlight in den Browser. Auf der anderen Seite läuft JavaScript sowieso schon im Browser und mit NW.js kriegt man JavaScript auf Windows und Mac und mit Apache Cordova auf Windows Phone, Android und iOS. Ich habe mich für JavaScript entschieden, da Silverlight mittlerweile uncool ist und das Silverlight-Plugin eh nicht mehr im Chrome läuft. Außerdem sehe ich C# jeden Tag und JavaScript nicht.

Was das Backend betrifft, konnten wir die externe Schnittstelle von STP KMS nutzen, sodass wir uns voll und ganz auf Client-Entwicklung konzentrieren konnten. Unser erster Prototyp lief nach ca. 7 Stunden dank NW.js und Apache Cordova auf allen uns zur Verfügung stehenden Platformen: Wir hatten Windows, Mac, Windows Phone, Android, iPhone und iPad dabei. Programmiert haben wir bis dahin wenig, die meiste Zeit ging für die Administration der Geräte und Deployment-Probleme drauf. Aber in diesem Prototyp hatten wir die Logik unter der Oberfläche mit AngularJS vollständig umgesetzt und uns um das Design überhaupt nicht gekümmert. Es lief dann zwar einwandfrei aber sah echt nichts aus. Also haben wir die restliche Zeit in UI-Design investiert und mit jQuery Mobile für Smartphones optimiert.

Wir hatten nach 24 Stunden eine harte Deadline. Aber das hat uns gereicht. Wir hatten sogar Zeit für Essen, Schlafen und Fitnessstudio. Dank Apache Cordova können wir unseren Client auch für BlackBerry, FirePhone, Tizen und alle anderen Geräte erzeugen, die wir heute noch gar nicht kennen.

Bei der Abschlusspräsentation des STP LabsDay haben wir dann die identische App auf Windows, Mac, Windows Phone, Android, iPhone und iPad gezeigt. Und das kam richtig gut an. Für unser Projekt “cross platform KMS-Aktensicht” haben wir anschließend zwei Awards gewonnen: Den “roadmapper”-Award (Kundenpreis) und den “leider geil”-Award (Zuschauerpreis). Ersteren hat ein echter Kunde der STP höchstpersönlich verliehen und für Letzteren haben alle Zuschauer der Ergebnispräsentation anonym abgestimmt. Den Vorstands-Award haben wir leider nicht mehr gewonnen, der ging an ein anderes Projekt. Dennoch haben wir mit modernen Web-Technologien in kurzer Zeit und ohne Vorwissen richtig viel erreicht und viele beeindrucken können. Und wir haben NW.js und Apache Cordova kennengelernt. Cross platform for the win!

WP_20151001_001
DSC_0105
DSC_0145

“Ich will keine Leben retten”

Vor kurzem habe ich den Satz gehört: “Ich studiere Medizin, damit ich Leben retten kann.” Das hat mich zum Nachdenken gebracht. Studiere ich nicht Medizin, weil ich keine Leben retten will? Eigentlich ist Leben retten ja eine gute Sache, also warum tue ich nicht alles mögliche, um Leben retten zu können? Medizin studieren zum Beispiel. Und wieso steht in meinen Gedanken jetzt über meinem Leben die Überschrift “Ich will keine Leben retten”?

Zunächst einmal retten nicht nur Mediziner Leben. Leben werden auch von Hilfsorganisationen in Krisengebieten und sogar von Soldaten im Krieg gerettet. Es geht nicht nur um Leben retten. Es geht auch um Leben schützen, Leben unterstützen und Leben verschönern. Außerdem bedeutet der Begriff “Leben” mehr als nur körperliche Gesundheit.

Meiner Meinung nach geht es eigentlich darum, einen Beitrag zur Gesellschaft zu leisten. Einen Beitrag zur Gemeinschaft der Menschen. Nach Karlfried Graf Dürckheim hat der Mensch einen doppelten Auftrag.

  1. die Welt gestalten in Werk

  2. reifen auf dem inneren Weg

Die Gestaltung der Welt für die Gemeinschaft der Menschen wird dazu führen, das “Leben” gerettet, geschützt, unterstützt und verschönert werden können. Vielleicht nicht direkt von mir, aber dann indirekt über die nächste oder übernächste Instanz in der Wertschöpfungskette. Zum Beispiel rettet der Hersteller von Seife keine Leben, aber der Arzt, der sich damit die Hände wäscht. Die Antwort auf die oben gestellten Fragen sehe ich in diesem doppelten Auftrag.

Was denken Sie?