Welche Rolle spielen Softwareentwickler bei der Digitalisierung?

0:04 Wege der Digitalisierung. Wir finden heraus, was Digitalisierung alles bedeuten kann. Heute sitze ich bei den FortiTools. Vor mir sitzt Axel Tetzlar. Wir kennen uns schon seit langer Zeit. Wir haben schon im Wohnheim zusammen gewohnt, zusammen studiert und haben zwischendurch nicht so den Kontakt gehalten. Ich weiß gar nicht genau, was Axel bis 2010 gemacht hat. Das wird er uns vielleicht erzählen. 2010 hat Axel mit ein paar auch Wettlern, soweit ich das weiß, die 40 Tools gegründet und spannenderweise ist dieses das erste Interview, das ich führe mit jemandem, der auch Softwareentwickler ist. Von daher werden wir, glaube ich, noch auf ein paar spannende Punkte kommen, die wir im Podcast bisher nicht so Fokus haben. Ja, und wir werden darüber reden, wie man als Softwareentwickler an eigene Produktentwicklungen rangeht und wo wir da so die Fallstricke jeweils gefunden haben.

0:53 Vor allen Dingen wird es heute darum gehen, wie wir als Agenturen unseren Kunden und damit sicherlich einigen der Leute, die hier zuhören, helfen, was so die Probleme sind, die wir da in der Zusammenarbeit oft erleben, gerade wenn es an die Projektstartphase geht. Axel wird auch ein bisschen erzählen, was für eigene Tools sie am Start haben, wo da vielleicht Fallstricke waren, was man daraus lernen kann. Ich freue mich auf das Interview. Vielen Dank, Axel, für deine Zeit und auf geht's! Erzähl mal, ergänzt, was ich erzählt habe. Wer bist du? Was machst du? Warum sind wir hier?

1:34 Ja, das war ja schon ein ganz guter Anfang. Genau, ich bin Axel und ich habe mit Timo und Sebastian vor sieben, acht Jahren unsere Firma FortiTools zusammen gegründet. Wir haben uns damals im Studium kennengelernt und eigentlich wollten wir irgendwann den Schwerpunkt in die Produktentwicklung schaffen, aber wir fahren immer noch so, dass eigentlich auch einer unserer signifikanten Standbeine die Softwareentwicklung als Dienstleistung ist. Da gibt es im Punkt Digitalisierung natürlich besonders viele Reibungspunkte und wir nutzen aber halt da auch immer die Erfahrung, die wir mit unseren eigenen Produkten in der Entwicklung gemacht haben, um unsere Kunden sozusagen davon profitieren zu lassen.

2:14 Unser eigenes Zugpferd sozusagen ist die Software Skyline. Das ist eine Bürolösung für Gebäudedienstleister. Das klingt erstmal relativ sperrig, aber ist im Prinzip eigentlich nur so eine Rechnungslösung, wie sie von vielen anderen auch angeboten wird, aber im Schwerpunkt halt mit ein paar branchenspezifischen Funktionen für Gebäudereiniger, da die wiederkehrende Rechnungsstellung ist für die halt besonders brennendes Thema, was wir halt besonders gut da abbilden. aber dabei oder daneben haben wir halt auch immer weiter für externe Kunden Software entwickelt und auch die auf dem Weg zum digitalen Produkt oder bei der Digitalisierung ihrer Prozesse halt unterstützt. Ja, so viel erstmal zu uns vielleicht.

3:02 Ja, dann würde ich sagen, lass uns doch mal kurz, bevor wir auf den Schwerpunkt von heute mit der Softwareentwicklung eingehen, Kurz die Frage, was bedeutet Digitalisierung aus deiner Sicht? Wir wissen alle, es gibt nicht die eine Antwort, aber jeder hat so sein persönliches Bild. Bisher aus den elf Interviews, die ich geführt habe, habe ich elf sehr unterschiedliche Bilder. Ich rechne jetzt mit einem zwölften Bild.

3:27 Ich versuche da etwas, was noch nicht gesagt ist, zu sagen. Also für mich hat sich, glaube ich, vor vielen Jahren sozusagen, als es mit den Computern losging, war Digitalisierung, glaube ich, halt einfach noch was anderes, einfach allein auf der Grundlage, dass die Computer nicht so leistungsstark waren. Das heißt, es gab einfach nur eine begrenzte Anzahl von Problemen, die man überhaupt mit Computern lösen konnte. Und damals war dann der Kunde einfach froh, wenn der Softwareentwickler ihn irgendwie da unterstützen könnte mit seinem Problem. Und heutzutage, wo Computer viel mehr Rechenleistung haben, ist halt der Möglichkeitsraum einfach viel größer, viel mehr Prozesse abzubilden. Also heutzutage verbringen Computer einfach viel, viel, viel mehr Zeit, damit grafische Oberflächen zu rendern, als das noch vor 20, 30 Jahren der Fall war.

