Entwicklung im Feierabendmodus

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Lucas Dohmen: Hallo und herzlich willkommen zu einer neuen Folge des innoQ-Podcast. Heute zu Gast ist der Robert. Hallo Robert.

Robert Glaser: Hi Lucas!

Lucas Dohmen: Wir sprechen heute in einem zweiten Teil noch mal über den Reisekosten-Gorilla. Diesmal aber aus einer technischen Perspektive. Aber vielleicht magst du erst mal kurz sagen, wer du bist - für die Leute, die es vergessen haben.

Robert Glaser: Kann man das vergessen? Ich bin doch jetzt so oft hier. [lachen] Nein, ich bin Robert. Ich bin Senior Consultant bei innoQ, jetzt schon seit fast 8 Jahren, und entwickle nebenbei, wie man vielleicht in der letzten Folge hören konnte, den sogenannten Reisekosten-Gorilla.

Lucas Dohmen: Klasse! Und du hast uns in der letzten Folge auch erzählt, dass ihr das so in einem Feierabendmodus macht. Also, man kommt von der Arbeit nach Hause und dann entwickelt man noch so ein bisschen. Manchmal vielleicht dann auch noch am Wochenende. Vielleicht auch in kürzeren Zeitslots und nicht jetzt acht Stunden am Stück. Ist das was, was eure Entscheidungen, was den Tech-Stack angeht beeinflusst hat?

Robert Glaser: Definitiv. Also, sogar zu einem sehr, sehr gewichtigem Anteil. Wir haben nämlich ganz am Anfang - also um noch mal einen Schritt zurückzugehen - Wir sind alle vier innige Liebhaber von Ruby on Rails. Wir machen da schon etliche Jahre - also wirklich sehr lange Jahre - erfolgreich mit Projekte. Und kennen - ich weiß gar nicht, ob ich leider sagen soll - aber wir kennen immer noch nichts Vergleichbares. Das hören wir auch von vielen Kollegen, die vielleicht gar nicht so hauptsächlich im Rails und Ruby Umfeld unterwegs sind. Und wir haben ganz am Anfang, als wir uns entschieden haben den Reisekosten-Gorilla zu bauen, haben wir vereinbart - unter uns vieren - bei uns wird keine Informatiker-Romantik herrschen. Wir ziehen das knallhart mit dem Stack durch, den wir aus unserer Westentasche blind und betrunken und was weiß ich nicht alles beherrschen, weil’s eben ultra kostbare Zeit ist, dass in seiner Freizeit zu tun oder am Wochenende. Und deswegen haben wir einfach gesagt, wir nehmen das, was wir können. Und nicht nur das, was wir können, sondern das, von dem wir halt auch wissen, dass es uns schnellstmöglich zu Ergebnissen verhilft. Weil wir eben noch gar nicht sagen können, machen wir mit diesem Projekt jemals ein florierendes Unternehmen? Trägt das Geschäftskonzept überhaupt? Das wissen wir alles noch nicht. Und um das zu beweisen, müssen wir erst mal schnell, entschuldige den Begriff, aber etwas auf die Straße bringen. Und da ist die Entscheidung für Rails halt immer noch, wie wir finden, goldrichtig.

Lucas Dohmen: Okay, also, aber ist, das ein MVP was ihr entwickelt oder ist wirklich ein fertiges Produkt? Was ist da euer erstes Ziel gewesen?

Robert Glaser: Also als erstes Ziel haben wir tatsächlich vorgehabt ein MVP, also ein sogenanntes minimal viable product oder minimum viable product zu entwickeln. Weil wir nämlich ganz konkret das Excel-Sheet, was bei innoQ für Reisekostenabrechnungen benutzt wurde, ablösen wollten. Und das war das minimale Feature Set. Ich sollte Ausgaben, Kilometerpauschalen, Verpflegungsmehraufwände in einer besseren Art vielleicht als zeilenweise erfassen können und das war’s. Ich drucke dann ein PDF aus und gebe das in die Buchhaltung. Und das war unser MVP. Und jetzt im letzten Jahr, wir bauen jetzt schon ein Jahr an dem Produkt und es ist ja jetzt auch live verfügbar (Man kann das 45 Tage lang kostenlos testen. Preise sind auch verfügbar), sind wir halt in einem Modus, wo wir deutlich über das MVP hinausgeschossen sind. Das war ja auch absolut berechtigt, weil wir in der Nutzung von innoQ einfach gesehen haben, das passt wie “Arsch auf Eimer”. Die aktuell circa 100 Mitarbeiter können da super mit arbeiten. Klar gibt es immer noch Extrawünsche. Und es gibt auch verschiedene Nutzertypen bei uns. Es gibt Beraterkollegen, die extrem viel reisen, und es gibt welche, die so gut wie gar nicht reisen. Und dann gibt es die dazwischen. Und für die alle muss es halt passen. Da war es einfach, enorm wertvolles Feedback von so vielen Leuten bei der MVP und der darüber hinausgehenden Entwicklung zu bekommen. Aber ich glaube, jetzt sind wir etwas abgeschweift.

