Devs on Tape x DOAG K+A 2023 - Performance-Edition mit Martin Klier

00:00:00: [Musik]

00:00:15: Hallo und herzlich willkommen zu einer weiteren fesselnden Podcast-Folge von

00:00:19: Devs on Tape. Ja, ein bisschen anderes Intro heute. Wir haben heute einen ganz

00:00:22: besonderen Gast aus der Welt der Oracle Datenmarktadministration zu Gast.

00:00:27: Der Gast ist Experte in Hochverfügbarkeitslösungen und hat sich

00:00:31: auf die Feinheiten der Performanceoptimierung spezialisiert. Als

00:00:34: renommierter Oracle Ace Director und stolzes Mitglied von Sim42 ist er nicht

00:00:38: nur national, sondern auch international bekannt. Wenn es um Community-Arbeit geht,

00:00:42: ist er immer und überall dabei. Und seine packenden Vorträge ziehen Zuhörer in den

00:00:46: Bann. Seid bereit, einen Blick hinter die Kulissen zu werfen. Herzlich willkommen

00:00:50: Martin Clear.

00:00:51: Dankeschön, schön, dass ich kommen durfte.

00:00:53: Ja, Martin, stell dich doch gerne mal für unsere Hörer, die, die dich nicht

00:00:57: kennen, noch etwas detaillierter vielleicht, als ich es gerade getan habe, vor. Was

00:01:01: machst du so und wo kommst du her?

00:01:03: Ja, ich bin in der IT durch die Ausbildung gekommen. Ich habe mich nach der

00:01:08: Zeit bei der Bundeswehr dafür entschieden, mich beim mittelständischen Unternehmen

00:01:12: als Fachinformatiker in der Fachrichtung Systemintegration zu bewerben, zur

00:01:17: Ausbildung. Bin dort genommen worden und habe dort dann so über den Weg

00:01:20: Linux-Administration und Integrationsaufgaben den Weg in die Richtung

00:01:25: Oracle Database gefunden. Ironischerweise nicht über den Weg, den viele gehen,

00:01:29: einfach durch Lösungen von Problemen datentechnischer Natur, sondern es ging

00:01:34: eher so ein bisschen anfangs um den Dreh. Naja, auf euren Linux-Systemen läuft

00:01:38: sowieso Oracle und dann könntest du das doch gleich mitmachen. Und dann gibt's

00:01:42: doch da jetzt von Oracle so einen tollen neuen Cluster, das Real Application

00:01:46: Cluster und wir brauchen sowieso da und dort eine Hochverfügbarkeitslösung und

00:01:51: das passt doch jetzt schön. Nach meiner Meinung hat mich da eigentlich keiner so

00:01:55: richtig gefragt und es kam dann so ein bisschen als Père-Décret-Mufti von meinem

00:01:59: damaligen Chef, als ich Bedenken geäußert habe, weil ich eigentlich diesem roten

00:02:04: und monolithischen Lizenz-behafteten Monster da gar nicht so zugetan war. Als

00:02:10: im Hintergrund in der Linux-Community zu sein und das gern zu machen, konnte ich

00:02:13: mich da mit dem Gedanken gar nicht so anfreunden. Aber das wurde mit dem Satz

00:02:16: "Sie machen das jetzt" sehr deutlich vom Tisch gewischt und ich habe dann so mit

00:02:20: der Zeit durchaus ein bisschen Geschmack gefunden an der ganzen Geschichte. Und

00:02:23: vor allem, was mich sehr angesprochen hat an der Welt der Oracle-Systeme, ist, dass

00:02:29: die Community sehr mit dem vergleichbar ist, was ich aus der Linux-Welt kannte,

00:02:33: aus dem Open-Source-Bereich. Obwohl das Produkt natürlich kommerziell ist und

00:02:36: auch nicht so modular aufgebaut ist, wie man das jetzt aus dem Bereich Linux-

00:02:41: Betriebssystem kennt, ist es so, dass die Menschen, die sich mit Oracle-

00:02:45: Technologie beschäftigen, sehr intensive Community-Arbeit pflegen. Das sieht man

00:02:49: jetzt auch in der Doha, in der ich tief bin. Das lebt ja von der Community, aber

00:02:55: auch international. Und diese Leute kommen alle so ein bisschen aus dieser

00:03:00: Historie der Unix-Systeme, weil Oracle ja ein System ist, das auch für diese

00:03:04: erstmals frei und herstellerunabhängig geschaffenen Unix-Systeme aus den 70er

00:03:09: und 80er-Jahren gebaut wurde. Und die haben so ein bisschen diesen freien

00:03:13: Know-how-Austausch aus dieser Welt des Betriebssystems mit in die Welt der

00:03:16: Datenbank genommen. Und das ist sehr, sehr kompatibel mit dem, wie Linuxer

00:03:21: denken und wie Linuxer arbeiten. Und darum hat sich da auch so eine gute,

00:03:24: fruchtbare, gemeinsame Konzeptwelt entwickelt. Und das hat mich angesprochen.

00:03:29: Das war dann toll, dass man einfach diese Community-Skills von einer Welt in die

00:03:33: andere mitnehmen konnte. Dadurch habe ich mich dann mit den, ja, vielleicht jetzt

00:03:38: für einen Open-Source-Fan nicht so attraktiven Aspekte da sehr gewöhnt. Und

00:03:43: ja, da kann man dann wachsen und da kann man gut seine Freude daran haben. Und es

00:03:47: hat mich dann auch immer mehr von meinem ersten Baby, dem Linux, weggeführt. Und

00:03:52: es ging dann immer mehr um datenbankspezifische Probleme, um zuerst um

00:03:56: Hochverfügbarkeitssachen, so mit der Real Application Cluster. Aber so habe

00:03:59: ich immer gesagt, das ist meine erste Liebe gewesen im Bereich Oracle. Und

00:04:01: später, auch durch einen Arbeitgeberwechsel, hat sich das dann mal so

00:04:05: mehr in Richtung Performance entwickelt. Und ja, jetzt seit zehn Jahren,

00:04:09: ziemlich genau zehn Jahren, bin ich jetzt zusammen mit einem Partner gemeinsam

00:04:13: für die Performing Databases unterwegs als Firma. Und das hat sich eigentlich

00:04:17: sehr gut bewährt. Und von dem kleinen Stachel, den ich da immer gefühlt habe,

00:04:20: dass ich das jetzt tun musste, ist jetzt quasi nichts mehr übrig. Und jetzt

00:04:24: gefällt mir das richtig gut. Und die Community ist natürlich immer noch toll.

00:04:27: Und man wächst dann einfach mit der Zeit in solche internationalen Organisationen

00:04:31: rein, wie jetzt das Oracle Ace Programm, das ja im Prinzip von Oracle für seine

00:04:35: Community-Arbeit ins Leben gerufen wurde. Und auch jetzt seit Neuestem eben

00:04:39: Symposium 42, die quasi auch so als Association of Speakers dient und

00:04:44: nicht herstellerspezifisch ist, sondern einfach versucht, die Community auch beim

00:04:47: Wechsel von der Plattform, also wenn sich jetzt einer von Oracle wegbewegt und

00:04:51: in Richtung von einem anderen System Postgres oder andere Systeme geht,

00:04:55: dass der diesem Netzwerk nicht verloren geht. Das sind Sachen, die mich sehr

00:04:58: angesprochen haben und die ich sehr gerne unterstütze. Und auch für mich ist es

00:05:01: auch keine Arbeit, dann da irgendwas zu machen in der Richtung.

00:05:03: Ich habe da eine Frage genau in diesem Zusammenhang, die ich dir schon immer

00:05:06: stellen wollte, weil für die Zuhörer, die dich nicht verfolgen auf Twitter zum

00:05:09: Beispiel oder die Oracle-Konferenzen allgemein verfolgen, ich habe das Gefühl,

00:05:13: du bist überall, einfach überall, egal wo Community ist, da ist Martin auch.

00:05:19: Wie schaffst du das?

00:05:20: Ja, es sind zweierlei Sachen. Also eine Sache ist natürlich, möchtest du an der

00:05:25: Community teilnehmen, also sprich, möchtest du konsumieren, möchtest du dich

00:05:30: dort einfach als Person zeigen, möchtest du dort die Vibes mitnehmen,

00:05:34: möchtest du dort einfach präsent sein, möchtest du was lernen. Das ist das eine.

00:05:38: Und die andere Seite ist, möchtest du Content liefern. Und beides hat so seine

00:05:42: Vorzüge. Ich meine, auf der einen Seite, ich bin eigentlich kein so furchtbar

00:05:46: geselliger Mensch. Also ich bin jetzt nicht so derjenige, der dann der Letzte

00:05:49: ist, der von den Partys nach Hause geht, sondern da habe ich schon irgendwo so

00:05:52: einen Sättigungspunkt, was dann eigentlich reicht. Und dadurch verausgabe ich mich

00:05:55: bei den Community-Sachen auch nicht so besonders. Also ich gehe dann vielleicht

00:05:58: trotzdem irgendwann mal aufs Zimmer und lasse es mal gut sein. Bin dann morgen

00:06:01: sowieso schon traditionell mit Startschwierigkeiten gesegnet. Da muss ich

00:06:05: dann nicht nachts noch bis um zwei dann das Lokal mit abschließen. Aber ich glaube,

00:06:08: der Schlüssel oder beziehungsweise die eigentliche Antwort auf deine Frage ist,

00:06:11: es macht einfach Spaß. Ich bin einfach schon gern mit Leuten zusammen und liebe

00:06:16: eben aus diesem genannten Grund, dieser Austausch von Know-how und das Erwerben

00:06:20: von Know-how in der Community. Das habe ich sehr schätzen gelernt. Was sich da so

00:06:24: ein bisschen geändert hat, jetzt auch wieder aus der Linux-Welt raus, anfangs

00:06:27: bist du natürlich erst mal nur Konsument. Das heißt, du gehst irgendwo hin, liest

00:06:31: dir Know-how an. Also bei Linux war das ganz klar so, dass in der Zeit, in der ich

00:06:35: das so gelernt habe, Anfang der 2000er Jahre, da war ja das Internet in voller

00:06:39: Blüte. Da konnte man in Foren alles Mögliche nachlesen und alles, was ich

