hype Driven Development

hype Driven Development

In der Software-Entwicklung treffen Teams oft Entscheidungen über die Architektur oder den Technologie-Stack häufig auf Grundlage von vagen Meinungen, Social Media oder im Allgemeinen was gerade als „hot“ angesehen wird, anstatt auf fundierter Recherche und ernsthafter Berücksichtigung der Auswirkungen auf die Projekte. Ein passender Name für diesen Trend ist: „Hype Driven Development“. Dies ist generell kein förderlicher Ansatz für das Software Development, vielmehr sollte man den Weg des „Solid Software Engineering“ wählen.

Neue Technologie - eine neue Hoffnung

Wer kennt es nicht? Ein Team ist auf der Suche nach einer passenden Technologie für das Projekt. Jemand liest einen Blog-Artikel, etwas trendet gerade auf Twitter, oder man kommt gerade von einer Konferenz zurück, auf der ein großartiges Gespräch über ein tolles neues Framework geführt wurde. Bald darauf beginnt das Team, diese neue glänzende Technologie – oder ein Designparadigma der Softwarearchitektur, was auch immer – zu verwenden, aber anstatt wie versprochen schneller zu werden und ein besseres Produkt zu entwickeln, gerät das Team ins Stocken. Alle werden langsamer, werden demotiviert und haben Probleme, die nächste funktionierende Version der Software zu liefern. Manchmal muss zunächst einmal ein riesiger Haufen Bugs gefixt werden, bevor man überhaupt mal an neue Funktionalitäten denken kann. Man braucht „nur noch ein paar Tage“, bis alles mit diesem neuen Ding läuft.

Hype

Hype Driven Development (HDD) hat viele Geschmacksrichtungen und berührt Projekt auf viele unterschiedliche Arten.

  • Reddit Driven Development: hiervon spricht man, wenn sich für Technologie/Architektur/Design entschieden wird, basierend auf dem, was irgendein beliebter Blogger geschrieben hat oder was auf Reddit, Hackernews, Blogs, Twitter, Facebook, GitHub oder anderen soziale Medien aktuell ist.
  • Conference Driven Development: Es ist immer spannend wenn Leute von einer Konferenz oder einem Meetup zurück kommen. Jeder ist unglaublich inspiriert! Aber Achtung, sofort das neueste heißeste lib/Framework/Architektur-Paradigma ohne ausreichende Recherche zu übernehmen könnte sich schnell als grober Fehler entpuppen. Als Tiger springen und als Bettvorleger landen.
  • Loudest-Shouting Driven Development: Irgendwer im Team hört nicht auf von dieser einen tollen Technologie zu labern. Hört nicht auf. Hört. Einfach. Nicht. Auf. Das Team gibt nach und es wird entschieden nun das einmal auszuprobieren.
  • Gem/lib/plugin Driven Development: Dies ist recht ausgeprägt in der Ruby On Rails Community zu beobachten. Die grundlegende Idee ist, dass jedes Problem in Rails mit einem Gem gelöst werden kann. Manchmal würden ein paar selbstgeschriebene Codezeilen alles schnell fixen, aber nein, viel lieber schmeißt man haufenweise Libs, Plugins, Gems oder Frameworks auf das Problem, bis es irgendwann funktioniert.
  • Stack Overflow Driven Development: Wenn Developer genau die Lösungen aus Stack Overflow – oder sonst wo – kopieren und einfügen, ohne sie wirklich zu verstehen.

Teams besiegeln ihr eigenes Schicksal

Das Problem mit zu viel Hype ist, dass es leicht zu den falschen Entscheidungen führt. Sowohl schlechte Entscheidungen zu Architekt als auch Fehlentscheidungen beim Techstack suchen ein Team oft Monate oder sogar Jahre später noch heim. Im schlimmsten Fall führt das zum „Big Rewrite“.

Die Wurzel allen Übels scheint in den sozialen Medien zu liegen, wo sich neue Ideen schneller verbreiten, als sie getestet werden können. Viel schneller als Menschen ihre Vor- und Nachteile verstehen können.