Lucas Dohmen: [lacht] Das ist nicht schlimm. Du hast eben gesagt, für euch war klar, wenn ihr das schnell auf die Straße bringen wollt, dann muss es Rails sein. Und einer der Gründe ist ganz klar, dass ihr damit natürlich am vertrautesten seid. Aber siehst du da auch noch andere Gründe? Wo Rails seine Stärke ausspielt, um schnell was fertig zu kriegen?

Robert Glaser: Ich glaube, Rails bringt als sogenanntes Full-Stack Framework unglaublich viel mit. Wir hatten da ja sogar schon mal eine Podcast Episode zu. Sogar mit mir glaube ich. [lacht] Das ist schon so lange her.

Lucas Dohmen: Das war vor meiner Zeit bei innoQ. [lacht]

Robert Glaser: Das kann sein, ja. [lachen] Es bringt halt einmal unglaublich viel mit, dass man alles sofort benutzten kann. Also vom ORM mapper, egal wie ich zu ORM-Lösungen stehe, aber er ist halt dabei. Genau wie eine asset pipeline. Und such mal - man kann auch von der Sprockets basierten asset pipeline halten was man will - aber such das mal in dem Umfang bei anderen Web frameworks. [Zustimmung von Lucas].

Zum Bespiel Express in Node, es gibt ja, die sehen sich ja viel minimalistischer. Noch minimalistischer als vielleicht Sinatra in der Ruby-Welt. [Zustimmung von Lucas] Das was ich kenne, was Rails so am Nächsten kommt in der Java-Welt, ist tatsächlich Play. [Zustimmung von Lucas] Da habe ich auch schon was mitgemacht, aber ich würde immer noch Rails bevorzugen. Alleine vom Umfang, egal, wie viel ich davon nutze oder nicht, aber auch wegen den Konzepten. Ich will nicht, wenn ich plane ein Unternehmen zu gründen, mir wieder Gedanken mit vier Leuten machen müssen, wo ich irgendwelche gottverdammten Konfigurationsdateien ablege, wie die aussehen sollen und nutze ich da YAML oder JSON. Ich will das einfach nicht. Das ist meine Freizeit und da muss ich mich auch nicht selbst verwirklichen - da irgendwelche Technologien zu erfinden.

Lucas Dohmen: Ja, das ist für mich auch eine der großen Stärken. Dass Rails schon eine ganze Menge an Entscheidungen getroffen hat, und bei vielen Sachen hat man halt irgendwie vielleicht eine Meinung. Aber der Kollege, der mit dir am Abend das auch entwickelt, hat eine andere Meinung, aber die ist nicht so stark, dass man jetzt darüber streiten möchte. Man nimmt halt einfach das, was Rails sagt. Und an den Stellen wo man jetzt wirklich sagt, ich habe das Gefühl, Rails hat da eine falsche Entscheidung getroffen, da hat man meisten doch noch irgendeine Möglichkeit, umzudenken. Nicht an allen Stellen, aber an einigen Stellen.

Robert Glaser: Ein schönes Beispiel ist ja jetzt dieser sogenannte Webpacker [Zustimmung von Lucas]. Das ist - da haben sie, durch ein externes Gem, Webpack einfach in Rails eingebaut.

Lucas Dohmen: Magst du kurz sagen, was Webpack ist. Ich glaube, das kennt …

Robert Glaser: Webpack ist so ein, ja, Schweizer Taschenmesser, ist schon fast zu minimalistisch, [Lucas lacht]. Es ist ein extrem umfangreicher, bunter Strauß an Software, den man dazu benutzen kann, eine asset pipeline aufzubauen. Nicht nur um JavaScript zu bundeln und Module aufzulösen und ES6 zu transpilieren, sondern auch um bspw.Images mit Fingerprints zu versehen. Vielleicht noch zu komprimieren. Das kann sogar CSS. Ich kann SASS nach CSS übersetzen. Es ist einfach eine Lösung, die alles erschlagen will, was jemals einem beim Thema Assets begegnen kann. Dementsprechend hyperkomplex ist das auch zu konfigurieren. Und da habe ich mich schon gewundert, dass sich DHH dann auch dazu entschlossen hat, so eine hyperkomplexe Sache wie Webpack mit Rails irgendwie zu verheiraten. Weil das eigentlich so gar nicht wie Rails funktioniert. Tatsächlich haben sie’s aber mit diesem Webpacker Gem so gut hingekriegt, dass du das als ganz normaler Rails Anwender, der lieber eine Webpack basierte asset pipeline anstatt die werkseitige Sprockets asset pipeline nutzen möchte, gar nicht wirklich mit Webpack so in Verbindung kommt, um erst mal so einfache Aufgaben zu erledigen [Zustimmung von Lucas] wie beispielsweise eben JavaScript-Module aufzulösen und zu bundeln. Das fällt wirklich raus. Aber man sieht, da wir eine ganze Reihe Konfigurationen gebaut - Konfigurationsdateien en masse - die einen schon erst einmal schlucken lassen, [Zustimmung von Lucas] wenn man die sieht.

Lucas Dohmen: Okay, gibt’s denn Stellen, wo ihr von diesem Stack, den Rails vorgibt, abweicht? Oder habt ihr wirklich gesagt, wir folgen allen Sachen? Minitests, ERB, alles Mögliche?