00:06:43: über das Linux weiß, mir auf dem Weg angeeignet. Und langsam wurde das immer

00:06:46: interaktiver. Dann fängst du irgendwann an, irgendwann reichen dir die Foren

00:06:49: nicht mehr. Dann fängst du an und schreibst in irgendeiner Mailing-Liste mit.

00:06:52: Das war damals so auch ganz üblich, dass man sich über Mailing-Listen austauscht

00:06:56: und dann ist es auf einmal persönlicher. Dann ist es nicht irgendein Avatar im

00:06:59: Forum, sondern dann ist es ein Mensch. Der schreibt vielleicht sogar unter seiner

00:07:02: Business-Mail-Adresse und plötzlich baust du so ein bisschen ein persönliches

00:07:05: Netzwerk auf. Gut, jetzt dann durch den Wechsel in die Oracle-Welt haben sich

00:07:09: natürlich diese Linux-Kontakte so ein bisschen zerschlagen. Es gibt schon

00:07:12: einige, die den Weg ungefähr zur gleichen Zeit mit mir mitgegangen sind, die man

00:07:15: jetzt dann im Oracle-Umfeld wieder getroffen hat. Aber im Großen und Ganzen

00:07:18: ging das erste Netz verloren. Was ich damals im Linux-Bereich schon angefangen

00:07:21: hatte, war auch mal auf Präsenzveranstaltungen zu gehen. Also so

00:07:24: das erste, was man da so 2005, ja um die 2005 rum würde ich sagen, angefangen

00:07:31: hat, ist zum Beispiel in Chemnitz auf die Linux-Tage zu fahren. Das gibt es immer

00:07:35: noch. Tolle Veranstaltung. Und da habe ich dann den Wert kennengelernt, sich da in

00:07:38: Vorträge reinzusetzen und das zu hören. Und dann irgendwann kommt natürlich mal

00:07:42: der Gedanke, Mensch, eigentlich ist das ganz toll. Da könnte man auch selber mal

00:07:45: was liefern. Im Linux-Umfeld habe ich das nie geschafft, da irgendwas zu machen.

00:07:49: Wir haben im Linux-Umfeld das soweit geschafft, dass wir in meinem Heimatort

00:07:52: in Nordbayern eine Linux-Usergroup gegründet haben, die jetzt auch seit 12

00:07:56: Jahren existiert, die sich einmal im Monat, am dritten Mittwoch im Monat trifft.

00:08:01: Und die ist jetzt in 12 Jahren, ist die genau einmal ausgefallen. Und wir haben

00:08:05: geschafft, dass wir da so eine Gruppe Leute schaffen, die das gern machen.

00:08:08: Und das war toll. Und da war dann das erste Mal, dass ich auch der Linux-

00:08:12: Community was zurückgeben konnte, indem man das organisiert, indem man das macht.

00:08:16: Aber das war eigentlich kein Opfer. Also wenn du jetzt sagst, wie schaffst du das?

00:08:19: Es ist sowieso so, dass man sich ja öfter mal mit seinen Freunden oder so

00:08:22: irgendwo hinsetzt und vielleicht ein Bier trinkt oder einfach ein bisschen

00:08:26: quatscht. Dann haben wir gesagt, dann geben wir dem Kind doch einen Namen. Und dann

00:08:28: war die Linux-Usergroup geboren. Man muss ja dann einfach nur immer am dritten

00:08:31: Mittwoch im Monat ins gleiche Wirtshaus gehen. Das ist ein Leuchter. Und so ist

00:08:34: das auch heute noch. Nur, dass es jetzt nicht mehr an mir allein hängt, sondern

00:08:37: dass es noch genügend andere gibt, die das auch treiben, wenn ich mal keine Zeit

00:08:40: oder vielleicht auch mal kein Interesse habe an dem Tag. Beim Umschalten in die

00:08:43: Oracle-Welt hatte ich natürlich dann die Erfahrung schon. Da wusste ich schon,

00:08:47: dass diese On-Premises-Veranstaltungen irgendwo cool sind und dass man da gern

00:08:51: hingeht. Und hatte dann auch die Möglichkeit, auf der DOR-Konferenz mal

00:08:54: einen Vortrag zu halten über ein ganz spezielles Projekt. Und das war dann

00:08:58: schön. Damit hat es dann das für ein paar Jahre wieder. Aber die positive

00:09:03: Erinnerung blieb da. Und so mit der Zeit habe ich auch gelernt, dass wenn ich

00:09:07: irgendwie meine Erfahrungen oder das, was ich so erlebe oder was in Projekten

00:09:12: passiert, irgendwo zu Papier bringe und vielleicht irgendwo eine Präsentation

00:09:16: daraus erstelle, dass das auch anderen hilft. Und es mir auch irgendwo auf ganz

00:09:20: primitiver Ebene was gibt, mich da vorhin hinzustellen und irgendwas zu erzählen.

00:09:24: Das ist so etwas, was mich einfach anspricht. Das kannst du vielleicht

00:09:27: irgendwo Geltungsbedürfnis nennen. Das mag vielleicht schon auch ein Antrieb

00:09:30: sein. Aber es ist auch wieder schön, so wie halt ein Künstler vom Applaus lebt,

00:09:34: dann so vielleicht mal die Erkenntnis bei den Zuhörern durchblitzen zu sehen

00:09:37: und zu sagen, ja, das war jetzt cool. Und das treibt mich natürlich dann schon

00:09:40: auch auf die Bühne manchmal. Das ist schon cool. Das ist schon schön. Das

00:09:43: gefällt mir immer wieder.

00:09:44: Es ist das Rausreißen, sag ich jetzt mal, aus dem Alltag, den man hat. Man lernt

00:09:47: neue Leute kennen. Man baut natürlich ein Netzwerk, was einem beruflich natürlich

00:09:51: auch zugutekommt. Aber ich kann das sehr gut nachvollziehen. Also erstmal sehe

00:09:54: ich sehr, sehr viele Parallelen zu der Entwicklungsgeschichte, die du uns

00:09:57: erzählt hast, aus der Linux-Welt. Open Source und dann das große rote O.

00:10:00: Möchte ich da wirklich hin? Oder nee, ich baue jetzt, ich habe es glaube ich

00:10:03: auch schon mal in anderen Episoden erzählt, wie mein Background ist, aber

00:10:06: auch da den Fachinformatiker für Systemintegration und lieber Open Source

00:10:09: und lieber alles auf Linux. Und wenn ich mir ein privates Projekt aufsetze,

00:10:12: nehme ich eine kostenlose MySQL-Datenbank, bevor ich jetzt hingehe und irgendwie

00:10:15: eine Oracle-Datenbank aufsetze. Aber es ist sehr interessant, das zu hören,

00:10:18: dass es da auch nochmal quasi parallele Geschichten am anderen Ende von

00:10:21: Deutschland gibt, die genauso gelaufen sind. Ich finde das aber auch besonders

00:10:24: toll, weil ich habe zum Beispiel zu der Linux-Community oder zu dem, was ich

00:10:27: damals so als Kontakt hatte, wirklich einfach die Verbindung auch verloren,

00:10:30: dass ich das über so viele Jahre hinweg trotzdem noch…

00:10:33: Ja, das ist gefährlich. Es ist eigentlich schade um das Netzwerk,

00:10:36: dass man sich da aufbaut. Und so auf der, sagen wir mal, deutschlandweiten

00:10:39: Bühne habe ich den Kontakt verloren. Das ist so. Ich habe es schon lang nicht

00:10:42: mehr nach Chemnitz geschafft. Ich habe schon lang nicht mehr auf eine wirkliche

00:10:45: reine FOSS-Veranstaltung geschafft. Aber es ist so, dass man natürlich in

00:10:49: gewisser Weise die Technologie nie irgendwo wegbekommt oder dass man sagt,

00:10:54: ich möchte es nicht mehr sehen. Aber auf der regionalen Ebene, wo das so

00:10:59: ein bisschen zu dieser Interessentenkreis auch so dann langsam in den Freundeskreis

00:11:04: übergeht, das ist jetzt auf der regionalen Ebene bei Linux so. Aber das ist auch

00:11:08: was, was so Systeme wie das ACE-Programm oder das Symposium 42 auch auf

00:11:13: internationaler Ebene schaffen. Da sieht man sich zwar dann nicht einmal im

00:11:17: Monat, aber es ist trotzdem so, dass sich dann so manche Treffen wie

00:11:20: Familientreffen anfühlen. Und das ist jetzt nicht nur Propaganda, sondern das

00:11:24: ist wirklich so, dass man sich auf die Menschen freut. Und es ist mir schon

00:11:28: passiert, dass ich auf eine Konferenz in die USA geflogen bin nach eigener Kosten

00:11:33: und habe dann am Ende nach einer dreitägigen Veranstaltung sagen müssen,

00:11:37: ja, ich habe jetzt drei Vorträge angehört und einen gehalten. Und unterm Strich ist

00:11:41: die Frage, wenn man das jetzt rein wirtschaftlich sieht, war die Reise

00:11:44: total sinnlos. Aber es gibt eben auf diesen Konferenzen mehr zu holen als nur

00:11:49: das Know-how und nur die Präsentationsfläche sich da darzustellen.

00:11:53: Ich war die ganze Zeit auf der Konferenz und es gab immer Gespräche, es gab

00:11:57: immer Erfahrungsaustausch. Und manchmal nimmt man aus den Gesprächen viel mehr

00:12:00: mit nach Hause als in allen Vorträgen zusammen. Und das ist das, was mir dann

00:12:03: Spaß macht. Und deswegen, da ziehe ich die Motivation her, weil ich mich auf die

00:12:06: Veranstaltungen fahre.

00:12:08: Auch ein schönes Schlusswort für den Abteil oder für den Absatz. Du bist ja,

00:12:14: also wir interviewen ja oft Entwickler, andere Entwickler, auch auf der Cloudland

00:12:19: und so. Und das heißt, du bist jetzt, du hast jetzt nochmal einfach einen ganz

00:12:22: anderen Blick auf die Themen.

00:12:23: Ich bin eben für die Reiche Entwicklung komplett blank.

00:12:26: Und deswegen würde mich interessieren, also es ist jetzt ein sehr allgemeines