Die Anatomie des Hype

Die meisten Hypes haben eine ähnliche Struktur.

Schritt 1: Echtes Problem und Lösung

Alles beginnt in einem Unternehmen mit einem Problem. Das Software Team entscheidet, dass die Lösung des Problems über den aktuellen Technologie Stack, Prozess oder die Architektur hinausgeht. Das Unternehmen schafft ein neues Framework, eine neue Bibliothek oder ein neues Paradigma und bald ist das Problem gelöst.

Schritt 2: Ankündigung, Buzz und Keywords

Das Team freut sich darauf, die gelungene Arbeit dem Rest der Welt zu zeigen. Bald werden Blog-Artikel geschrieben und fleißig Talks auf Konferenzen und Meetups gehalten. Das Problem ist oft nicht bloß trivial, daher sind alle stolz darauf die beeindruckenden Ergebnisse einer nicht trivialen Lösung zu präsentieren. Die Leute sind begeistert von der neuen Technologie. Das einzige Problem ist, dass nicht jeder, der aufgeregt ist, das genaue Problem und alle Details der Lösung vollständig verstehen kann. Es war ja schließlich ein nicht triviales Problem mit einer nicht trivialen Lösung. Es braucht mehr als einen Tweet, einen Chat oder einen Blog-Beitrag, um das zu ausreichend zu schildern. Mit Kommunikationswerkzeugen wie Social Media, Blogposts und Blitzgesprächen auf Konferenzen wird die Nachricht auf dem Weg unscharf.

Schritt 3: Manie

Alle Hype Driven Developer lesen Blog-Beiträge und nehmen an Konferenzen teil. Bald setzen die Teams auf der ganzen Welt die neue Technologie ein. Aufgrund der unscharfen Botschaft treffen einige von ihnen eine voreilige Entscheidung, die gehypten Frameworks zu verwenden, obwohl es keines ihrer tatsächlichen Probleme löst. Das Team hat jedoch die Erwartung, dass diese neue Technologie helfen wird – man hört ja schließlich überall wie toll diese neue Sache ist.

Schritt 4: Enttäuschung

Im Laufe der Sprints erleichtert die Technologie das Leben des Teams dann doch nicht so sehr, wie man es sich erhofft hätte. Stattdessen kommt aber viel zusätzliche Arbeit daher. Viel Code Umschreiben, zusätzliche Zeit für das Erlernen der neuen Technologie. Die Teams werden langsamer, das Management ist sauer. Niemand ist happy, die Leute fühlen sich betrogen.

Schritt 5: Realisierung

Schließlich führt das Team eine Retrospektive durch und erkennt, welche Kompromisse man für die neue Technologie eingehen muss und für welchen Use Case die Technologie überhaupt relevant wäre. Alle werden klüger und treffen sicherlich nicht mehr so vorschnelle Entscheidungen... bis der nächste Hype auftaucht.

Fallbeispiele

Schauen wir uns einmal ein paar reale Beispiele an, wie diese 5 Schritte eines Hypes abgelaufen sein könnten.

Beispiel 1: React.js

  • Schritt 1: Komplizierte One-Page Apps wie Facebook haben so viele State changing Events, dass es schwierig ist, den Überblick zu behalten und den tatsächlichen Status der Appliklation konsistent zu halten.
  • Schritt 2: Facebook promotet neues Paradigma mit schönen Buzzwords „functional, virtual DOM, components“. Wow!
  • Schritt 3: Im Team hört man nun „Facebook hat das Front-End-Framework der Zukunft geschaffen! Schreiben wir von nun an alles in React!“
  • Schritt 4: Es tritt auf einmal viel, viel Arbeit auf.
  • Schritt 5: React eignet sich hervorragend für One-Page Apps mit vielen Notifications in Echtzeit, zahlt sich jedoch nicht unbedingt für einfachere Anwendungen aus.