Robert Glaser: Tatsächlich sind wir bis jetzt zu fast 100 % dem Standard-Stack gefolgt. Also, von Minitest bis Sprockets basierte asset pipeline, und sind damit jetzt auch ein Jahr sehr, sehr gut gefahren. Aber jetzt haben wir natürlich auch schon kleinere Themen, wie zum Beispiel, wir würden jetzt gerne schon ES6 mal benutzen, für unser JavaScript im Frontend. Und das ist halt mit Sprockets, also mit dem Standard Rails Umfang, nicht ganz so einfach hinzukriegen.

Und da kratzen wir uns echt am Kopf, ob wir uns dann der Omakase-Empfehlung Webpacker bedienen sollen oder vielleicht doch was eigenes nehmen, das vielleicht auf rollup basiert, was auch viel einfach zu verstehen ist. [Zustimmung von Lucas] Da sind wir noch nicht. Aber tatsächlich gibt es da Überlegungen, das zu tun. Auch, trotz unserer Vereinbarung am Anfang hin gegenläufig, dass wir knallhart uns an die Standards halten. Einfach um nur Speed [Zustimmung von Lucas] zu haben.

Lucas Dohmen: Und du hast auch am Anfang gesagt, dass ihr am liebsten nur Sachen nehmen wollt, die ihr kennt. Gibt’s denn dafür auch Ausnahmen, wo ihr Sachen genommen habt, die ihr vorher nicht benutzt habt?

Robert Glaser: Tatsächlich haben wir am Anfang ganz stoisch nur das genutzt, was wir konnten; was wir beherrscht haben. Stichwort: Standard Stack. Einfach auch dem Grunde wegen, dass wir das als Unternehmensgründung begreifen und nicht als, “Ich möchte in meiner Freizeit neue Technologien kennenlernen.” Was überhaupt nicht verwerflich ist. Das mache ich auch gerne, aber man kann halt nur begrenzt Dinge in seiner Freizeit noch in seinen Kopf kriegen. Und unser klares Ziel ist halt daraus ein Unternehmen zu entwickeln, und nicht irgendwie in unserer Freizeit neue Möglichkeiten kennenzulernen wie man beispielsweise vom Rails standard stack abweicht, welche alternativen ORM Mapper es gibt, und so weiter.

Aber um auf deine Frage zu antworten, wir haben tatsächlich jetzt ein paar Technologien ins Projekt geholt, die wir persönlich vorher nicht kannten, also, nicht ansatzweise so gut wie den Rails standard stack. Die aber gar nicht so in dem Gehege spielen. Beispielsweise Docker. Docker kannten wir vier sehr wenig bis gar nicht. Was sich aber auch ausgezahlt hat, einfach deswegen, dass wir einfach sehr lange gewartet haben und das so ein bisschen ausgesessen haben - den großen Hype - und als wir’s dann für unser Deployment benutzt haben, war es halt extrem stabil und das hat uns überrascht und uns auch super wenig Zeit eigentlich gekostet. Also, ich glaub' da hat sich dieses Aussitzen vielleicht bisschen gelohnt.

Lucas Dohmen: Aber ihr hättet ja auch sagen können wir machen Heroku, zum Beispiel. Also git push deployment. Warum habt ihr euch entschieden, da Docker zu nehmen? Weil es eigentlich ja euren Prinzipien widerspricht.

Robert Glaser: Genau, wie du vollkommen richtig sagst, haben wir uns Heroku auch als Erstes sogar angeguckt. Sind dann aber schnell zu AWS und Beanstalk gekommen. Elastic Beanstalk ist ja so ein bisschen das Amazon Pendant zu Heroku son bisschen. Also Plattform-as-a-Service. Und wir haben es einfach deswegen gemacht, weil wir das ganz nett fanden und Amazon halt auch in Deutschland Rechenzentren hat. Was für den Betrieb von uns schon wichtig war. [Zustimmung von Lucas] Und ein Kollege brachte uns dann darauf, dass Beanstalk mittlerweile auch Docker Support anbietet. Weil einer unserer Sorgen war auch aus der Heroku Erfahrung heraus ein bisschen, dass wenn man sehr schnell Updates fahren will, beispielsweise eine neue Ruby Version oder so was, dann ist man schon immer so ein bisschen an den kuratierten Stack von so einem Anbieter wie Heroku oder Beanstalk gebunden. Man kriegt natürlich unglaublich viel dadurch geschenkt, aber man zahlt einen kleinen Preis, dass man mit Updates eben nicht ganz so schnell unterwegs sein kann, sondern erst mal wieder warten muss, bis dieser Stack von den Betreuern ein bisschen gepflegt wurde. Das war tatsächlich ein Trade-Off, den wir gemacht haben, weil uns das einfach wichtig war.

Lucas Dohmen: Ihr habt euch ja für AWS entschieden. Was war da der ausschlaggebende Grund? Also, du hast einmal gesagt, dass sie in Deutschland hosten. Gibt es da noch andere Sachen, warum ihr euch für AWS entschieden habt?