00:12:29: Thema natürlich, weil du jetzt ja auch für das Performance Tuning oder nicht

00:12:32: jetzt, sondern schon eine ganze Zeit im Performance Tuning bist und so, ob du

00:12:36: irgendwie was Griffiges hast, wo du zum Beispiel, es gibt ja ganz viele

00:12:41: Beispiele, du kannst ja auf Datenbankebene tunen, du kannst, du hast dann

00:12:45: vielleicht die Hibernate Anwendungen, so Klassiker einfach, die dann keine

00:12:48: Beinvariablen benutzen oder sowas. Hast du irgendwas Griffiges, wo du sagen

00:12:52: kannst, Leute, bitte achtet darauf, ich aus meiner Warte, ihr helft mir oder

00:12:58: der Datenbank oder wie auch immer.

00:13:00: Ja, also sag mal, du kannst jetzt von mir eine sacherlich-technische Antwort

00:13:05: haben. Du kannst von mir natürlich auch eine gefühlsmäßige Antwort haben.

00:13:08: Ich habe dadurch, dass ich natürlich wenig Einblick in die Welt der Software

00:13:12: Entwicklung habe, außer dass ich natürlich geschäftlich für Firmen tätig

00:13:16: bin, die Software entwickeln. Also das ist so mein Einblick. Also sprich, du

00:13:19: kommst irgendwo hin, bist dort dann natürlich technisch für das Datenbank

00:13:22: System irgendwo verantwortlich, ob es für einen Optimierungsauftrag ist oder

00:13:25: ob das irgendwie längerfristig ist. Aber die Entwicklungsteams können ja dort

00:13:28: zum Beispiel auch durchaus der Erwerbszweck der Firma sein. Also sprich,

00:13:32: die entwickeln dann Software nicht für sich selber, sondern sind halt Softwarehersteller,

00:13:35: die damit auf den Markt gehen. Und das ist so meine Perspektive. Und ich habe

00:13:39: ab und zu natürlich die Möglichkeit, auch Community-seitig auf Veranstaltungen

00:13:44: zu gehen, die sich hauptsächlich mit dem Thema Softwareentwicklung

00:13:47: beschäftigen, die dann vielleicht irgendwo mal einen Vortrag hören wollen

00:13:50: zum Thema Theorie von Performance oder solche Geschichten. Das mache ich dann

00:13:53: durchaus für Softwareentwickler auch. Was mir da so, das ist jetzt die

00:13:56: zynische Antwort, was mir da so ein bisschen aufgefallen ist, dass ein

00:13:59: Großteil der Entwicklerkonferenzen sich mehr mit den Arbeitsbedingungen und der

00:14:04: Arbeitsweise der Softwareentwickler beschäftigt, wie mit der Frage, wie

00:14:07: schreibe ich guten Code? Das ist vielleicht ein bisschen der Sache

00:14:10: geschultert, dass man vielleicht auch unter schlechten Bedingungen einfach

00:14:13: keinen guten Code schreiben kann. Das ist durchaus so. Aber da fällt mir der

00:14:17: Kontrast zu den Administratoren sehr auf. Also gerade jetzt im Linux-Umfeld oder

00:14:22: im Datenbank-Umfeld, da gibt es wenig Leute, die sich über die Arbeitsorganisation

00:14:26: jetzt im Sinne von, wie organisiere ich ein agiles Team oder so, da macht sich

00:14:29: eigentlich keiner Gedanken. Vielleicht viel zu wenig. Und ich frage mich halt

00:14:32: immer, wenn ich dann wieder so ein Negativerlebnis hatte, dass sich halt

00:14:36: einer überhaupt nicht darum kümmert, ob der Code, den er da verzapft hat, ob der

00:14:41: da irgendwie performant läuft, denke ich mir halt, ok, hättest dich vielleicht ein

00:14:44: bisschen weniger damit beschäftigt, ob es dir in der Arbeit gut geht und hättest

00:14:47: vielleicht ein bisschen ein Buch mehr gelesen, wenn man das ordentlich schreibt,

00:14:50: dann hättest du der ganzen Firma mehr Arbeit erspart. Das war jetzt die

00:14:53: zynische Antwort. Die rein technische Antwort ist natürlich, jeder, der sich

00:14:58: über den Gesamt-Stack Gedanken macht, der sich Gedanken macht, ok, auf der

00:15:03: einen Seite habe ich vorne natürlich einen Business Case, den muss ich

00:15:06: erfüllen. Der erste Fehler wäre schon, wenn man nicht über die Menschen

00:15:10: nachdenkt, die mit dem Ding arbeiten müssen, also User Experience, das ist das

00:15:13: zweite. Natürlich wäre es schön, wenn die Logik auch schlüssig bleibt, also

00:15:17: sprich, die handwerkliche Arbeit, habe ich alle Fäden in der Hand behalten,

00:15:21: habe ich das irgendwie oder habe ich das irgendwo vermasselt, wo natürlich

00:15:24: menschliche Fehler passieren, ganz klar, wo vielleicht die meisten Fehler

00:15:26: passieren, wo man darüber nachdenkt und trotzdem Fehler macht, ganz normal.

00:15:29: Es ist aber auch so, dass vielleicht so die Schicht, auf der die Daten gehalten

00:15:33: werden, durchaus für jeden, der Software schreibt, eine Überlegung wert sind.

00:15:37: Und sagen wir mal, natürlich bin ich da jetzt nicht ganz objektiv, aber so die

00:15:40: Erfahrung zeigt aus den letzten Jahren doch, dass Daten oft länger halten als

00:15:44: Applikationen, also sprich, dass die Firmen die Daten, die sie generieren,

00:15:47: länger behalten möchten als die Software, die sie erzeugt hat. Das ist nicht,

00:15:51: also das betrifft jetzt nicht unbedingt das Datenmodell, aber es betrifft

00:15:55: sicherlich so ein bisschen den Fall, ich habe jetzt mühsam Daten erworben, ich

00:15:59: möchte die Daten langfristig auswerten oder ich möchte vielleicht irgendwelche

00:16:02: Strukturen in die Zukunft weiter überführen und es ist gar nicht mehr

00:16:05: möglich, die Software zu pflegen, weil die ist halt ziemlich dynamisch entstanden

00:16:08: und das Team hat sich davon wegentwickelt oder es gibt es vielleicht auch nicht

00:16:11: mehr und jetzt muss ich mir was Neues einfallen lassen. Habe aber, sagen wir mal,

00:16:14: den Use Case immer noch irgendwo und den Datenbestand auch noch und dann ist es

00:16:17: diese Software-unabhängige Datenhaltung ist sicherlich kein Auslaufmodell.

00:16:22: Es ist aber, wie mit so vielen anderen Dingen, auch mit der Datenhaltung so, es

00:16:26: ist sicherlich nicht mehr so wie früher, dass man das nur noch ganz statisch in

00:16:29: einem Modell halten kann und die ganze Firma in einem Modell abbildet und dann

00:16:33: 40 Jahre lang auf der gleichen Datenbank rumklopft. Also das ist vermutlich auch

00:16:37: nicht mehr das, was das Zeichen der Zeit ist. Ich finde es halt nur immer schade,

00:16:40: wenn Softwareentwickler wenig sich Gedanken machen, ob das, was sie da

00:16:45: Daten weiterentwickeln, ob sich das auch irgendwo effizient abbilden lässt.

00:16:51: Also da geht es gar nicht so, dass man sie unbedingt in ein bestimmtes Produkt

00:16:54: reinzwingen möchte. Es ist allerdings schon so, dass manchmal ich mir wünschen

00:16:58: würde, dass die Softwareentwicklung die Hilfsmittel, die ihnen die Datenschicht

00:17:03: anbietet, auch nutzen. Also es bringt ja nichts, wenn ich sowieso weiß, das Ding

00:17:07: läuft jetzt irgendwie die nächsten fünf Jahre auf einer spezifischen Plattform,

00:17:11: dass ich komplett plattformunabhängig entwickle. Dann damit schmeiße ich ganz

00:17:15: viele Features, die ich mir eigentlich einfach nutzen könnte, schmeiße ich

00:17:18: einfach über Bord. Ich meine, bei Oracle ist es so, da zahlst du viel Geld dafür,

00:17:21: dass du ein Hochleistungsprodukt hast und dann nutzt es nicht, weil du vielleicht

00:17:26: unabhängig sein möchtest oder weil du Hypernet genannt hast, weil du einen

00:17:30: Abstraktionslayer benutzt, der vielleicht Datenbank-typagnostisch ist und keine

00:17:34: spezifischen Features hernimmt, du aber dann für irgendwo viel mehr Aufwand in die

00:17:38: Performance reinstecken musst oder auch in die Optimierung. Und auch wenn du jetzt

00:17:41: sagst, ich bin jetzt auf Postgres unterwegs und ich nutze zum Beispiel nicht

00:17:44: die Möglichkeit, dass ich irgendwo Packages verwende, obwohl das mit Sicherheit die

00:17:48: effizienteste Möglichkeit ist, Daten zu manipulieren, dann ist es einfach schade,

00:17:51: weil es was ist, was die Datenschicht könnte. Und was ich eigentlich wissentlich

00:17:55: lasse, vielleicht aus organisatorischen Gründen, weil ich sage, ich möchte nicht,

00:17:59: dass die Softwareentwickler neben ihrer Hauptsprache auch noch PG oder PSSQL

00:18:04: lernen müssen oder weil sie sagen, ich kann es schlecht einchecken oder dann

00:18:07: funktioniert der Rolloutprozess nicht so besonders gut. Da sind wir wieder bei den

00:18:11: Arbeitsbedingungen. Vielleicht ist es manchmal ganz gut, sich auch darüber

00:18:14: Gedanken zu machen, ob der Business Case noch erfüllt werden kann, wenn das Ding

00:18:18: langsam ist. Und da sind dann die Performanceoptimierer manchmal so ein

00:18:22: auf verlorenem Posten, weil wenn ich das architektonisch schon mal bis zu einem

00:18:25: gewissen Grad ignoriert habe, dass das Ding auch skalieren muss, dann ist es

00:18:29: ganz schwer wieder aufzuholen.

00:18:31: Ich finde es echt interessant. Also wir haben jetzt die Seite, du hast es gerade

