Top Athleten und Sänger haben Coaches! Warum ich nicht?

Ich habe bei “The New Yorker” einen tollen Artikel gelesen, der mich sehr inspiriert hat: Link

In dem Artikel erzählt ein Arzt von seinem Problem, dass er irgendwann unfreiwillig aufgehört hat besser zu werden. Am Beginn seiner Kariere hat er noch große Fortschritte gemacht. Die Zahl an Komplikationen nach OPs sank sehr rapide. Dann langsamer, bis er schließlich stagnierte. Die Zahl der Komplikationen, waren verglichen mit denen seiner Kollegen mittelmäßig. Er wusste also, dass noch Verbesserungspotential da ist, nur nicht wie er sich verbessern könnte. Es existierten eine Art “Blinde Stellen”, in der man seine eigenen Fehler einfach nicht erkennt.


Der Autor schreibt, dass sich der Arzt viele Gedanken gemacht hat, wie er diese blinde Stellen ausmerzen kann um endlich wieder Fortschritte zu machen. Wenn man auf Probleme stößt, die man einfach nicht lösen kann, hilft es meist über den Tellerrand hinaus zu sehen. Haben andere Menschen diese Probleme auch? Welche Problemlösungsansätze funktionieren wo anders und lassen sich auch hier anwenden? Der Arzt hat erkannt, dass es bei Sportlern ganz natürlich ist einen Coach zu haben. Wenn diese Sportler an ihre Leistungsgrenze kommen, erstellt ein Coach ein anderes Trainingsprogramm, dass die Leistungsgrenze wieder ein Stück nach oben schiebt. Das gleiche ist bei Sängern. Wenn man selber singt, hört man etwas ganz anderes, als die Person die vor einem steht. Hier entstehen sehr oft diese blinden Flecken, in denen der Akteur seine eigenen Fehler nicht erkennt bzw. gar nicht erkennen kann. Hier hilft der Coach als Außenstehender eine andere Sichtweiße zu representieren.

Klingt also vielversprechend! Wenn man sich das Thema genauer ansieht, findet man Versuche von Lehrern, die andere Lehrer angestellt haben um sich coachen zu lassen. Die Ergebnisse sind beeindruckend! Ein Lehrer erzählt, dass er mit bestimmten Schülern einfach nicht zurecht gekommen ist. Ein anderer Lehrer hat sich für ein paar Stunden mit in die Klasse gesetzt und die Situation beobachtet. Er konnte ein paar gute Denkanstöße geben mit dem Ergebnis, dass der Klassenlehrer gelernt hat mit den Schülern umzugehen.

Ein Coach ist aber im Normalfall kein Lehrer! Ein Lehrer hat das Ziel den Lernenden etwas beizubringen, so dass diese das Gelernte am Schluss selbstständig anwenden können. Der Prozess hat also ein genau spezifiziertes Ende. Ein Coach ist dazu da etwas zu verbessern. Das kann ein immer fortwährender Prozess sein, der niemals endet. So unterscheidet sich auch die Art wie ein Lehrer und wie ein Coach interagieren. Ein Lehrer macht etwas vor, erklärt und lässt dies reproduzieren. Ein Coach analysiert, kritisiert und überprüft.


Zurück zu dem Artikel mit dem Arzt. Der Arzt hat einen im Ruhestand befindlichen Kollegen gebeten, bei ein paar OPs mit zu zu sehen und danach Tips zu geben. Der Coach hat überraschenderweiße kaum fachliche Dinge kritisiert, ehr “Stell dich mal anders hin, damit dir dein Assistent besser helfen kann” und “Achte darauf, dass das Licht immer optimal ist”. Das Ergebnis war, dass seine Komplikationsrate wieder begann zu fallen und sie sich der Arzt jetzt 2-3 Tage im Monat coachen lässt.
Ich denke das Beispiel zeigt eindrucksvoll wie gut sich Coaching auch auf andere Bereiche einsetzen lässt. Vor allem in der IT Branche in der es wie nirgends anders auf den Menschen ankommt, der den Computer bedient, ist das Konzept sehr gut anwendbar.

Platforms, Platforms, Platforms, Platforms, Platforms, …!


Der Titel soll eine Anspielung auf Steve Ballmers Rede zu “Developers” sein: http://www.youtube.com/watch?v=8To-6VIJZRE

Tatsächlich ist das was ich ausdrücken möchte sehr ähnlich dem, was Herr Ballmer mit seiner Rede bezwecken wollte. Schon 2006 wusste Microsoft, dass es unmöglich ist, alle Features, Programme, Ideen, … selbst zu entwickeln. Nur wenn sehr viele schlaue Köpfe an Puzzleteilen arbeiten entsteht am Schluss ein großes Ganzes. Die Zeiten sind vorbei in denen eine Firma ein Produkt auf den Markt wirft und ohne fremdes zutun langfristig erfolgreich wird. Wäre das IPhone so erfolgreich gewesen, gäbe es nicht so viele Apps dafür? Warum ist Windows immer noch erfolgreicher als Mac, obwohl MacOS die bessere Usability hat und günstiger ist? Warum ist Amazon (der als langweiliger Bücher-Onlineshop gestartet ist) so erfolgreich?