Robert Glaser: Genau! Weil AWS einfach unglaublich viel anbietet, von dem was schon da ist. Beispielsweise hätte ich natürlich immer selber eine Queue aufsetzen können - auf Redis Basis. Das kann man ja sogar bei Amazon auch. Aber selbst dort haben wir uns dann entschieden, noch einfacher hinzugehen und SQS, also den Simple Queue Service von AWS zu nutzen. Weil ich dadurch eben noch weniger Arbeit habe. Und das einfach auch kostengünstig interessant war.

Lucas Dohmen: Eine der Sachen, die du im Vorgespräch gesagt hattest, war, dass das auch so gut mit Beanstalk integriert ist. Magst du das kurz erklären?

Robert Glaser: Genau, in Beanstalk redet man von sogenannten Applikationen. Und jede Applikation kann ein Web- und ein Worker-Environment haben, die auch voneinander getrennt sind. Und wir nutzen das halt um einmal, unsere Webanwendung auszuliefern, als auch, um unseren Worker zu betreiben, der irgendwelche asynchronen Jobs für unsere Anwendung ausführt, damit die nicht blockiert. Beispielsweise Emails verschicken, Belege handeln, umkonvertieren und so was. Da kam uns Docker auch zur Hilfe, weil Beanstalk gar nichts darüber wissen muss, was wir alles genau in diesen Containern tun. Wir schieben diese Box dahin. Die können wir auf unseren Entwicklermaschinen reproduzieren. Wir können sehr gut debuggen, wenn was auf Beanstalk nicht funktioniert - irgendein Beleg nicht konvertiert werden konnte oder was weiß ich - können wir das Lokal einfach sehr gut reproduzieren. Weil das die exakte Abbildung der Produktionsumgebung auf Beanstalk ist.

Lucas Dohmen: Und ihr setzt trotzdem auf dieses typische ActiveJob basierte Ding von Rails, da ihr da eine Code Basis habt, wo alles drin ist, richtig?

Robert Glaser: Genau, wir haben tatsächlich einen Monolithen, der mittlerweile mehr oder weniger groß ist - ich würde ihn noch als klein bezeichnen [Lucas lacht]. Das war auch eine unserer Entscheidungen ganz am Anfang. Nicht, dass jetzt Leute auf die Idee kommen, die haben’s jetzt falsch gemacht, weil sie’s nicht besser wissen. Wir waren uns sehr darüber bewusst und haben sehr bewusst die Entscheidung für einen Monolithen getroffen. Auch wieder aus Gründen. Wir haben ganz andere Probleme zu lösen, wie beispielsweise ein Geschäftsmodell zu validieren. Gibt es Nutzer, für die diese Anwendung hilfreich sein kann? Und da hilft es uns nicht, wenn wir das Ganze erst mal in einer schönen Architektur in Self-contained Systems oder was auch immer zerschneiden und von Beginn an eine viel zu aufwendige Architektur bauen, die wir am Ende vielleicht wegschmeißen, weil sich dann herausstellt, was ich nicht glaube, das es passiert und nicht hoffe, dass es passiert, dass das Geschäftsmodell einfach nicht trägt. Und um da eben auch mit diesem Feierabendmodus ins Spiel zu kommen, haben wir uns einfach bewusst für diese - wie DHH es nennt – Glorious Monolith Architektur entschieden. Denn er sagt in einem seiner Blogpost – denn können wir ja vielleicht in den Show notes verlinken – dass eben Monolith zu Unrecht ein beschmutzter Begriff ist – was wir auch denken. Wenn man denn einige Sachen beim Monolithenbau beachtet, kann man mit einem kleinen Team sehr schnell und sehr effizient dran arbeiten.

Lucas Dohmen: Ich meine, böse Zungen behaupten ja, man kann mit Rails nur Monolithen bauen. Ist das ein ausschlaggebender Grund: Ihr habt Rails benutzt, deshalb musstet ihr einen Monolithen bauen?

Robert Glaser: Genau, Rails ist ja bekanntermaßen nur dazu geeignet, einen Monolithen zu bauen, und man kann nichts anderes damit bauen. Ich weiß nicht, wie man auf so einen Trichter kommen kann. Ich halte das auch persönlich für völligen Bullshit - solche Aussagen. Rails ist einfach nur ein sehr gutes Web Framework, was sich sehr gut an Webstandards orientiert. Also, ich habe ein Request/Response cycle, ich bin stateless by default, ich habe eine Cookie basierte, verschlüsselte Session. Es ist egal, an welchen Servern hinter meinem load balancer meine Requests ankommen, da muss ich mich nicht drum kümmern. Deswegen sage ich sogar, Rails ist per default sehr gut dafür geeignet, eine hochgradig skalierte Webanwendung zu bauen.

