#120 No-Code ist technische Schuld!

No-Code-Tools sind technische Schulden!

Wenn es zu dem Thema No-Code kommt, gibt es oft zwei Lager: Die einen lieben es. Die anderen sagen “Das ist doch gar kein richtiges Programmieren”. Dennoch gibt es Firmen, die No-Code-Plattformen im großen Stil einsetzen. Und immer wenn damit “mal was richtiges” gebaut wird, stellen sich dieselben Fragen wie bei richtiger Software-Entwicklung: Wie sieht es mit der Security / Maintainability / Skalierung und Co aus? Und wenn wir sowas auf den Tisch bringen, dann ist das Thema Refactoring und technische Schulden nicht mehr weit.

Und genau darum geht es in dieser Episode. Wolfgang ist fest überzeugt von “No-Code-Tools sind technische Schulden!”. Und Andy lässt sich das ganze mal erklären, um zu verstehen, was er eigentlich damit meint. Wir sprechen darüber, was No-Code und Low-Code eigentlich ist, was technische Schulden sind und warum dies ggf. nicht subjektiv zu sehen ist, welche Probleme sich bei großer No-Code-Nutzung auftun und ob klassische Probleme (aber auch Lösungen) der Software-Entwicklung sich auf die No-Code-Entwicklung übertragen lassen.

Bonus: Streit auf LinkedIn ist wohl nicht gern gesehen.

**** Diese Episode wird von der HANDELSBLATT MEDIA GROUP gesponsert.

Wirtschaft ist nicht immer einfach. Deswegen lautet die Mission der HANDELSBLATT MEDIA GROUP: „Wir möchten Menschen befähigen, die Wirtschaft zu verstehen.“ Mit ihren Kernprodukten, dem Handelsblatt und der WirtschaftsWoche, sowie 160.000 Abonnements, 15 Millionen Besuchern und 3 Milliarden Anfragen in einem Monat leisten sie einen wichtigen Beitrag zur Orientierung und Meinungsbildung in den Bereichen Wirtschaft und Politik und machen damit einen ausgezeichneten Job.

Wenn du Teil dieser Mission sein möchtest, schau auf https://engineeringkiosk.dev/handelsblatt vorbei und werde ein Teil der HANDELSBLATT MEDIA GROUP.

********

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) No-Code sind technische Schulden

(00:03:13) Die Handelsblatt Media Group (Werbung)

(00:04:18) Was ist No-Code und Low-Code?

(00:23:03) Was ist Technical Debt?

(00:32:08) Technische Schulden bei keinem Code - Wie geht das?

(00:38:07) Gelöste Probleme im High-Code-Umfeld sind neue Probleme im No-Code-Umfeld

(00:47:35) Security im No-Code-Umfeld

(00:52:38) Steht No-Code im Konflikt zu moderner Software-Entwicklung?

(00:59:17) No-Code richtig eingesetzt ist dein Beschleuniger

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:04 - 00:00:48)

NoCode ist technische Schuld. Zumindest ist das meine Theorie. Und damit willkommen zu einer neuen Episode im Engineering Kiosk. Heute dreht sich alles um das Thema NoCode und die eventuell damit verbundenen technischen Schulden. Wir besprechen, ob NoCode die magische Lösung ist, alles schneller und zugänglicher zu machen und wir diskutieren, wie NoCode die Softwareentwicklung demokratisieren könnte und ob es wirklich ein Allheilmittel gegen den Fachkräftemangel sein kann. Du erfährst, was technische Schulden wirklich sind und warum diese nicht immer negativ sein müssen. Also auf geht's, tauchen mit uns ein in die Welt der APIs, Workflows, automatisierten Prozesse, No-Code, Low-Code, High-Code und natürlich den technischen Schulden.

Andy Grunwald (00:00:48 - 00:01:21)

Einige Leute fragen uns, hey, wie kommt ihr immer eigentlich auf eure Themenideen für den Podcast? Ich meine, ihr habt jetzt circa 120 Folgen, 120 Episoden. Und irgendwann müssen euch doch mal die Themen ausgehen. Und das heutige Thema kam eigentlich durch Zufall. Storytime. Der Wolfgang hört sehr, sehr viel Podcasts. Also wenn ich sage sehr, sehr viel, meine ich sehr, sehr, sehr viel. Der hört pro Tag glaube ich drei, vier, fünf Podcasts. Und auf jeden Fall hat er versucht auf LinkedIn dann einen Streit anzufangen über einen Podcast, den er gehört hat.

Wolfi Gassler (00:01:21 - 00:01:26)

Man meint, ich streite nicht. Ich streite nur mit dir. In der Öffentlichkeit streite ich natürlich nicht.

Andy Grunwald (00:01:26 - 00:01:58)

Von mir aus wollte er auch seine Beraterposition stärken. Ich weiß es nicht. Auf jeden Fall fängt der LinkedIn-Post von Wolfgang, den wir natürlich auch in den Schauern uns verlinken, an mit, CTOs who don't think that refactoring is bad and mention refactoring more than once in an interview are bad CTOs and refactoring is bullshit. Und das war ein Quote von einem CTO einer Firma namens FIN. FIN ist ein Service, wo man Autos mieten kann, so ähnlich wie so eine Software-as-a-Service-Subscription. Kannst du da Autos mieten?

Wolfi Gassler (00:01:58 - 00:02:02)

Also Auto-Abo eigentlich, so ein Auto-Abo abschließen für ein paar Monate.

Andy Grunwald (00:02:02 - 00:02:04)

Also Spotify des Autos, wenn du so möchtest.

Wolfi Gassler (00:02:04 - 00:02:05)

Ja, genau.

Andy Grunwald (00:02:05 - 00:02:26)

Und FIN nutzt sehr, sehr viel No-Code beziehungsweise Low-Code. Und dann hat Wolfgang diesen Post gemacht und hat dann gesagt, Andi jetzt like den mal, der muss jetzt hier ein bisschen steil gehen. Und dann hat auch der CTO von Fynn geantwortet, aber dann hat Wolfgang irgendwie das Gas da rausgenommen. Auf jeden Fall wurde der Streit.

Wolfi Gassler (00:02:26 - 00:02:30)

Ich habe ihn eingeladen in unseren Podcast, aber noch nichts bisher gehört.

Andy Grunwald (00:02:31 - 00:03:02)

Auf jeden Fall ist dieser Post dann in eine Diskussion umgewandelt worden zwischen Wolfgang und mir im WhatsApp, was ich so über No-Code denke, was ich so über Refactoring denke, technische Schulden. Und irgendwann sagt der Wolfgang, hey, Andi, hör mal jetzt auf zu diskutieren. Ich merk schon, das hier ist eine eigene Podcast-Folge. Worum geht es heute? Heute geht es um technische Schulden, weil das ist eben die Regel, der Trigger fürs Refactoring und No-Code und das Ganze nämlich in Verbindung.

Wolfi Gassler (00:03:02 - 00:03:13)

Vor allem weil No-Code ja derzeit so das absolute Hipster-Wort ist und irgendwie überall Anwendung findet und jeder macht nur mehr No-Code und Low-Code und das wird uns alle retten und ganz viel Zeit bescheren.

Andy Grunwald (00:04:18 - 00:04:43)

Und bevor wir jetzt in deine heiße These einsteigen mit Refactoring ist doof, beziehungsweise du sagst ja die andere These, dass Refactoring sein muss, hol mich mal ganz kurz ab, weil ich bin genau wie bei AI und GitHub Copilot ein Late Adopter, was No-Code angeht. Was ist No-Code für dich? Wie würdest du den ersten Paragraf von Wikipedia zum Artikel zu NoCode beschreiben?

Wolfi Gassler (00:04:43 - 00:06:42)

Ich bezweifle ja, dass du gar keine NoCode-Tools verwendest, weil du verwendest ja auch sicher irgendwelche Schnittstellen und APIs und irgendwelche Services. Und eigentlich ist es ja schon ein NoCode-Tool. Also wenn du irgendwo einen Service hast, eine API und da HTTP-Requests hinsendest und da passiert irgendwas, dann hast du da ja eigentlich schon ein NoCode-Tool, das du verwendest. Aber meistens spricht man natürlich eher von NoCode, wenn du diese Services, die du da ansprichst bei API in irgendeiner Form verbindest und vielleicht eine Oberfläche dazu baust, ein Formular, das du absenden kannst und im Hintergrund wird das irgendwo abgespeichert und triggert dann eine E-Mail oder so. Also dass man sich da im Prinzip Prozesse, die man sonst mühsam wahrscheinlich irgendwie programmieren würde mit Formularen, Datenbanken, dass man da ein Toolset verwendet, das einem das Ganze erleichtert. Also früher hätte man gesagt, vor dieser ganzen No-Code-Welle und No-Code-Tool-Welle, man speichert die Daten vielleicht in einem Google Sheet und spricht dann über die API dieses Google Sheet an und triggert dann im Hintergrund vielleicht wieder irgendeinen anderen Service, der E-Mails aussendet oder so. Und das hat man sich vielleicht noch selber zusammengeschustert, irgendwie mit ein bisschen Glue-Code. Und jetzt kannst du halt diesen Glue-Code auch nochmal in der Oberfläche bereitstellen, indem du gewisse Sachen zusammen klickst und in einer Oberfläche verbindest, also so klassische Pipelines baust, die dann in irgendeiner Form ablaufen. Und nachdem da nirgends dann Code involviert ist, weil du alles mit Klicky Bunty zusammen baust, heißt das Ganze eben No-Code und ist dann eben auch für Nicht-Developer geeignet, sagt man zumindestens, weil die natürlich ohne Code sich dann auch irgendwas zusammen klicken können und die können Google Docs beherrschen, die können vielleicht ein Airtable, so eine Tabellenkalkulation in irgendeiner Form verwenden, die können zusammen klicken, wenn dort ein neuer Eintrag passiert in der Tabelle, dann sende er ein E-Mail aus zum Beispiel. Das kann wahrscheinlich jede und jeder selbstständig machen, der einigermaßen sich am Computer auskennt.

Andy Grunwald (00:06:42 - 00:06:58)

Ich nutze den Service IFTTT, if this then that, und dem habe ich gesagt, prüfe bitte kontinuierlich den RSS-Feed von Home Assistant und immer wenn beim Blog ein neuer Post kommt, schicke ihn mir bitte per E-Mail.

Wolfi Gassler (00:06:58 - 00:07:00)

Eben, dann hast du einen No-Cut. Tool schon geschrieben.

Andy Grunwald (00:07:01 - 00:07:06)

Ja, ich habe Google Reader damit ersetzt, weil ich würde gerne wissen, was in Home Assistant so abgeht.

Wolfi Gassler (00:07:06 - 00:07:08)

Und funktioniert es noch?

Andy Grunwald (00:07:08 - 00:07:18)

Ungemein gut. Ich kriege jede zwei Wochen oder so eine E-Mail über ein neues Blogpost und dann lese ich den, weil sonst müsste ich ja, also ich werde informiert, wenn ein Blogpost da ist und sonst müsste ich da jede zwei Wochen auf die Webseite gehen.

Wolfi Gassler (00:07:18 - 00:07:19)

Und da gibt es keinen RSS-Feed?

Andy Grunwald (00:07:19 - 00:07:22)

Ja doch gibt es aber ich habe kein rss feed reader mehr weil google reader.

Wolfi Gassler (00:07:22 - 00:07:31)

Du bist in der in der apple hipster technologie welt gibt es keine rss reader mehr würdest du thunderbird verwenden hättest du rss feeder eingebaut in deinem email client.

Andy Grunwald (00:07:31 - 00:07:34)

Hätte hätte fahrradkette aber gut.