00:18:35: ein bisschen zynisch formuliert, es ist nicht der Elefant im Raum, aber man

00:18:39: spricht es ja ein bisschen an, dass die Entwickler und die Datenbankkollegen am

00:18:43: besten weiter auseinander im Büro sitzen und eine Tür dazwischen geschlossen ist,

00:18:47: damit die sich nicht in die Haare kriegen. Jetzt haben wir es gerade zynisch

00:18:50: ausgehört, dass du schon sagst, dass die Entwickler sich Gedanken darüber machen

00:18:53: sollten, dass die Datenbank richtig läuft. Ich weiß nicht, ob es jetzt nur meine

00:18:56: Betrachtung der Dinge ist, dass es diese zwei Lager gibt, aber ich habe tatsächlich

00:19:00: schon sehr häufig entdeckt, dass die einen sagen, die Entwickler sollen mal ein

00:19:03: bisschen besser auf die Datenbank Performance achten, wie sie das verwenden.

00:19:06: Und die Entwickler sagen vielleicht, die Datenbankler, die sind doch dafür

00:19:09: zuständig, dass die Datenbank Performance für mich läuft. Was würdest du sagen,

00:19:12: ist der Schritt aufeinander zu oder wie ist die Vorgehensweise, wenn es so eine

00:19:16: Situation gibt, dass man die besser auflösen kann?

00:19:19: Also der Aspekt zusammenzuarbeiten ist auf jeden Fall sinnvoll. Und ich glaube,

00:19:24: dass das Dilemma, oder diesen Widerspruch, den du gerade angesprochen hast,

00:19:28: der einen Seite ist es natürlich einfach, immer auf den anderen zu zeigen.

00:19:31: Und ich habe es jetzt natürlich sehr aus Datenbank-Sicht dargestellt.

00:19:34: Es ist aber schon auch so, dass wenn man es jetzt von der anderen Perspektive sieht,

00:19:38: es ist natürlich sehr wünschenswert, dass die Datenbanker sich gut Gedanken

00:19:42: darüber machen, wie denn eigentlich Software entwickelt wird.

00:19:46: Ob sie es dann selber auch können, ist eine ganz andere Frage oder

00:19:49: hinterreichend verstehen. Ich kenne da einfach meine eigenen Defizite.

00:19:52: Wenn man sich da so dann über das Tooling oder über den ganzen Prozess unterhält,

00:19:56: da bist du einfach als Datenbanker ganz weit weg. Und da spricht man einfach

00:19:59: eine andere Sprache. Aber es ist natürlich schon sinnvoll, wenn man so ein bisschen

00:20:02: versteht, welche Notwendigkeiten in der Softwareentwicklung da sind.

00:20:06: Je besser ich das als Datenbanker verstehe, desto besser kann ich natürlich

00:20:10: einen Service anbieten. Allerdings ist es so, die Datenbank hat natürlich,

00:20:14: also der Schritt von der Software in die Datenbank rein, das ist natürlich schon

00:20:17: auch eine Abstraktionsschicht, wo man im Prinzip einen Medienbruch hat.

00:20:21: Also wenn ich sage, okay, ich muss jetzt zum Beispiel von einem Modell,

00:20:24: das eher objektorientiert handelt, auf einmal in so eine

00:20:27: datenrelationale Struktur rein. Und das beißt sich halt oft genug.

00:20:31: Und das ist nicht nur eine technische Challenge, sondern das ist ja auch

00:20:33: ein anderer Denkansatz. Und der Bruch lädt natürlich zu diesem

00:20:38: Abstraktionsdiskurs ein, zu sagen, ja, die Datenbank ist irgendwo so ein Service,

00:20:42: den nutze ich und die soll noch bitte dafür sorgen, dass wenn ich dann

00:20:45: die Querie absetze, dass ich mich nicht um die Querie kümmern muss,

00:20:47: sondern die ist syntaktisch korrekt und alles andere ist mir dann einfach egal.

00:20:51: Weil ich meine, das muss halt so sein. Und in der anderen Richtung denkt man sich

00:20:54: halt immer, ja Leute, es ist doch völlig klar und dokumentiert, dass das,

00:20:58: was ihr da treibt, einfach nicht performant sein kann. Könnt ihr euch

00:21:01: dann einmal Gedanken machen darüber. Das ist menschlich, irgendwo menschlich.

00:21:05: Und das Zweite ist das Negative am Menschen. Das Schöne am Menschen wäre

00:21:09: aber auch, dass wir ja adaptiv sind. Also wir könnten uns ja eigentlich anpassen.

00:21:13: Und deswegen ist für mich dieses Thema "Zwei Räume und die Tür dazwischen"

00:21:17: jetzt eher kontraproduktiv. Weil ich meine, man muss ja diese Tränen

00:21:21: und ich darf noch befördern. Ob man das jetzt dann gleich Development

00:21:25: und Operations zusammenführt und eigentlich dann das Problem schafft,

00:21:29: dass man keine Zeit mehr hat, in einem der beiden Bereiche richtig

00:21:33: tief einzutauchen. Weil ich meine, wenn ich jetzt als Developer viel Operations

00:21:37: machen muss, dann werde ich als Developer schlechter. Wenn ich als Operator

00:21:41: Development machen muss, dann verliere ich Know-how darüber, wie

00:21:45: mein Objekt sich betreiben soll, wie das funktioniert.

00:21:49: Das ist beides irgendwie schlecht. Ich bin mir da nicht so sicher, ob

00:21:53: der Ansatz in jeder Tiefe dann gerechtfertigt ist.

00:21:57: Genau, das lässt diese Frage einfach nach einem pragmatischen Ansatz, wie man sowas

00:22:01: lösen kann, einfach erscheinen. Also wäre es möglich, die Entwickler

00:22:05: mit der Operations zusammenzusetzen. Ich nenne es jetzt wirklich ganz pragmatisch

00:22:09: einfach einen Regeltermin, wo man sich darüber unterhält und wirklich nur die

00:22:13: notwendigsten Dinge, die sie sich zu sagen haben, die Daten

00:22:17: man gleich sagen. Ich verstehe das vollkommen, dass du bei der Softwareentwicklung auf die besten

00:22:21: Prinzipien deiner Softwareentwicklung, deiner Umgebung, deiner Sprache, deiner Framework

00:22:25: was auch immer du benutzt, dass du darauf erpicht bist, es auf den Weg zu machen.

00:22:29: Ich implementiere meine Query so und so und so und ich mache das so, ich baue das so auf, ich arbeite objektorientiert.

00:22:33: Ich verstehe aber, dass ihr mir ans Herz legt

00:22:37: für die Operations-Teil, für den Datenbankteil, es besser so zu machen,

00:22:41: dass der Austausch auf dieser Ebene läuft, dass man vielleicht irgendwie gemeinsames Verständnis entwickeln kann,

00:22:45: ohne dass der eine sich zu sehr in Richtung Softwareentwicklung denken muss und der

00:22:49: andere nicht zu sehr sich Gedanken über das Datenmodell machen muss, weil ja eigentlich die Anwendung sein Fokus ist.

00:22:53: Lässt sich, wirklich ganz pragmatisch gesagt, Regeltermine, gemeinsame

00:22:57: Dokumentationen, gemeinsame Richtlinien. Queries müssen so geschrieben

00:23:01: sein, aber Operations muss auch verstehen, dass es auf der anderen Seite so und so besser ist.

00:23:05: Wie geht man das Problem an? Erstens mal glaube ich nicht, dass

00:23:09: Just Another Bloody Meeting irgendwas hilft.

00:23:13: Die Akzeptanz von Meeting und am besten noch online, das macht sicherlich nicht besser.

00:23:17: Und sogar Regeltermin. Ja genau, den sowieso jeder schwänzt,

00:23:21: den er erst erschwänzen kann. Der zweite Punkt ist, dass ich jetzt so ein bisschen

00:23:25: mich an dem Begriff Operations, den ich selber mitgebracht

00:23:29: habe, ein bisschen störe.

00:23:33: Operations ist natürlich ein Teil. Also sprich, gerade wenn du jetzt

00:23:37: was Software entwickelst, dann hat die natürlich irgendwann eine Entwicklungsphase und irgendwann hat sie eine Betriebsphase

00:23:41: und wieder changes dann. Und mit der Datenbank ist es eigentlich auch so, nur dass wir die nicht entwickeln.

00:23:45: Sondern die Datenbank wird im Prinzip geplant, die wird architektonisch

00:23:49: geplant, auch sowohl das Datenmodell, das machen ja meistens trotzdem

00:23:53: dann die Entwickler, weil die müssen ja im Prinzip beurteilen, wie sie es modellieren wollen, aber auch

00:23:57: sagen wir mal, dieser ganze Rumpf, also diese Basistechnologie,

00:24:01: die da läuft, die muss ja irgendwie auf das adaptiert werden, wie es später

00:24:05: betrieben werden soll. Und dann gibt es da auch eine Schaffungsphase und dann

00:24:09: geht es in den Betrieb über irgendwann. Und dann stellen sich ganz andere Probleme

00:24:13: als in der Auftaktphase. Und in der Auftaktphase

00:24:17: ist es natürlich eine Challenge, solange man noch nicht so ganz genau weiß, wie die Software eigentlich am Ende

00:24:21: aussehen soll. Man kennt nur das Problem, aber die Lösung noch nicht. Dann schon zu designen,

00:24:25: wie die darauf unterliegende Infrastruktur ausgelegt werden muss. Das ist

00:24:29: natürlich schon immer ganz spannend. Und gerade in der Phase sollten eigentlich die

00:24:33: Softwarearchitekten und die Systemarchitekten schon zusammenarbeiten, bevor es überhaupt

00:24:37: um den eigentlichen Entwicklungsprozess geht. Dass man einfach dem Systemarchitekten

00:24:41: vermittelt, wie die Software grundsätzlich funktionieren wird und dass auch der Softwarearchitekt

00:24:45: schon grundsätzlich weiß, was er von der Datenhaltungsschicht an

00:24:49: Leistung und auch an Dienstleistung erwarten kann, was er daran auslagern kann.

00:24:53: Ich meine, wir sind ja da, um das ganze Ding

00:24:57: zu unterstützen. Und wenn es jetzt bei uns schon Funktionen gibt, die