Aber, um noch mal auf das Thema Monolith zu kommen, denke ich auch nicht, dass Rails in besonders starkem Maße, im Gegensatz zu anderen Web Frameworks, wie beispielsweise Play, einen dazu verleitet einen Monolithen zu bauen und sich vielleicht eine spätere Auseinanderschneidung in Self-contained Systems völlig zu verbauen. Im Gegenteil, ich glaube, Rails macht das dadurch sehr einfach, dass es eben serverseitiges HTML proklamiert und so weiter und so fort, und nicht wie viele Single Page Web Frameworks, die auf Client-Seite propagieren, die Architektur dort hochzuziehen. Also, wenn ich Rails benutze und dem Standardweg folge und das nicht zwanghaft ohne Gründe versuche mit einer Single Page App basierten Architektur zu verheiraten, verbaue ich mir überhaupt nichts für die Zukunft. Im Gegenteil, wir planen ja auch irgendwann, wenn wir denn mal ein florierendes Unternehmen sein sollten, mit vielleicht mehr Entwicklern als uns vier, dann planen wir ja auch Architekturänderungen, um diesen Teamgedanken mehr Zuspruch zu geben. Also, wenn wir irgendwann dann mal verschiedene Teams haben sollten, die verschiedene Teile der Anwendung entwickeln müssen, wie beispielsweise die Backoffice Ansicht oder das Profilmanagement, wo der User sein Passwort ändern kann oder seine Zahlungsdaten ändert, das will man dann vielleicht langfristig nicht mehr bei einem Team alles haben. Oder in einem System. Und dadurch, dass wir Dinge wie serverseitiges Markup - wir nutzen keine Single Page Apps ohne Grund - beherzigen, verbauen wir uns für die Zukunft auch überhaupt nichts. Ich kann das Ding dann irgendwann vielleicht sogar sehr gut in Self-contained Systems zerschneiden, weil ich das serverseitige HTML auch sehr gut transkludieren kann.

Lucas Dohmen: Und eine Sache, die ja auch viele Leute an den Microservices oder den Self-contained Systems schätzen, ist ja das unabhängige Deployment. Gerade wenn man so etwas machen möchte wie Continues Delivery. Ist das ein Paint point bei euch, dass ihr an manchen Stellen denkt, hmmm, jetzt kriegen wir das nicht deployed, weil es ein Monolith ist. Ist das was …

Robert Glaser: Überhaupt gar nicht. Wir sind halt zugegebenermaßen auch ein sehr kleines Team. Die dann auch noch nicht mal ihre volle Tageszeit daran arbeiten. Sondern eben im Feierabend und am Wochenende und vielleicht mal dann und wann tagsüber. Da kommen wir uns, ehrlich gesagt, aktuell Null ins Gehege.

Lucas Dohmen: Also würdest du sagen, für euch wäre jetzt so eine Self-contained Systems-Architektur eine frühzeitige Optimierung gewesen, die keine Vorteile für euch gebracht hätte?

Robert Glaser: Ich glaube, die hätte uns zu so einem frühen Zeitpunkt überhaupt keine Vorteile gebracht, weil wir eben ein kleines und, das muss man auch dazu sagen, extrem eingespieltes Team sind. Wir haben schon sehr viele Projekte zusammen gemacht. Kennen alle die Technologie. Haben alle einen ähnlichen Entwicklungsrhythmus. Und das jetzt per se zu zerschlagen, einfach weil man’s vielleicht so machen sollte, um für die nächsten Hundert Jahre gerüstet zu sein - ich übertreib jetzt ein bisschen, so ein Fall kann schon deutlich früher kommen – haben wir uns einfach entschieden, es nicht zu tun. Weil wir eben als Primärziel erst mal keine Architektur schaffen mussten, die von vielen Teams sehr gut weiterentwickelt werden kann. Sondern, wir wollten halt ein Geschäftsmodell entwickeln und validieren, ob das prüft. Dafür ist ein Monolith in unserer Teamkonstellation eine sehr sehr gute Option.

Lucas Dohmen: Eine Sache, die ich mir als große Herausforderung in eurem Arbeitsmodus vorstelle, ist ja, dass ihr sehr asynchron arbeitet. Also vielleicht hat der Robert Dienstagabend nichts vor. Der arbeitet jetzt mal vier Stunden und der Rest ist gerade mal überhaupt nicht da. Wie geht ihr damit um, dass trotzdem alle wissen, wo ihr steht; wer an was arbeitet? Wie kommt ihr da zurecht?

Robert Glaser: Also wie jedes ordentliche Start-Up nutzen wir natürlich Slack für den Hauptteil unserer Kommunikation. Wir haben tatsächlich auch sehr wenig Channels. Was cool ist, ist, dass wir Externe hin zu holen können. Beispielsweise unseren Designer oder unsere Kollegin, die das Business-Development aktuell so ein bisschen für uns macht. Das hilft uns schon sehr. Wobei Slack einen auch so ein bisschen überfluten kann. Und man muss auch in so einem kleinen Team, wie wir es sind, extrem penibel darauf achten – das müssen wir auch in Zukunft noch stärker beherzigen – dass man einfach keinen information overflow erzeugt. Vielleicht muss man da auch ein bisschen - in so einer Unternehmensgründungphase in der Freizeit - stärkere Richtlinien zum Thema Kommunikation schaffen, wie wir sie gerade bei der Technologie haben. Wie kommunizieren wir? Was ist sinnlos? Wann schneiden wir das raus und wann ist was wichtig?

Lucas Dohmen: Also ist das für dich vor allem eine Frage der Disziplin?

Robert Glaser: Genau, ja.