4:20 Und das ist, glaube ich, auch so das Hauptproblem, wo der Mindshift einfach noch nicht so passiert ist, dass sich Digitalisierer wie wir und unsere Kunden halt damit auseinandersetzen müssen, welche Prozesse überhaupt digitalisiert werden. und dass man von dieser Selbstverständlichkeit weg muss, es gibt eigentlich nur das eine Problem, was es zu lösen ist, sondern dass man einfach mal einen Schritt zurück macht, bevor man anfängt Software zu entwickeln und sich fragt, was ist denn eigentlich das Problem, was wir lösen wollen.

4:51 Ich finde, das ist eine super Überleitung. Genau, also es passt irgendwo so zu dem O-Ton, der sich aus den bisherigen Interviews ergibt, dass man oft daher kommt, dass man denkt, jetzt habe ich ein neues Tool oder eine neue Technologie. Und das ist oft der Stein des Anstoßes, aber das ist halt eben nicht die Lösung, sondern das ist nur der Anfang. Und Prozesse, je nachdem, wo man hinguckt, oft auch dann die Führungs- und Menschenthemen wieder noch dranhängen. Am Ende muss ja irgendwer das, was wir beiden bauen, auch nutzen. Da kann man es auch richtig oder nicht so richtig machen, auf jeden Fall. Ja, dann lass uns doch einfach schon mal direkt zur Software kommen. Also ich bin ja sehr gespannt, weil ich da im Podcast noch nicht mit jemandem so in der Form groß drüber reden konnte.

5:41 Ja, also Software ist Kern eures Geschäftsmodells, kann man schon so sagen. Ihr seid eine Softwareagentur, so wie Lionizers auch. Im Prinzip auch von Anfang an. Also ihr habt zwar mit eigener Produktentwicklung auch von Anfang an angefangen, aber ihr habt auch von Tag 1 an Kundenprojektive übersetzt. Erzähl mal ein bisschen, wo ist da euer Schwerpunkt? Was sind so die Probleme, die ihr am liebsten löst? Was sind die Probleme, die ihr gerade noch löst? Und was sind Probleme, wo ihr sagt, das können wir nicht, wollen wir nicht, braucht ihr wen anders?

6:16 Also unsere Kernkompetenz ist auf jeden Fall Prototypenentwicklung, schnell, produktiv was auf die Beine zu kriegen und Leute dabei zu unterstützen, auch ihr wahrscheinlich digitales Geschäftsmodell sozusagen zu evaluieren. Und da gehört eine unserer Kernkompetenzen aus dem Bereich, es hat auf jeden Fall auch Leuten Features und Funktionen sozusagen auszureden. Unsere Technologie, auf die wir da halt hauptsächlich setzen, also es ist hauptsächlich webbasiertes Kram, den wir bauen, auf Basis von Ruby on Rails, weil wir da auch das beste Aufwand-Nutzen-Verhältnis sozusagen haben. Also Timo und ich haben vorher auch eine Agentur gearbeitet, wo wir für Java gemacht haben. Und auch aus dieser Erfahrung ist auch dieses Bedürfnis entstanden, schneller einfach was auf die Straße zu kriegen.

7:10 Und in dem Spektrum, da liegt auch sozusagen unser Sweet-Spot, also alles, was so, sage ich mal, nur eine kleine Webpräsenz oder eine Webseite ist, das ist eigentlich für uns nicht so interessant. Und eine Software, an der irgendwie 20 Leute ein Jahr entwickeln sollen, das ist eigentlich auch nicht so unseres. Also wir wollen wirklich, was wo jemand sagt, so innerhalb von den nächsten drei Monaten will ich online sein. Und wir helfen dem Kunden dabei auch, da seinen MVP spitz zu machen, zu sagen, brauchst du das wirklich oder schaffen wir das vielleicht auch nach dem Launch? Das ist eigentlich das, wo wir am meisten Spaß auch dran haben.

7:51 Ja, cool. Also das passt genau zu meiner Erfahrung. Also Web-Backend-seitig nutzen wir auch Ruby on Rails. also bin ich einfach seit Jahren hängen geblieben und ich habe halt früher viel Embedded Software gemacht und Steuergeräte und das war dann halt Plain C und da hängt auch noch viel Prozess dran, der einen manchmal quälen kann ja von daher war Ruby on Rails für mich auch so eine Erleuchtung sag ich mal, nach ein paar Jahren C, kann ich sehr gut verstehen also geht es auch so, dass wir da einfach sehr schnell Dinge auf die Straße kriegen. Du hast schon gesagt, dieses Features Ausreden ist so eine Stärke. Wie läuft das? Jemand kommt zu euch, hat eine Idee und du hattest im Vorgespräch schon gesagt, oft sind das Leute, die denken, dass man einen analogen Prozess einfach so in Software gießen kann.