Wolfi Gassler (00:07:34 - 00:07:40)

Aber ist ein schöner use case muss ich dazu sagen also um ehrlich zu sein ich hatte das ja auch mal in verwendung genau für den gleichen use case.

Andy Grunwald (00:07:41 - 00:08:02)

Das bedeutet, es gibt irgendwo eine Plattform, die hat ein Workflow-Management und da kann ich sagen, da ziehe ich mir eine Komponente rein, mache eine HTTP-Request, wenn ich da 200 rauskomme, dann schicke ich eine E-Mail und trage in dieses Excel-Sheet einen grünen Haken ein. Also ich kann mir das visuell zusammenklicken per Drag-and-Drop-Interfaces. Ist das richtig? Ist das No-Code?

Wolfi Gassler (00:08:03 - 00:09:24)

Im Prinzip ist das No-Code. Ja, üblicherweise kann man da vielleicht auch zwischendrin irgendwo kleine Codeschnipsel mit einbauen oder ein If oder sowas oder ein Switch-Statement oder auch optisch, grafisch, visuell vielleicht so ein If-Zweig, so eine Weiche damit realisieren. Das ist also möglich. Was ich kürzlich mal gemacht habe zum Beispiel, einfach um mal was auszuprobieren, um dann so ein Proof-of-Concept zu machen und ich glaube für sowas ist das ja auch bestens geeignet. Wir bekommen zum Beispiel Feuerwehr-Alarmmeldungen per E-Mail unter anderem auch. Dann habe ich mit Mailgun so ein E-Mail-Forwarding gemacht, dass Mailgun, wenn da ein E-Mail reinkommt, wird ein API-Call gemacht. Dann schlagt es bei mir bei einer No-Code-Plattform N8n auf. Die schaut dann in einem Google-Sheet nach, welche Leute informiert werden müssen automatisch, zieht sich da spezielle Keys und mit den Keys wird dann an der nächsten API gegangen, um auf eine Android-App Alarmmeldungen zu schicken. und in der Excel-Sheet-Tabelle steht, welche Personen da informiert werden müssen und das ist natürlich super praktisch, weil wenn da jetzt was Neues hinzugefügt wird, kann man das einfach in dem Google-Sheet hinzufügen, diese Nummer und man braucht nicht in irgendeinem Code einsteigen, nicht in irgendeine Datenbank, man braucht kein Interface. Google-Sheets ist einfach das Interface und das ist relativ schnell zusammengeklickt gewesen.

Andy Grunwald (00:09:25 - 00:09:43)

In dem Beispiel, was du gerade aufgeführt hast, da hast du auch ein bisschen rumprogrammiert. Ich habe auch mal irgendwie so einen Begriff gehört, Low-Code, also No-Code mit keinem Code und Low-Code, also nicht tiefgelegener Code oder ähnliches, vielleicht auch einfach nur wenig Code. Gibt es da einen Unterschied? Ist das das Gleiche? Wie siehst du das?

Wolfi Gassler (00:09:44 - 00:10:41)

Ja, im Prinzip, meiner Meinung nach, gibt es fast keine klassische No-Code-Plattform, weil alle Plattformen in irgendeiner Form dann auch anbieten, dass man ein bisschen tiefergehend irgendwas an Code schreibt. N8n hat zum Beispiel JavaScript, die meisten haben halt dann JavaScript, das ist recht naheliegend, dass man sich da vielleicht noch irgendwas zusammenbasteln kann, was mit den klassischen Knoten, die man in diesem Workflow-Management, Prozess-Management-Tool zur Verfügung hat, eben nicht abbilden kann. Dann kann ich da noch was dazu programmieren, sofern ich JavaScript programmieren kann. Das geht dann natürlich auch noch wesentlich weiter. Es gibt natürlich dann auch so Low-Code-Plattformen, die fast von der anderen Richtung kommen, die dann eher Developer ansprechen, wo ich dann weniger grafisch machen kann, beziehungsweise ich kann schon grafische Dinge machen, Formulare und solche Sachen, aber es schaut dann so fast aus wie eine Entwicklerumgebung. Oder es erinnert mich auch sehr stark an diese 4GL-Sprachen von früher. Sagt dir ja hoffentlich was, oder?

Andy Grunwald (00:10:41 - 00:10:42)

Wann wurde ich geboren?

Wolfi Gassler (00:10:43 - 00:10:45)

Ist das eine Fangfrage?

Andy Grunwald (00:10:45 - 00:11:05)

Vor GL, das hört sich an wie OpenGL. OpenGL hab ich noch mitgekriegt, VorGL wird wahrscheinlich nichts mit den Grafiktreibern von OpenGL zu tun haben. VorGL hört sich aber alt an. Und immer, wenn du anfängst mit, das erinnert mich an, dann denk ich mir, okay, jetzt erzählt Opa wieder vom Krieg. Also, ich bin 87 geboren. Das hab ich mit hoher Wahrscheinlichkeit nicht mitgekriegt.

Wolfi Gassler (00:11:06 - 00:12:14)

Also wir haben ja in vielen Episoden schon darüber gesprochen, ist immer schön, dass du was mitnimmst aus unseren Episoden und das auch gleich wieder vergisst, aber die 4GL-Sprachen, das waren diese Dinger in den 90er, 2000er auch noch, wo du einfach alles gemeinsam hattest, eine Oberfläche, wo du Formulare generieren hast können, dort ist eine Datenbank integriert meistens und das war so ähnlich wie so ein Visual Basic damals, aber Plus Plus würde ich fast sagen, wo man eben alles in einem Baukasten hatte und sich da relativ schnell Applikationen zusammenschrauben hat können. So Rapid Application Development hat man es später mal auch genannt. Und heutzutage würde ich einfach Low-Code-Applikationen dazu sagen. Und da gibt es halt auch sowas wie mittlerweile sogar Microsoft Power Apps, also sogar Microsoft hat da mittlerweile ein Produkt dafür. wo du sehr schnell Applikationen zusammenstellen kannst, aber ich würde sagen, die gehen dann schon eher in die Richtung, dass du Developer-Skills brauchst oder technische Skills, weil da der Code dann schon sehr im Vordergrund steht. Klar kann man viel zusammen klicken, aber Code ist definitiv auch überall ein richtiger wichtiger Bestandteil.

Andy Grunwald (00:12:14 - 00:12:26)

Ich hatte jetzt schon iftt genannt du hattest schon n8n und power apps genannt was was gibt es da noch so auf dem markt nur damit du mal einfach mal ein paar was wörter drop falls irgendjemand mal so ein tool gehört hat.

Wolfi Gassler (00:12:26 - 00:14:37)

Ja so mittlerweile gibt es eigentlich massiv tools und garantiert egal wie viel lang man jetzt die liste macht wird man gewisse sachen vergessen. Aber sowas, was ich sehr stark durchgesetzt habe, sind eigentlich diese Workflow-Management-Systeme, also sowas wie Mac.com oder Zapier oder keine Ahnung, wie man es wirklich ausspricht, kennen wahrscheinlich die meisten. Oder dein IET, wie heißt es nochmal? Wenn wir niedermerken, das sind also die klassischen Workflow-Engines, wo du den Prozess abbildest, der dann die verschiedenen APIs und Datenbanken anbindet. Dann gibt es üblicherweise diese aufgeblähteren Datenbanken, Airtable oder NoCodeDB zum Beispiel ist eine Open Source Variante von dem Ganzen. Das sind so Tabellen plus plus, wo du eben auch ein Bild reinladen kannst in eine Spalte. oder komplexere Strukturen in der Tabelle verwalten kannst. Das sind dann wirklich die Data Stores dahinter, die man auch bei API ansprechen kann und teilweise bieten die auch gewisse Sachen an, dass man E-Mail versenden kann, aber das macht man auch oft dann über die Prozess Engines und die Workflow Engines. Also du hast eine Datenbank, du hast eine Workflow-Engine und dann hast du meistens auch noch Plattformen, die dir ermöglichen Oberflächen zu bauen, ein Formular oder ein komplizierteres Formular. Retool ist da super bekannt. Das hat sich spezialisiert auf dem Backend-Bereich oder Back-Office-Bereich, wo du wirklich dann Administrationsoberflächen zusammenbauen kannst, wo du dann eben diese Daten aus den Datenbanken schön darstellen kannst, gewisse Logik drauf bauen kannst. AppSmith wäre so eine Open-Source-Variante wieder von dem Retool, dass du Administrationsapplikationen entwickeln kannst. Und dann gibt es natürlich auch noch Plattformen, die eher dann wieder Richtung Frontend gehen, also nicht für Back-Office-Anwendungen, sondern wirklich für Frontend-Anwendungen, wo du eine App bauen kannst, die dir das dann alles anzeigt. Und es geht natürlich vielleicht sogar so weit, dass man in Richtung Webseiten geht, wenn du sagst ein klassischer Webseiten-Baukasten, der vielleicht ein bisschen mehr kann, sowas wie Webflow, könnte man vielleicht auch noch unter NoCode sogar dazuzählen.

Andy Grunwald (00:14:37 - 00:14:43)

Jetzt stelle ich mir die Frage, wie viel technisches Verständnis ist denn überhaupt notwendig, um No-Code-Plattformen zu nutzen?

Wolfi Gassler (00:14:43 - 00:16:39)

Ich würde sagen, es kommt darauf an, was du mit der Plattform erreichen willst. Der Einstieg ist bei den meisten Plattformen sehr einfach. Da brauchst du null technisches Verständnis, würde ich mal sagen. Wobei null technisches Verständnis ist natürlich auch so eine Sache, weil du musst natürlich verstehen, was ist eine API, wie kannst du eine API ansprechen, was ist JSON? Solche Dinge musst du natürlich schon verstehen. Also da könnte ich mir natürlich vorstellen, dass wenn jemand, keine Ahnung, sein Leben lang nie was damit zu tun hatte und Word so das Maximale war an technischen Skills, dann ist es vielleicht schwierig. Aber sobald du so ein bisschen Skills entwickelst, was ist eine JSON-Datei, wie ist eine JSON-Datei aufgebaut, dann kannst du da eigentlich schon relativ damit sinnvolle Anwendungen bauen, würde ich mal sagen, kleine und da gewisse Sachen schnell bewerkstelligen. Also das funktioniert besser, als man denkt. Ich kenne zum Beispiel auch einen Produktmenschen, der bei einer sehr großen Food Delivery Firma damals ohne technische Hilfsmittel einfach so ein Tool gebaut hat, dass die Fahrradkuriere informiert werden oder so eine Erinnerung bekommen. Das war zu Covid-Zeiten wegen Schutz und Masken und so weiter. Setze die Maske auf, bevor du mit dem Kunden redest. und der hat das komplett selbstständig zusammengebaut und hatte aber keine Ahnung natürlich von irgendwie wirklichem Coding, aber der hatte ein bisschen Python-Skills, Data Science-Skills, die hatten die Plattformen bei der Firma und dann hat er sich das relativ schnell zusammengestöpselt mit den verschiedenen APIs und Tools, die er zur Verfügung gehabt hat. Also wenn jemand aus der Product-Ecke kommt und solche Dinge versteht und sich zusammenbauen kann, dann ist das natürlich ideal, weil du superschnell sowas machen kannst, ohne einen einzigen Entwickler oder Entwicklerin zu fragen, hey, hilf mir mal bitte oder mach mir das. Und der hat das einfach während der Covid-Zeit zum Beispiel superschnell an den Start gebracht und hat dann tausende Fahrradkuriere einfach so informiert. Und da hatte kein einziger Developer irgendwas. Ich glaube, es hat nicht mal jemand gewusst, dass das existiert dann von den Developern. Das war einfach komplett unabhängig von dem eigentlichen Developer-Team gemacht.