Lucas Dohmen: Und wie funktioniert das, wenn beispielsweise du ein Feature bauen möchtest, wo vielleicht ein Kollege schon mit angefangen hat, was du aber brauchst, um dein Feature zu bauen? Bist du dann blockiert? Wie geht ihr damit um?

Robert Glaser: Wir stimmen uns da natürlich ab und versuchend die Features in unseren Backlogs möglichst isoliert zu halten. Aber so ein größeres Feature, was halt auch viele Teile der Anwendung niederschlägt, wie zum Beispiel ein Payment – da hat man ja sehr viele Berührungspunkte und muss auch noch mal unter Umständen ans Datenmodell dran und so weiter und so fort – da versuchen wir uns natürlich, da die asynchrone Arbeit sehr zu erleichtern, indem wir die Pakete sehr klein schneiden. Was wir auch immer machen, ist, keiner entwickelt irgendwie im U-Boot ein Feature vor sich hin und deployed das dann. Wir machen also Pull Requests by Default, kann man so sagen. Es sei denn, es sind wirklich kleine Textänderungen auf der Website, die nicht rechtsrelevant sind oder so was. Das kann man natürlich direkt auf dem Master machen.

Aber wir haben uns schon angewöhnt, irgendwann Pull Requests zu nutzen – zum Standard. Sodass mindestens vier Augen sich mal ein Feature angeguckt haben. Einfach, weil auch so eine – wir sind noch keine gigantische Anwendung – aber, um auch Wissen stetig zu verteilen. Wir wollen nämlich nicht, dass es irgendwann den bei uns im Team gibt, der sich extrem gut mit dem Payment auskennt. Oder der sich extrem gut mit dem User-Management auskennt. So schafft man halt so Silos, in schon so einem kleinen Team und das sollte man halt tunlichst vermeiden. Und wenn es halt um Features geht, die einen Niederschlag auf das User Interface haben, beispielsweise ich entwickle neue Formulare oder was weiß ich, dann gehen wir tatsächlich auch erst mal, wenn das komplexere Themen sind, mit einem schnellen, leichtgewichtigen Wireframing daran. Das können wir, müssen wir sogar remote machen. Das gibt es verschiedene Mittel und Wege. Wir haben ein iPad Pro im Einsatz, wo man den Screen ja auch capturen kann und remote übertrage kann. Roman macht das zum Beispiel. Dann schließen wir uns über Telefon oder Slack in einen Call zusammen, wireframen was. Er macht einen Screen capture und sendet mir den quasi von Köln nach Berlin und wir können quasi live darüber reden. Das ist immer noch nicht so, als wären wir zusammen in einem Raum, aber das ist die maximale Annäherung an diesen Zustand.

Lucas Dohmen: Das bedeutet, dass ihr auch ein Remote-Team seid? Also ihr seid nicht alle in derselben Stadt, sondern ihr seid über Deutschland verteilt?

Robert Glaser: Genau. Also Tim und ich sitzen in Berlin. Roman sitzt in Köln und der Jan sitzt in Krefeld. Also, wir haben eine NRW Bastion und eine Berlin Bastion. Genau. Aber ich glaube, das funktioniert auch sehr gut. Wir haben manchmal Treffen, wenn wir beispielsweise ein wichtiges, großes Feature oder einen Meilenstein, den wir erreicht haben – den feiern wir ganz gerne. Das sollte man auch tun. Eben um nicht in so einem Endlos-Spurt zu enden und gar nicht mehr wahrzunehmen, dass man tatsächlich auch mal einen Erfolg erreicht hat. Hört sich nach Plattitüde an, aber Erfolge sollte man, gerade in dem Kontext, wirklich auch mal feiern. Dann schließen wir uns an einem Ort auch zusammen, und dann geht es vielleicht dann auch wieder weiter. Und wir arbeiten im Team vor Ort zusammen an irgendeinem größeren Feature. Oder wir machen mal einen Bug mash, wo wir mit kurzen Abstimmungswegen über den Küchentisch hinweg dann uns quasi abstimmen können: Hier wie war das? Warum tritt der Bug auf? Und so weiter und so fort. Das sind halt Werkzeuge, um aus dieser Remote-Arbeit auch mal auszubrechen und halt wirklich gebündelt was wegzuschaffen.

Lucas Dohmen: Ja. Und von der Teamstruktur her? Seit ihr alles Universalisten, die an allem arbeiten können? Oder seid ihr irgendwie zwei Frontendler, zwei Backendler? Wie seid ihr da aufgestellt?

Robert Glaser: Also wir arbeiten alle am UI, als auch am Backend mit. Das liegt einfach in unserer Natur. Wir sind alle irgendwie – ich möchte jetzt gar nicht den schlimmen Begriff Full-Stack-Entwickler bemühen - aber wir können das alles. Klar hat der eine oder andere Fokuspunkte, die auch saisonal schwanken können. Ich habe früher sehr viel Backend-Entwicklung gemacht, mache jetzt sehr viel Frontend-Entwicklung. Das wird nächstes Jahr vielleicht auch mal wieder anders sein. Ich weiß es nicht. Aber, dadurch dass man immer so pendelt und auch immer mit allem Berührungspunkte hat, baut man, glaube ich, auch am besten Wissen auf.