8:43 Wie läuft das ab? Was passiert alles, bis ihr real anfangt, die Software zu schreiben und sie live geht? Da liegen ja ein paar Schritte zwischen, die man als Nicht-Software-Entwickler gar nicht so erwartet.

8:56 Genau, also wir versuchen natürlich im Sinne dieser Time-to-Market sozusagen die Anzahl und Länge dieser Schritte so klein und kurz wie möglich zu halten. Und es hängt auch immer von dem Kunden sozusagen ab, der an einen herantritt. Branchenmäßig haben wir da auch keine Vorzüge, sozusagen von Banken bis Schüleraustauschorganisationen haben wir schon ziemlich viel bedient. Und es hängt natürlich auch immer von der Komplexität des Businessmodells des jeweiligen Kunden ab. und auch natürlich wie gut derjenige vorbereitet ist und auch wie sehr er sich vielleicht schon vorher mit agilen Prozessen auseinandergesetzt hat. Weil das ist eigentlich Grundlage jeder Zusammenarbeit, dass man sich erstmal auf ein gemeinsames Vorgehensmodell einigen muss.

9:43 Das klingt mal jetzt pompöser, als das sein sollte eigentlich, weil wir natürlich nicht überraschenderweise eine agile Vorgehensweise bevorzugen, wobei wir uns nicht da dogmatisch jetzt an ein Scrum oder Kann-Bahn halten unbedingt, sondern halt da versuchen, zuerst mal eine Vertrauensbasis mit dem Kunden herzustellen und dann merkt man auch relativ schnell bei den beteiligten Leuten, wie sehr das dogmatisch oder eher auf Zugruf laufen kann. Und wenn das klar ist, dann machen wir halt meistens nochmal einen Tag lang Workshop mit einem Kunden, um sozusagen den Umfang vom MVP klarzumachen. Und entweder fängt man dann schon an, gemeinsam Storys zu schreiben oder man sagt, der Kunde schreibt erst mal einen Aufschlag und wir ließen das gegen oder wir machen das genau umgekehrt.

10:37 Aber im Prinzip steht nichts im Wege, wenn das vertraglich alles dann auch abgesegnet ist, nach ein oder zwei Wochen direkt mit der Entwicklung zu starten.

10:48 Und so aus deiner Erfahrung heraus, Also wie sehr baut ihr in der Regel das, womit die Leute anfangs durch die Tür kamen? Und wie sehr habt ihr da gemeinsame Learnings in den ersten Wochen, bis das dann losgeht?

11:02 Also in unserer Erfahrung bauen wir nie das, womit der Kunde eigentlich kommt, was er denkt, was er braucht, sage ich immer. weil es häufig so ist, also gerade wenn man bestehende Unternehmen versucht, Sachen von denen zu digitalisieren, kommen die halt häufig mit der Erwartung, dass man einfach das, was sie schon analog machen, einfach digital abbildet. Und damit verschenkt man einfach super viel Potenzial, beziehungsweise wenn es ans Businessmodell geht, wenn jemand dann ein digitales Produkt hat und er geht so vor, dann hat er einfach keine Chance gegen eine Konkurrenz, die das halt gut macht. Und deswegen ist meistens auch die Anfangsphase bei diesen Projekten, die Komplexität liegt meistens nicht auf der technischen Seite, sondern auf der Spezifikationsseite oder auf der Umfangsseite oder Auftragsklärungsseite, dass häufig Leute zu uns kommen und uns sagen, was sie denken, was sie brauchen und von uns einfach nur wissen wollen, wie lange wir jetzt brauchen, um das umzusetzen.

12:06 und wir meistens dann sie davon überzeugen müssen, dass man eigentlich nochmal einen Schritt zurückgehen muss und nochmal erstmal klären muss, erklärt uns bitte erstmal nochmal, was euer Problem ist und dann können wir euch vielleicht eine technische Lösung vorgeben, die viel besser ist als das, was ihr euch gedacht habt. Weil das Thema Softwareentwicklung ist, glaube ich, einfach so zweigeteilt. Einerseits ist es einfach nur das Programmieren, sozusagen, wie bringe ich den Computer dazu, zu machen, was ich will. Und das andere, was aber auch eine Kompetenz ist und die liegt halt irgendwo zwischen der Fachlichkeit und der Softwareentwicklung, ist, wie ich ein Problem mithilfe des Computers löse.