Beispiel 2: Test Driven Development (TDD)

  • Schritt 1: David Heinemeier Hansson (Entwickler des Ruby on Rails-Frameworks) erkennt, dass es schwierig ist TDD mit Rails durchzuführen, da dieses Framework keine Architektur hat, die eine gute objektorientierte Programmierung unterstützt. Er trifft eine pragmatische Entscheidung: keine Tests im Voraus schreiben.
  • Schritt 2: Der Hype beginnt mit dem Blogpost und einem Talk. Knackig formuliert mit „TDD is dead. Long live testing.“
  • Schritt 3: Im Team wird geredet „Lassen wir doch Tests aus! Unser Guru sagt es. Wir haben sowieso keine Tests gemacht. Jetzt tun wir zumindest nicht mehr nur als ob. Wir sind endlich ehrlich.“
  • Schritt 4: Ups! Jetzt funktioniert noch weniger als wie vorher.
  • Schritt 5: „TDD ist weder tot oder lebendig. TDD unterliegt Kompromissen, einschließlich des Risikos von API-Änderungen, der Fähigkeiten der durchführenden Person und des vorhandenen Designs “ - Kent Beck.

Beispiel 3: Microservices

  • Schritt 1: Große Monolithanwendung skaliert schwer. Es gibt einen Punkt, an dem wir sie in einzelne Services aufteilen können. Es wird einfacher zu skalieren, sowohl teamübergreifend, als auch in Bezug auf Requests pro Sekunde.
  • Schritt 2: Es fliegen die Buzzwords herum „Skalierbarkeit, loose Coupling, Monolith“.
  • Schritt 3: Das Team sagt: „Schreiben wir doch alles in Services um! Wir haben sowieso so einen riesigen Ball an Spaghetti-Code, weil wir ja eine monolithische Architektur haben! Natürlich müssen wir alles in Microservices umschreiben!“
  • Schritt 4: Das Team sagt dann aber auch: „Mist! Die Entwicklung der App ist jetzt viel langsamer, schwierig zu deployen und wir verbringen viel Zeit damit, Fehler auf mehreren Systemen zu verfolgen.“
  • Schritt 5: Microservices erfordern gute DevOps Skills im Team und mit richtigem Engagement kann sich dieses Konzept durchaus auszahlen, um das System und das Team zu skalieren. Bevor aber ernsthafte Skalierungsprobleme überhaupt erreicht werden, sind Microservices ein Over-Investment.

Beispiel 4: NoSQL

  • Schritt 1: SQL-Datenbanken haben Probleme mit hohen Lasten und unstrukturierten Daten. Teams auf der ganzen Welt beginnen also mit der Entwicklung einer neuen Art von Datenbanken.
  • Schritt 2: Stichwörter wie „Skalierbarkeit, BigData, High Performance“ fliegen überall herum.
  • Schritt 3: Das Team sagt: „Unsere Datenbank ist zu langsam und nicht groß genug! Wir brauchen NoSql!“
  • Schritt 4: Danach sagt es: „Müssen wir wirklich Tabellen verbinden? Das ist ein No Go. Einfache SQL-Operationen werden immer schwieriger. Die Entwicklung ist langsam und unsere Kernprobleme bleiben trotzdem ungelöst.“
  • Schritt 5: NoSql sind Tools zur Lösung sehr spezifischer Probleme – entweder extrem hohe Datenmengen, unstrukturierte Daten oder sehr hohe Lasten. SQL ist eigentlich ein wunderbares Tool und kann auch mit hohen Lasten und großen Datenmengen gut umgehen, wenn es geschickt eingesetzt wird.

Beispiel 5: Elixir und Phoenix

  • Schritt 1: Web-Frameworks wie Ruby On Rails eignen sich nicht gut für High Performance Anwendungen, distributed Applications und Websockets.
  • Schritt 2: Es fallen wieder die Wörter „Skalierbarkeit, high Performance, Distributed, Fault-Tolerant“.
  • Schritt 3: Das Team: „Oh mein Gott, unsere Anwendung ist langsam und unser Chat ist nicht skalierbar! Kein Wunder dass nichts funktioniert!“
  • Schritt 4: Das Team, etwas später: „Wow, Functional Programming und der Distributed Approach zu Erlernen ist nicht so einfach. Wir sind jetzt sehr langsam.“
  • Schritt 5: Elixir und Phoenix sind großartige Frameworks, erfordern jedoch erhebliche Mühe um sie zu Lernen. Es zahlt sich nur auf lange Sicht aus, wenn eine speziell leistungsstarke App entwickelt werden soll.