Ein hoch aktuelles Beispiel ist Google+ mit dem Google sehr ambitioniert in den Markt gedrungen ist, mit dem Ziel Facebook das Wasser abzugraben. Google ist ein Branchenriese, hat viel Geld in die Hand genommen, Innovative neue Features gebracht und hat definitiv das Potential Facebook gefährlich zu werden. Die ersten Fachartikel und Benutzerfeedbacks waren durch die Bank sehr gut. Es stand im Grunde fest, dass Google Facebook auf Augenhöhe begegnet. Fragt man jetzt, einige Monate nach dem Release, Benutzer und Beobachter, sieht die Sache überraschenderwei

se komplett anders aus. Die Leute sind gelangweilt von Google+. Nur wenige Leute können tatsächlich in Worte fassen warum Facebook besser ist.

Dabei ist der Grund ganz einfach. Facebook ist überall und alles ist in Facebook. Fast an jeder Ecke im Netz  gibt es “Gefällt mir” Buttons. Es gibt Webseiten die auf Facebook gehostet sind. Die ganzen Spiele á là Mafia Wars führen dazu, dass Benutzer nur aus diesem Grund mehrmals am Tag auf Facebook gehen. Diese Spiele sind “time sinks” und haben im Grunde gar nichts mehr mit Facebook zu tun. Aber Facebook ermöglicht diese Spiele überhaupt erst! Weil Facebook eine Platform ist!


Was ist denn überhaupt eine Platform technisch gesehen? Warum gibt es Spiele auf Facebook aber nicht auf Google+? Stark abstrahiert, sind es Schnittstellen in denen Dritthersteller ihre Anwendungen/Plug-Ins integrieren können. Sagen zu können “Hier kannst du deine App hoch laden und dann läuft sie auf unserer Plattform” reicht aber bei weitem nicht! Im optimalsten Fall sollten alle Funktionen der Plattform auch den App Entwicklern zur Verfügung stehen und zwar in einer Qualität die über jeden Zweifel erhaben ist. Nicht frustiert (hobby-)Entwickler mehr als eine einschränkende und fehlerträchtige API. Die Entwickler sollen sich mit der Umsetzung ihrer Ideen beschäftigen, nicht damit Workarounds für Bugs zu finden.
In diesem Kontext hört man immer und immer wieder die selbe Phrase “Eat your own dogfood“. Nur wer die API die er bereit stellt auf für seine eigenen Funktionen benutzt, kann sicher sein, dass die Qualität ausreicht. Nur der kann herausfinden welche Funktionen in der API noch fehlen. Dort draußen gibt es genug APIs die nicht mal Hundefutter sind. Eine API muss Spaß machen dagegen zu programmieren. Genau das fördert auch das Ziel viele coole Apps zu bekommen. Es gibt genug Entwickler die Ideen haben aber nicht die Zeit sie umzusetzen. Für ein kleines Weekend Projekt reicht die Zeit aber meistens. Es ist also Aufgabe der API dafür zu sorgen, dass 90% der Apps in einem Wochenende umgesetzt werden können.

Meine persönliche Meinung, die ich mit immer mehr Leuten teile, ist eindeutig: Wer plant in Zukunft erfolgreich zu sein, sei es durch eine neue Anwendung oder eine bereits bestehende Anwendung (egal wie groß sie sein mag) wird nicht darum herum kommen eine Platform zu bereit zu stellen. Es reicht nicht mehr alle Features selbst zu entwickeln. Gleichzeitig sollte man es aber auch als Chance sehen: Neue Funktionen die einen Mehrwert für den Benutzer bieten, ständig neue Ideen auf die man selbst vermutlich nie gekommen wäre und das alles (fast) geschenkt!

Hadoop, HBase, Hive, HDFS, WTF?!

Hadoop EcosystemIch glaube inzwischen ist klar geworden, dass ich mich derzeit viel mit Hadoop und allem was da dran hängt (und das ist VIEL!) befasse.

Es gibt zwar so einige Aufstellung, aber so kurz und prägnant habe ich das leider bisher noch nicht gefunden. Allgemein sind Docus zu dem Thema entweder gar nicht vorhanden oder so umfangreich, dass sie viele 100 Buchseiten füllen könnten. Der Definitive Guide von Tom White, den ich derzeit lese hat über 450 Seiten! Keine gute Lektüre für ein “Quick Hands on”! Vielleicht kann ich da Licht ins Dunkel bringen:

HDFS

HDFS steht für Hadoop Distributed File System. Und hier beginnt die Verwirrung bereits! Ein File System impliziert für mich, dass es eine bestimmt Art und Weise ist in der die Bits und Bytes auf der Festplatte abgelegt sind, wie mit Fragmentierung umgegangen wird und wie die Metadaten behandelt werden. Das ist aber nur fast richtig. HDFS benutzt jedes beliebige Dateisystem zur Datenablage. Allerdings setzt es einen Abstraktionslayer oben drauf. Metadaten und Binary Content sind noch mal in eigene Dateien gekapselt. Ziel des ganzen ist ein Dateisystem über Rechnergrenzen hinweg aufzuspannen. Da gibt es natürlich ganz andere Anforderungen als an ein typisches Dateisystem. Beispielsweise: Wie komme ich an die Daten, die auf einem anderen Rechner liegen? Wie gehe ich mit Rechnerausfällen um? Kann ich die Performance durch Loadbalancing steigern? Wie wird synchronisiert? Die Liste ließe sich vermutlich noch lange fortführen. Am Schluss kommt dann durchaus wieder ein Dateisystem heraus. Allerdings muss nicht die Festplatte nach dem Dateisystem formatiert werden sondern der Cluster.
Eine Anmerkung die ich recht spannend finde: Während die Blockgröße auf einer Festplatte heutzutage so um die 64kbit liegt, ist sie bei HDFS üblicherweiße größer 64 MegaByte

HBase

In HDFS dürfen Daten einer beliebigen Struktur abgelegt werden. HBase macht daraus eine Tabelle. Ursprünglich stammt HBase von der Google Big Table ab. HBase ermöglicht es, unsere Daten in einer strukturierten Form abzulegen. Wir haben dann also Zeilen in dessen Spalten wir unsere Daten ablegen können. Heißt das also, dass wir eine RDBMS mit der Power von Hadoop haben? Leider nicht! HBase sorgt nur dafür, dass die Daten die wir rein geben sauber aligned und delimited in Dateien gespeichert wird und auf die gleiche weise wieder ausgelesen werden können. Da von einer RDBMS zu sprechenn wäre übertrieben!

Hive

Hive bietet die Möglichkeit auf HBase Tabellen über eine SQL ähnliche Sprache zu zu greifen. Jeder der SQL kann wird keine Probleme mit der HiveQL genannten Sprache haben. Als ich mich mit Hive beschäftigt habe, ist mir die Idee gekommen einen IDBConnection Wrapper für .NET zu schreiben. Ich bin immer noch der Meinung, dass dies möglich ist. Leider hat mich die Motivation verlassen als ich bemerkt habe wie unglaublich langsam Hive ist. Hive ist leider nur dazu da Auswertungen / Aggregationen über sehr große Datenmengen zu machen. Performance sollte keine Rolle spielen dürfen. Schade!

Hadoop

Was soll jetzt bitte Hadoop sein? HDFS mit HBase/Hive reicht doch! Hadoop stellt sozusagen die Engine dar, auf die HBase erst aufsetzt. Im Grunde sin Abfragen im Hadoop Umfeld immer Map/Reduce Scripte. Map um die Daten die im HDFS liegen auszuwerten und Reduce um das Ergebnis von Map zu filtern / sortieren. (Wow, war das jetzt stark vereinfacht! Hoffentlich ließt das niemand, der wissenschaftlich an das Thema heran geht!) HBase selbst generiert aus den übergebenen Befehlen vollautomatisch Map/Reduce Scripte und sendet sie an Hadoop zur Ausführung. Das Ergebnis wird daraufhin aufbereitet und an den Clienten gesendet.
Übrigens stammt der Name Hadoop von dem Sohn eines Contributors. Der Sohn hat einen gelben Elefanten geschenkt bekommen. Als Name für den Elefanten suchte sich der Junge den Namen Hadoop aus. Das fand der Contributor so gut, dass er auch sein Projekt so benannte.

Ich hoffe ich konnte etwas Licht ins Dunkel bringen. Es gibt natürlich noch viel mehr Systeme im Context von Hadoop á là Zookeeper, Jobtracker, Pig, Chuckwa, Sqoop, … Vielleicht gibt es dazu ein andermal noch Blogartikel.

C# IDbConnection zu Hadoop/Hive

Spricht etwas dagegen einen IDbConnection Implementierung zu Hadoop, genauer gesagt Hive, zu machen? Hive soll ja im Grunde das Arbeiten mit Hadoop so darstellen, als wäre es eine relationale Datenbank. Wenn das tatsächlich so funktioniert, sollte man auch einen Wrapper schreiben können, den man wie gewohnt verwenden kann. “Wie gewohnt” ist an dieser Stelle natürlich extrem optimistisch. Mir fallen da jetzt schon Probleme mit Transaktionen, ConnectionStrings und IDbCommand ein. Aber ich glaube es wäre ein Anfang.