00:25:01: mit dem Standardprodukt kommen, dann sind natürlich alle eingeladen,

00:25:05: die auch herzunehmen. Aber und auf der anderen Seite, wenn ich jetzt schon

00:25:09: weiß, die Software hat die und die Pläne und wir wollen das so und so aufbauen,

00:25:13: egal ob sie jetzt dann dieses Angebot nutzen oder nicht. Auch es kann ja eine bewusste

00:25:17: Entscheidung sein, pass auf, das können wir jetzt nicht tun, weil es zum Beispiel irgendwelche Abstraction Layer

00:25:21: nicht hergibt oder was auch immer. Dann kann man trotzdem sehr, sehr schön hergehen und kann sagen,

00:25:25: okay, dann modellieren wir unser System darauf hin,

00:25:29: dass das eben nicht genutzt wird, sondern dann müssen wir halt vielleicht irgendwo Ressourcen einplanen oder wir müssen

00:25:33: miteinander über die Connections zur Datenbank anders sprechen. Wir müssen das vielleicht

00:25:37: mehr diversifizieren oder mehr konzentrieren oder was auch immer. Und je früher man da drüber

00:25:41: spricht, desto weniger Konflikt gibt es hinterher. Und gerade

00:25:45: wenn es um dieses Thema Softwareentwicklung im agilen Umfeld geht, da geht es

00:25:49: ja selten um Changes, sondern da geht es ja wirklich um Neuprodukte bzw. dann um

00:25:53: die schnelle Adaption der Produkte an den Markt. Und

00:25:57: da, wenn man natürlich von vornherein schon mal miteinander gesprochen hat und schon weiß, wie das Ganze

00:26:01: aufgebaut werden soll und wie die Module aussehen und wie die Schnittstellen irgendwann mal aussehen können

00:26:05: und so die ganze Architektur zeigt, dass man da so entwickeln muss. Wenn man das schon unter Einbeziehung

00:26:09: auch der Datenschicht macht und deren Expertise

00:26:13: dazu einholt, kann man unter Umständen dem Entwickler viel Arbeit ersparen.

00:26:17: Nicht, weil man ihn dazu zwingen möchte, dass er sich daran hält, wie das bei

00:26:21: Oracle oder bei der Datenbank läuft, sondern einfach, um ihm zu zeigen, was

00:26:25: denn alles schon fertig ist, was man gar nicht bauen müsste. Und auch

00:26:29: zählt das natürlich auch in Richtung Performance, weil man sagt, warte mal auf, wenn ihr eure Datenstruktur so und so baut,

00:26:33: dann können wir effizienter joinen, dann können wir irgendwelche anderen Dinge

00:26:37: effizient lösen. Und je mehr das dann auch auf beiden Seiten verstanden wird,

00:26:41: warum bestimmte Sachen nicht gehen auf Development-Ebene, dann gibt es auch weniger

00:26:45: Protesthaltung bei den Datenbänkern. Und in der anderen Richtung, wenn

00:26:49: auch die Developer natürlich ein bisschen wissen, wie sie das

00:26:53: Klavier spielen müssen, dann klingt es auch besser. Das ist einfach so.

00:26:57: Und es ist halt so, wenn man an die Infrastruktur Lasten auslagert,

00:27:01: muss die Infrastruktur natürlich dafür geschaffen werden. Aber das muss man ja auch wissen.

00:27:05: Das heißt jetzt nicht, dass das eine Bringschuld für die Entwickler ist, sondern es ist schon auch irgendwo

00:27:09: die Frage, wie kann man das abholen. Dazu muss man natürlich immer erstmal wissen,

00:27:13: dass es das Projekt überhaupt gibt. Das ist in der Praxis ganz oft eines der Probleme, über die sich die Kollegen oft

00:27:17: beschweren. Die sagen, warte mal auf, Freunde, wir unterstützen euch ja gern, aber wenn ihr zu uns erst kommt,

00:27:21: wenn das Produkt schon fertig ist, dann haben wir natürlich auch keine Chance mehr, euch da irgendwo

00:27:25: was zu liefern. Das sind halt so die Challenges, die mehr organisatorischer Natur sind, als

00:27:29: dass es wirklich ein technisches Problem ist. Und wenn man jetzt da in getrennten Räumen oder

00:27:33: getrennten Gebäuden sitzt, dann kriegt man gar nicht mit, dass die anderen ein Projekt betreiben.

00:27:37: Wenn man das schon von Grund auf mischt, nicht aufgabenmäßig, sondern einfach auch rein im Büro oder

00:27:41: einfach in den Teams, dann ist es schon schön, weil man einfach dadurch, was die anderen

00:27:45: für Meetings haben und was die anderen für Telefongespräche führen, schon mitkriegt, was die

00:27:49: eigentlich treiben. Und dann kann man durchaus mal sagen, Leute, schaut mal her, ich habe jetzt gehört, ihr seid da drüber,

00:27:53: wollen wir nicht mal kurz über die Datenhaltung sprechen? Und dann kann

00:27:57: ich natürlich je nach Mentalität die Antwort kriegen, ja cool, komm mit ins nächste Meeting. Oder, was ich leider

00:28:01: auch schon gehört habe, ja, wenn ich das Problem auf Datenbankebene lösen muss,

00:28:05: dann habe ich schon grundsätzlich was falsch gemacht. Und einmal der Satz klingt in mir schon sehr

00:28:09: nach, dass man da schon gesagt hat, Leute, das war eine ganz klare Sache,

00:28:13: also da möchte ich mich nicht damit beschäftigen. Und genauso gibt es

00:28:17: natürlich von den Datenbankkollegen auch, das sage ich ja Freunde, die haben ja sowieso keine Ahnung

00:28:21: von den Daten, Hauptsache, die haben schnell irgendwelche Events ausgelöst

00:28:25: und alles andere ist ihnen egal gewesen. Und das geht halt nur durch menschliches

00:28:29: Miteinander. Nur dann kriegt man das los.

00:28:31: Ist auf jeden Fall notiert. Also erstmal auf organisatorischer Ebene vorher gucken,

00:28:35: dass die Leute miteinander sprechen, der Systemarchitekt mit dem Softwarearchitekten auf jeden Fall

00:28:39: vorher zusammenarbeiten, sich vorher darüber informieren, dass man denn gegenseitig auch

00:28:43: irgendwas voneinander bekommt oder auch was übergibt. Das macht auf jeden Fall Sinn.

00:28:47: Und natürlich der kulturelle Aspekt, dass man die Kollegen auch wirklich früh genug

00:28:51: zusammenbringt und dass sie gemeinsam an der Lösung arbeiten. Ja, das war meine

00:28:55: Frage zu dem Zwist zwischen Developern. Und das Problem existiert jetzt nicht mehr.

00:28:59: Wunderbar.

00:29:01: Ich finde, man kann so lange über dieses Thema sprechen.

00:29:05: Natürlich hat man auch selber vielleicht, also ich weiß nicht, wie es den anderen geht, aber

00:29:09: ich habe natürlich auch schon mal eine Erfahrung mit DBAs gemacht, gute und schlechte.

00:29:13: Für mich ist einfach hängengeblieben, man muss sich halt auch gegenseitig zuhören, weil

00:29:17: auch wenn man dann als Entwickler das vielleicht so ein bisschen versucht, loszuwerden, das Thema,

00:29:21: weil man ist einfach mit vielen anderen Themen auch beschäftigt, muss man trotzdem gucken,

00:29:25: wie viel, sorry für den Ausdruck, wie viel Haufen Scheiße einfach auf den Tischen

00:29:29: der DBAs landen. Und es ist halt einfach immer ein Geben und Nehmen im Endeffekt.

00:29:33: Aber es ist ja alles, was wir tun im Business,

00:29:37: läuft ja besser, wenn es geplant wird. Also ich meine, wir wissen alle, dass es Ad-Hoc-Arbeiten

00:29:41: gibt, die sich einfach irgendwo ansammeln oder die über einen reinbrechen,

00:29:45: wenn es halt irgendwie am, keine Ahnung, so die Klassiker

00:29:49: ist ja so Black Friday immer, wo du sagst, das ist so der Tag im

00:29:53: Jahr, an dem die Verkäufe einen Peak haben. Und

00:29:57: sich auf sowas vorzubereiten, das geht halt nur bedingt. Dann gibt es halt mehr

00:30:01: On-Call-Bereitschaft an dem Tag und so weiter. Aber sowas kann natürlich auch mal

00:30:05: zwischendurch passieren, wo man nicht drauf gefasst war. Und dann muss man das sowieso schaufeln.

00:30:09: Das hilft ja nichts in der Situation. Aber wenn man in der Planung

00:30:13: die Performance einfach auch als Feature mit einrechnet,

00:30:17: also ich meine, das ist einer meiner großen Vorbilder,

00:30:21: das ist ein Amerikaner, der sich da im Thema Performance sehr stark

00:30:25: engagiert, das ist der Kerry Millsap, und der hat eine ganze Zeit lang eine erfolgreiche

00:30:29: Präsentationsserie auf den Konferenzen gehalten, die hieß "Performance ist ein Feature".

00:30:33: Und wenn ihr jetzt aus Softwareentwicklungssicht auf

00:30:37: Features guckt, Features sind ja nicht nur positiv, sondern

00:30:41: Features machen ja auch Arbeit. Features, die man haben will, die muss man planen, die muss man

00:30:45: budgetieren, dafür muss man irgendwie Ressourcen bereitstellen, die muss man sich Gedanken

00:30:49: machen. Und wenn man jetzt Performance von Software schon von Anfang an, schon ab

00:30:53: dem Lastenheft irgendwo mit dort stehen hat, dass man sagt, okay, ich erwarte,

00:30:57: dass das Ding so und so viele Abfragen pro Sekunde liefern kann am Ende oder

00:31:01: so und so viele User bedienen kann und so weiter, und das nicht einfach blind vor sich hinwächst,

00:31:05: sondern von Anfang an klar war, wie es skalieren soll, zweites Passwort, Skalierung,

00:31:09: dann macht man natürlich allen Beteiligten das Leben leichter.

00:31:13: Natürlich macht man allen Beteiligten das Leben auch ein bisschen schwerer, weil sie auf einmal in einer Phase,