Andy Grunwald (00:16:39 - 00:16:54)

Das klingt jetzt mal hart nach Shadow-IT, aber da sprechen wir gleich noch drüber. Das klingt für mich aber grad erst mal so, dass es vielleicht gar nicht so tief gehen muss, dass du Python verstehen musst oder JSON oder ähnliches, sondern dass du einfach, ich sag mal, mit gutem logischen Denken doch schon relativ weit kommst, oder?

Wolfi Gassler (00:16:54 - 00:17:51)

Du musst dir natürlich die Abfolgen überlegen, und ich glaub, du kommst dann sehr schnell an den Punkt, wo du nicht mehr weiterkommst und dann ein Problem hast, klar. Wenn du sagst, wenn da ein neuer Kunde hinzugefügt wird in der Excel-Liste oder in meinem Airtable-Sheet oder was auch immer in der Tabelle, dann schicke ich ein Willkommens-E-Mail aus, das ist kein Problem. Aber wenn du dann natürlich sagst, ja und wenn dann der Status dort geändert wird und dann irgendwas weitergeschickt wird unter der Status, Dann wird es schon schwieriger, würde ich sagen. Und wenn es dann vielleicht nochmal irgendwie komplexer wird und du dann irgendwelche Return-Werte von irgendwelchen APIs verarbeiten musst, dann muss man natürlich spätestens da, muss man dann irgendwie chasen oder so verstehen. Und das ist natürlich schon ein Problem. Du kannst dann natürlich schon die API abschicken, schicken E-Mail. Aber was passiert, wenn das E-Mail nicht geschickt wird? Was ist, wenn irgendwo ein Error passiert? Kann das dann dein Workflow-Management-System? Bekommst du das überhaupt mit? Oder bekommt der Kunde einfach kein Willkommen ins E-Mail? Und solche Dinge sind natürlich schwierig.

Andy Grunwald (00:17:51 - 00:18:34)

Guter Punkt, aber wenn ich mir heutiges Marketing mal ansehe, ich reingestriere mich irgendwo, dann lande ich ja auch in irgendeiner E-Mail-Automation-Engine und dann habe ich vielleicht noch angegeben, dass ich irgendwie Gewicht verlieren möchte und dann bin ich ja auch in einem E-Mail-Workflow drin, der mir alle drei Wochen oder so nach einem bestimmten Intervall dann immer neue Informationen schickt. Das ist ja, also was ich damit sagen möchte, Auch heute im Marketing wird ja schon ziemlich viel mit diesen Workflows und diesem logischen Denken, ähnlich wie du jetzt gerade hier No-Code-Tools beschreibst, gearbeitet. Und auch mit Template-Variablen für Namen und vielleicht für, keine Ahnung, Gewichtsangaben, die ich dann da irgendwie vorher in so einem Intro-Formular ausgeben habe und so weiter. Und deswegen stelle ich mir wirklich die Frage, wie viel ist da wirklich notwendig zu wissen über JSON und Code?

Wolfi Gassler (00:18:34 - 00:19:28)

Ja klar, also es kommt darauf an, auch wie die Systeme miteinander arbeiten. Also wenn du natürlich ein System hast, wo sehr viel integriert ist und abgestimmt aufeinander, dann ist es natürlich easy. Aber wenn du natürlich ganz viele Services verwendest von unterschiedlichen Anbietern, dann werden die nicht aufeinander abgestimmt sein. Und klar, Zapier hat gewisse Module, dass du möglichst viele APIs ansprechen kannst mittlerweile in so einem Quasi wie so einen App Store, dass du dir einen Knoten für deine Workflow Engine reinziehst und da brauchst du dann recht wenig Kenntnisse über die eigentlichen APIs. Das stimmt natürlich, aber du brauchst halt dementsprechend die APIs und die Informationen oder vielleicht so einen Knoten, der schon programmiert wurde. Und je nachdem, was du natürlich verwendest, ist die Frage, ob das Ganze existiert oder ob da eine Dokumentation da ist oder eine Information und wie gut du dich natürlich auskennst. Klar, also es kommt auf die APIs drauf an, auf die Schnittstellen und wie viel technische Ahnung du hast, ganz klar.

Andy Grunwald (00:19:29 - 00:19:54)

Glaskugel Wolfgang, denkst du, No-Code und Low-Code-Tools haben die Möglichkeit, Softwareentwicklung zu demokratisieren und oder gegebenenfalls die Lösung für den Fachkräftemangel zu sein? Weil wenn du jetzt sagst, okay, aktuell ist noch relativ viel technisches Verständnis notwendig, das wird sich ja mit hoher Wahrscheinlichkeit über Zeit ändern, dass weniger und weniger technisches Verständnis notwendig wird und mehr Leute enabled werden, diese Plattform zu nutzen.

Wolfi Gassler (00:19:55 - 00:21:51)

Also ich glaube nicht, dass es Demokratisierung von Softwareentwicklung sein wird. Es wird vielleicht die Demokratisierung von einer Applicationentwicklung sein. Das heißt, ich kann gewisse Applikationen unter Umständen bauen, ohne dass ich Development Skills brauche. Aber Softwareentwicklung ist für mich schon immer eigentlich, da ist schon Coding in irgendeiner Form dabei oder dass ich das tiefere Verständnis habe. Und das brauche ich aber vielleicht auch gar nicht. Vielleicht für gewisse Use Cases reicht mir so ein simpler Workflow-Engine, wo ich irgendwas abbilde. Und ich glaube, das sehr wohl kann auch die Developer entlasten, weil, seien wir uns ehrlich, wer hat Spaß daran, ein hunderttausendste Formular zu basteln und irgendein Validator zu schreiben oder wieder zu checken, ob die E-Mail stimmt und solche Dinge. Also da ist ja auch jeder Entwickler und Entwicklerin froh, wenn man auf irgendwelche Lips vertrauen kann, die das einfach komplett übernehmen und wenn dann halt so gewisse Teile gar nicht mehr gebraucht werden und die die Leute selber machen können in den jeweiligen Fachabteilungen, Dann ist es natürlich schon eine Entlastung, würde ich sagen. Ob das jetzt den Fachkräftemangel löst, glaube ich jetzt weniger, weil alles komplexer wird. Aber ich glaube, es wird schneller. Die Leute können selbstständig schneller Applications auf den Markt, ist es ja meistens nicht, oft sind es ja so interne Tooling-Sachen, aber der interne Markt sozusagen, schneller live bringen. Und das ist natürlich schon ein großer Punkt. großer Vorteil, dass man da einfach mit geringeren Kosten schneller Dinge an den Start bringt und auch schneller das Ganze in einer agileren Form machen kann. Also ohne, dass man irgendwen fragen muss oder warten muss womöglich auf irgendein Team, sondern ich baue mir das einfach schnell zusammen. Ich will da jetzt bei Covid eben irgendwelche Notifications aussenden, baue mir das zusammen, teste es einmal, funktioniert schon irgendwie und am nächsten Tag ist es live. oder am selben Tag noch. Das ist natürlich mit Developer oder mit einem Developer-Team, was gerade im Sprint ist und wo man immer Product-Owner gehen muss und solche Dinge, ist das natürlich ganz was anderes.

Andy Grunwald (00:21:51 - 00:22:18)

Das klang jetzt gerade so ein bisschen wie die Marketing-Webseite von AWS Lambda zum Thema Serverless, gemünzt auf No-Code auf der Tonspur. Und damals wurde gesagt, look ma, keine Server. Und jetzt sagst du, look ma, it's no code. Hier gibt's gar keinen Code. Und wir wissen alle, Serverless ist nicht Serverless, denn es sind nur die Server von jemand anders. Meine Frage ist, ist No-Code wirklich No-Code oder ist das nur Code von jemand anders?

Wolfi Gassler (00:22:19 - 00:22:42)

Ja, natürlich ist es ein Code von jemand anderem, klar. Aber das hast du ja immer. Also, wo verwenden wir heute keinen Code von anderen Leuten? Aber wenn du dich nicht darum kümmern musst und jemand anderer die Updates macht und jemand anderer sich darum kümmert, wie man die Google Sheet-Schnittstelle abfragt, um da die Daten rauszubekommen, dann ist das für mich abstrahiert. Das macht irgendwer anderes, kümmert sich jemand anderer und das ist genau wie Serverless, ganz klar.

Andy Grunwald (00:22:43 - 00:22:54)

Okay, das klingt erstmal ganz cool. Jetzt kommen wir zu dem zweiten Punkt, womit nämlich dein Streit auf LinkedIn angefangen hat mit Refactoring oder das Refactoring scheiße ist oder nicht benötigt wird.

Wolfi Gassler (00:22:54 - 00:23:02)

Auf jeden Fall wurde da Bullshit schon richtig zitieren. Es war ein deutscher Podcast gewesen, aber Refactoring ist Bullshit war das Zitat.

Andy Grunwald (00:23:03 - 00:23:26)

Und immer wenn jemand sagt, Thema A ist Bullshit, dann stelle ich mir die Frage, warum macht man denn Thema A? Warum gibt es eine Daseinsberechtigung für Refactoring? Und da bin ich dann drauf gekommen, okay, vielleicht weil man technische Schulden hat, Technical Debt. Und dann bin ich mit ihr in die Diskussion eingestiegen und gesagt, also ich bin mir nicht sicher, ob wir hier von dem gleichen Verständnis von Technical Debt reden, weil das ist ja alles immer subjektiv.

Wolfi Gassler (00:23:27 - 00:23:34)

Ja, meine Aussage war ja, oder meine Theorie ist ja, dass No Code Technical Depth ist. Also No Code ist Technical Depth.

Andy Grunwald (00:23:34 - 00:24:05)

Und das ist spannend. Und um die Aussage gleich mal auseinanderzunehmen, möchte ich erst mal verstehen, was du überhaupt unter Technical Depth verstehst. Weil da bin ich mir nicht sicher, ob wir das Gleiche meinen. Ich verbinde diesen Begriff eigentlich sehr viel mit Subjektivität. Technical Depth ist oft ein Gefühl, ein frustrierendes Gefühl. Und ich hab auch das frustrierende Gefühl, dass der Begriff technical debt oft misused wird. Es ist egal wo du ihn erwähnst, er wird immer negativ behaftet wahrgenommen.

Wolfi Gassler (00:24:05 - 00:24:48)

Ja, ich glaube, es ist so ein ständiger Kampf. Also die Development-Welt verwendet den irgendwie so als Hilfeschrei. Technical debt, technische Schulden, wir müssen da irgendwas machen. Und auf der Business-Seite, und daher kommt, glaube ich, auch die Aussage, Refactoring is bullshit, auf der Business-Seite ist das sehr negativ konnotiert, weil, wenn man ja den Refactor-Begriff sich zum Beispiel ansieht, dann heißt es ja, ich ändere irgendwas, ohne dass der Output verändert wird, ohne dass die Funktion verändert wird. Das heißt, es ist meistens irgendwas, was Zeit kostet, was mein Team Zeit kostet, aber ich auf der Product-Seite nichts rausbekomme. Und darum ist dieses Technical Debt so nicht ganz greifbar auf der Business-Welt vielleicht, aber es ist ein Begriff, was die Developer-Welt halt gerne verwendet.

Andy Grunwald (00:24:49 - 00:25:00)

Da bin ich 100 Prozent bei dir. Aber was ist denn jetzt Technical Debt? Wie würdest du es definieren? Also ist das subjektiv oder sagst du, nee, da steckt schon ein bisschen mehr hinter, das ist beschrieben als?

Wolfi Gassler (00:25:00 - 00:27:17)