12:51 Und das hat weniger damit zu tun, wie ich den programmiere, sondern wie ich die Prozesse strukturiere, was für Abläufe ich einfach mache, was für Bildschirmfolgen und wo die Buttons sind meinetwegen und solche Sachen. Und das ist halt das, wo häufig zu wenig Energie reingesteckt wird oder was vom Kunden im Projektablauf gar nicht vorgesehen ist als Kostenpunkt oder als Aufwandspunkt.

13:14 Ja, kann ich total bestätigen. Ich weiß, dass noch Anfang des Studiums, erstes, zweites Semester Software Engineering ging, das nur um so weiche Themen wie Anforderungen und Prozess. Ich weiß noch, dass mich das als erstes Semester total genervt hat, weil ich doch wissen wollte, wie man programmiert. Und ich weiß, dass du auch Vorlesungen hältst gelegentlich. Und ich halte ja auch als freier Dozent an der HAW Software-Architektur-Vorlesung. Also mittlerweile nerve ich meine Studis halt genau damit, dass ich sage, ja, Coding ist wichtig, muss man gut lernen, ist immer nur das Handwerkszeug. Am Ende muss man aber irgendwas bauen, was die Leute auch benutzen können und was die benutzen wollen. Also von daher, ich denke, das ist genau der Punkt, dass viele Leute halt mit der Idee kommen, ich weiß doch, wie mein Prozess aussieht.

14:07 Aber da kommen wir auch genau zu den Menschenthemen, die in den vergangenen Interviews schon oft angerissen wurden. Gerade die beiden Coaches, die ich interviewt habe, die Christiane Brandes-Fisberg und die Frau Kahlsen, Die coachen ja gerade Unternehmen dahin, in dieser Zeit, in der alles immer schneller wird, immer digitaler, wie schaffe ich es denn, meine Leute mitzunehmen. Und im Prinzip ist das total wichtig, dass die Tools da an die Menschen angepasst sind. Weil wenn ich als Mitarbeiter in einem Unternehmen, der sowieso schon keinen Nerv hat auf diese ständigen Veränderungen, dann auch noch eine Software kriege, die eigentlich nicht so arbeitet, wie ich das erwarte, dann habe ich als Unternehmen, das so eine Software bauen lässt, natürlich noch viel mehr Schwierigkeiten.

14:55 Also das ist auch was, das war auch sehr witzig, wenn ich jetzt so zurückblicke, als ich damals an der Fachhochschule Wedel angefangen habe zu studieren, hatte ich mich schon damals auf diesen Medieninformatik-Bereich ja so gestürzt, weil ich diese Grafik- und Audiothemen auch einfach persönlich spannend fand, aber es war immer so diese Frage auch im Hinterkopf, wer braucht am Ende eigentlich einen Medieninformatiker? Und ich muss jetzt so sagen, im Nachgang öffnet mir das so viele Türen und macht mir das gewisse Sachen leichter, weil diese Mediensache so eine Brücke zwischen diesem harten Computing-Kram irgendwie ist und dem Menschen, der das bedienen muss, dass ich halt einfach in dieser Zwischenwelt ganz gut zurechtkomme.

15:41 dass ich einfach, glaube ich, auch besser weiß als jemand, der nur Software entwickelt und nur in Registern und Arbeitsspeicher denkt. Also ich bin kein Profi-Designer oder sowas, aber trotzdem habe ich ein Gefühl und kann die Sachen einordnen in diesem grafischen Bereich. Ich kann mit dem Designer reden, aber ich kann halt auch mit dem Softwareentwickler reden. Und zusätzlich habe ich halt gelernt durch meine berufliche Praxis, mich auch in verschiedene fachliche Branchen reinzureden und auch zu denken und mit dem Kunden zu reden irgendwo. Und da ist, glaube ich halt, um jetzt den Bogen zur Digitalisierung wiederzukriegen, da liegt der Hund einfach begraben in diesem Bereich. Und es gibt nicht das Studium dafür und auch, wie du gesagt hast, was du uns im Studium dazu erzählt hast, Es gibt keine Vorlesungen, die einem das beibringen kann, wie man das irgendwie macht, weil das halt ganz viel auch mit Menschen zu tun hat und wie Menschen denken und nicht wie Computer denken.