00:31:17: wo Funktion im Vordergrund steht, plötzlich auch sich drüber

00:31:21: Gedanken machen soll, dass vielleicht für heute utopische Workload noch funktionieren

00:31:25: soll. Aber es geht ja manchmal sehr schnell, dass die Workload auf dem

00:31:29: System dann ansteigt. Und ich meine, dann zu sagen, na ja, Performance ist erst im

00:31:33: übernächsten Sprint dran, das bringt es dann vielleicht auch nicht so wirklich.

00:31:37: Manche Weichen werden schon sehr, sehr früh gestellt

00:31:41: und man weiß das auch, aber oft sind die halt mit Mühe verbunden und auch

00:31:45: vielleicht mit Performance-Einschränkungen im Niedriglastbereich verbunden,

00:31:49: aber dafür ist die Skalierung halt besser hinten raus. Und "Know your needs"

00:31:53: ist ja immer ganz gut, wenn ich weiß, was ich brauche, dann kann ich auch gute Software schreiben.

00:31:57: Black Friday ist ein super Beispiel, finde ich nicht,

00:32:01: weil wir den jetzt gerade vor uns haben und dein Telefon bestimmt nicht still steht. Aber es ist ja

00:32:05: letztendlich so, dass wenn ein Mediamarkt, Saturn, sage ich jetzt einfach mal so, Name-Dropping von Marken,

00:32:09: dürfen wir ja, wir sind ja im Verein hier, die können damit rechnen, dass wenn die entsprechende Angebote

00:32:13: rausstellen, dass sie einen riesen Performance-Peak jetzt am Freitag haben werden, definitiv.

00:32:17: Haben, glaube ich, auch wirtschaftlich gesehen dann einfach mit dieser Black Friday Week

00:32:21: oder Black Week, haben sie die Last vielleicht ein bisschen verteilt oder dieses langsame Ankommen

00:32:25: der Performance-Engpässe vielleicht so ein bisschen herangeführt. Naja, ich habe eine kleine

00:32:29: Anwendung, ich starte die zu entwickeln, ich habe einen kleinen Online-Shop, ich verkaufe drei Artikel

00:32:33: vielleicht, ich baue das System langsam auf über eine gewisse Zeit und dann

00:32:37: irgendwann bin ich so groß und so bekannt, dass ich auch sage, ja, wir machen jetzt auch Black Friday Deals und plötzlich

00:32:41: sind diese Requirements, die ich vorher nicht in Betracht ziehe, weil ich sage, nein, ich muss keine

00:32:45: fünf Millionen User innerhalb von zwei Stunden bedienen können mit meiner Datenbank.

00:32:49: Ich setze jetzt auf nur Open Source, was auch immer für eine Datenbank, ich rechne damit sowieso erstmal

00:32:53: nicht. Dann sind wir ja schon zu spät, weil wir solche Fragen am Anfang nicht beantworten,

00:32:57: sondern wir beantworten in erster Linie, wie kriege ich überhaupt erstmal meine Produkte verkauft.

00:33:01: Wir reden jetzt nicht nur über die großen Unternehmen, die neue Anwendungen schreiben, die wissen,

00:33:05: wir haben einmal im Jahr eine Riesenlast, vielleicht nur ein zweites Mal, da muss man später handeln.

00:33:09: Und wann ist der richtige Zeitpunkt dafür? Lass ich es erstmal einmal knallen

00:33:13: und dann lerne da draus und guck, was erwartet uns eigentlich und dann müssen wir skalieren.

00:33:17: Wir haben genau 364 Tage Zeit dafür, weil das kommt nächstes Jahr wieder.

00:33:21: Das sind die Learnings, aber am liebsten macht man das vorher.

00:33:23: Ja, ich meine, im Prinzip ist das so, dann hast du eigentlich in der Zeit, wo du

00:33:27: Gedanken fürs Business brauchst, also wo du jetzt sich zum Beispiel mit der Frage

00:33:31: beschäftigst, biete ich Black Friday Deals an und das kann ja vielleicht auch eine relativ

00:33:35: kurzfristige Entscheidung sein. Die ist ja vielleicht nicht 364 Tage vor Black Friday gefallen,

00:33:39: sondern vielleicht vier Wochen vorher und dann ist auf einmal das notwendige Refactoring der Software

00:33:45: auf einmal ein Business-Hindernis und je nach Struktur von der Firma wird dann die IT als

00:33:49: Ganzes eher als Hemmnis angesehen, obwohl es eigentlich das Business bis dahin gebracht hat.

00:33:53: Absolut, ja. Das heißt, wir sprechen ja nicht nur über die Kommunikation zwischen dem Development

00:33:57: und der Datenhaltung und der Infrastruktur, sondern wir sprechen auch von der Kommunikation

00:34:01: vom Business mit der IT so grundsätzlich und je mehr man natürlich weiß, was das,

00:34:05: durch welche Reifen das Business in der nächsten Woche springen möchte, dann kann man sich

00:34:09: natürlich vielleicht auch ein bisschen darauf einstellen und wenn man natürlich jetzt irgendwo

00:34:13: einen wildgefangenen Löwen dazu bringen möchte, durch den Reifen durchzuspringen, das wird

00:34:17: vielleicht in vier Wochen eher ein Desaster. Da ist es vielleicht besser, man weiß es ein bisschen

00:34:21: vorher und ich kann jetzt ein gutes Beispiel nennen, weil du jetzt gerade so den

00:34:25: Electronic-Markt genannt hast. So was so meine Branche ist, in der ich hauptsächlich

00:34:31: tätig bin, ist Logistik. Das heißt, viele meiner Kunden sind entweder Betreiber

00:34:35: von automatischen Logistikanlagen oder noch viel mehr die Softwarehersteller, die diese

00:34:39: Logistikanlagen bauen. Das ist eigentlich so einer der größten

00:34:43: Kundenkreise, die ich so bediene. Und das sind Applikationen, die eigentlich gemessen

00:34:47: an dem, was jetzt von Softwareentwicklungstechnologien modern und gut

00:34:51: ist, sind die eher zurückhaltend. Die brauchen jetzt zum Beispiel von Java nur sehr, sehr

00:34:55: grundlegende Dinge. Also die werden jetzt keine Beans verwenden und solche Geschichten oder

00:34:59: irgendwelche sehr spezialisierten Sachen machen. Die haben eigentlich relativ anspruchslosen

00:35:03: Code, aber sehr komplexe Business Cases, die also sehr viel bewältigen müssen und die

00:35:09: je nach Automatisierungsgrad der Lagersysteme sehr, sehr latenzempfindlich sind. Das heißt,

00:35:14: du musst unter Umständen komplexe Entscheidungen genauso schnell treffen wie einfache.

00:35:18: Das ist nicht nur für den Code eine Challenge, weil wenn du jetzt irgendwie sagst, ich habe

00:35:22: jetzt von der Hardware vorgegeben eine Fördergeschwindigkeit, wo die Kiste auf dem Fördermedium

00:35:28: irgendwie mit drei oder vier Meter pro Sekunde fährt, dann kann ich das ja schon aus

00:35:32: mechanischen Gründen nicht ständig anhalten. Und wenn es dann eine Abzweigung gibt, dann

00:35:35: gibt es einen Abstand zwischen dem Sensor und dem Antrieb und durch die Fördergeschwindigkeit

00:35:41: von der Kiste ist vorgegeben, wie lange kann die Entscheidung dauern. Und das ist dann

00:35:44: Fullstack. Da geht es dann los. Irgendjemand schickt dann ein Netzwerkpaket auf die Reise,

00:35:50: das schlägt auf dem Application Server auf, dann rattert das dort irgendwie durch die

00:35:55: Software, dann braucht er dafür eine Datenbank-Query, dann liefert die Datenbank wieder den ganzen

00:36:00: Schwung Netzwerk-Krimskrams zurück und sagt, ja, dann mache ich jetzt mal was draus. Die

00:36:03: Software macht daraus eine Entscheidung und schickt ein einzelnes Paket wieder zurück.

00:36:07: Und da ist jetzt so ein ganz gängiger Zeithorizont, ist da so irgendwie so um die 100 Millisekunden.

00:36:12: Wenn der ganze Zirkus länger dauert wie 100 Millisekunden, fährt die Kiste einfach

00:36:15: geradeaus weiter. Und je nachdem, wie jetzt die Struktur ist und die Topologie, kommt

00:36:19: sie dann einfach irgendwann wieder, weil der Loop geschlossen ist. Dann ist es noch glimpflich

00:36:23: abgegangen in dem Einzelfall. Wenn es die Sackgasse war, dann steht das Ding irgendwo

00:36:27: hinten und jemand muss sie in die Hand nehmen und wieder vortragen. Ich meine, wenn das

00:36:30: jetzt einmal passiert, dann lachen alle drüber. Wenn du aber jetzt anfängst, dass du sagst,

00:36:34: da fahren jetzt irgendwie bei einer Fördergeschwindigkeit von drei Meter pro Sekunde irgendwie dann auch

00:36:39: faktisch sieben Kisten pro Sekunde auf der Fördertechnik, weil die klein genug sind.

00:36:44: Hinten am Ende der Sackgasse kommen pro Sekunden sieben Totläufer raus, weil wir zum Beispiel

00:36:49: eine Minute lang schlafen mit der Software, weil irgendwas hängt. Dann kommen eine Minute

00:36:53: lang jede Sekunde sieben Kisten hinten an. Und dann sitzt der irgendwann unter dem Berg

00:36:58: von Kartons und ruft nach Hilfe. Und das ist schon nach der ersten Minute, kann das schon

00:37:03: haarsträubend ausgehen.

00:37:04: Das klingt tatsächlich nach einem Use Case, wo wirklich, du sagst jetzt gerade Fullstack,

00:37:09: wo es an unheimlich vielen Stellen auch hapern kann.

00:37:12: Ja, natürlich. Das kann dann eben am Ganzen hapern. Und das, was ich jetzt eigentlich

00:37:17: daran gedacht habe, war gar nicht dieses Fördertechnik Problem, das wir ja jeden Tag tausendmal haben,

00:37:22: sondern sehr spannend war zum Beispiel der Tag, das läuft jetzt ein bisschen auf relationale