Ja, es kommt immer drauf an, wenn du da durchfragst, ganz klar. Also vielleicht als Hintergrund habe ich heute auch mal rausgegoogelt, wer das eigentlich erfunden hat. Das war der Ward Cunningham, hast du vielleicht schon mal gehört. Der war auch beim Agilen Manifesto dabei, ist einer von diesen grauhaarigen alten weißen Amerikanern. Oh ja, ich hoffe, er ist ein Amerikaner oder vielleicht UK, ich bin mir jetzt gar nicht ganz sicher. Der hat auf jeden Fall Wikis erfunden. Die absolute Chaos-Schleuder und Chaos-Struktur quasi schlechthin ist sehr interessant, wenn er dafür sonst eigentlich eher so auf der Strukturseite ist und Technical Depth den Begriff eben damals in die Welt rausgetragen hat, dass man da was dagegen machen muss. Und zur Definition ist es natürlich schwierig, weil du kannst nicht sagen jetzt, wenn in deinem Code dieses Pattern nicht angewendet ist, dann ist es Technical Depth oder eine technische Schuld. Also auf dem Level, meiner Meinung nach, ist es auf dem Level eben nicht möglich, sowas zu sagen. Für mich ist es eigentlich eher sowas, dass man auch erst später merkt unter Umständen, weil man irgendwann mal sieht, okay, da kommen jetzt die ganzen Probleme und da haben wir jetzt Probleme mit unserer Architektur und da haben wir Probleme mit unserem Code und jetzt wollen wir was Neues dazu bauen und jetzt müssen wir zuerst mal alles umbauen oder ändern oder es ist so schwierig, dass wir jetzt da was dazu bauen oder es ist schon fünfmal was dazu gebaut worden, dass das sechste Mal jetzt nochmal komplizierter wird und alles steht auf wackelnden Beinen und bricht was zusammen und Monitoring haben wir auch kein gutes und Tests haben wir sowieso nie geschrieben. Das heißt, können wir da überhaupt dran was ändern? Und dann investiert man so viel Zeit, die man eigentlich vielleicht gar nicht investieren müsste. Also, wenn die Komplexität steigt mit der Zeit, dann hat man technische Schulden aufgebaut. Und ich finde Schulden ist ja ein super Begriff, weil wirklich über die Zeit die Schulden durch die Zinsen immer höher werden, immer alles schwerfälliger wird und es wird immer schwieriger die Schulden zurückzuzahlen und genauso ist es mit der technischen Schuld meiner Meinung nach. Die häuft sich an und macht alles immer langsamer, immer schwieriger und man muss es früher oder später irgendwann zurückzahlen oder vielleicht dann sogar mit dem Rewrite, dem bösen Neuschreiben von der gesamten Applikation. Das ist natürlich das Schlimmste, was passieren kann. Das will ja eigentlich niemand. Aber ich glaube, man baut da einfach Schulden auf, die man irgendwann dann büßen muss.

Andy Grunwald (00:27:17 - 00:28:04)

Du hast das Wort Komplexität genannt und da wurde ich ein bisschen stutzig, denn es gibt ja Business-Modelle, eine Versicherung zum Beispiel, da ist das Domänenmodell, das Business-Modell ja schon sehr kompliziert. Bis man den richtigen Betrag für deine Versicherung berechnet, das ist ja so abhängig von so vielen Attributen, das ist ja auch komplex. Da würde ich aber nicht sagen unbedingt, dass die automatisch technische Schulden haben. Deswegen habe ich mal, während du da diesen Monolog gehalten hast, einfach mal gegoogelt. Und wenn man Google fragt, dann kommt man auf den Satz, technische Schulden sind die kumulierten Kosten oder Folgen von Shortcuts oder suboptimaler Design- und Implementierungsentscheidungen während der Softwareentwicklung. Und wenn ich das so lese, dann frage ich mich, technische Schulden sind doch eigentlich eine aktive Entscheidung, oder?

Wolfi Gassler (00:28:05 - 00:29:31)

Natürlich und es kann auch eine gute Entscheidung sein. Also gleich wie Schulden per se ja nicht schlecht sind, wenn du Schulden aufnimmst, damit du ein Haus bauen kannst, dann ist es ja nichts Schlechtes, weil du hast ja was davon und dann zahlst du halt die Schulden über die Zeit zurück. Also genau das, was Schulden halt aussagt, ist es auch bei der technischen Seite. Wenn du einen Shortcut, eine Abkürzung nimmst, wie du das so schön erwähnt hast, Dann bist du vielleicht schneller am Markt, bist früher dran, hast einen Vorsprung gegenüber deinen Mitbewerbern. Oder du hast zu wenig Leute und musst einfach möglichst schnell irgendwas rausbringen. Dann bringt dir das einen Startvorteil. Aber irgendwann musst du eben diese Schulden zurückzahlen, sonst hast du ein Problem. Und wenn du da die Schulden in Kauf nimmst, ist es komplett fair. Und solange da sich jeder bewusst ist, ist es ja auch kein Problem. Und das ist ja in der Businesswelt auch das klassische Problem, mit dem wir Developer alle zu kämpfen haben. weil wir gehen technische Schulden ein, alle sind einverstanden, aber wenn es dann darum geht, die technischen Schulden zurückzuzahlen, also aufzuräumen oder vielleicht sogar ein Refactoring, dieses große Wort Refactoring zu machen, dann ist es natürlich oft schwierig auf der Business Seite und dann heißt es ja warum, warum müssen wir das jetzt investieren, es ändert sich ja gar nichts und es gibt kein neues Feature oder so im ersten Moment zumindest oder warum brauchen wir jetzt für das neue Feature diesen Rewrite oder dieses Refactoring davor, warum brauchen wir das überhaupt? Und da ist halt ein wenig Verständnis. Also die Schulden können aufgebaut werden, aber es muss halt auch klar sein, dass wir sie zurückzahlen.

Andy Grunwald (00:29:31 - 00:29:53)

Wenn Technical Debt eine aktive Entscheidung ist, auf Basis von Time-to-Market-Deadlines, hat Surat genannt, oder schnell ändernden Anforderungen, ja, in Startups oder ähnliches, Können dann technische Schulden überhaupt vermieden werden, beziehungsweise ist nicht jeder Code irgendwie bereits technical dept?

Wolfi Gassler (00:29:53 - 00:31:09)

Naja, wenn du dich nicht aktiv dazu entschieden hast, dann wäre es ja auch nach deiner Definition eigentlich keine Schuld, die man aufnimmt, sondern dann wäre es halt vielleicht ein schlechtes Design, man hat es nicht besser gewusst. Das passiert natürlich ständig. Man darf das auch nicht verwechseln übrigens mit schlechtem Code. Also sehr oft wird das eigentlich genannt, aber meiner Meinung nach sind technische Schulden kein schlechter Code. Also nur weil ich zu faul bin, um irgendwie sinnvolle, ich nehme immer das ganz einfache Beispiel von Variablennamen, dass ich sinnvolle Variablennamen vergib. Wenn ich dazu faul bin, dann ist es keine technische Schuld, sondern es ist einfach dreckig Coden. Das hat nichts mit technischer Schuld zu tun. Wenn ich aber natürlich sage, okay, ich will möglichst schnell auf den Markt gehen und ich spare mir jetzt das Monitoring-System, weil wir haben gerade nicht die Zeit, dieses Monitoring-System zu implementieren oder den Test und wir wollen möglichst schnell am Markt sein und nehmen das auch in Kauf, dass da irgendwo Fehler passieren, dann ist das eine technische Schuld, die man aktiv aufnimmt. und die man dann halt irgendwann nachholen muss, das Monitoring, weil es funktioniert halt nur eine gewisse Zeit und irgendwann brauchst du wahrscheinlich Monitoring. Kann man darüber streiten, wann braucht man das wirklich, aber wenn ich natürlich ein super kleines Startup mal loslege, zwei Kunden habe und sowieso die ganze Zeit da weiterentwickele, dann brauche ich vielleicht auch im ersten Moment noch kein super komplexes Monitoring.

Andy Grunwald (00:31:09 - 00:31:14)

Das bedeutet aber auch, wenn ich sage, ich wusste es damals nicht besser, das sind dann keine technischen Schulden, oder?

Wolfi Gassler (00:31:14 - 00:32:07)

Ist die Frage, ob man das mit rein nimmt. Ja klar, aber meiner Meinung nach ist es keine technische Schuld, nur weil ich eine falsche Entscheidung getroffen habe damals, eine falsche Architekturentscheidung, weil ich es nicht besser wissen konnte natürlich. Natürlich muss man es trotzdem aufräumen, klar. Und vielleicht ist da trotzdem ein Refactoring nötig, aber ich würde es jetzt nicht als technische Schuld bezeichnen. Also technische Schulden sind für mich eigentlich gar nicht so negativ, solange man sie immer wieder mal aufräumt, weil ich sie eben aktiv in Kauf nehme und mir das einen gewissen Vorteil bringt, wenn ich eben gewisse Dinge weglasse, die mir Zeit kosten, damit ich schneller am Markt bin, damit ich mit meinen Leuten vielleicht einfach schneller bin beim Coden, was rausbringen und vielleicht sowieso sich in drei Tagen wieder ändert. Dann teilweise macht es ja auch gar keinen Sinn. Also wenn man was ausprobieren will, dann macht es vielleicht Sinn, da eine technische Schuld aufzubauen, weil wenn ich alles wegwirfe, dann sind die Schulden damit auch wieder gedillgt und weg.

Andy Grunwald (00:32:08 - 00:32:27)

Okay, und jetzt kommen wir mal zu deiner starken These. No Code is Technical Debt. Als ich das das erste Mal gehört habe, so hast du mir diese Episode ja auch so ein bisschen gepitcht, beziehungsweise in dieser WhatsApp-Diskussion, von der ich gesprochen habe, habe ich mich gefragt, wenn es doch kein Code gibt, wie kann es dann technische Schulden geben?

Wolfi Gassler (00:32:27 - 00:33:13)

Weil eben, die technische Schuld gar nicht zu den Code betrifft, sondern eher die Architektur meiner Meinung nach. Also auf der Architekturebene gibt es viel mehr technische Schulden als auf der Code-Ebene oder zumindest auf der Code-Ebene erst, wenn man auf Architekturebene geht, auf gewisse Patterns und wie man Code strukturiert, also auf höherer Ebene. Und erst da beginnt meiner Meinung nach so klassische technische Schuld, beziehungsweise das gibt es vielleicht auf mehreren Ebenen. Und auf der No-Code-Ebene, auf der Architekturebene, wie arbeiten Services zusammen, da gibt es meiner Meinung nach sehr wohl technische Schuld. Und da sind wir wieder da, dass meiner Meinung nach, wenn ich No-Code einsetze, dann habe ich schon aktiv technische Schuld aufgebaut. Also sobald ich mich entscheide, No-Code zu verwenden, habe ich eine technische Schuld aufgebaut.

Andy Grunwald (00:33:13 - 00:33:23)

Hol mich mal ab, was du mit Architektur meinst, ja? Wenn ich von Architektur im richtigen Code, wie nennen wir richtigen Code? Also jetzt nicht No-Code, sondern nennen wir das Code, oder?

Wolfi Gassler (00:33:23 - 00:33:31)

High-Code wird's oft genannt, oder Hard-Code, aber High-Code eigentlich. Also No-Code, Low-Code, High-Code. Und High-Code sind dann wirklich Developer. Okay.

Andy Grunwald (00:33:32 - 00:33:50)

Architektur im High-Code-Kontext verstehe ich, ja? Microservices, Monolith, Design-Patterns, Factory und Composer-Pattern und all sowas, ja? Und Verbindungen über HTTP, JSON, Recipe, IG, RPC. Was ist Architektur im No-Code-Kontext? Gib mir mal ein Beispiel.