16:42 Eine Frage, die ich auch bisher selten stellen konnte, ist, welche Fehler würdest du versuchen, nicht zu wiederholen? Die würde ich jetzt mal ein bisschen drehen. Und zwar, wenn du an die Leute denkst, die zu euch kommen, so typische Mindset-Dinge, die du drehen musst, wo ihr einfach auf eine gemeinsame Linie kommen müsst, damit das eine gute Zusammenarbeit führt. Gibt es da wiederkehrende Themen? Du hast schon gesagt, ihr baut nie genau das, womit die Leute durch die Tür kommen, aber gibt es da konkrete Dinge, wo du sagen kannst, das sind Punkte, auf die ihr ganz genau guckt, weil das immer wieder vorkommt?

17:26 Also der wichtigste Punkt sicherlich, aber das ist jetzt auch keine große Neuigkeit, ist dieses MVP-Denken. Also wenn man so eine Software oder die meisten Leute, wo haben eine bestimmte Budget- oder Zeitvorstellung, aber wenn es dann darum geht, die Spezifikation zu schaffen, was soll denn die Software alles machen oder was soll sie nicht machen, dann muss man halt häufig, ist man als Softwareentwickler in der Position, diesen Prozess zum Konvergieren zu bringen. Also vom Kunden kommt dann häufig immer nur, was man noch alles machen könnte oder meine Lieblingshassfrage ist, gerade wenn man dann schon im Prozess ist und die Zahlkrise sind irgendwie eng und dann am liebsten noch über einen Tracker oder sowas die Frage, könnt ihr auch noch das einbauen?

18:16 Weil ich sage immer, wenn diese Frage auch kommt oder zu meinen Kollegen, wenn ich mit jungen Entwicklern oder sowas arbeite, wenn die dann die Frage der Kunde hat gefragt, können wir nicht auch noch das bauen? Sage ich immer, die Antwort auf diese Frage ist eigentlich immer ja. Es sei denn, es geht darum, irgendwelche NP-vollständigen Probleme in linearer Zeit zu lösen oder sowas. Aber die Antwort auf die Frage, können wir das noch bauen oder könnt ihr das noch einbauen, ist eigentlich immer ja. Und eigentlich bringt es aber nie was, diese Frage aus Losgelöst zu stellen, weil Zeit und Geld sozusagen, es muss in dieser Frage immer mit drin sein. Und deswegen, das ist eine der schwierigen Aufgaben, diese Verantwortung oder dem Kunden das klar zu machen, die Konsequenzen und die Verantwortung seines eigenen Handelns.

19:11 Wir können jederzeit jedes Feature einbauen, zumindest solange wir die Kapazität noch haben. Aber das verändert hat halt Einfluss auf unseren Plan, den wir irgendwann mal am Anfang gemacht haben. Und dafür benutzen wir natürlich Tools wie irgendwelche Tracker oder irgendwelche Karten, die sich dann stauen oder nicht stauen, um das möglichst transparent zu machen. Aber das ist eine der großen Sachen, an denen man kontinuierlich mit Kunden immer arbeitet, diese Transparenz aufrecht zu erhalten und diese Verantwortung immer wieder dem Kunden deutlich zu machen. Und ja, wie gesagt, dieses Zurücktreten von der Haltung, ich weiß genau, was ich brauche, ihr müsst mir jetzt noch hier diesen Knopf einbauen, sondern dass man immer sagt, wir haben festgestellt, wir haben das jetzt benutzt, Dafür haben wir einen agilen Prozess, dass sie schnell mit der Software arbeiten können.

20:01 Wir haben festgestellt, wir haben hier mit dem Prozess noch ein Problem. Wie können wir das zusammen lösen, anstatt zu sagen, ich brauche hier einen Knopf, der das ausdruckt oder das löscht.

20:13 Ich finde es in dem Fall immer hilfreich zu sagen, es gibt ja noch eine dritte Dimension. Man kann ja auch an der Qualität drehen, aber das will ja eigentlich niemand. Ich habe noch nie erlebt, dass jemand dann sagt, okay, dann baut es halt scheiße, also baut es ein, aber macht alles nur halbgut.

20:30 Das ist halt extrem, dieser Aspekt Softwarequalität, der ist ja schon für Softwareentwickler untereinander super schwer, transparent zu machen und gegenüber dem Kunden noch viel schwieriger. Deswegen ist das eigentlich kein Heft, was ich dem Kunden jemals in die Hand geben möchte, weil der kann sich die Konsequenzen da im Zweifelsfall halt nicht abschätzen. am Ende ist das Teil unseres Vertrauensverhältnisses, dass wir dem Kunden eine Software bauen, die auch in einem halben Jahr noch wartbar ist, aber natürlich auf der anderen Seite den Kompromiss auch so machen, dass man nach einem halben Jahr schon was benutzen kann, wir nicht erstmal irgendein Framework konstruiert haben oder irgendwas.