Die Liste geht weiter und weiter. Im stark überfüllten Raum der IT gibt es viele Bereiche, in denen solche Hypes häufig auftreten. In der JavaScript-Welt werden täglich neue Frameworks geboren. Node.js („Event Programming“), reactive Programming, Meteor.js („Shared State“), Front-End-MVC, React.js. Und wie sie alle heißen. In der Softwareentwicklung entstehen auch neue Architekturen: Domain Driven Development, Hexagon, DCI. Man kann ja wirklich aus einer Fülle an Buzzwords und Hypes schöpfen!

Good Practices

Wenn wir uns also nicht auf die Aussagen und Meinungen anderer im Internet verlassen können, wie können wir dann aber kluge Entscheidungen treffen? Hier einige gute Praktiken:

Testen und recherchieren Sie, bevor Sie sich entscheiden.

Spikes – die favorisierte Technologie nicht aus Blogs lernen, sondern durch (abgesichertes) Learning by Doing. Nimm dir ein oder zwei Tage Zeit, um den Prototyp einer Funktionalität in der neuen Technologie zu erstellen, bevor du die Entscheidung triffst, alles zu wechseln. Lass das Team die Vor- und Nachteile analysieren.

Hackathons – eine großartige Möglichkeit, das Bewusstsein eines Teams für Kompromisse bei verschiedenen Technologien zu stärken. Anstatt nur eine Person, soll sich das ganze Team etwas Zeit herausnehmen, um alle interessanten, neuen Technologien auszuprobieren. So bekommt man auch eine Vorstellung, wie diese neuen Änderungen im gesamten Team funktionieren.

Die richtige Zeit

Im Prinzip kann man eigentlich jederzeit auf den Neue-Technologie-Hype-Zug aufspringen, wenn man wirklich sicher ist, dass sich die für den Wechsel aufzuwendenden Ressourcen auch bezahlt machen. Die meisten Technologien wurden entwickelt, um ein bestimmtes Problem zu lösen. Ist auch wirklich dieses bestimmte Problem hier auch vorhanden? Ist das Problem überhaupt groß genug? Wird der Wechsel auch genug Zeit sparen? Was passiert wenn nach dem Wechsel die Development Geschwindigkeit um den Faktor Zwei verlangsamt wird? Oder Faktor Vier?

Jedes Team ist unterschiedlich. Manche brauchen etwas länger, manche liefern schneller. Schnelle Teams langweilen sich mit einfachen Sachen – solche Teams sind es auch, die häufiger neue Technologien einführen.

Klar, jedes Team ist unterschiedlich, aber das ist keine Entschuldigung, keine Spikes zu verwenden oder keine Hackathons zu veranstalten. Wenn sich aber zeigt, dass das Team Probleme hat Ergebnisse zu liefern, dann ist Vorsicht geboten.

Die richtigen Leute

Ein starker technischer Hintergrund ist dein Freund – Menschen, die mit verschiedenen Paradigmen vertraut sind, die Theorie (z. B. Algorithmen, Parallelität, etc.) verstehen und eine gute Ingenieurkultur haben, neigen dazu, weniger zu übertreiben. Junge Developer lassen sich leichter vom Hype mitreißen. Aber diejenigen, die über die Jahre viele Technologien gesehen haben und oft in Schwierigkeiten waren, neigen dazu, etwas relativierte Ansichten über die Wahl der nächsten Technologie zu bekommen. Wissen und Erfahrung sind die Gegengifte zum Hype.

Entwickler Jobs in Deutschland

Das könnte dich auch interessieren