Wolfi Gassler (00:33:50 - 00:36:05)

Also ich glaube, man kann das auch sehr gut vergleichen mit dem, was du jetzt gerade gesagt hast, mit einer Microservice-Architektur, weil ganz oft, wenn man sich so Architekturen ansieht von NoCode, betrifft natürlich nicht absolut alle NoCode-Tools und je nachdem, wie man es einsetzt, man kann das jetzt nicht über einen Kamm scheren in jedem Szenario, wo das verwendet wird. Aber ganz oft ist es ja, ich verbinde APIs miteinander, teilweise dreckigere APIs, schönere APIs, aber ich verbinde irgendwie APIs, Events in so einer Workflow Engine, vielleicht noch ein paar Formulare dran, eine Administrationsoberfläche. Also ich mache eine Verbindung von ganz ganz vielen Services, die meistens nicht von mir programmiert werden, sondern extern sind, von ganz vielen externen Firmen, von meinen Partnerfirmen zum Beispiel oder also Paymentfirmen oder Firmen, die mir dann vielleicht irgendein Produkt raussenden oder die die Rücknahmen abwickeln, das Marketing machen. Also es sind ja ganz oft externe Tools. Das ist sowas ähnliches wie Microservices, meiner Meinung nach. Also du hast ganz viele APIs, die du zusammen stöpselst. Und jeder, der mal mit Microservices gearbeitet hat, weiß, dass das irgendwann sehr kompliziert wird, weil du die Übersicht verlierst. Du hast ganz viele APIs, die zusammenarbeiten und du sollst das Ganze monitoren. Du hast plötzlich irgendwie Probleme am HTTP-Stack, am Netzwerk-Stack. kannst gewisse Dinge nicht erreichen. Was machst du dann? Machst du einen Retry? Was machst du mit der Dokumentation von deinen ganzen Services, Microservices, die extern, intern sind? Also da kommen ganz, ganz viele Dinge auf einen zu, die man beachten muss und meistens Zumindest wenn man klassisch eben Netflix war ja damals so ganz groß, die die ganzen Tools dann zusätzlich herausgebracht haben, um mit den Microservices zu arbeiten und zu monitoren und den Netzwerkstack zu überwachen und so weiter. Die haben zusätzliche Tools rausgebracht. Wenn du jetzt aber NoCode verwendest und auf deiner simplen Make.com Plattform oder N8n einfach da irgendwas zusammenstöpselst, externe Services, interne Services, bisschen Code zwischendrin reinschreibst, irgendein JavaScript-Code, dann ist der selten dokumentiert, dann ist der selten getestet, dann ist der selten gemonitort überhaupt und da ist es halt dann wirklich schwer, das Ganze zu skalieren und sinnvoll zu betreiben. Also das ist ein sehr wackeliges Konstrukt, würde ich mal sagen.

Andy Grunwald (00:36:05 - 00:36:31)

Ich frage mich gerade eher, ist das der Anspruch von NoCode? Weil, wenn wir die Vorteile noch mal heranziehen, ja, ich kann da schnell was zusammenklicken, ich kann Prototypen bauen, ich kann gucken, ob mein Service überhaupt von Kunden gekauft wird. Und dann beschreibst du grad das andere Extrem, ja? Monitoring, Observability, Log, Tracing und, ne, Shift-Left. Und ich weiß noch nicht, welches Buzzword ich grad vergessen hab. DevSecOp oder ähnliches.

Wolfi Gassler (00:36:31 - 00:36:43)

Eigentlich ist ja No-Code übrigens auch Shift-Left, weil du drückst ja da quasi die Programmierung noch weiter nach links Richtung Product, so über den Developer hinaus Richtung Product oder Business oder was für Abteilung auch immer ist, Marketing.

Andy Grunwald (00:36:43 - 00:36:54)

Ja, ich frage mich gerade eher, ob du nicht auf der Over-Engineering-Seite bist. Also ich kann dir sagen, super viele Websites und Services, die nicht auf No-Code gebaut sind, haben bestimmt nicht das, was du gerade beschrieben hast.

Wolfi Gassler (00:36:55 - 00:38:07)

Auf jeden Fall, ganz klar. Also darum sage ich, ich glaube, es ist vergleichbar mit der Microservice-Welt. Wenn du skalierst, wenn du größer wirst, wenn du mehr MitarbeiterInnen bekommst, die alle dieses Zeug verwenden, die da ihre Workflows zusammenbauen, dann wirst du an den Punkt kommen, wo du irgendwann dieses Problem hast mit der Dokumentation, mit dem Monitoring, weil du das nicht mehr überblicken kannst. Jeder macht irgendwas Eigenes und es ist halt ganz schwierig, das nachzuvollziehen. Wenn das so kleine Dinge sind, die man einfach mal ausprobiert, die wieder weggeworfen werden, bei einem Startup, weil man einfach schnell loslegen will, weil man noch gar nicht weiß vielleicht, wie sehen die perfekten APIs aus, wie ist der perfekte Prozess, dann macht das absolut Sinn und ich baue mir dann eine technische Schuld auf, wieder aktiv, entschieden, technische Schuld aufzubauen und das ist komplett in Ordnung. Aber wenn ich natürlich mehrere Jahre dann damit arbeite und vielleicht auch wachse, solange es klein bleibt, ist es ja auch meistens kein Problem und auch meine ganzen Dinge sind selten getestet, die ich so im privaten Umfeld mache oder irgendwo mal schnell schnell zusammenstöpsel, da braucht man das auch nicht. Aber ich habe auch keinen Anspruch, das zu skalieren. Das ist halt der große Unterschied. Also sobald du das Ganze skalieren willst, wird es schwieriger.

Andy Grunwald (00:38:07 - 00:38:14)

Aber ich frage mich gerade, in der High-Code-Situation sind das ja alles gelöste Probleme. Das, was du gerade erzählt hast, 50...

Wolfi Gassler (00:38:14 - 00:38:38)

Naja, ich bin mir nicht so sicher, ob das gelöste Probleme sind, weil jeder, der mal in der Microservice-Architektur gearbeitet hat, weiß, Netflix kann das und Netflix hatte die Tools dazu gebaut damals. Und wenn man das selber macht, Microservices, dann ist es gar nicht so leicht, da sinnvolles Monitoring einzubauen. Und wie du es richtig sagst, das machen wahrscheinlich viele auch nicht, aber die werden halt auch merken, dass wenn man größer wird, skaliert, dann ein Problem damit hat, egal ob No-Code oder Microservice. Welt.

Andy Grunwald (00:38:38 - 00:39:13)

Ja, aber nehmen wir nochmal das Beispiel, dass 50 Mitarbeiter in deinem No-Code-Tool Workflows zusammenbauen und du sagst, dann fehlt Dokumentation oder du verlierst die Übersicht, wo die Daten langfließen und welcher Workflow irgendwie was macht und gegebenenfalls machen drei Workflows auch genau das gleiche, nur von drei Mitarbeitern und die haben nicht miteinander gesprochen. Wenn ich mir jetzt mal das High-Code-Beispiel dann ist das vergleichbar mit einem data warehouse eine google big query oder ein paar kafka topics die daten hin und her streamen ja da hat man ja auch sogenannte data lineage und im high code bereich gibt es ja data lineage tools.

Wolfi Gassler (00:39:13 - 00:39:19)

Aber auch die sind nicht standard und sehr wenig firmen haben die eigentlich also dieses problem besteht dort genauso.

Andy Grunwald (00:39:19 - 00:39:34)

Also jeder, der in irgendeiner Art und Weise ein Data Warehouse hat und mit mehr als zwei Leuten an diesem Data Warehouse arbeitet, um versucht aus diesen Daten irgendeine Sinnhaftigkeit zu ziehen, der wird irgendwelche Workflows brauchen.

Wolfi Gassler (00:39:35 - 00:40:42)

Ja, Workflows schon, aber ob die dokumentiert sind, ist eine andere Frage. Und ich kann dir auf Anhieb mindestens fünf Firmen sagen, die über 300 Leute haben oder 500 Leute sogar, die das alle nicht haben. Also in der realen Welt ist es noch nicht so klar, dass das gebraucht wird. Aber ich glaube, es macht Sinn und es macht halt dann auch auf der NoCode-Seite irgendwann Sinn, weil ich eben meine Workflows in irgendeiner Form dokumentiert haben muss. Vielleicht kommt dann sogar irgendwann mal so ein nerviger, so ein CISO, glaube ich heißt das, oder? Chief Information Security Officer oder sowas, um die Ecke, weil man halt größer wird und vielleicht auch mal mit Kundendaten oder so Sachen unter Umständen hantiert. Und wenn der dann irgendwie mal mit Security-Anforderungen um die Ecke kommt, dann viel Spaß mit deinen 300 oder 800 No-Code-Workflows, die da irgendwo in irgendwelchen Ecken programmiert wurden und trennen oder auch nicht trennen. Oder du hast keine Ahnung, wo da eigentlich die Daten hin und her fließen, welcher externen Provider du hast. Also spätestens dann gibt es ein Problem und das musst du dann eben aufräumen und dann die technische Schuld wieder auflösen.

Andy Grunwald (00:40:43 - 00:40:49)

Willkommen zum Podcast für gratis Startup-Ideen. Heute Data Lineage für No-Code-Tools.

Wolfi Gassler (00:40:50 - 00:41:10)

Vielleicht gibt's da auch was, muss ich auch dazu sagen. Ich will's jetzt nicht ausschließen, dass da auch einige dran arbeiten. Auch so was Simples wie Staging zum Beispiel ist echt schwierig. Bei ganz vielen No-Code-Tools kommt aber jetzt so langsam, dass man das mal auf einem Staging-System ausprobieren kann, weil früher war ja einfach alles Brot. Alles, was irgendwie No-Code ist, ist automatisch Brot.

Andy Grunwald (00:41:10 - 00:41:23)

Meine erste Frage ist, Wenn du dieses Problem von Skalierung, so wie du es immer hast, ja, das ist auch typisches Berater-Buzzword, streich das mal bitte aus deinem Wortschatz, wenn wir hier Podcast aufnehmen, dann ist das doch ein tolles Problem zu haben.

Wolfi Gassler (00:41:23 - 00:41:36)

Ja. Es ist ja auch ein tolles Problem zu haben, in deinem eigenen Haus zu wohnen, das du mit Schulden gebaut hast, und die Schulden dann zurückzuzahlen. Ist ja auch ein schönes Gefühl, wenn du in deinem Haus dann wohnen kannst, trotzdem musst du die Schulden irgendwann zurückzahlen.

Andy Grunwald (00:41:36 - 00:41:39)

Ja, aber ist das nicht irgendwie der Sinn von NoCode?

Wolfi Gassler (00:41:39 - 00:41:58)

Ja. Vollkommen korrekt. Das ist der Sinn von No Code und das ist auch der Sinn von technischen Schulden. Darum sehe ich ja technische Schulden nicht als negativ an, wenn du sie zurückzahlst und du sie einfach in Kauf nimmst. Das ist vollkommen okay. Ich finde auch, dass das oft sehr negativ dargestellt wird in der Developer-Welt, diese technischen Schulden, weil sie ja oft helfen können.

Andy Grunwald (00:41:58 - 00:42:08)

Du vergleichst das ja jetzt gerade die ganzen Schulden mit finanziellen Schulden von einem Haus. Jetzt nehmen wir mal eben ganz kurz die Schufa als Beispiel. Kennst du die Schufa?

Wolfi Gassler (00:42:08 - 00:42:12)