21:16 Ja, genau. Also ich meine auch nicht, dass man sagt, okay, wir machen es und machen es halt schlecht, aber dass man es, also Ich meine, du hast gesagt, es gibt immer diese Dimension Budget und Zeit. Und also natürlich kann ich die Zeitdimension statisch lassen und ich kann noch eine Ressource raufpacken, da brauche ich aber mehr Geld. Und andersrum zu sagen, wenn aber Zeit und Geld fix sind, dann ist die einzige Möglichkeit, noch mehr da rein zu quetschen, dass die Qualität leidet.

21:44 Ja, und also Funktionsumfang halt. Das ist eher die Größe, über die man steuern kann.

21:49 Genau, das ist ja die Größe, über die man steuern kann. Aber wenn jemand kommt und sagt, könnte mich das auch noch einbauen, also damit wächst der Funktionsumfang ja erstmal. Oder man sagt halt, wir switchen.

22:01 Ja, also natürlich kann man dann, das was ja als erstes immer wegfällt, sind ja automatisierte Tests. Das ist für mich halt schon Teil der Qualität der Software. Natürlich kann ich das erstmal, kann ich alle Tests weglassen und dafür vielleicht zwei, drei Features mehr bauen. Aber wie gesagt, im Zweifelsfall schießt man sich da als Entwickler eh selber ins Bein. Auf jeden Fall. Und dem Kunden auch noch. Und da sitzt man als Entwickler immer am Ende der Nahrungskette. Also deswegen muss man da, ja, da muss man einfach, die Verantwortung werden wir glaube ich auch einfach nicht los. Und das ist, es wäre schon schön, wenn wir die anderen Verantwortungen sozusagen alleine losbremnen. Aber das ist, selbst das ist in jedem Projekt immer wieder auch ein kontinuierliches Thema.

22:45 Ja. Da würde mich interessieren, ob ihr sowas wie eine rote Linie habt für Projekte, die ihr annehmt. Vor dem Hintergrund dieses Thema automatische Tests. Ich habe zwei oder dreimal so ein Projekt angenommen, wo ich eine bestehende Software einfach weiterentwickeln wollte, sollte. Und ich habe mich da zweimal so in die Nesseln gesetzt. Also am Ende habe ich es zwar irgendwie so hingekriegt wie vereinbart, aber es war ein unglaublicher Schmerz auf beiden Seiten. Und da habe ich später bei meinen Retros festgestellt, das war jedes Mal ein Projekt, das kam zu mir. Große Code-Basis, teilweise veraltete Sachen und nicht ein Test. Und von daher ist für mich eine rote Linie, wenn jemand zu mir kommt, also ich möchte dann immer vorher gerne einen Blick in den Code werfen und wenn ich sehe, es gibt keine Tests und vor allem keine automatisierbaren, ausführbaren Tests, dann sage ich, kann ich nicht.

23:38 Dafür sind wir nicht geeignet, um dieses Risiko zu tragen. Ich denke, das ist ja für Kunden auch interessant, so zu wissen. Man lässt sowas ja extern entwickeln, weil man keine eigene Entwicklungsabteilung hat. Wenn man das Ganze dann irgendwann weiterentwickelt haben möchte, sind eigentlich automatisierte Tests heute Bestand der Technik. sollte jeder machen und wer es nicht macht, ist irgendwo ein bisschen hinter der Zeit zurückgeblieben. Habt ihr solche Grenzen, wo ihr sagt, das machen wir nicht? Also der Markt gibt es

24:20 ja glücklicherweise her, dass man sich um Legacy-Projekte größtenteils drücken kann. Das versuchen wir natürlich auch, wo es geht. Ansonsten Wir mussten jetzt zum Glück noch keine Ruby on Rails Legacy Projekte groß übernehmen, haben aber auch da schon teilweise für Kunden dann Rails Upgrades auch selber gemacht. Und man kann natürlich auch selber einfach Tests dazustellen, die den Ist-Zustand erstmal sicherstellen. Aber grundsätzlich würde ich sowas nur auf Abrechnung auf Aufwandsbasis machen. Und das ist natürlich immer schmerzhaft. Also am Ende des Tages ist dann das Kind ja auch schon in den Brunnen gefallen. Also das ist vielleicht auch nochmal eine interessante Möglichkeit jetzt an die Kunden da draußen, die vielleicht gerade mit irgendwelchen Softwareentwicklern verhandeln sind, ob es automatisierbare Tests gibt oder nicht.