00:37:28: Daten raus, wo man so ein bisschen überlegen muss, wie stehen die Relationen von Daten

00:37:32: zueinander, was man als Softwareentwickler vielleicht im objektorientierten Bereich gar

00:37:35: nicht so auf dem Schirm hat, was aber natürlich im relationalen Bereich unser tägliches Brot

00:37:40: ist und wo natürlich dann auch das Verständnis leidert. Und zwar ist das eine Geschichte

00:37:44: aus dem Launch von, du hast gesagt, Vendor Dropping ist okay, von iPhones. Das heißt,

00:37:50: gerade am Anfang, als das Produkt noch relativ neu war, war ja auf diese neuen iPhones immer

00:37:55: an den Tagen, an denen es gelaunt wurde, war der Run groß. Da gab es Schlangen vor den

00:38:00: Geschäften.

00:38:01: Also wie Kai. Leute wie Kai.

00:38:03: Ja, die halt einfach das Produkt sehr gern haben. Und das ist ja nicht nur auf das Telefon

00:38:07: bezogen. Das gibt es ja für Spielkonsolen und für alles Mögliche gibt es den Hype.

00:38:12: Es war jetzt nur bei den Telefonen. Die sind ja relativ klein und hochwertig. So und normalerweise

00:38:17: sind die Retailer darauf ausgelegt, dass sie halt an die Märkte sehr viele gemischte

00:38:22: Warenpaletten liefern. Also die verkaufen ja kein Produkt so besonders oft, sondern

00:38:27: die haben halt, keine Ahnung, vom Mixer bis zum Fernseher und von der Druckerpatrone für

00:38:32: einen Drucker 27 bis hin zu irgendeinem Steckadapter haben die ja so alles im Sortiment. Und es

00:38:38: wird alles in einigermaßen vorhersehbaren Stückzahlen abverkauft. Und genau in der

00:38:42: Mischung kriegen die auch jeden Tag ihre Lieferungen. Und der Fall, der spielt sich praktisch in

00:38:47: einem Lager ab, das automatisiert ist und das genau diese Märkte beschickt. Und jetzt

00:38:52: an einem Tag, wo der iPhone-Launch passiert, verkaufen sie natürlich oder liefern sie

00:38:56: natürlich sehr viele iPhones. Und in dem konkreten Fall war es halt so, du hast ja

00:39:00: immer so die Zusammenstellung so zwischen, ich habe einen Auftrag, der Auftrag hat verschiedene

00:39:04: Positionen und jede Position hat eine Stückzahl. Und normalerweise gibt es da eine entsprechende

00:39:08: Mischung, wie ich gesagt habe. Also du hast einen Auftrag, der hat viele, viele verschiedene

00:39:11: Positionen und die haben einigermaßen, ja ich möchte jetzt nicht sagen gleich verteilt,

00:39:15: aber zumindest vorhersehbar verteilte Stückzahlen. Und das ist was, das wird ja im relationalen

00:39:20: Modell auch so abgebildet. Das heißt, ich habe quasi einen Auftrag, ich habe eine Auftragsposition

00:39:24: und ich habe den Artikel. Das sind so drei Tabellen, die so in Relation zueinander stehen.

00:39:28: Und die Datenbank ist darauf spezialisiert, dass wenn es jetzt in diesem relationalen

00:39:32: Modell irgendwelche Verschiebungen gibt, dass sie möglichst effizient darauf reagiert.

00:39:36: Bildest du dieses relationale Modell aber mehr oder weniger unbeholfen jetzt objektorientiert

00:39:41: ab, bist du vielleicht nicht in der Lage, auf eine Verschiebung von diesen Mengen adäquat

00:39:46: zu reagieren. Und in dem Fall war es dann so, dann gab es einen Auftrag, der hatte nur noch

00:39:50: eine Position, aber dort tausend Stück. Und auf einmal ist eine Query, die jahrelang schön

00:39:57: vor sich hingelaufen ist, natürlich genau an dem Punkt eskaliert. Und hatten wir schon

00:40:02: gedacht, indem wir das jetzt optimieren und das in Ordnung bringen, und auch die Software-Jungs,

00:40:06: die ja auch Logistik-Spezialisten waren, haben das natürlich schnell adaptiert und haben

00:40:09: auch gesehen, wo da die Schwächen waren und haben das gebaut und dann lief das auf einmal

00:40:12: schnell. Das heißt aber nicht, dass das Gesamtkonzept skaliert. Und auf einmal haben wir das Problem

00:40:17: nur von diesem Zwiespalt zwischen Datenbank und Applikation an die nächste Schicht verlagert.

00:40:22: Die nächste Schicht war nämlich dann die Applikation, die planen musste, wie verpacke

00:40:25: ich das Zeug. Und auf einmal war nicht mehr im Vordergrund gestanden, ich packe jetzt

00:40:30: relativ große Kisten effizient auf eine Palette drauf, sondern im Wesentlichen haben

00:40:34: wir jetzt Schüttgut verladen. Und auf einmal hat dieses System, das eigentlich darauf ausgelegt

00:40:39: war, so mindestens Schuhkarton-große Gebinde effizient auf eine Euro-Palette drauf zu stapeln,

00:40:44: dass das Größenverhältnis nicht so schlimm ist. Da hast du so drei Kartons in Länge,

00:40:48: passen halt drauf und vielleicht vier quer oder so. Und dann konnte das Modell relativ

00:40:52: gut darstellen, wie man die Schachtel drehen muss und wie sie dann drauf gestapelt werden

00:40:56: muss, dass es stabil ist und so weiter. Machst du das aber auch mit Gebinden, die jetzt nur

00:41:00: vielleicht ein Viertel oder vielleicht nur ein Sechstel von der Größe haben, steigt

00:41:04: natürlich der Rechenaufwand. Und du kommst an die Grenze, wo du den, der die Palette

00:41:08: wirklich bestückt, noch sinnvoll visualisieren kannst, wie denn jetzt das Telefon auf die

00:41:13: Palette draufstechen soll. Und auf einmal ist natürlich auch das erste Mal, dass dieses

00:41:18: Volumenberechnungsmodell geplatzt hat, dort Rechenzeitspikes verursacht. Dann war das

00:41:23: Rechenmodell endlich fertig und dann waren die Menschen gar nicht in der Lage, dem Modell

00:41:26: folgende Palette zu stapeln. Und dann hat das halt so richtig den ganzen Tag oder die

00:41:32: ganzen zwei Tage einen Mist nach dem nächsten und am Ende war die Lösung, ja weniger Technologie

00:41:37: hätte uns jetzt echt geholfen. Ja, einfach ganz viele iPhones in einen Schuhkarton packen

00:41:42: und dann funktioniert es. Oder halt einfach egal, stapelt halt einfach drauf, ist ja sowieso

00:41:46: ein Artikel. Also das muss man ja gar nicht vorbestimmen, wie der gestapelt wird. Dafür

00:41:50: hast du ja einen Menschen am anderen Ende, der kann das ja.

00:41:52: Auch da hat man dann aber auch genau ein Jahr, um sich darauf vorzubereiten, wenn das nächste

00:41:56: iPhone kommt. Und dann bringt Apple die Uhr raus und dann hat man den ganzen Salat von

00:42:00: vorne.

00:42:01: Also es gab das Problem dann, als ob wir nicht schon genug gelitten hätten, paar Wochen

00:42:05: später dann noch mit SIM-Karten. Und wenn du dann mal angefangen hast, irgendwie 24.000

00:42:11: SIM-Karten in eine Gitterbox rein zu stapeln, genau folgend nach Vorschrift, also dann kannst

00:42:15: du ungefähr nachvollziehen, wie viel Spaß das gemacht hat. Also für alle Beteiligten.

00:42:19: Ich finde das aber unheimlich interessant. Ich meine, Caro hat es ja gerade schon geteast.

00:42:22: Nein, noch mal für die Zuhörer, ich habe noch nie vor einem Apple Store gecampt. Ich

00:42:26: bin maximal an Release Day dreimal dran vorbeigelaufen, um zu gucken, ob ich mal so ein Gerät anfassen

00:42:30: darf. Aber bitte, anderes Thema. Ich finde das toll, wenn man solche technischen Beispiele

00:42:35: so greifbar mit solchen Themen erklären kann, wo da wirklich ganz konkret diese Schwachstellen

00:42:40: sind. Ich finde, an der Stelle haben wir eine tolle Story gehört. Ich bin mir unheimlich

00:42:44: sicher, dass du für eine zweite Folge auch noch genügend Geschichten hast. Wir selber

00:42:47: kennen auch schon einige davon. Naja, die Doak ist noch lang. Mal schauen, wann es uns

00:42:50: hier nochmal in den Raum verschlägt. Aber wie immer wechseln wir jetzt rüber zu den

00:42:54: Kategorien. Die stellen wir, die Hörer wissen schon, die stellen wir all unseren Gästen,

00:42:58: um hinterher auch mal einfach die unterschiedlichen Denkweisen ergleichen zu können.

00:43:03: Gibt es ein Zeitlimit für den Podcast?

00:43:05: Nein, es gibt natürlich kein Zeitlimit, außer dass bestimmt unten schon das Essen

00:43:08: aufgebaut wird, hier im Konferenzzentrum. Aber wir starten mit der ersten Kategorie.

00:43:12: Rein hypothetisch. Was würdest du denn gerne im Technologiebereich irgendwie erfinden oder erschaffen?

00:43:18: Ich würde gerne eine Möglichkeit schaffen, um mehr oder weniger automatisch transparent

00:43:26: im Bereich Laufzeiten Performance zu schaffen. Es gibt viele Lösungen, die in die Richtung

00:43:32: gehen, die Visualisierung schaffen für den Stapel an Technologie. Aber das ist meistens

00:43:38: mit sehr viel Konfigurationsaufwand verbunden und es ist sehr viel mit dem Aufwand verbunden,

00:43:44: eine fallspezifische Lösung zu bauen. Und das ist was, was, denke ich mal, die kommende

00:43:50: Technologie so in Richtung generativer AI uns leichter machen könnte. Dass man im Prinzip

00:43:56: in standardisierter Form die Struktur beschreibt und dann zum Beispiel das Festlegen von Messpunkten