Ich bin ohnehin extrem überwältigt, dass ich ganz offensichtlich der erste Mensch auf der Welt bin, der versucht Hadoop/Hive mit .NET zu verwenden. Vadim Chekan hat zwar bereits C# Code aus den Thrift-Templates erzeugt, aber die sind defakto nicht zu gebrauchen. Arbeiten denn alle anderen mit den REST Schnittstellen? Oder ist C# schon viel zu uncool um mit so etwas coolem wie Hadoop zu arbeiten? Komisch! Wer es mir sagen kann, schreibt bitte einen Kommentar! Bis ich schlauer bin versuche ich selbst einen .NET Wrapper zu entwickeln… To be continued

Management as a Service (MaaS)

Es gibt derzeit einen starken Trend alles als Service anzubieten. Den ersten Kontakt mit der Bewegung hatte ich mit Software as a Service (SaaS). Sie beschreibt, dass Businesslogik als Dienst angeboten wird. Man bietet üblicherweise eine von Menschen bedienbare Oberfläche an, genauso gut können aber auch “Andere” auf den Dienst zugreifen und so die Businesslogik benutzen. Beispiel Facebook: Natürlich gibt es die offizielle Webseite, aber jeder kann seine eigene Webseite, App, usw. dafür schreiben!

Ich habe gerade in meinem Informatik Studium das Themengebiet Unternehmensführung. Es wurde analysiert welche Aufgaben eine Führungskraft eigentlich hat, wie sie agieren sollte und welche Probleme in Zukunft auf den Personenkreis zu kommen wird. Als Quintessenz wurde herausgearbeitet, dass im Zuge der demografischen Entwicklungen viele neue Probleme entstehen werden. Außerdem ist der hierarchische Ansatz auf lange Sicht tot und der kooperative Führungsstil ist ohnehin viel effektiver. Man muss in Zukunft die aktuellen Strukturen in Management evtl. komplett neu denken.

Es wurde zwar nicht explizit erwähnt, aber für mich hat sich somit nur eine Chance ergeben: Das Management stellt seinen Kunden – den Mitarbeitern! – seine Dienste zur Verfügung. Mitarbeiter sind ohnehin nach Kunden bereits das wichtigste Gut in einem Unternehmen und werden immer wichtiger. Warum sollte das an der Grenze zu dem Hoheitsgebiet des Management halt machen? Das Management muss die Mitarbeiter befähigen ihre Arbeit hervorragend zu erledigen. Das ist bereits ein Dienst den die Führungskräfte ihren Mitarbeitern anbieten. Warum sollte die Visions-/Zukunfts-/Zielentwicklung nicht auch als Dienst gesehen werden? Die Mitarbeiter entscheiden selbst wo die Reise hingehen soll. Die Führungskraft muss dann dafür sorgen, dass die Mitarbeiter alle relevanten Informationen zur Verfügung haben (sollten Sie bereits ohnehin!), kann evtl. Vorschläge und Rahmenbedingungen vorgeben, lässt sich aber die Entscheidung abnehmen.

Ich denke das hätte einen unglaublichen Motivations- und Produktivitätsschub zur Folge. Da die Mitarbeiter zum einen ganz sicher eine Vision haben und diese Vision für sich selbst erfüllen. Aktuell ist es ehr so: Irgendwelche Stakeholder (die die Mitarbeiter persönlich eventuell gar nicht kennen) entwickeln eine Vision, übermitteln sie über Mittelsmänner zu den Arbeitern und diese setzen die Vision dann “für” den Stakeholder um.

Vorraussetzung sind natürlich kleine, bereits sehr agile, funktionierende Teams.
Ein Problem habe ich noch nicht gelöst: Was ist mit längerfristigen strategischen Visionen? Ich denke, diese sollten auch noch in Zukunft vom (Spitzen)management entschieden werden. Diese müssen sich natürlich irgendwie mit den kurzfristigen Entscheidungen der Teams vereinbaren lassen. Vielleicht ergibt sich eine Problemlösung aber ganz automatisch durch eine Unternehmensübergreifende Sicht auf die Zukunft…

Es gibt übrigens bereits einiges an Literatur zu dem Thema. Ich denke ich werde mich da mal etwas schlau machen…

Manifest

Dieser Blog soll als geistiger Sparingspartner für mich dienen!

Oft gehen in meinem Kopf Gedanken und Ideen umher die einfach zu komplex sind, dass ich sie in einem Schritt zu Ende denken kann. Dann hilft es sie nieder zu schreiben und vielleicht später darauf zurück zu kommen.

Natürlich sind Kommentare gerne gesehen! Sagt mir was ihr von meinen Posts oder dem Blog allgemein denkt!

Grüße,
Sebastian