25:20 Das sind halt das, was man jetzt spart, dadurch, dass man keine automatisierbaren Tests macht, das zahlt man, ich würde mal sagen, locker mit einem Faktor 5 oder 10 dann in 2-3 Jahren darauf, wenn man an der Software was machen will. Und es ist vielleicht, wenn das eine extrem kleine Software ist und es ist derselbe Entwickler, der da die ganze Zeit dran entwickelt, dann lässt sich das vielleicht mindern, dieser Faktor. Aber wenn es eine wachsende Software ist und ein Team mit Fluktuationen drin, dann ist es unabdingbar, dass sich gewisse Gesetzmäßigkeiten in so größeren Softwaresystemen einfach automatisierbar testen lassen.

25:58 Ja, gerade, also das habe ich gelernt im Gespräch mit Leuten, die so ein Legacy-System haben und da teilweise dann auch niemanden finden, der es weiter pflegen will. Also einerseits kann einem das passieren. Ich habe irgendwann mal für viel Geld ein Stück Software bauen lassen und ich kann es nicht weiterentwickeln und mein Business stagniert. Und andererseits, jedes Mal, wenn dann irgendwer ein Feature dazu baut, dann geht irgendwas anderes kaputt und ich merke es erst, wenn der Kunde anruft und sagt, jetzt ist aber das kaputt. es ist einfach hilfreich

26:29 und das ist auch nochmal vielleicht Anschluss auf das was ich ganz am Anfang gesagt habe, was die Erwartung an Software hat sich halt in den letzten 30 Jahren auch extrem geändert es wird halt heutzutage also früher war es halt so es gab ein spezifisches technisches Problem und ein Team von drei Ingenieuren hat sich ein halbes Jahr eingeschlossen um dann ein C-Programm mit weiß ich nicht tausend Zeilen zu schreiben, was dieses Problem gelöst hat. Heute ist es halt so, die Erwartungen sind ganz anders. Ich erwarte halt, dass ich innerhalb von, wie gesagt, drei Monaten irgendwie ein Multiserver Setup mit einem Webshop und einer Datenbank und mandantenfähig und weiß ich nicht, was irgendwie alles eingerichtet habe und ich erwarte auch, dass ich die nächsten drei Jahre dieses System kontinuierlich erweitern kann.

27:20 Und diese Anforderungen, Und die lassen sich halt, also die Frage, die sich mir gestellt hat jetzt eigentlich, warum ist denn das mit den automatisierten Tests jetzt erst so heiß irgendwie? Warum war das vor 30 Jahren nicht so? Weil sich einfach die Komplexität der Software meiner Meinung nach da extrem erhöht hat.

27:39 Ja. Ja, und weil es auch immer mehr in missionskritische Systeme reinwächst. Also ich meine, heute gibt es Firmen, die rein online-shopbasiert ihr Geschäft betreiben. Das heißt, für die ist es natürlich wichtig, dass der Onlineshop 24-7 läuft, wo das vielleicht vor zehn Jahren noch so ein Add-on war, also wo vielleicht vordenkende Ladengeschäft-Inhaber auch einen Onlineshop hatten. Ja. Ja. Okay, wir stellen fest an alle, die da zuhören, automatisierte Tests sind wichtig. Hast du noch irgendwas, was du dazu ergänzen willst? Ich glaube, wir könnten da noch Stunden drüber philosophieren, aber die Kernpunkte, die ich besonders spannend finde, haben wir eigentlich abgedeckt.

28:30 Ja, das geht mir ähnlich so. Da kann ich stundenlang drüber reden, sicherlich. Und man kann das auch wahrscheinlich noch anhand von konkreten Beispielen noch sehr viel deutlicher machen. Aber wie gesagt, für mich sind die Kernpunkte, Also die Verantwortung beim Kunden und die Transparenz, was die Anzahl von Funktionen und dass man nicht immer fragt, könnt ihr nicht auch das und das machen? Das ist die eine Sache und das andere, dass man davon zurücktritt zu denken, man hat schon die Lösung, nur weil man das Problem kennt. Der Lösungsraum ist bedeutend größer, als ich mir das als Nichtsoftwarentwickler vielleicht vorstellen kann. Das sind so vielleicht die zwei Takeaways, die ich in dem Umfang runterbrechen könnte.

29:20 Ich finde, das ist eine hervorragende Zusammenfassung. Dann würde ich jetzt zu den drei Abschlussfragen kommen, die ich immer stelle. Im Rahmen der Digitalisierung, was ist so das größte Thema, an dem du dich die nächste Zeit beschäftigen willst? Kann man das überhaupt sagen für euch, weil ihr eigentlich rundum Digitalisierung macht? Oder gibt es irgendwas, was du ganz besonders angehen wirst?

