Neuerdings fällt mir immer häufiger eine Botschaft auf, die ich neuen SeLF-Projekten — jenen,  die Software programmieren möchten — an die Hand geben will: Du bist nicht Google. Du bist auch nicht Facebook, Amazon, WhatsApp. Was haben diese Firmen gemeinsam? Sie entwickeln coole neue Programmiersprachen und Frameworks mit tollen Namen und Funktionen.

Das sind etwa tolle Datenbanksysteme die auf Namen wie „MongoDB“ oder „CouchDB“ hören. Klingt cool! Oder Programmiersprachen wie Rust, Swift und Go. Samt Load-Balancing-Tools, tolle Deploying-Plattformen, Virtualisierungsframeworks, Tech-Stacks bis zum Umfallen.

Made to scale

All diese Werkzeuge haben eins gemeinsam: Sie wurden von gewinnorientierten Firmen als dringende Antworten auf Skalierungsprobleme entwickelt. Das können ganz verschiedene Probleme sein: Zu langsame Rechner oder zu viele Benutzer. Oder die Ineffizienz bestehender Sprachen, Debuggingprobleme, Teamarbeit oder welchen Probleme eine Billion-Dollar-Company sich gegenübersieht.

Dem Gegenüber stehst du mit deinem neuen Projekt: Einem Budget von 10.000 Euro, einer Nutzerbasis von maximal allen 45.000 Studierenden der Goethe-Universität, ein paar Mitarbeitern. Natürlich soll es cool werden und gut aussehen. Und es soll schnell fertig sein.

Deswegen brauchst du den Softwarestack des Webs, der vor einigen Jahren in Mode kam und seitdem keinen Tag älter geworden ist: Django, Ruby on Rails, ein Framework welches Datenbankinhalte darstellt und verwaltet, ohne dass du dafür viel programmieren musst. Du und deine Freunde könnt euch um ein cooles Design im aktuellen Metro-Stil (oder ist jetzt gerade das Material Design in?) kümmern. Was ihr bekommt, ist eine seit 40 Jahren entwickelte robuste Datenbank-Technologie namens SQL. Das klingt nach Großvaters Schießgewehr. Hat aber einen großen Vorteil: Wenn ihr euren Job gut macht und eure neue eLearning-Idee der Kracher wird, dann haben eure Daten den bestmöglichen Platz, den man sich vorstellen kann. Typischerweise überleben die Daten in einer SQL-Datenbank die zugeordnete Anwendung um einen großen Zeitraum. Eine gut gemachte relationale Datenbank ist schnell, skaliert und trennt Logikschichten.

Eine weitere Sache stellt der traditionelle Webstack sicher: Dass ihr eine Seite habt, die nicht nur mit dem neusten fancy Browser benutzbar ist, sondern im barrierefrei zugänglich ist. Zu euren behinderten Besuchern gehört auch eure Lieblingssuchmaschine Google.

Frontend: Here be Dragons

Mein Tipp: Baut serverseitig auf eine solide Basis. Klar könnt ihr Node.js verwenden. Oder klassisch Java auf Windows-Server? Kein Problem, solange die Datenbank auf dem Boden der Tatsachen bleibt. Ihr werdet verwundert sein, wie viele moderne Lösungen für alte Probleme ihr damit nutzen könnt und wie leicht sich auch die Programmiersprache ändern lässt, denn objektrelationales Mapping funktioniert fast überall gleich.

Wo ihr euch hingegen austoben könnt, ist beim Frontend. Das, was Benutzer sehen und wo die Gutachter von SeLF und eLF nicht mehr aus dem Staunen rauskommen. Es blinkt und blitzt dank JavaScript und 3D im Browser? Das Smartphone glüht während die Daten über den Bildschirm flitzen? Fantastisch.

Eine Entkrassungs-Strategie

Die Entscheidung für die richtige Technologie ist besonders bei einem eLearning- bzw. Programmierprojekt mit nur 12 Monaten Laufzeit sehr wichtig. Trotzdem habe ich schon viele Fehleinschätzungen erlebt — und auch selbst falsch eingeschätzt. Der Artikel You are not Google, der meinem Artikel zugrunde liegt, listet sechs Schritte zum „Entkrassen“ auf — englisch UNPHAT:

1. Understand the problem. Welches Problem willst du eigentlich lösen? Welcher Natur sind die Hürden, die dir auffallen? Welche technischen Hürden kannst du zu Papier bringen?
2. eNumerate: Kennst du Lösungen für ähnliche Probleme? Liste sie auf! Wie unterscheiden sich die Lösungsansätze? Bedenke: Fast jedes Problem der Menschheit wurde schonmal von irgendjemandem gelöst oder versucht zu lösen. Du brauchst das Rad nicht neu erfinden sondern stehst auf den Schultern von Giganten.
3. Paper: Lies, lies, lies. Mehr als 80% ihrer Zeit verbringen selbst gute Entwickler damit, zu lesen. Lies alles über deine favorisierte neue Methode.
4. Historical context: Welches Problem wollten die Macher deiner neuen Methode lösen? Wie lange hat es gedauert, das zu entwickeln und wem wurde damit geholfen? Falls das Produkt schon länger existiert, wer hat es ursprünglich entwickelt und von wem wurde es wann aufgekauft? Warum ist es Open-Source geworden?
5. Advantages: Gewichte die Vorteil gegenüber den Nachteilen deiner favorisierten Methode. Was kann sie besser als die Alternativen? Wie groß ist die Community? Ist es ein Forschungsprojekt?
6. Think: Überlege ehrlich, wie gut die neue Methode dein Problem löst. Funktioniert die Software überhaupt auf den dir zur Verfügung stehenden Maschinen? Kannst du ein Tutorial in der vorgegebenen Zeit (1 Stunde, nicht 1 Woche) durchführen? Kriegst du eine Entwicklungsumgebung zustande, mit der du arbeiten kannst? Wenn nicht, ist die Zeit vielleicht noch nicht reif für diese Methode.

Das Experimentieren mit neuer Technologie macht Spaß, aber die meisten coolen neuen Techniken sind deswegen interessant, weil kaum jemand mit ihnen gearbeitet hat. Vieles kommt aus dem akademischen Bereich, man kommt also oft mit Themen in Berührung, über die man eigentlich keine Ahnung hat. Neuronale Netzwerke auf Grafikkarten? Cool, aber wer bezahlt die 15.000€-Grafikkarte, den zugehörigen Computer und wer versteht das Paper, welches mit der Sofware veröffentlicht wurde? Zur Beratung was möglich ist, hilft oft auch der Blick nach links und rechts. Was können deine Mitstreiter, womit habt ihr Erfahrung? Wenn ihr alle „nur“ PHP-Programmierer seid, dann lasst die Grafikkarten links liegen und lernt eine Programmiersprache beyond PHP. Serverseitiges JavaScript oder Python ist euer Ding. Oder PHP mit Symfony. Beides auf einmal ist schon zu viel.