00:44:04: und die Darstellung von Messpunkten einfach automatisch erzeugt und uns einfach leichter

00:44:09: Einblick in komplexe Systeme ermöglicht. Das würde ich für die Performanceoptimierung

00:44:13: sehr begrüßen.

00:44:14: Da brechen wir schon fast aus der Kategorie "rein hypothetisch" raus, weil das klingt

00:44:19: nach einem konkreten Plan. Ich bin mir sicher, dass wir nächstes Jahr hier nochmal sitzen

00:44:22: und darüber sprechen werden, was du mit diesem Wunsch oder was du mit deinem hypothetischen

00:44:27: Plan denn alles schon wirklich geschaffen hast und gemacht hast.

00:44:30: Ich würde dann einmal in die nächste Kategorie springen, nämlich ganz privat. Und wir haben

00:44:34: uns ja vorhin schon über deine Community-Aktivitäten unterhalten. Daher die Frage, bist du zufrieden

00:44:38: mit deiner Work-Life-Balance?

00:44:40: Das schwankt. Oft ist es so, dass ich meistens dann unglücklich bin, wenn es fremdbestimmt

00:44:47: ist. Es ist so, dass dich im Normalfall keiner mehr antreiben kann als dein innerer Chef.

00:44:53: Gesehen davon, dass ich jetzt unmittelbar im Geschäft keinen Vorgesetzten habe, aber

00:44:57: die Art und Weise, wie man damit umgeht, dass Projekte oder Kunden ihre Wünsche zur Geltung

00:45:03: bringen, das ist immer so ein bisschen die Frage. Ich hatte in den letzten Monaten, jetzt

00:45:08: gerade am Ende des Sommers mehrmals die Möglichkeit, einfach so richtig mit Mobile-Working meine

00:45:14: Gelüste zu befriedigen und habe einfach mit einem ganz alten Campingbus mich wo in der

00:45:19: Schweiz auf dem Staudamm draufgestellt oder bin irgendwo in Italien an den See gefahren

00:45:24: und habe mich dort einfach hingestellt, habe von dort aus gearbeitet, habe die Leute mit

00:45:28: sehr authentischen Video-Hintergründen in den Meetings überrascht. Das war toll und

00:45:33: an den Tagen ging es mir hervorragend. An Tagen, wo man sich wünschte, ja gut, okay,

00:45:37: hätte ich ein bisschen mehr Zeit, um sich um meine Kinder zu kümmern, um Dinge miteinander

00:45:42: zu erleben, die man nur versäumern kann, aber nie wieder aufholen kann mit den Kindern.

00:45:46: Das ist dann das, was mich dann ein bisschen melancholisch stimmt und was ich natürlich

00:45:50: auch durch solche Eskapaden, wie jetzt alleine irgendwo hinfahren, eher dann noch schlimmer

00:45:55: mache. Es ist zwar dann gut für mich persönlich, aber es schafft dann auch wieder so einen

00:45:59: leeren Spot irgendwo, wo man sagt, okay, da müssen auch dann gerade jetzt Kinder oder

00:46:04: Partnerinnen auch mal zu ihrem Recht kommen, sonst macht es irgendwann auch keinen Spaß

00:46:08: mehr.

00:46:09: Das leitet uns auch direkt zur weiteren Frage aus dem Bereich ganz privat auch über. Welche

00:46:14: Rolle spielt denn dein privates Umfeld bei der Ausübung deines Berufs? Also wenn du

00:46:19: diesen Cut setzt, fertig mit der Arbeit, jetzt hast du gesagt, deine Familie zu Hause, die

00:46:24: braucht dich, aber bist du denn sonst in deinem privaten Leben auch umgeben von, wir nennen

00:46:28: es jetzt mal Geeks oder anderen technologisch affinen Personen, wo es dann doch leider immer

00:46:32: wieder an das Thema reingeht, was man auch beruflich macht?

00:46:34: Den Fehler habe ich lange Zeit gemacht. Ich habe ja schon erwähnt, mit der Ledungs-User-Group,

00:46:38: da sind natürlich Freunde geworden, aber das ist nicht das engste soziale Umfeld. Das sind

00:46:42: halt Freunde, die man kennt. Früher war es so, dass mein Freundeskreis eigentlich ausschließlich

00:46:47: aus anderen Computer-Nerds bestanden hat, wo man dann immer wieder in die gleichen Themen

00:46:52: verfallen ist. Das hat auch irgendwo seine Zeit und so ein gewisses Lebensalter, einen

00:46:56: gewissen Lebensabschnitt, was toll ist, aber irgendwann hat man davon mal genug. Und ich

00:47:00: habe das auch bei meinen Freunden beobachtet, die alle so ungefähr im gleichen Alter waren.

00:47:04: Die sind alle den Schritt auch gegangen. Manche haben ein komplettes Kontrastprogramm

00:47:08: angefangen. Die machen immer noch erfolgreich IT und das ist ja gut und haben sich dann

00:47:12: aber irgendein naturnäheres Hobby gesucht und sind zum Beispiel zum Bergsteigen gegangen

00:47:17: oder haben angefangen, Reiten zu lernen zum Beispiel, was erstmal ein komplettes Kontrastprogramm

00:47:23: schafft. Ich habe das nie geschafft, komplett von der Technik wegzugehen. Also ich kann

00:47:28: sehr gut auch ein Wochenende ohne Datenbanken und Linux verbringen, aber der Technik kann

00:47:35: ich nicht entsorgen. Und ich persönlich habe irgendwann mal dieses alte, staubige Hobby

00:47:39: des Modelleisenbahnbaus wieder angefangen. Natürlich nicht mit traditionellen Sachen,

00:47:44: sondern voll digitalisiert und automatisiert und so weiter, aber nicht basierend auf Datenbanken.

00:47:49: Ja gut, Linux, der Leitrechner ist Linux, aber grundsätzlich mal spricht das natürlich

00:47:55: den Techniker und den Bastler in mir an und auch den Troubleshooter, der ich viel mehr

00:47:59: bin als der Bauer. Aber es ist schon so, dass das einen Kontrast schafft, weil es einfach

00:48:04: nichts mit Projektstress zu tun hat. Und das belastet mich viel mehr als technische Probleme.

00:48:08: Ich würde sagen, wir gehen in die letzte Kategorie, nämlich in den Konsum. Und du

00:48:13: hattest auch schon erwähnt, dass du ja auch viel im Community-Bereich wieder unterwegs

00:48:18: bist. Ich komme immer wieder darauf zurück. Daher die Frage, wie gehst du mit der wachsenden

00:48:22: Informationsflut über diverse Kanäle um? Also News und Information kommen immer mehr

00:48:26: und immer häufiger und du bist ja auch viel auf Twitter unterwegs etc. Wie hältst du

00:48:31: dich da auf dem Laufenden?

00:48:33: Also Informationen, die mich jetzt persönlich interessieren, ob das jetzt für private Interessen

00:48:39: ist oder für geschäftliche Interessen, die konsumiere ich dort und dann, wenn sie mich

00:48:43: interessieren. Also dadurch, dass sie ja immer verfügbar sind, kann ich sowohl abends auf

00:48:48: dem Sessel mich über irgendwelche Neuerungen im Bereich Oracle informieren oder werde informiert,

00:48:53: zwangsinformiert, weil der Kollege in den USA halt jetzt gerade jetzt twittert und das bei

00:48:57: mir ping macht. Oder es gibt natürlich auch Situationen, wo ich dann während der Arbeit

00:49:01: einen Gedanken habe aus dem Hobby und schaue mir dann halt irgendwo ein Hobby basierte

00:49:05: Informationen an, weil es mich halt jetzt einfach interessiert, mache mir meine Notizen und dann

00:49:08: geht es in der Arbeit weiter. Dann komme ich in der Arbeit wieder auf neue Gedanken und

00:49:11: die andere Seite ist auch nicht verloren gegangen. Was mir persönlich ein bisschen

00:49:15: Schwierigkeiten bereitet, ist auch wieder Ruhe und Abstand zu schaffen. Das heißt,

00:49:19: manchmal muss ich einfach sagen, okay, jetzt hat bei der Geschichte mal das Telefon nichts

00:49:23: verloren. Jetzt brauche ich mal keine Social Media Komponente. Jetzt möchte ich einfach

00:49:27: mal konzentriert arbeiten oder konzentriert schlafen oder konzentriert lesen oder

00:49:31: konzentriert irgendwas anderes machen. Da muss ich immer wieder lernen, den Stecker

00:49:35: zu ziehen und gerade so Konferenztage und Wochen sind da immer ein Risiko. Und ich bin

00:49:39: jetzt wieder mal so weit, ich habe jetzt einfach alles andere, was jetzt nicht

00:49:43: geschäftlicher Social Media ist, was jetzt mit der Konferenz zu tun hat oder Business

00:49:47: Sachen ist, habe ich jetzt komplett auf null zurückgefahren. Ich brauche zur Zeit kein

00:49:51: privater Social Media. Das überlastet mich jetzt gerade im Moment.

00:49:54: Du hast es gerade ganz richtig gesagt und zwar auch das, was jetzt kommt, angekündigt.

00:49:58: Wir werden jetzt den Stecker ziehen. Wir werden uns jetzt zum Ende dieser Konferenz,

00:50:02: des Konferenztages, werden wir physikalisch den Stecker ziehen und einfach mal

00:50:06: den Konsum von den Sachen, die wir lieber mögen, als das auf dem Handy widmen.

00:50:10: Und ja, ich bedanke mich ganz herzlich bei dir, Martin. Für die tolle Episode.

00:50:14: Es war sehr interessant, meiner Meinung nach, über gerade auch diese fachlichen, diese greifbaren

00:50:18: Thematiken zu sprechen und freue mich mit Sicherheit auch über eine zweite Episode, wo wir die

00:50:22: Geschichten hören können, die es noch so interessant ist aus deinem Arbeitsumfeld gibt.

00:50:25: Und ja, herzlichen Dank fürs dabei sein und danke auch an die Hörer für das Hören

00:50:30: dieser aktuellen Folge.

00:50:31: Dankeschön.

00:50:32: Vielen Dank, dass ich da sein durfte und ich freue mich aufs nächste Mal.

00:50:35: [Musik]

00:50:45: [Ende]