Ja, natürlich. Mehr Skandale gibt es ja gar nicht mit eurer Schufa.

Andy Grunwald (00:42:12 - 00:42:16)

Einer der größten Frechheiten, die Deutschland je zu Rande gebracht hat.

Wolfi Gassler (00:42:16 - 00:42:18)

Wieso verwenden die auch No Code?

Andy Grunwald (00:42:18 - 00:42:42)

Nee, aber was die haben ist folgendes. Und zwar unterscheiden die in welcher Art von Schulden du hast. Nämlich ein Haus ist mehr oder weniger gute Schulden und ein Konsumkredit, wie zum Beispiel für ein Fernseher, sagen die sind schlechte Schulden. Und immer wenn du Finanzen oder technische Schulden mit Finanzschulden vergleichst, nimmst du immer die guten Kredite. Ich möchte jetzt von dir wissen, was sind denn die Konsumschulden von NoCode?

Wolfi Gassler (00:42:43 - 00:43:04)

Also ich glaube nicht, dass man da irgendwas unterscheiden kann in zwei Klassen. Natürlich gibt es Schulden, die schwieriger zurückzuzahlen sind oder mehr Aufwand sind, klarerweise. Aber das ist halt einfach die Höhe. Ob es da jetzt zwei Kategorien gibt, würde mir jetzt keine einfallen, dass eines irgendwie schlimmer ist oder besser, weil es kommt halt wirklich immer auf den Use Case drauf an.

Andy Grunwald (00:43:05 - 00:44:07)

Also ich hätte vielleicht zwei Beispiele, aber da bin ich mir nicht ganz sicher, ob das wirklich mit Konsumschulden zu vergleichen sind. Auf der einen Seite ist das Datenkonsistenz beziehungsweise Dateninkonsistenz. Weil ich glaube, du vergisst in diesen ganzen No-Code-Workflows, oder kann ich mir zumindest vorstellen, sehr schnell die wirkliche Source of Truth. Weil du nimmst ja Daten irgendwo raus, woher sie kommen, dann machst du damit irgendwas, du modifizierst sie, transformierst sie und so weiter, und hast ja dann mehr oder weniger neue Daten. Und die werden ja durch die No-Code-Workflows, ich sag mal, wie Kamelle beim Karneval, rumgeschmissen. Also da kann ich mir schon vorstellen, dass das wirklich zu harten Fehlentscheidungen im Business führen kann, wenn Dateninkonsistenzen entstehen, das Mapping von Datenstrukturen nicht korrekt durchgeführt wird, diese Daten gegebenenfalls nicht mehr wirklich verifiziert werden können und vielleicht sogar als official data erkannt werden also beispiel in ganz vielen ganz vielen firmen fängt man jetzt an daten zu verifizieren weil man möchte innovation fordern und sagen hier ist das data warehouse geht einfach mal ran fördern.

Wolfi Gassler (00:44:07 - 00:44:10)

Nicht fordern oder innovation fördern nicht fordern.

Andy Grunwald (00:44:10 - 00:44:41)

Ich fordere sie, andere fördern sie, das ist richtig. Aber jeder macht was mit den Daten und später weißt du gar nicht mehr, weil unterschiedliche Ergebnisse rauskommen, welche sind jetzt eigentlich Daten, auf die ich vertrauen kann. Und deswegen fangen jetzt Leute an, in Firmen Daten zu verifizieren. Das sind Daten, da ist der Workflow verifiziert bzw. da haben Leute drauf geguckt und diesen Daten kann man auf für Businessentscheidungen oder für Investitionsentscheidungen vertrauen. Und da stelle ich mir gerade so die Frage, ist das nicht gegebenenfalls ein Konsumkredit?

Wolfi Gassler (00:44:41 - 00:46:23)

Es ist auf jeden Fall ein extremes Anti-Pattern, würde ich mal sagen, wenn du da keine Source of Truth zur Verfügung hast. Und ich kenne das selber, gerade in einem kleineren Projekt habe ich kürzlich mit einem Developer gesprochen, der ein spezielles Datum an vier Stellen irgendwie, weil es halt verschiedene Services waren, irgendwie manuell gepflegt hat. Und er hat gemeint, es wird garantiert ein Problem, wenn wir das Datum mal ändern, weil wir vergessen da Stellen. Und er meinte, nein, so oft ändern wir das ja nicht, das sind ja nur vier Stellen und so weiter. Natürlich mittlerweile, ich hab mal reingeschaut, bei einer Änderung, es waren irgendwie vier verschiedene Daten in den verschiedenen Systemen drinnen. Einfach, das hat keiner mehr gewusst, was ist überhaupt jetzt das Richtige, obwohl das ein Mini-Projekt ist. Also das sind so Dinge, die darf man einfach nicht machen, meiner Meinung nach. Und das ist ein allgemeines Problem. Ich glaube, nicht bei No-Code oder bei High-Code, egal, das Problem hast du immer. Ich glaube, dass es in der Developer-Welt vielleicht bekannter ist, dass das eigentlich ein Problem ist. Wenn du jetzt aber nicht Developer an deine No-Code-Tools setzt oder denen halt ermöglichst und die auch enablest, dass die selber Abläufe bauen können, dann haben die halt diese Dinge, die wir vielleicht auf der Development-Seite einfach wissen oder vielleicht auch mal schon schmerzhaft feststellen haben müssen oder vielleicht auch gelernt haben. Die haben die halt nicht so intus, würde ich sagen, und die machen dann halt irgendwas, speichern irgendwo was ab, machen dann mit den Daten wieder irgendwas und die denken nicht dran, oh shit, jetzt habe ich da womöglich ein Datum dreimal dupliziert in unterschiedlicher Form und ich habe keine single source of truth mehr zur Verfügung, beziehungsweise man vergisst es halt auch einfach oder beziehungsweise man denkt halt einfach nicht dran, dass das ein Problem sein könnte, weil man die Erfahrung noch nie gemacht hat.

Andy Grunwald (00:46:23 - 00:46:45)

Aber du willst ja auch kein Gatekeeper-Team installieren, das sagt, hey, liebe Firma, jeder aus der Personalabteilung oder jeder Produktmanager darf jetzt No-Code-Tools nutzen, aber wenn ihr die in Produktion packen wollt, dann müssen diese verifiziert werden durch den Entwickler. Das kann es ja auch irgendwie nicht sein, weil das sind ja dann auch schon irgendwie Gatekeeper. Du willst ja schon die Innovation ich fordern, du fördern, aber...

Wolfi Gassler (00:46:45 - 00:47:34)

Was du halt schon machen kannst, ist, dass du zum Beispiel interne Plattformen zur Verfügung stellst, wo das möglichst dann automatisch dokumentiert wird. Du baust einen Workflow, du hast dann nicht fünf verschiedene Systeme, sondern du hast ein System. Jeder Workflow ist klar definiert. Du kannst dann vielleicht rausfinden, welcher Workflow greift auf welche Daten zu, dass das im Hintergrund automatisch passiert. Da bewegt sich ja auch viel bei den No-Code-Tools. Aber darum stellen halt Firmen auch so gern irgendwas Traditionelleres eigentlich ihren Mitarbeitern zur Verfügung und vielleicht ist man da eben nicht so schnell mit dem coolen neuen hippen Zeug. Aber das ist halt dann sehr oft in einem Konzern einfach begründet, dass man das nachvollziehen kann, dass das Security mäßig bisschen besser abgesichert ist. Also solche Dinge. Das ist halt einfach schwieriger und darum sind halt große Konzerne eher langsamer als jetzt irgendein kleines cooles Startup, was einfach sagt, okay, ich hab da jetzt meine Make Instance und go for it.

Andy Grunwald (00:47:35 - 00:47:50)

Mega-Überleitung, die war nicht abgesprochen. Denn mein zweiter Konsumkredit ist nämlich die Sicherheit. Und zwar rede ich nämlich davon, Authentication, Authorization oder sogenannte API-Keys oder Access-Keys durchrotieren. Und da kommst du nämlich mit.

Wolfi Gassler (00:47:50 - 00:47:51)

Durchrotieren.

Andy Grunwald (00:47:51 - 00:47:52)

So heißt das?

Wolfi Gassler (00:47:52 - 00:48:01)

Ja, ja, ist schon klar. Aber schau mal an, wo du irgendwelche Keys auf Knockout-Plattformen, die eine Marketingperson geschrieben hat, ob du da irgendwo Keys durchrotierst.

Andy Grunwald (00:48:02 - 00:48:37)

Ja aber du hast jetzt gerade von einem Enterprise und von einem Konzern gesprochen und da sind Keys oder Secrets durch rotieren in einem regelmäßigen Intervall ist da Standard. Jede AWS kann das auch, also jede große Plattform die Enterprise Kunden hat, bietet sowas an und besonders in Konzernen stelle ich mir vor, dass NoCodeTools schon sehr sehr viel helfen können weil die prozesse sind langsam vielleicht wird noch wasserfall genutzt und vielleicht ist es wirklich so dass wenn du heute etwas planst dass das frühestens in zwölf monaten die entwicklung gilt geht und da sind natürlich noco tools ja neuer wein in neuen schleuchen sogar.

Wolfi Gassler (00:48:37 - 00:49:03)

Ja Darum gibt es zum Beispiel Appian, heißt eine von diesen Plattformen, die schimpfen sich Enterprise Low-Code Prozessautomatisierung. Und die haben wahrscheinlich, ich habe jetzt nicht genau nachgeschaut, was deren coolen Feature diesbezüglich sind, aber ich könnte mir vorstellen, dass die halt da auch in der Beziehung vielleicht das eine oder andere coole Feature haben, damit es eher Enterprise-ready ist. Ohne das jetzt zu wissen, muss ich ganz zu dazu sagen.

Andy Grunwald (00:49:04 - 00:49:56)

Und wenn ich jetzt von Authentication und Autoresession spreche, spreche ich ja nicht nur, kann der Wirkung sich da einloggen und darf der auf den Produktionsworkflow, sondern eher, dass man das NoCodeTool Make.com oder wie das heißt, auf mein ERP-System lässt, Salesforce oder so, und dass dort die authorization richtig eingestellt ist ja dass du die also eigentlich die integrationen zwischen verschiedenen tools weil so wie ich das jetzt verstanden habe ist das die reale power von no code tools dass du die alle miteinander integrieren kannst dass du dann wirklich tool a nur die berechtigung und den zugriff auf ganz spezifische daten aber nicht auf alles gibt und Weil das macht ja glaube ich die das tor zur hölle auf oder besonders wenn das leute ohne einem security hintergrund ohne einem entwickler hintergrund wir reden hier von wir sind in deutschland datensparsamkeit.

Wolfi Gassler (00:49:56 - 00:52:38)