Lucas Dohmen: Das bedeutet auch, dass im Prinzip jeder von euch jedes Ticket übernehmen kann?

Robert Glaser: Klar! Das ist schon so. Wir haben natürlich Spezialfälle, wie zum Beispiel Illustrationen für die Startseite bauen. Oder ein On-Boarding illustrieren. Das kann dann wirklich, weil uns da auch einfach die Kompetenz fehlt, nur unser Illustrator machen. Auch zum Thema Animationen. Aber das geht ja schon deutlich über die klassische Full-Stack Entwicklung hinaus.

Lucas Dohmen: Auch über euch vier hinaus?

Robert Glaser: Ja, definitiv! Ja. Aber wir versuchen schon, das Kernprodukt komplett selbst zu entwickeln. Und für Spezialfälle, weil man eben nicht alles gut kann, einfach die entsprechenden Profis dazu zu holen. Dazu zählt halt auch Business Development. Da sind wir auch nicht irgendwie mit einem BWL-Studium gesegnet, sondern müssen da ganz einfach auch auf das Wissen von anderen zurückgreifen.

Lucas Dohmen: Und eine Sache, die du gesagt hast, ist, dass ihr auf AWS gesetzt habt. Habt ihr da Sorge über diesen Vendor Lock-in, dass ihr nicht mehr zu einem anderen Anbieter wechseln könnt? Ist das was, wo ihr denkt, das könnte sich später rächen?

Robert Glaser: Das ist tatsächlich eine sehr gute Frage, die wir uns auch schon selbst gestellt haben. Weil, wenn man sich natürlich in so einen Anbieter so einkauft und auch hingeht, und wenn man eine Queue braucht, nimmt man eben die Queue, die der Anwender bereitstellt und selbstentwickelt hat, dann kauft man sich natürlich sehr heftig in so eine Infrastruktur von so einem Anbieter ein. Aber das tun wir halt auch bewusst, weil eben aktuell eben nur das schnelle Iterieren nur zählt. Uns ist bewusst, dass wir irgendwann wahrscheinlich ein paar Probleme haben sollten, wenn wir von AWS wegziehen müssen – aus welchen Gründen auch immer. Die ich auch aktuell überhaupt nicht sehe. Und ich glaube es auch nicht zielführend eine Anwendung so over zu engineeren, so, dass die ultra portabel ist und in jeder Cloud ohne Konfigurationsanpassung – übertrieben formuliert – laufen kann. Wir versuchen uns schon so ein bisschen an der Twelve-Factor-App zu orientieren. Also, die Anwendung wird halt über Umgebungsvariablen konfiguriert. Log nach standard out und so weiter.

Da kam man ja schon bei sehr vielen Anbietern sehr einfach reinkommen. Gerade auch Docker ermöglicht das ja eigentlich heutzutage noch viel besser. Ich bin gar nicht mehr darauf angewiesen, dass der Anbieter, zu dem ich vielleicht umziehen möchte, einen Rails-Stack hat – ein Deployment, das irgendwie Ruby unterstützt. Das braucht den überhaupt nicht mehr zu interessieren, weil ich einfach ihm nur eine Box gebe, die er auf einem Port HTTP spricht. Und das war’s dann. Und ich glaube, da wird auch noch sehr viel passieren was so Plattform-as-a-Service-Anbieter angeht.

Lucas Dohmen: Okay. Da denkst du, wenn da jetzt der nächste supercoole Anbieter kommen sollte, dann könntet ihr immer noch wechseln. Ihr seid nicht so fest verdrahtet, aber ihr seht das nicht als Hauptaugenmerk von euren Entscheidungen?

Robert Glaser: Nee, wir sehen das auf jeden Fall gar nicht als Hauptaugenmerk. Also, wir könnten sicher wechseln und es würde etliche Arbeit kosten, wenn man mal die reine Webanwendung, die HTTP spricht, außen vorlässt – die ist wahrscheinlich hochgradig portabel. Was weniger portable ist, sind die Sachen, die drumherum sind. Die Datenbank, die in RDS läuft. Das ist ein Amazon-Dienst, der Relationale Datenbank Systeme bereitstellt. Klar, da könnte ich mir einen Dump ziehen und den in eine andere Datenbank einspielen, die dieselbe Engine hat. Aber ich verliere halt auch sehr viel dadurch, dass ich halt keine Snapshots mehr habe, die ich mir einfach zusammenklicken kann. Wartungsfenster, die ich vorgeben kann, wo dann jemand am anderen Ende der Welt sich diesen Server anguckt und Wartungen vornimmt und Updates einspielt. Das habe ich halt alles nicht, wenn ich mich dazu entscheide, so ein Business nicht in so einer Cloud-Umgebung hochzuziehen.

Lucas Dohmen: Wenn du jetzt ein Jahr zurückgehen würdest und deinem früheren Ich einen Tipp geben würdest, das solltest du vermeiden? Gebe es da was, wo du sagen würdest, da solltet ihr euch anders entscheiden?