29:45 Also was natürlich für mich als Softwareentwickler einfach immer spannend ist, sind die aktuellen Entwicklungen in der Softwareentwicklung. Das heißt auch, das ist für uns Rails Boys, sage ich ja auch mal ein bisschen hart, dieser Shift zum Client. Das heißt, dieser Ansatz Browser Request Response mit HTML hin und her, das ist ja langsam ein bisschen out. Das heißt, wir brauchen auch neue Strategien, um unsere Architekturen zu strukturieren, unsere Projekte aufzusetzen. Bisher haben wir viel unserer Storys an Controllern direkt entlanggehangelt und es war immer klar, wie die Abläufe sind und sowohl die Erwartungshaltung beim Benutzer als auch die technischen Möglichkeiten haben sich, oder das hängt ja voneinander ab, haben sich da weiterentwickelt.

30:40 Es muss irgendwie, die Oberflächen müssen viel responsiver sein irgendwie und wie lassen wir das in unsere Projektplanung auch einfließen. Das sind auf jeden Fall technische Sachen, die mich da faszinieren und ansonsten ist natürlich jeder Kunde, der mit einer neuen Fachlichkeit kommt, ist wieder ein neuer spannender Bereich, in dem es sich einzuarbeiten geht.

31:08 Ja, kann ich, kenne ich. Bei uns geht es eher in die Richtung, was für Plattformen entstehen in Richtung IoT, weil wir ja das Backend, aber dann die Hardware anbinden, aber geht mir genauso. Also wir haben in letzter Zeit viele Rails API-only Dinge gebaut, wo auch das Frontend einfach fehlt. Ja, du hast schon gesagt, das Auf-dem-Laufenden-Halten ist schwierig. Jetzt sind das für dich sicherlich eher die Software-lastigen Quellen, aber gibt es da irgendwas, was du benutzt, um da auf dem Laufenden zu bleiben? Irgendwas Konkretes, also Spezielles, was du empfehlen kannst?

31:44 Also außer Hacker News sozusagen, was immer ein guter Einstiegspunkt ist, habe ich da jetzt nicht die eine Quelle, die, an der ich mich langhange oder sowas. Also ich nehme einfach dieses Internet, das geht ganz gut.

31:59 Ah, okay. Ich werde das mal verlinken. Ja, dann letzte Frage. Hast du jemanden, den du gerne in einer kommenden Episode hier im Podcast hören würdest? Tatsächlich. Ich habe ja schon mal einen Podcast

32:14 von dir gehört und ich finde es zwar toll, mir irgendwelche Stars und Sternchen zu wünschen, aber damit das auch ein bisschen konkreter wird habe ich gedacht, dich mal an einen alten Kontakt von mir weiterzuleiten und zwar den Matthias Lau der hat früher für einen Kunden von uns gearbeitet als ich noch in der Agentur gearbeitet habe und ist jetzt Co-Founder von Connected Health und die beschäftigen sich halt mit der Digitalisierung von Prozessen im medizinischen Bereich. Und das fände ich mal sehr spannend zu hören, was für Hürden der in seinem bisherigen Vorgehen da gesammelt hat.

33:04 Oh ja, das finde ich sehr spannend. Vielen Dank, bin ich ganz gespannt. Ich habe bzw. meine Frau als Mitgründerin hat vor ein paar Jahren für Philips Medical Embedded Software geschrieben für Röntgenröhren. Und das ist Prozess, Pain, wie man ihn sich nicht schlimmer ausmalen kann. Von daher weiß ich, was da regulatorisch alles möglich ist.

33:30 Ich glaube auch, mit dem medizinischen Bereich haben wir ja noch nichts zu tun gehabt. Und ich glaube, was es da an verkrusteten analogen Prozessen abzubilden gibt, das ist noch eine Nummer härter als alles, was wir bisher schon gesehen haben.

33:44 Bin ich gespannt. Dann hoffe ich, dass es demnächst eine Episode geben wird. Ich auch. Dann wissen wir alle mehr darüber. Ja, vielen Dank für deine Zeit. Ich habe wieder spannende Sachen gelernt. Ich habe zum Glück alles bestätigt bekommen, was ich auch so denke. Ja, ich werde alles, alle Links, die wir so, es waren nicht so viele, aber alles, was wir an Quellen haben, werde ich verlinken. Die Shownotes gibt es wie immer auf wegederdigitalisierung.de zu finden. Das hier wird, wenn ich das richtig im Sinn habe, das 13. Interview werden. Und ja, wie immer würde ich mich über ein Review bei iTunes freuen. Das hilft uns auf jeden Fall weiter. Vielen Dank fürs Zuhören. Vielen Dank für deine Zeit, Axel.

34:23 Gerne. Und bis bald.