Kommt jetzt in amerika auch ganz frisch übrigens die datensparsamkeit mit dem neuen den neuen bill auf irgendwas. Aber auf jeden Fall, du hast vollkommen recht. Und wie gesagt, der CISO oder GDPR-Beauftragte oder sowas, also da wird es natürlich schwierig, wenn du dann mit sowas hantieren musst oder da gewisse Richtlinien hast oder irgendwelche Zertifizierungen brauchst. Das ist halt dann einfach schwierig. Aber wie gesagt, im Startup-Umfeld ist das alles kein Problem. Wobei man dazu sagen muss, jetzt zum Schutz von No-Code, auch für Developer ist das ganze Security-Thema natürlich ein großer Punkt und gar nicht so einfach. Also sogar auf der Ebene gibt es ja extrem viele Probleme und klar, wenn du das Shift-Left dann ja noch weiter betreibst, da haben wir ja schon eine Episode dazu gemacht, dann wird es halt noch schwieriger, wenn es dann zu irgendwelchen nicht-technischen Leuten eigentlich kommt die Kontrolle, würde ich mal sagen. Ohne das jetzt negativ zu meinen, aber es ist halt einfach ein Problem in der Realität, wenn es dann um Security Features oder Implementierungen geht. Es ist ganz schwierig. Und was meiner Meinung nach auch noch so ein großes Problem ist bei NoCode ganz allgemein, ist das Debugging. Wenn du irgendwo ein Problem hast, also du musst das Problem erst mal sehen, bevor jetzt ein Kunde anruft und sagt, hey, wo ist eigentlich mein Produkt, das ich bei euch bestellt habe? Oder wo ist meine Keycard von meinem Fitness Center Abo? Das wurde mir nie zugeschickt oder so diese Karte zum Beispiel, weil da im Hintergrund hat halt deine NoCode-Pipeline zufällig bei dem Kunden gerade nicht funktioniert, weil da irgendein Umlaut im Namen war oder sowas. Also daran irgendwie das ganze zu debuggen, das Problem zu finden, ist natürlich super schwierig. Und klar, die Tools unterstützen da teilweise. Logging und solche Dinge kommt immer mehr. Aber man muss schon sagen, man muss es auch wissen, dass man da sinnvoll loggt, wenn das Tool das nicht automatisch macht. Debugging ist halt auch ein Skill, der gar nicht so einfach ist. In der Developmentwelt kennt man den. Aber vielleicht der, der die Marketing-Pipeline aufgebaut hat, der hat keine Ahnung von Debugging, was das Wort überhaupt heißt. Und da wird es natürlich dann auch schwieriger, in einem Problemfall zu reagieren. Und dann hast du halt so eine technische Schuld, die du bei der Auflösung des Problemfalls vielleicht schon bezahlen musst, weil du da eben dann viel mehr Zeit investieren musst, als wenn du jetzt ein sauberes Logging hast. Und jeder, der mal Side-Projects oder irgendwelche kleinen Projects angefangen hat, weiß, wie schön Logging ist. Und umso früher man irgendwie ein strukturiertes Logging, ein schöneres Logging macht, umso einfacher ist es auch, dann Bugs zu finden oder Probleme zu beheben. Aber jeder fängt halt meistens an mit irgendeinem ganz simplen Echo System Out, was es auch immer heißt, je nach Programmiersprache. Und wenn man dann größer wird, will man halt irgendwann sinnvolles Logging haben. Und das muss man dann einfach irgendwann einbauen und da die Schuld, die technische Schuld zurückzahlen.

Andy Grunwald (00:52:38 - 00:53:21)

Das bringt mich zu einer ganz interessanten Frage. Steht No Code nicht eigentlich im Konflikt zu moderner Softwareentwicklung beziehungsweise der Praktiken in modernen Softwareentwicklung? Du hast grad schon Logging erwähnt, Debugging. Und ich schmeiß mal Buzzwords in die Runde. Devops, Shift-Left, Versionierung. Du hattest schon ein bisschen was mit Staging und Produktion angesprochen. Observability. Vielleicht sogar Analytics, AB-Testing, wie oft wird ein Workflow denn wirklich executed? Ist dieser überhaupt noch in Benutzung? Ich sag mal hier Clean-up und alle drunter dran, was man sagen würde, Dead-Code, Dead-Workflow. Steht das alles nicht irgendwie ein bisschen in Konflikt mit dem, was wir uns hier alle über die Jahre aufgebaut haben?

Wolfi Gassler (00:53:22 - 00:54:42)

Ich glaube nicht unbedingt, es muss halt dementsprechend auch dort implementiert sein. Also wenn man da die N8n-Plattform, diese Open-Source-Plattform sich anschaut, das ist eigentlich relativ cool. Du siehst ja dort alle Aufrufe, die basiert sind von deinen Pipelines, kannst in einen Aufruf reinklicken und kannst dann in jeden Node reinspringen, was hatte der für Aufrufparameter, wie hat der reagiert, was ist da passiert. Also du kannst da schon sehr tief reingehen und das ist eine Art von Debugging, da muss man gar nicht wissen, dass das Debugging heißt und das funktioniert eigentlich schon ganz gut. Also solange man diese ganzen Best Practices dann in irgendeiner Form in der Clicky-Bunty-Umgebung umsetzt und zur Verfügung stellt und die Leute vielleicht auch ausbildet, klarerweise. Also man lernt ja auch am Job, wenn man da mehr mit der Plattform arbeitet, wenn man Probleme begegnet. Also umso mehr bewegt man sich dann wieder in die professionelle Richtung, wo die Best Practices angewandt werden. Aber man muss halt schon sagen, dass die meisten Tools da noch relativ schwach sind auf der Brust. Zumindest noch, was ich bisher so mitbekommen habe. Und jeder, der mal in so einer No-Code-Plattform JavaScript irgendwie probiert hat zu entwickeln und zu debuggen und rennen zu lassen und du hast keine sinnvolle Idee und kein Syntax-Highlighting hat man meistens, aber Autocompletion und von Copilot sprich ich mal noch gar nicht. Also das sind schon Unterschiede, muss man ganz klar sagen. Und das ist kein gemütliches Programmieren, wie man es so kennt.

Andy Grunwald (00:54:42 - 00:55:12)

Wenn ich jetzt so eine No-Code-Plattform habe, die mir die Möglichkeit gibt, da etwas Code einzufügen, du hast gerade JavaScript genannt, vielleicht hat irgendeine Plattform auch eine Art Custom-Sprache, verdoppeln sich dann nicht die Nachteile von Technical Depth, weil es man dann auf zwei Ebenen einführen kann? Einmal auf der Workflow-Ebene und dann hat man eigentlich noch Workflow-Steps, wo man vielleicht Custom-Code ausführen kann, und da kann man ja ebenfalls dreckige Design-Decisions und Shortcuts und all das, was Technical Adaptation ausmacht, einführen.

Wolfi Gassler (00:55:12 - 00:56:19)

Also ihr habt es bei ganz vielen No-Code- oder Low-Code-Implementierungen, die ich bisher gemacht habe, eigentlich schon gehabt. Ich habe begonnen und habe mir gedacht, sehr cool, ich habe da in 0,19 HTTP API aufgesetzt gehabt mit Authentifizierung, Keys und so weiter. Das läuft automatisch auf dem Server, ich kann das sogar testen, ich kann das schon aufrufen, das ist super schnell. Also da habe ich mir extrem viel Zeit gespart. Und dann fange ich so an, diese Pipeline zu bauen, den Workflow zu bauen und dann denke ich, boah, da war jetzt ein If-Fein und dann probiere ich das mit irgendwelchen Nodes zu machen. Das ist dann zu komplex, das geht mit den Nodes nicht. Dann fange ich an, irgendeinen Custom-JavaScript-Code zu schreiben. Dann habe ich gewisse Elemente nicht, die werden in irgendwelchen anderen Objekten übergeben. verbratet man da teilweise so viel Zeit und es wird extrem kompliziert und komplex. Und da denke ich mir dann oft, okay, wenn ich das jetzt einfach von Grund auf selber geschrieben hätte mit einer Library, dann wäre Schlussendlich wieder schneller gewesen. Also es ist schon die Frage, wie komplex darf das Ganze sein, wie sehr gehe ich da rein und was spart mir das dann an Zeit Schlussendlich?

Andy Grunwald (00:56:20 - 00:56:49)

Komplexität bei Workflows finde ich auch eine interessante Geschichte. Und zwar, wenn ich dir so zuhöre, kann ich mir vorstellen, und da bin ich ganz ehrlich, ich habe das noch nie gemacht, ich habe da einen Workflow-Manager und habe dann 100 Workflows drin. Die laufen auch alle, aber mit der Erfahrung, die ich gesammelt habe durch die Erstellung dieser 100 Workflows, wird's alles ein bisschen undurchsichtig. Und ich würd sagen, okay, ich würd das gerne neu machen. Da bist du ja schon wieder in der Maintainability-Hell, oder?

Wolfi Gassler (00:56:50 - 00:56:51)

Ja, klar.

Andy Grunwald (00:56:51 - 00:56:53)

Das ist so ähnlich wie ... Hast du schon mal Factorio gespielt?

Wolfi Gassler (00:56:54 - 00:56:56)

Na. Aber ich hab schon mal davon gehört, ja.

Andy Grunwald (00:56:56 - 00:57:17)

Das ist ein Aufbau-Computerspiel, wo du halt, ich sag mal, weiß ich nicht, Elemente von A nach B packen musst und dann, ne, so Fahrbänder musst du da hinstellen und so weiter. Das bedeutet, du baust ganz viele Straßen, würd ich mal sagen. Und hast du das mal 30-mal gemacht, denkst du dir, scheiße, ich möchte neu anfangen. Weil ich möchte das jetzt sauber machen. Ich möchte saubere Straßen haben.

Wolfi Gassler (00:57:17 - 00:57:23)

Da brauchst du kein Computerspiel dazu. Da kannst du jede Codebase nehmen, die du mal gestartet hast.

Andy Grunwald (00:57:23 - 00:57:30)

Ja, richtig. Und irgendwie ist ja der visuelle Workflow-Manager eines NoCode-Tools irgendwie wie Vectorio.

Wolfi Gassler (00:57:30 - 00:59:17)

Ja, klar. Ich glaube, Maintenance ... Änderungen, die waren einfach viel schwieriger. Alleine schon, also wenn ich mir meine eigenen Workflows anschaue und die will da jetzt irgendwas ändern, bis ich wieder verstehe, was ich da eigentlich damals gemacht habe, dann muss ich da diese einzelnen Notes durchklicken, dann habe ich da meistens irgendwelche Workarounds gemacht, weil halt irgendwas nicht möglich war und ich muss mir denken, warum habe ich da jetzt eine Linie zu dem Knoten und irgendwie was anderes aufgerufen. Also du hast ja halt dokumentationsmäßig dann relativ wenig Möglichkeiten. Klar hast du das beim Code auch, das kennt jeder, Aber ich finde es fast bei so Oberflächen nochmal schwieriger, weil es auch vielleicht, und das könnte natürlich ein Grund sein, für mich als Developer mit meinem Developer-Background einfach die falsche Herangehensweise ist. Und ich bin halt viel mehr gewöhnt, Code zu lesen und Code zu debuggen und mich da schneller zurechtzufinden und die Kommentare zu haben und meine Möglichkeiten, die man halt in Code hat, ein If-Statement. Teilweise gibt es ja nicht einmal sinnvolle If-Statements in so Workflow-Engines. sondern nur irgendwelche Weichen und das wird dann alles super kompliziert. Ich könnte mir aber vorstellen, dass es für nicht technische Leute unter Umständen die bessere Herangehensweise ist, weil die ein anderes Denkmuster haben. Also ich will jetzt gar nicht sagen, dass das absolut falsch ist und in die falsche Richtung geht, aber für mich als Developer geht es eher in die falsche Richtung und das sagen ja auch viele Developer, dass sie eigentlich nicht so gerne diese No-Code und Low-Code Tools verwenden. weil es teilweise wirklich mühsamer und aufwendiger ist. Natürlich gewisse Sachen, wenn du da ein Formular machst, da bist du einfach super schnell oder wenn du einfach nur einen Google Form machst, bist du auch super schnell, also wenn du das selber programmierst, ganz klar, aber sobald es komplexer wird, hat man da, glaube ich, als Developer sofort die Anforderung, hey, ich würde das noch gern so machen, ich würde das noch gern komplizierter machen, ich würde da noch gern diesen Sub-Branch machen und ein schönes Logging dazu und das fällt dann natürlich alles sofort weg.

Andy Grunwald (00:59:17 - 00:59:48)