Robert Glaser: Tatsächlich sind wir mit den Entscheidungen, die wir getroffen haben, echt extrem gut gefahren. Ich wüsste jetzt auf Anhieb auch gar nicht, was man da - sollte man jetzt alles von vorne machen was die technische Seite angeht - komplett anders machen sollte. Was die Business-Seite angeht, haben wir halt einfach unglaublich viel gelernt. Wenn ich, wenn ich dasselbe noch mal neu starten würde, hätte ich auch ganz viel Wissen durch das, was ich schon jetzt gelernt habe. Und da bräuchte ich wahrscheinlich einfach auch nicht mehr so viel externe Hilfe. Also, sollte ich so was noch mal machen, dann habe ich halt diese ganzen Lernerfahrungen, die ich jetzt in diesem Kontext gemacht habe, die ich dann einfach nutzen könnte und dadurch vielleicht weniger externen Support bräuchte.

Lucas Dohmen: Hmmm. Zum Abschluss, welche Sache hast du auf dem Weg entdeckt, wo du gesagt hast, “Wow, was für eine Überraschung, dass das so cool ist” oder wo du sagst, das sollte man auch mal ausprobieren, weil das einfach eine Sache ist, die mehr gebracht hat, als du vielleicht gedacht hast?

Robert Glaser: Das ist eine gute Frage, weil wir ja eigentlich vereinbart hatten, dass wir stoisch den Weg beschreiten werden ohne uns groß umzugucken, was Links und Rechts technologisch so passiert, um eben einfach Geschwindigkeit ohne Ende zu haben. Tatsächlich hat uns aber eine Sache extrem überrascht. Und das ist - das nutzen wir auch - das ist der CI-Service von GitLab. Wir nutzen gitLab.com, um unsere Repositories zu verwalten. Und uns hat einfach extrem überrascht, wie super gut mittlerweile so ein Continuous Integration Service mit einem Repositories-Management-System integriert sein kann, und was für Vorteile halt einfach Docker in dem Kontext bringt. Also ich muss da kein Jenkins mehr Kaputt-Installieren, bis ich dann endlich mal meine Anwendung testen oder verpacken kann. Sondern, da muss das CI-System halt auch mal nichts von wissen, weil es das alles in einem Docker-Container tun kann.

Ich kann durch Sachen wie Docker-in-Docker, da kann einem zu Anfang schon mal so ein bisschen schwindlig werden – aber das ist auch extrem praktisch, um so ein CI-System halt einfach auch für den Anbieter, der so was entwickelt und anbietet, möglichst sauber zu halten – die Architektur – viele Vorteile bieten. Wie zum Beispiel, ich erlaube halt den Nutzern meines CI-Systems, dass sie sich ihre Umgebung per Docker zusammenbauen können. Und dann letzten Endes die eigentliche Anwendung, die da dann nach einem Commit gebaut werden soll, auch noch mal in einem Docker-Container, in diesem CI-Docker-Container, zu bauen, in eine Registry zu pushen, Tests in diesem Container auszuführen und so weiter und so fort. Also das war schon eine Technologie, wo wir echt heilfroh sind, dass wir die haben. Und wir haben die sogar dadurch erweitert, dass wir in unserem AWS-Account EC2-Maschinen haben, die quasi Build-Slaves, in Jenkins-Sprech sind. In GitLab nennt man das Runner. Einfach weil, wenn die Amerikaner aufwachen, dann merkt man beim GitLab.com schon deutlich, dass man sehr lange auf Builds warten muss. Weil diese sogenannten Community-Runner halt auch von Firmen wie DigitalOcean gesponsert sind. Und das ist auch total okay, wie ich finde, dass man da zu Stoßzeiten auch einfach nicht mehr erwarten kann. Was ich top finde, ist, dass man das ganz einfach durch eigenes Blech oder eine eigenen Cloud-Maschine erweitern kann, auf der dann der letztendliche Build ausgeführt wird. Also, das was schon so für uns die Technologie-Überraschung dieses Jahres. Auch wenn wir entschieden haben, uns keine Technologie-Überraschung anzusehen zu wollen.

Lucas Dohmen: Und wenn du jetzt einem jungen zukünftigen Unternehmer einen Rat geben würdest, würdest du trotzdem sagen, versuch die “langweiligen Technologien”, die du schon kennst, zu benutzen?

Robert Glaser: Definitiv würde ich das immer raten. Aber je nachdem was so der Day-Job für einen bereithält, schaut man natürlich schon nach links und nach rechts. Das ist ja auch Aufgabe und das tun wir auch leidenschaftlich gerne als hauptberufliche Berater. Aber wenn es dann halt darum geht einfach, eben möglichst schnell, ein Geschäftsmodell zu überprüfen, muss man sich halt davon lösen. Und rein finanziell oder freizeitsparend orientiert, muss man halt irgendwie sehr stringent eine Linie verfolgen und einfach wenig ausprobieren. Also, so ein bisschen die klassische Informatiker Romantik bannen und vermeiden.

Lucas Dohmen: Zurückfahren zumindest.

Robert Glaser: Genau!

Lucas Dohmen: Gut, dann danke ich dir für all die interessanten Informationen.

Robert Glaser: Ich habe zu danken!

Lucas Dohmen: Und ja, den Hörern bis zum nächsten Mal.

Robert Glaser: Tschüss!

Lucas Dohmen: Tschüss!