Aber kann das richtig eingesetzt nicht eigentlich einen totalen Raketenboost geben, weil ich habe mal jetzt gerade zwei Anwendungsfälle. A, Experimente. Du möchtest nur mit etwas experimentieren, du möchtest nur etwas recht schnell bauen, recht spartanisch und nicht diese extra Wurst, die du gerade beschrieben hast, da reinpacken. dann bist dann launch du das und schaust wird das genutzt oder nicht und wenn das genutzt wird dann kannst du es ja noch mal ordentlich in wie hast du es genannt high code ja in eigener software gießen.

Wolfi Gassler (00:59:48 - 01:01:06)

Das ist glaube ich eine super herangehensweise das ist genau dafür wofür man eigentlich technische schuld aufbaut meiner meinung nach man macht schulden um schneller auf den markt zu kommen um feedback zu bekommen weil wenn man es dann weg wirft sind die schulden ja auch weg ist ja nicht so wie bei einem klassischen kredit Aber sie sind dann weg, die Schulden, wenn man das ganze Projekt wegwirft. Und da macht es absolut Sinn, weil da verzögere ich quasi das Investment in dieses Produkt, um das auf den Markt zu bringen, um was auszuprobieren. Und das sind genau diese Punkte, wo ich das auch verwende, um schnell was auszuprobieren oder um kleine Sachen zu machen. Also wenn ich jetzt zum Beispiel einen simplen Webhook irgendwo bekomme, jetzt von Netlify zum Beispiel, wenn irgendwas gebaut wird, eine Webseite und ich will danach eine Slack-Message bekommen, dann kann ich da halt meinen Webhook schnell verarbeiten in so einer Workflow-Engine und mir dann eine Slack-Message schicken. Also solche Dinge sind halt einfach super schnell zusammengeklickt. Das ist für mich als Developer auch ganz fein und praktisch. Sobald es komplexer wird, muss man halt irgendwie den Absprung dann schaffen. Also wie lange mache ich das noch mit No-Code, Low-Code? Und wann wächst denn High Code? Und diesen Absprung, diese Gradwanderung ist halt glaube ich schwierig und muss man halt dann wirklich je nach Firma, je nach Use Case, je nach Produkt für sich definieren.

Andy Grunwald (01:01:06 - 01:01:31)

Der zweite Anwendungsfall, der mir in den Sinn kommt, ist, wenn Produktmanager sich ein neues Feature ausdenken. Die könnten sich das doch eigentlich recht gut in einem No-Code-Tool zusammenklingen und das dann visualisieren, um ihre Idee zu den Entwicklern zu transportieren. Dann stellen die Entwickler nochmal drei, vier, fünf Fragen. aber im endeffekt haben sie ich will nicht sagen den running prototype das wäre vielleicht ein bisschen zu viel ist guten aber schon eine sehr sehr gute idee und das reduziert einfach kommunikationsprobleme oder.

Wolfi Gassler (01:01:32 - 01:02:13)

Wäre eine Möglichkeit, wobei da sehe ich eigentlich fast irgendwie Wireframing oder so Figma Click Dummies eigentlich die bessere Variante, weil das ist schon viel Arbeit, um sowas auch in einem No-Code-Tool zu programmieren, nur um den Developern zu zeigen, wie was funktioniert. Aber klar, wenn das dann auch wirklich eingesetzt werden kann, dann ist es was anderes. Also ich glaube, für schnell mal was ausprobieren oder auch für ganz viele API-Anbindungen, die man einfach wo man jetzt keine extreme Skalierung braucht, weil die wird einfach zweimal im Monat aufgerufen, ist auch nicht so kritisch, nicht so businesskritisch vielleicht, dass das auch nicht so schlimm ist, wenn die mal nicht aufgerufen wird oder so. Ja natürlich, perfekter Anwendungsfall meiner Meinung nach.

Andy Grunwald (01:02:14 - 01:02:27)

Jetzt sind wir recht bold in dieser Episode gestartet mit No Code is Technical Debt. Und jetzt hört sich das aber doch schon recht positiv an, Wolfgang. Wie stehst du denn jetzt zu No Code generell?

Wolfi Gassler (01:02:27 - 01:03:21)

Also, ich unterschreibe die SA-Aussage immer noch. No Code ist technische Schuld, eindeutig. Das ist eine technische Schuld, wenn ich mit No Code anfange. Aber ich finde das positiv. Für mich ist das nicht negativ. Technische Schulden sind was Positives, wenn ich sie richtig einsetze und darum finde ich NoCode extrem cool, aber für den richtigen Anwendungsfall, wenn es was Kleines ist, wenn es einfach was zum Ausprobieren ist, wenn es was ist, wo man einfach schnell starten will, in einem Startup zum Beispiel und Für mich als Developer zumindest bisher, ich persönlich habe dann ganz oft, sobald es ein bisschen komplexer wird, einfach den klassischen High Code bevorzugt, weil ich da mehr Möglichkeiten habe und dort bin ich ja auch schnell, wenn ich meine Umgebung habe, um schnell eine REST API irgendwo hochzufahren, zu hosten, serverless, da bin ich einfach schneller und habe dann aber meine ganzen Tools, IDEs, Monitoring, Logging, alles was ich brauche und was mich persönlich enablen.

Andy Grunwald (01:03:21 - 01:04:01)

Und beschleunigen Liebe Hörerinnen und Hörer, jetzt mal etwas ganz kurz behind the scenes vom Podcast. Und zwar, der Wolfgang möchte nämlich, dass wir mal ein bisschen mit NoCode experimentieren in der Produktion von diesem Podcast. Und zwar hat er überlegt, eine State-Management-Table in Airtable anzulegen, wo wir dann, wenn einer von uns einen Schritt in der Produktion einer Episode fertiggestellt hat, dass man da drauf klickt, dann einen grünen Haken macht und dass dann eine Aktion getätigt wird. Und mir wird immer vorgeworfen, dass ich ja Hacky Code mache. Ich möchte nur kurz erwähnen, dass der Wolfgang jetzt zur Produktion technische Schulden vorschlägt.

Wolfi Gassler (01:04:02 - 01:04:29)

Genau, finde ich eigentlich sehr gut. Man muss ja auch sagen, die jetzigen Automatisierungen, die wir haben, da ist ja auch null Monitoring drauf. Also klar bekommen wir von GitHub vielleicht eine E-Mail, wenn wir Glück haben und da wirklich ein Error richtig ausgespuckt wird. Sonst ist einfach mal unsere Webseite down zum Beispiel. Hatten wir ja auch schon. Also da gibt es auch kein ordentliches Monitoring. Ist auch eine technische Schuld. Ist aber in so einem Projekt einfach, um schnell was an den Start zu bekommen, absolut sinnvoll meiner Meinung nach.

Andy Grunwald (01:04:29 - 01:04:32)

Wir sind ja noch in der Evaluierungsphase von diesem Podcast.

Wolfi Gassler (01:04:32 - 01:04:41)

Eben, nach 100.000 Downloads und über 100, wie viele Episoden, 150 Episoden oder so was da, klar, da sind wir noch in der Evaluierung.

Andy Grunwald (01:04:41 - 01:04:56)

Du träumst auch noch mal, dass du zwei Meter groß wirst, ne? 150 Episoden. Wir sind da über 120 oder so. Also von daher, das passt schon. Naja, ich werde mir auf jeden Fall mal N8n als Open-Source-No-Code-Plattform ansehen, denn... Und.

Wolfi Gassler (01:04:56 - 01:05:27)

No-Code-DB ist so auch da ein großer Player in dem ganzen Game. Also da ist mehr die Datenbankseite drin. Aber es gibt auch garantiert tausende andere. Wenn ihr da irgendwie gute Vorschläge habt oder irgendwie Erfahrung, bitte kommt vorbei bei uns in der Discord-Community. Link ist in den Show Notes. und erzählt uns, was es sonst noch an coolen Tools gibt, die ihr verwendet, weil es gibt wirklich viele, viele, viele coole Tools und für spezielle Anwendungsgebiete. Und wie gesagt, ich bin komplett offen und ich finde auch viele von diesen Tools sehr hilfreich und ich würde auch einiges damit machen.

Andy Grunwald (01:05:27 - 01:05:55)

Lasst uns mal wissen, welche No-Code-Workflows ihr eingerichtet habt und wie ihr dazu steht, ob ihr sagt, das sind technische Schulden oder das ist mein neues Produktionssystem. Ich freu mich auf jeden Fall auf die ersten sechs Personen, die dem Wolfgang mal richtig ordentlich Kasala Contra geben, denn ich glaub, das hat er mal verdient. Weil wenn er vernünftig versucht, auf LinkedIn einen Streit anzufangen und dann mal ratzfatz wieder den Rückwärtsgang einlegt, also ...

Wolfi Gassler (01:05:55 - 01:06:14)

Wie gesagt, die Einladung an den CTO von Fint steht natürlich. Wir können gerne im Podcast darüber sprechen. Würde mir auch interessieren, einfach seine Erfahrungen im No-Code-Bereich. Die Einladung steht und wie gesagt, kann jeder schön mitdiskutieren dort. Kein Rückwärtsgang eingelegt. Hoffe auf viele Vorwärtsgänge von anderen Leuten.

Andy Grunwald (01:06:15 - 01:06:38)

Ich bin ja immer noch der Freund von nichts ist persistenter als der beste Hack. Und deswegen, wenn wir im Podcast hier mit No Code anfangen, technische Schulden, tut mir leid, ich sehe mich nicht dieses zurückzuzahlen. So viel von uns. Also, wenn ihr diese Episode gehört habt, dann sind die technischen Schulden noch da. Andernfalls können wir diese Episode nicht produzieren.

Wolfi Gassler (01:06:38 - 01:06:57)

Na gut, aber vielleicht noch auch so zur Ergänzung. Es gibt ja eigentlich fast keine Firma, die keine Schulden hat. Also Schulden werden ja wirklich gezielt auch eingesetzt. Und insofern habe ich da auch gar kein Problem, dass wir technische Schulden haben für so ein Projekt. Und es läuft ja auch gut. Also da gibt es gar nichts dagegen zu sagen eigentlich.

Andy Grunwald (01:06:57 - 01:07:27)

Wirtschaftlich sind Schulden oft sehr gut und besonders in einer jetzigen Phase, wirtschaftlich gesehen, wo man wieder Zinsen auf dem Konto kriegt, macht es ab und zu, je nach deiner Situation, keinen Sinn, Sondertilgungen für dein Haus oder Wohnung zu leisten, weil jetzt gerade auch bei der hohen Inflation werden deine Schulden weniger. Also alles sehr simplifiziert ausgedrückt, aber denk mal darüber nach, Nun gut, Schulden sind nicht immer schlecht, aber...

Wolfi Gassler (01:07:27 - 01:07:30)

Sagt der Finanzbeirater Andi Grundwald.

Andy Grunwald (01:07:30 - 01:07:39)

Nein, nein, nein, das hat hier nichts mit Finanz- oder Steuerberatung zu tun. Wie heißt dieser Disclaimer bei diesem ganzen Börsen-Podcast? Ihr handelt auf eigene Rechnung. Blabliblub.

Wolfi Gassler (01:07:39 - 01:07:42)

Sendet einfach, wenn ihr irgendwas falsch gemacht habt, sendet das an Andi.

Andy Grunwald (01:07:42 - 01:07:42)

Super.

Wolfi Gassler (01:07:42 - 01:07:44)

Andi steht dafür gerade.

Andy Grunwald (01:07:44 - 01:07:48)

Wolfgang, bevor ich hier noch mehr Briefe kriege, vielen Dank dafür. Bis später. Tschüss. Ciao.