All posts tagged: code

Skillbyte Podcast #40: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 2)

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt (Teil 2)

// Inhalt //
01:27 – Masiar’s IT Katastrophengeschichte
02:29 – 6. Lektion: Verstehe zuerst das Problem, schreibe dann erst Code für die Lösung
08:18 – 7. Lektion: Frage um Hilfe wenn du nicht weiter kommst (ultimative Superkraft)
11:20 – 8. Lektion: Du wirst immer weiter lernen (müssen)
21:22 – 9. Lektion: Test driven development (TDD) ist ein Mythos
26:34 – 10. Lektion: Alles dauert länger als geplant. Lass dich nicht von willkürlichen Deadlines verrückt machen.

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Nein. Prozess. Prozess beim ersten Mal o. citta bibber und um Gottes Willen und die Welt geht unter. So, und dann machst du und tust du. Und dann bist am Wochenende da und nachts bis drei. Und hin und her. So wird es aber trotzdem später, weil irgendetwas passiert ist, wo du keinen Einfluss drauf hast oder merkst. So schlimm war das jetzt doch nicht, weil der der Druck gemacht hat. Der war dann auch entspannt. So, und wenn das ein paarmal passiert, dann zuck sogar wenn Merkel.

Herzlich Willkommen zu unserem Skill bald Podcast Episode Nr. 40 10 Lektionen, die wir in über vierzig Jahren Softwareentwicklung gelernt haben. Teil 2 Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld, wenn ihr die Entscheider oder die Fachkraft seid. Wenn ihr Hörer Fragen habt, sendet uns gerne eine E-Mail an Podcast als Skill bei D. Wir freuen uns immer über eine positive Bewertung und wenn ihr den Podcast an Freunde und Kollegen aus dem ähnlichen Arbeitsbereich weiter empfehlt ich bin heute hier wieder mit Mazur zum zweiten Teil.

Hallo Masiar, Hallo Maurice, du bist heute sehr Energized.

Ich bin heute total Energieriese. Ich hatte eine gute Woche und freue mich jetzt mit dir. Wirklich, wirklich. Weil die ersten 5 Lektionen sind schon super angekommen. Da hab ich viele Zuschriften bekommen per WhatsApp und freue mich jetzt mit dir. Lektion 6 bis 10 durchzusprechen voller Energie. Vorher allerdings möchte ich dich fragen Sind dir noch Katastrophen aus deinem Leben eingefallen?

Ganz im Ernst. Ich habe überlegt und überlegt, wie es wirklich nichts eingefallen. Allerdings muss ich sagen, jetzt letztens kam eine GERB für Gravity Kiwi so toll eingerichtet. Was dir berichtet, ob alles in Ordnung ist. Und da kam eine Falschmeldung und damit hat sich das Herz in die Hose gerutscht. Da hatte ich seit langem mal wieder Angst, weil ich unterwegs war und nix machen konnte. Aber es war eine Falschmeldung. Insofern war es wieder gut. Was stand in der Meldung, dass Gravity nicht verfügbar ist?

Also komplett offline? Ja, genau. Ah, okay. Ich dachte jetzt Datenbank kaputt. Hacker haben die Daten geklaut oder so irgendwas Relevantes.

Mir ist nichts passiert in der Richtung nichts passiert. Okay. Erst bauen und Fehlalarm.

Das ist bestimmt meine Aura, die sowieso alles abhält. Deine Aura möchte ich auch haben. Na gut, springen wir zur sechsten Lektion. Vielleicht fällt dir unterwegs noch eine Katastrophe auf, wenn wir durch die Lektionen gehen. Die sechste Lektion ist eine ganz wichtige. Und zwar verstehe zuerst das Problem und schreibe erst dann den Code für die Lösung. Das Problem hierbei ist es oft. Ich bin sicher, das hast du auch gesehen, dass wenn es um Softwareentwicklung geht, springen viele Leute sofort ins Coding.

Die haben die Anforderung gehört. Ach ja, ich weiß schon, was ich machen muss. Achja, da mache ich das so. Da braucht man hier in Cash und das und das und setzen sich sofort an die Tastatur und legen los. Neue Funktionen wenn, dann so iterativ, ganz schnell implementiert und laufend angepasst. Und man merkt erst nach einiger Zeit, dass man das Problem gar nicht korrekt verstanden oder vollumfänglich verstanden hat. Und dann fängt man nochmal von vorne an oder es kommt auf jeden Fall zu einem erheblichen Zeitverlust.

Ich bin sicher, das hast du auch schon gesehen.

Ja, absolut. Ich meine, ich hab mich selber schon mal dabei ertappt. Ich hab mir seit dem das war so in den Anfängen hab ich das so gemacht. Tatsächlich. Aber irgendwann hab ich mir angewöhnt, keine Sequenzer, Diagramme, Urmel, Diagramme und so weiter groß gemacht, sondern einfach auf ein Blatt Papier, so die Komponenten aufgemalt, die Beziehungen aufgemalt. Kann echt auf einem Blatt Papier sein, um einfach mein Kopf zu sortieren und dann steige ich habe auch schon gerne ein.

Mir liegt die Klassennamen auf oberster Ebene, verknüpfe sie, schreibe die ersten Tests Duala Test Driven und das funktioniert ganz gut.

Das ist so, bis ihn der Flow, denn ich habe genau das ist für mich ein ganz klarer Indikator, ob man es mit einem Junior Entwickler oder Senior Entwickler zu tun hat. Ein Senior Entwickler stellt erst einmal sehr viele Fragen und versucht das Problem genau zu verstehen oder die Anforderungen genau zu verstehen und ist halt erst Input fokussiert. Wie geht man das jetzt an? Also du hast es eben schon gesagt. In jungen Jahren geht der Tüftler mit einem durch und man möchte sofort einsteigen und loslegen.

Ich habe so zwei unterschiedliche Pattern, je nachdem ob es um Feature Entwicklung geht oder um Bugfix sing.. Fangen wir mal mit dem Einfacheren an. Das wäre das Bugfix sing.. Das Allerwichtigste beim Bugfix sing. ist, dass man erst einmal den Bug zuverlässig reproduzieren kann, weil erst dann sinnvolle Entwicklung eines Fixes möglich. Meiner Ansicht nach erst, wenn ich weiß, wenn ich hier klicke und da klicke und dann tritt der Fehler auf und das immer wieder machen kann. Erst dann kann ich ja quasi prüfen, ob meine Lösung das Problem wirklich löst.

Ein weiterer Hinweis und ich bin verblüfft, wie viele Leute das nicht machen ist, den Debugger zu verwenden, also wirklich Schritt für Schritt durch das Programm durch zu steppen und sich die Variablen anzugucken. Was passiert hier? Was passiert da gerade, wenn man das Programm selber nicht kennt oder es nicht selber entwickelt hat, dann wird es oft sehr einfach, da einen Fix zu entwickeln, weil man einfach genau sieht Ah, ok, an dieser Stelle muss etwas anderes passieren oder muss etwas weiteres passieren und das könnte man dann implementieren.

Einfach den die Bagger abklemmen und idealerweise wenn man den Bug dann gefixt hat, dann hinterher war man jetzt schon im Thema drin. Noch einen Testa zu schreiben, der prüft, dass der fix funktioniert und dass das Problem eben nicht nochmal auftritt. Das ist meiner Ansicht nach eine professionelle Möglichkeit ans Bugfix hing ranzugehen, um nicht direkt in den Code zu springen. Bei der Feature Entwicklung und da bist du wahrscheinlich bei mir ist es oft so, dass die Anforderungen gar nicht so klar sind.

Also das ist wirklich ganz ganz selten, dass der Projektleiter. Jeder auf einen zukommt und glasklar schon sagt Das soll so sein. Das soll so sein. Das soll so sein. Das soll so sein, sondern ja, wie hat man altes System? Und da lief das so und so und ich möchte das jetzt genau so haben. Nur hier und da, da muss etwas geändert werden. Also das tritt sehr häufig auf. Auch hier das Problem erst einmal voll umfassend verstehen.

Wenn schon Quote da ist. Also wenn z.B. das Feature eine Erweiterung darstellt, erst einmal diesen verstehen, dann ne Lösung Skizze erstellen, genau wie du sagst. Ich versuche mir immer die Eingabe und Ausgabe Daten erst einmal aufzuschreiben. Was geht rein, was soll rauskommen und dann eine Technologie Skizze zu machen. Und im Grunde ist für mich ein Computersystem in Daten Topf mit Code drumherum, also eine Daten Haltung die Transformationen auf diesen Daten durchführt. Und ich glaube, wenn man die Daten und die Transformations Schritte hinreichend genau beschrieben hat, dann wird das Problem mehr oder weniger klar und der Rest folgt fast automatisch.

Oder die Problemlösung folgt fast automatisch. Und bis man soweit ist, hat man sehr viel gelesen, aber noch keinen Code geschrieben oder sehr wenig Code geschrieben. Warum passiert das? Warum springt man sofort in den Code? All das einfacher ist, als sich Gedanken über das Problem zu machen. Das ist oft sehr schwierig. Man muss nachfragen, man hat es nicht genau verstanden. Man muss diese Zeichnung erstellen und direkt zu coden. Das möchte im Grunde jeder. Aber mit zunehmender Reife weiß man, dass das nicht unbedingt das zielführende Vorhaben ist.

Du bist auch motiviert, hast eine Idee im Kopf und setzt sich hin und willst das sofort machen. Also ich muss sagen, wenn ich tatsächlich eine Idee fest im Kopf habe, dann mach ich das auch schon mal hier und da setze ich mich hin und knallt die Klassen einfach rein. Das funktioniert auch ganz gut, aber ich glaube, das kannst du nur machen, wenn du gewissen Erfahrungsschatz mitbringst.

Erstens das und wenn das Problem hinreichend klein ist. Ja, definitiv. Also nicht bei super komplexen Funktionen oder wo sehr viele Transformationen gemacht werden müssen. Genau. Und dann ist es oft auch wichtig, das Problem korrekt zu erfassen oder das ist eigentlich das Wichtigste und dann das Problem zu lösen, anstatt irgendwie fancy mit Architektur Patterns technische Exzellenz zu zeigen. Das sehe ich auch relativ häufig. Dann werden dann einfache Sachen technisch exzellent gelöst, aber das Problem ist gar nicht so richtig verstanden worden.

Da gibt’s ein schönes Zitat und damit möchte ich die sechste Lektion abschließend von Abraham Lincoln Gib mir sechs Stunden einen Baum zu fällen und ich werde die ersten vier Stunden mit dem Schärfen der Axt verbringen.

Als Kind ist es echt schön. Ja, genau.

Ich kenne sogar so eine extreme Version. Da heißt es Gib mir fünf Stunden und 50 Minuten zum Schärfen der Axt, sodass man mit einem Hieb im Prinzip den Baum durchbekommt. Aber was heißt das hier? Ganz klar Desto genauer du das Problem verstehst, desto einfacher wird die Lösung hinterher. Nur man muss halt mehr Zeit mit der gedanklichen Beschäftigung mit dem Problem verbringen statt mit dem eigentlichen Coding. Deshalb ist das so schwierig zu befolgen. Die siebte Lektion ist für mich eine ultimative Superkraft.

Und zwar Frage um Hilfe. Wenn du nicht weiterkommst, wie machst du das?

Wenn ich nicht weiterkomme, muss ich sagen such ich tatsächlich im Internet. Stack Overflow ist definitiv eine Quelle, die mir sehr viel Tipps und Inspiration gibt, aber auch alle Menschen toll sehr Ego im Netz sind. Da werde ich für den speziellen Fall, wo ich nix finde, frage ich ja tatsächlich natürlich auch Kollegen.

Man verbeißt sich oft in Problem oder so geht’s mir manchmal. Du fängst an, alles ist ganz einfach. Dann kommen irgendwie Hindernisse, auf den gelangst du immer tiefer in diesen Kaninchenbau rein. Man probiert unterschiedliche Ansätze und wendet sehr viel Zeit auf. Also dann ist man richtig frustriert und fragt nach zwei Stunden vielleicht einen Kollegen. Und er sagt Ach ja, kenne ich schon. Du musst hier das und das machen. Boah, das hat mich damals drei Tage gekostet, das herauszufinden oder so, wo man so richtig schön per Facepalm dann denkt Oh Mann, da hätte ich mal vorher gefragt.

Das ist aber auch so eine Gratwanderung. Du kannst ja nicht wegen jeder Kleinigkeit den Kollegen fragen. Na weil, dann ist er auch irgendwann genervt. Manchmal, wenn du der Mensch bist, der sich am längsten mit einem Problem beschäftigt hat oder am längsten ein Projekt ist. Es ist einfach unwahrscheinlich, dass die andere weiterhelfen können. Natürlich Google Stack Overflow und alle Quellen benutzen, die man im Internet findet. Das ist das Naheliegendste. Aber hier soll es wirklich darum gehen, den Kollegen zu fragen oder die Kollegen Kolleginnen zu fragen, ob man weiterkommt.

Also ich mache das so, ich probier das erstmal eine halbe Stunde, sag ich mal. Wenn ich an ein Problem komme und wenn ich dann nicht weiterkomme, zwinge ich mich, aufzustehen und jemanden zu fragen oder eben patschert jemanden zu fragen. So um dann einerseits respektvoll mit der Zeit der Kollegen umzugehen, auf der anderen Seite aber auch nicht zu viel Zeit zu verständigen. Und das hat sich bei mir eigentlich als gutes Vorgehen herausgestellt. Aber du fragst nicht so viel, oder?

Nee, hat vielleicht auch ein bisschen mit Persönlichkeit zu tun. Ich versuche lieber selber zu lösen. Keine Ahnung, ist einfach so. Ich kann nicht sagen, warum. Aber ich will den Knoten selber irgendwie aufmachen.

Das hab ich auch, dieses Gefühl. Man hat schon so ein bisschen das Gefühl Ah, wenn ich frage.

Und das ist jetzt vielleicht eine einfache Sache, das geht so ein bisschen in die Berufsehre. Sitzt noch nicht mal irgendwie, aber so ich mache auch nicht gerne welche Superpower Grabbing oder sowas würde ich programmiere, möchte ich irgendwie allein sein. Ich hoffe, das versteht Cat irgendwie, oder ob das jemand nachvollziehen kann.

Ich glaube, das können sehr viele nachvollziehen. Bei mir ist das tendenziell auch so, aber ich hab ne Frustrationstoleranz, die sehr niedrig ist, wenn ich nicht in kurzer Zeit ausreichende Fortschritte mache. Also wenn ich das Gefühl habe, oh, mit jemandem zusammen komme ich schneller voran. Der Zweck heiligt die Mittel sozusagen. Dann setze ich mich auch zu zweit hin. Wenn ich das Gefühl hab, ich komme ja alleine weiter, dann hab ich auch kein Problem, das zu machen.

Aber ich glaube dennoch ab und an um Hilfe zu fragen. Kann einem sehr schnell sehr viel weiterbringen. Zumindest für das Team. Insgesamt ist es besser, als wenn jeder verbissen an seiner eigenen Lösung arbeitet. Die 8 Lektion. Hier geht es um Weiterbildung. Da haben wir ja auch schon in diversesten Episoden drüber gesprochen. Im IT-Sektor wirst du immer weiter lernen müssen. Das Technologie Umfeld ändert sich so schnell. Bestehende Technologien verlieren an Relevanz, neue kommen hinzu, die es noch gar nicht gab, die sehr schnell sehr prominent werden.

Und es wird gefordert, weil man ist ja Technologie Experte, dass man sehr schnell eine Einschätzung liefern kann. Was sind kurzlebige Trends und was sind wirklich längerfristige Entwicklung und was bedeuten diese für das eigene Umfeld? Im Grunde Welche Technologien muss ich lernen und welche kann ich einfach vorbeiziehen lassen? Wie machst du das? Hast du da bestimmte Kanäle, über die du dich informierst, abseits der üblichen wie Heise, Golem usw.?

So um Trends und so weiter mitzubekommen. Tatsächlich einfach im Internet. Heise Golem. Ich habe aber auch diese ich habe mal Subscription eins zu Cloud, Gusi und viele Yumi Kurse. Da schaue ich regelmäßig mal vorbei und gucke, was neue Kurse sind. Speziell ist es aber für die Bereiche Java oder DevOps. Wo ich unterwegs bin, suche ich gezielt danach. Und wenn mir irgendwas interessant erscheint oder mir ein Wort begegnet Technologie, von dem ich noch nicht gehört habe, dann gucke ich mal rein.

Dann suche ich danach explizit. Ich versuche halt immer so ein Level zu erreichen, wo ich verstehe, was das Tool macht. Will mir eins besonders interessant erscheinen, oder? Ich meine, das passt mir sehr gut den Kram. Dann mach ich auch schon mal so ein Tutorial mit, um einfach mitreden zu können, einfach zu wissen, was es ist, was man damit machen kann und so erweitere so nach und nach mein Tool. Schade. Oh dann, je nachdem ich das nächste Mal auf so ein Problem stoße, weiß ich Aha, da gab’s doch mal so ein Tool.

Okay, toss im Grunde diese Sternenkarte schon im Kopf. Und wenn ein neuer Stern auf ploppt, dann guckst du dir den kurz an und kannst ihn dann einordnen.

Ja, das halte ich auch für sehr wichtig. Ich finde, diese längerfristigen Entwicklungen oder diese großen Trends, die erkennt man relativ gut, weil sie auch mehrere Jahre bestehen. Also Cloud wäre z.B. ein Trend, Datenauswertung wäre ein großer Trend. Generell Megatrend ist natürlich Digitalisierung. Wobei tue ich mich schwer, das als Trend zu beschreiben, sondern das ist einfach eine weitere Entwicklungsstufe der Menschheit. Das möchte ich jetzt nicht als Trend verstanden sehen, sondern man kann technologisch einfach Prozesse effizienter abbilden, als man das manuell könnte.

Gerade jetzt mit Heimarbeit wird das offenbar an vielen Stellen, sodass das auf eine weitere Entwicklungsstufe ist. Aber es gibt auch Micro Trends, das sind z.B. Tools im Kobanê, das Umfeld oder im Container Umfeld, die man so ein bisschen im Auge behalten muss. Vielleicht hier als Tipp. Ich weiß nicht. Kennst du jeden Freitag auf dem Heise Newsticker diese Developer News in ein, zwei Sätzen? Du kannst mal auf Heise Slash Developer gehen, da kriegst du nur die für Developer relevanten Artikel angezeigt.

Ist für mich ein Super Life Hack und die ganzen Clickbait Artikel sind dann weg und da gibts es jeden Freitag so ein Digest, wo dann in zwei Sätzen immer dran steht. Das Tool ist und der und der Version entschieden. Das kann jetzt so und so.. Die Software hatte Sicherheitslücken, die wird nicht mehr gepflegt, die ist neu hinzugekommen. So und das sind immer 35 40 Einträge, wo man einfach weiß, was so abgeht. Dieses Symbolbild von dem Artikel ist immer das gleiche.

Daran erkennt man es dann sofort und man hat einfach einen schnellen Überblick. Viele Tools sagen einem auch nichts. Also wenn das sieht so aus dem Automotive Bereich kommt oder irgendein Spezialwerkzeug ist okay, dann hat einem das noch nicht berührt. Aber so hat man so einen Überblick. Und da guck ich dann rein. Wenn jetzt ein Tool schon zum dritten, vierten Mal Erwähnung findet, dann kann ich mir vorstellen Ah, okay, das scheint auf jeden Fall wichtig zu sein, oder?

Da wird häufiger drüber gesprochen, weil die Entwicklung da so rasant ist. Jede Woche eine neue Version ist ja dann schon eindeutig ein guter Tipp. Auf der anderen Seite, also wenn es schon gesagt. Im IT-Bereich wird man immer lernen müssen. Auf der anderen Seite finde ich auch desto mehr Erfahrung man hat, desto weniger Schrecken ein. Diese neuen Technologien, weil man immer wieder feststellt So wirklich, wirklich Neues. Das kommt vor. Aber es ist nicht so häufig, sondern oft erscheinen neue Frameworks oder Libraries.

Und die sind nur ein Aufguss einer bekannten Technologie aus einem anderen Kontext. Und alles war irgendwie schon mal da. Deshalb bin ich dazu übergegangen, mir eher die Konzepte anzuschauen Welches Konzept steckt denn hinter der Blockchain oder einem Paket Manager oder Haskell? Wenn du SQL kannst, da kannst du alle Datenbanken und nicht nur eine bestimmte. Wenn du weißt, wie ein Paket Manager funktioniert, dann kannst mit N.P. Umgehen, mit Maven, mit Neef, geht mit APC, mit Pacman Kapern und wie sie alle heißen.

Und wenn dann jetzt der nächste dazukommt, dann weiß man AOC, dass im Paket Manager DeWitt irgendwie so funktionieren. Ich weiß, was im Paket Manager macht und das ist dann der Achte im Bunde. So ungefähr auch Protokolle. Also ganz früher gab’s den Remote Procedure Call, der ist sogar noch vor meiner Zeit, den kennst du wahrscheinlich noch. Dann kam die Scope Schnittstelle. Heute sind wir bei Rest APIs angekommen. Wer weiß was danach kommt. Hier Proto Buffer oder so.

Bei Frameworks genauso Tools kommen auch andauernd neue hinzu. Na da gibt’s natürlich so mega Tools wie Git. Also Code Warning ist glaube ich schon in den letzten 15 Jahren extrem gepusht worden, wo früher die Leute ihre Dateien irgendwo gesichert haben. Es war ganz grausam und zwischen den einzelnen Ökosystemen, also dort net Java node Python you name it. Wenn irgendwo ein cooles Feature auf ploppt ist meiner Erfahrung wird das sehr oft geklaut.

Sehr gut. Ist ja normal. Ja, ich finde das auch gut. Das ist ja die Schönheit. Ein Open Source. Wenn einer was rausgefunden hat, können alle profitieren. Also wie schließen wir mit dieser Lektion ab oder was ist unser Empfehlung? Ich würde sagen, man muss nicht alles im Detail verstehen, aber man sollte halt die Konzepte verstehen und diese Themen einordnen können. So wie du das eingangs im Prinzip gesagt hast. Du hast diese Sternenkarte und kannst neue Sterne schnell platzieren.

Du versuchst halt zu abstrahieren, soweit wie möglich.

Was ist für dich eine Technologie der letzten Jahre, wo du gedacht hast Okay, das ist ein Megatrend? Mein Gott, da muss ich wirklich viel lernen.

Das ist das Thema Cluster Orchestrierung. Docker Dieses ganze Gebilde. Das war für mich völlig klar, dass ich meine, damals waren mehrere so am Start da visus Marathon, kybernetisch, die waren alle gleich auf. Und interessanterweise, das hab ich auch schon bei einem anderen Podcast erwähnt. Ich hab mich am Anfang komplett gegen diese Docker Technologie gewehrt, als die Kollegen das angesprochen haben. So ein bisschen erklärt hab. Ich fand das halt mega abstrakt. Ich hab das alles gar nicht verstanden wie Leya und wie.

Ich kann da nicht reinschreiben was soll der Scheiß. Nach und nach je mehr die das gemacht und eingeführt haben, umso mehr hab ich verstanden. Mein Gott und dann hat es irgendwann Klick gemacht. Hat euch boah wie geil darunter. War mir klar, das willst du lernen. Ja, da hab ich mich rein gekniet. Das war vor fünf Jahren. Und dieses Universum expandiert wie das richtige Universum, wie es permanent neue Tools erfindet sich neu. Da kommt K3 is leichtgewichtige Scobel net das, was du quasi auf dem Raspberry laufen lassen kannst.

Das explodiert quasi diese Technologie. Und ich liebe es aber auch so dran zu bleiben. Kugel und auch Madhya. Das ist super und find ich klasse. Also diese Technologie war für mich so zu all dem was die letzten Jahre passiert ist mit ein Gamechanger der Wahnsinn.

Nachdem du dich zuerst gewährt hast, wusste ich gar nicht. Hast du gedacht, das ist so kleinteilig?

Und was braucht man mehr als VMS oder genau was bringt da auch so außer jetzt eine riesen Lernkurve? Muss das jetzt sein? Sah ich so halt als Spielerei der Admins an und eigentlich war diese Erfahrung ganz gut, weil wir ich jetzt quasi bei einem Kunden bin. Und du hast meinetwegen so einen alteingesessenen Unix Systemadministrator, der diesem Konzept entsprechend auch nicht aufgeschlossen gegenüber ist. Dann kann ich das super nachvollziehen und weiß dann, wie ich den anderen führen kann. Was so?

Weil du diese Entwicklung selber mitgemacht hast, kannst du sozusagen auf der empathischen Schiene sagen. Ich weiß, die Bedenken hatte ich auch. Aber sieh mal folgendes Ja, da kommen mehrere Sachen zusammen. Mit Docker hattest du so eine erste Abstraktionsebene und Docker alleine bringt ja nicht so viel. Aber in dieser Kombination mit dieser Cluster Technologie und diesem Paradigmenwechsel dieser da wir eine Episode gemacht dieser 12 Faktoren für Cloud Native Apps kannst du ja Anwendungen komplett anders bauen, die dann eben wirklich weltweit skalieren.

Also du kannst mit den großen Gagfah Unternehmen mithalten, vom technischen Standpunkt aus, wenn du diese Software nach diesen Paradigmen entwickelst und diese Gaffer unternehmen haben die sie ja entwickelt. Das ist nicht nur Technologie, sondern auch so ein Mindset plus auch diese Cloud. Denke da kommt alles zusammen. Und das ist eine größere Blase oder ein eigenes Universum, was man nicht so isoliert betrachten kann. Und für dich? Du hast ja mal gesagt, dass du auch früher viel IT Administration gemacht hast.

Also Netzwerk Administration, Linux Administration nehme ich mal an..

Die SEMA Administration oder so Backoffice wirklich, oder?

Ich war Third Level Support einmal und zum zweiten haben wir mit einem anderen Kollegen via Mail und Unix Systeme. Administriert mit send Mail. Ja, das waren noch Zeiten. Okay, da war noch nichts Container visiert. Äh, nicht so wirklich.

Ich kann mich genau erinnern, wo der Kollege ankam mit 20 Disketten und Material. Guck mal, Linux hier, Ledoux da. Das war also damals das Linux System. Putzer und Linux kam gerade erst auf und VM, wer will ich nie faxen? Wir sagte hier Guck mal die Virtualisierung von VM. Wer und wie ich da Disketten reingeschoben hab und damit rumgespielt hab. Und da waren wir auch. Glaube, da könnte was draus werden und diese war so Vollbild geworden ist.

Das stimmt. Also dieses Feld wandelt sich weiter und wie im Universum. Es gibt schnelle Sterne, es gibt langsame Sterne, große Sonnen, die nicht mehr weggehen. Und das kommt in der IT auf jeden Fall mit. Man muss sich weiterbilden in allen 40 Jahren oder in all der Zeit. Dann die neunte Lektion. Ich weiß nicht, ob es schmerzhaft ist oder lustig. Test Griffen Die Welt abmahnt ist ein Mythos, heißt die Lektion. Und was ich damit meine ist Testserver Development, dass man zuerst die Tests schreibt und dann anhand der bestehenden Test da rein die Funktion implementiert.

Das hab ich schon so oft gehört. Bei Kunden und in der Theorie macht das auch Sinn, dass man sich zunächst über alle Grenzfälle einer Anwendung Gedanken macht und das Verhalten genau bestimmt. Und wie soll es denn sein? Wie soll sie sich verhalten, dass man anschließend alle diese Annahmen in Unit oder Integrations Test niederschreibt und dann im Prinzip die Komponente selbst entwickelt und nur noch die Komponente so minimal entwickeln muss, dass alle Tests grün sind, also alle Tests erfolgreich durchlaufen werden.

Und dann hat man sozusagen die minimale Lösung, die alle Tests erfüllt. Das habe ich in der Praxis noch bei keinem Projekt gesehen, wo das wirklich funktioniert hat. Ich freue mich schon über die Zuschriften.

Gerne melden, wenn es bei euch in der Firma funktioniert oder wenn ihr ein Projekt kennt, wo es funktioniert hat. Aber ich habe es einfach noch nicht erlebt. Und ich glaube, das Problem besteht darin, dass die Anforderungen für ein neues Feature oder für eine neue Anwendung oft nicht so messerscharf spezifiziert werden können, dass sich daraus Tests direkt ableiten können. Ist da deine Erfahrung?

Ja, Test am Anfang hat man immer gemeint. Also ganz ehrlich, ich gehörte auch dazu. Tests machen die Sache nur teurer, weil du ungefähr ein Drittel deiner Zeit damit verbringen musst. Wenn du Test Rival entwickelst. Aber je mehr ich in komplexeren Projekten eingestiegen bin, um so mehr ist mir bewusst geworden, wie wichtig doch Tests sind. Und inzwischen gibt’s ja Tests irgendwie. White Box Testing, Blackbox Testing, Tschiche Test Varianten und jedes für sich macht Sinn.

Ja, je mehr, desto besser. Weil so hältst du deine Software wandelbaren, gewitzte, gewisse Sicherheit da auch Änderungen zu machen. Und du hast einfach keine Chance, manuell irgendetwas zu testen, wenn du in irgendeiner Ecke rumschrauben.

Ich glaube, da spielen mehrere Faktoren eine Rolle. Und zum einen verändert sich Software heute schneller als früher, weil sich die Geschäfts Anforderungen schneller ändern. Man ist gewöhnt. Ah, ich muss die Software nur ändern und dann ist die neue Funktion da drin und das funktioniert sofort. So, das ist bis in die Vorstandsetage hoch Geblubber. Und deshalb ist die Erwartung. Ich kann die Software schnell ändern, dann können wir das abfangen gestiegen. Also die Zeiträume bis hin zur Implementierung sind halt kürzer.

Wenn die Zeiträume kürzer sind, heißt das aber auch Development to Market ist kürzer. Und wenn du jetzt keine Tests hast, dann ist das so, als wenn du in schneller Folge beim Domino Day die Dominosteine aufstellen willst und umgeben bist von anderen Dominostein. Die Gefahr, dass du da irgendetwas anderes um stößt, ist gerade in komplexen Systemen riesig. Das heißt, die meisten Projekte, so kenne ich das, verwenden schon automatisierte Tests, meistens Unit Tests für einzelne Funktions Komponenten, die dann von der CCD Pipeline, also Git Lab, Bruna, Maven Tests usw.

angestoßen werden und Schlüssel Komponenten testen. Die IBAN sieht die richtig aus? Stimmen, die Datums Konvertierungen usw. und sofort. Aber eben nicht alles abdecken. Auch RPI Tests gibt es mehr und mehr, die einfach die Funktionsweise von Schnittstellen testen. Aber niemand hat 100 prozent und im Falle des Falles unter Zeitdruck fallen die Tests halt einfach runter. So, das ist meine Erfahrung und definitiv. Das sieht ja auch erstmal niemand.

Also du hast 100 Funktionen, 99 davon sind getestet, eines ungetestet. Jetzt machst du noch 10 Funktionen, noch 10 Funktionen ohne Tests, sodass nur so graduell wird das immer schlimmer. Aber das ist wie Carius. Erst einmal sieht man es nicht. Und irgendwann wird es dann offenbar. Und ich will nicht sagen, dann ist es zu spät. Aber dann muss man es dann doch behandeln. Ich glaube, ein guter Kompromiss ist hier die Kernfunktion, also kritische Sachen, wenn es um Transaktionen geht von Benutzerdaten, also datenschutzrechtlich relevanten Inhalten oder Zahlungsarten.

Das ist super wichtig, dass man das alles ab testet.

Es gibt dabei in jeder Anwendung auch unkritische Bereiche, da muss man sich ganz so genau nehmen. Unit Tests zumindest Völklein Komponenten halte ich für wichtig. Ja, und auf Front in Tests gibt es mehr und mehr und auch desto länger die Software besteht, desto mehr lohnen sich Tests. Gerade wenn viel verändert werden soll, hast du noch einen Tipp, wie man vielleicht dieses Tests Problem besser lösen kann? Also wie machst du das? Wie teilst du dir die Zeit ein für Tests?

Machst du Tests oder nur wenn es gefordert ist? Oder bestehst du darauf?

Nee, also so rigoros oder stringent bin ich nicht. Wenn ich meine, dass eine Interaktion zwischen Komponenten oder einer Komponente selber für mich in gewissem Komplexitätsgrad übersteigt, wo ich meine Oh, wenn es hier eine Änderung gebe, dann könnte es zu Problemen führen. Oder wäre das schön, wenn die anderen Komponenten das das bastel ich mir so im Kopf zusammen. Und wenn das einen gewissen Sprechrolle übersteigt, dann mach ich die Tests auch nicht für jede Klasse und jede Methode, sondern wirklich da, wo ich der Meinung bin, das könnte schwierig werden.

Später für die Worker oder Helper oder Converter oder sowas. Eben genau die sehr oft aufgerufen werden und die so eine Kernfunktion dann bewerkstelligen. Ja, sehe ich auch so. Haben wir schon einen gleitenden Übergang zur zehnten und letzten Lektion. Und davon können alle die Mitarbeiter und IT-Fachkräfte und Projektleiter ein Liedchen singen. Die zehnte Lektion heißt Alles dauert länger als geplant. Lass dich nicht von willkürlichen Deadlines verrückt machen. Das geht eher in Richtung Entwickler. Alles dauert länger als geplant. Wäre vielleicht die richtige Überschrift hier.

Was ist das Problem? Das Problem ist bei Kreativ Arbeit und nichts anderes ist ja die Erstellung von Programmcode. Im Grunde genommen ist ja nicht so, dass man da Mathematik rechnet, sondern eher kreativ sich eine Lösung überlegt und die dann runter codiert oder eine Formsprache bringt. Bei kreativer Arbeit ist es schwierig eine realistische Zeit Abschätzung abzugeben, gerade wenn die Anforderungen nicht klar sind. Zudem gibt es eine Vielzahl von Zeitfresser. Das erlebe ich immer wieder, die niemand auf dem Schirm hat.

Neue Bugs kündigen sich nicht an. Man kriegt einen problematischen Mertz Request von jemand anderem zugewiesen und brauch dafür 2 3 Stunden länger als gedacht. Mitten im Projekt gibt es Bibliothek, Updates oder Sicherheitslücken, die nicht warten können. Diese Bibliothek Updates ziehen Schnittstellen Änderungen nach, die man sofort machen muss. Was sonst funktioniert es nicht mehr? Irgendetwas funktioniert nicht wie beschrieben, kommt auch relativ häufig vor. Ein Kollege muss eingearbeitet werden, ein Kollege fällt aus. Es gibt viele Meetings.

Die Firma hat eine Restrukturierungen. Es wird kommuniziert, was jetzt alles restrukturiert wird und so weiter und so fort.

Und das taucht in keiner Zeit Abschätzung auf. Also ich habe noch bei keiner Sheets Runde gehört. Ja, also eigentlich würde ich sagen, ich brauch Tag, aber wenn wir restrukturiert werden unterwegs sollte ich vielleicht mal 2 Tage einplanen, weil beweiß. Dann bin ich ein Tag mit Meetings zugeschüttet oder so. Ich hatte jetzt letztens eine das hat mich nicht selber betroffen, aber eine Mitarbeiterin, die für ein Promo Video der Firma einen Tag quasi zur Verfügung stehen sollte. So was wird natürlich auch vorher nicht abgeschätzt.

Also was bedeutet das? Es dauert immer länger als du denkst. Sogar wenn du weißt, dass es länger dauert als du denkst. Wie gehst du damit um? Weil da wird ja manchmal schon relativ starker Druck gemacht. Extrem entspannt.

Also da drüber bin ich echt hinaus, um mir Druck machen zu lassen von Projektmanagerin oder Product Owner. Bei den Schätzungen gehe ich so vor, dass ich so eine Excel Liste mache und wir die jeweiligen Features Zeile für Zeile aufschreibe. Und dann mach ich eine Abschätzung für den Best Case, eine Abschätzung für den Worst Case dmit dort den Schnitt und addiere darauf nochmal 30 prozent für Unvorhergesehenes. So und so eine Schätzung gebe ich dann ab. Und wenn es dann länger dauert?

Ich versuche dann halt immer so ein bisschen zu dokumentieren, wenn was dazwischen kommt, was nicht auf dem Schirm war. Einfach um nachher, wenn einer fragt bis eine Liste raus und kann sagen Ja, das und jenes, welches ich habe keine Information bekommen nicht gebraucht habe oder der Kollege Z. Als Ansprechpartner war drei Wochen krank, ohne Vertreter, Regelung und und und, um einfach so ein bisschen sicher zu sein. Ansonsten kann ich es sagen. Wenn es dann noch länger dauert, dann ist es halt so.

Also du hast dieses Lass dich nicht von willkürlichen Deadlines verrückt machen völlig verinnerlicht.

War das bei dir immer so oder ist das ein Prozess?

Nein. Prozess. Prozess beim ersten Mal oh citta bibber und um Gottes Willen. Und die Welt geht unter. So und dann machst du und tust du. Dann bist am Wochenende da und nachts bis drei. Und hin und her wird’s aber trotzdem später, weil irgendwas passiert ist, wo du keinen Einfluss drauf hast oder Bergsee. So schlimm war das jetzt doch nicht, weil der der Druck gemacht hat. Der war dann auch entspannt. So wird das ein paarmal passiert da ja auch.

Was will man machen? Also zuckte du noch mit den ATL dieses Druck machen?

Ich sag mal ein bisschen Druck machen, okay. Aber dieses starke Druck machen? Es ist ja nicht so, dass du am Fließband stehst und jeden Tag in acht Stunden acht Autos Ponti hast. Und wenn du da zehn Stunden stehst, montiert du zehn Autos. Du denkst ja nicht schneller, weil du unter Druck geraten bist. Also. Ich weiß nicht. Bei mir funktioniert das nicht. Ich werde dann eher geblockt oder so. Wenn ich weiß Oh du Dexia, die schneller.

Ja, das ist ja sozusagen die Denke, da trödelt jemand, die mach ich jetzt.

Beine Nee, das kommt so aus der Industrialisierung und den setze ich unter Druck.

Und dann konzentriert er sich besser oder bleibt eher an der Sache dran. Das funktioniert bei Creativ Arbeit ja nicht. Also wenn ich einem Künstler sage mach schneller! Dann wirft er den Farbeimer gegen die Staffelei und dann kann er auch nicht sagen Ich bin fertig. Also vielleicht kann er das sagen, aber dann ist das Kunstwerk nicht gut. Und das sieht man leider auch mancher Software an, dass sie unter großem Zeitdruck entstanden ist.

Ich habe aber auch das Gefühl, Entwickler schätzen tendenziell zu positiv. Ich weiß nicht wieder.

Deine Erfahrung ist das kann ich so nicht sagen. Weiß ich das? Ich würde weder sagen positiv noch mal ist es klar mehr positiv, mal negativ heckt und ein bisschen damit zusammen, wie viel erfahrener oder unerfahrener Kollegen du im Team hast. Also eine generelle Tendenz kann ich glaube ich nicht sehen.

Ich hatte schon mal den Fall, dass Projektmanager bei Schätzungen gedrängt haben und sagen Nee, das ist zuviel, das muss schneller gehen und selber dann die Schätzung visieren oder beeinflussen.

Das auf jeden Fall halte ich für sehr gefährlich, es sei denn, der Projektmanager sagt vorher ganz offen Du, wir müssen unter diesem und jenem Level bleiben, um das Projekt genehmigt zu bekommen. Wenn das dann einmal läuft, dann wird es keiner mehr stoppen, wenn es länger dauert. Das hatte ich auch schon. Dass das so offen kommuniziert wurde, ist natürlich auch grenzwertig, aber das passiert manchmal. Aber klar, wenn das Projekt einmal läuft und man hat es schon 60 Prozent geschafft, dann wird es vielleicht der oberen Etage schwerer fallen zu sagen Na, wir stoppen das jetzt, weil das Budgets aufgebraucht, lass die letzten 20 Prozent weg.

Macht jetzt nochmal 20 Prozent und dann ist out.

Ich habe einmal erlebt, wo ein Produkt oder ein Kollegen so gedrängt hat, wird er das jetzt so so schätzt oder nicht fertig wird, dann gibt’s als mit dem Bonus nix.

Also wenn er es schätzt oder wenn es nicht fertig bekommt in der Zeit nicht oder so grob geschätzt.

Und dann sagte er Ja, es dauert halt so lange oder sagt sie Nee, auf keinen Fall. Dann gibt es wieder Modus. Nix gibt’s alles.

Ich hoffe, sie meint es nicht ernst. Doch ich war dabei.

Wenn’s nur auf die Schätzung ankommt, dann wird immer alles ganz schnell geschätzt.

Echt so, die Softwareentwicklung? Ja, manchmal ist es schon verrückt, meiner Erfahrung nach. Man kann sehr zuverlässige Schätzungen abgeben. Allerdings nur für sehr kleine Projekte oder sehr kleine abgegrenzte Probleme. Wenn die eingesetzten Werkzeuge und der Anwendungsfall sehr genau bekannt ist und man sicher gehen kann, dass man nicht von extern gestört wird. Das sind dann aber kleine Projekte und da weiß ich nicht. Die finden in den Firmen nicht so häufig statt. Meiner Erfahrung nach Bara sind dann nicht so wichtige Themen.

Ist denn in deiner Erfahrung mal ein Projekt vor der veranschlagten Zeit fertig geworden?

Ja doch, auf jeden Fall auch schon erlebt.

Ist zwar extrem selten gewesen, aber da gibt’s definitiv bei SKL bei Tamir einfallende, wo wir supergut im Zeitplan lagen. Oh, das war mega. Aber ansonsten. Ich muss mal überlegen. Na gut, auf der anderen Seite wir sind eine Consulting Firma und wir werden meistens angerufen, wenn in Excel schon eine rote Zelle erscheint.

Ja also diese Feuerwehr Geschichten gibt’s natürlich auch der Druck entsprechend groß ist.

Ja, das waren die 10 Lektionen. Unglaublich. Ich bin auf die nächsten 40 Jahre gespannt oder?

Ich hoffe nicht. Da mache ich so eine Abschluss Folge zur Verrenkung. Dann was ich gelernt habe, wenn unsere Zuhörer Fragen haben zu der aktuellen Episode oder auch so können Sie uns eine E-Mail an Podcasts Gilbert D.

Senden. Wir freuen uns immer über Bewertungen oder wenn ihr den Podcast abonniert. Empfehlt den Podcast auch an eure Freunde und Kollegen weiter und schaut auf der Skill bei D. Slash Jobs Seite vorbei. Weitere spannende Technologie Artikel findet ihr Weißgerber D im Blog Masa Es war wie immer ein pures Vergnügen mit ihr zu sprechen. Danke Rorys, dann wünsche dir noch einen schönen Abend.

Maurice KnoppSkillbyte Podcast #40: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 2)
Mehr

Skillbyte Podcast #39: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 1)

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt

// Inhalt //
01:20 – 1. Lektion: Halte die Komplexität in IT-Projekten so niedrig wie möglich
08:24 – 2. Lektion: Der beste Code ist einfacher Code.
14:44 – 3. Lektion: Gutes Projektmanagement ist wichtiger als das Vorgehensmodell
22:36 – 4. Lektion: Es ist sehr wichtig eine verantwortliche Person zu bennen
25:07 – 5. Lektion: Katastrophen werden passieren – stelle dich darauf ein!

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Also das Gefühl, wenn du so ein Ding gelöst hast. Das ist. Ich weiß es nicht. Ich kann nicht sagen, es ist besser als beim Sex. Aber es ist halt klar, den noch viele ein bisschen Aufregung und Spannung. Endorphine werden ausgeschüttet und wenn es dann gelöst, dass man das Adrenalin weg ist, dann fühlt sich einfach nur so hey, quasi.

Herzlich Willkommen zum Skill bald Podcast Nr. 39 10 Lektionen, die wir in mehr als 40 Jahren Softwareentwicklung gelernt haben. Teil 1 Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld er Entscheider oder die Fachkraft seid. Wenn ihr Hörer Fragen auf der Prisoner habt, sendet uns gerne eine E-Mail an Podcasts. Geh weiter. Bewertet diese Episode gerne mit 5 Sternen und wir uns immer bei Weiterempfehlung an Freunde und Kollegen und schaut auch bei der Skill BYD Jopp Seite vorbei. Ich bin hier heute wieder mit Malaysia.

Hallo Malaysia. Hallo Boris, grüß dich.

Freut mich, dass du da bist und dass wir heute aus deinem ganzen Erfahrungsschatz schöpfen können. Ich hoffe, da bin ich ganz sicher. Ich springe einfach mal mit der ersten Lektion rein und illustrer kurz das Problem und dann können wir gemeinsam darüber sprechen. Die erste Lektion ist Halte die Komplexität in Projekten so niedrig wie möglich. Was bedeutet das genau? Das Problem besteht darin, dass häufig in Projekten alle möglichen Werkzeuge verwendet werden Libraries, alte wie neue. Daraus entsteht eine sehr, sehr hohe Komplexität und ein Wartungsaufwand.

Weil natürlich jede Library dies irgendwann mal ins Projekt geschafft hat, muss mitgeschleppt, gewartet werden, weiterentwickelt werden. Gegebenenfalls. Wenn Sicherheitslücken auftreten, müssen die gefixt werden, was zu einem sehr großen Aufwand bei Versions Upgrades führt. Denn all diese Inhalte, die einmal ins Projekt gekommen sind, die laboris, müssen mitgezogen werden.

Das wird insbesondere dann kritisch, wenn man Komponenten verwendet hat, die aus dem Support raus sind, also die einfach nicht mehr gepflegt werden, weil es sich beispielsweise um eine veraltete Technologie handelt. Ich bin sicher, da kannst du auch eine ganze Menge zu sagen. Leider ja. wÃchentlich wir aber bei dem Lieblingsthema Scrum, wo die Verantwortung ja quasi dem Team obliegt und das Management diesen Prozess komplett vertraut. Nämlich, dass das Team sich selber organisiert. Dass das Team, bevor sie neue Tools und Technologien einführt, sich einig ist.

Ich muss jedem Mensch mit tatsächlichen Augen öffnen sein. Dem ist nicht so. In jedem Projekt, wo ich war, wo das so mal rigoros gelebt worden ist, haben Entwickler Tools Frameworks eingeführt, wie sie wollten. Natürlich, der Entwickler will dazulernen. Das ist auch völlig legitim. Er will mit neuen Technologien spielen. Aber leider hat halt der Entwickler, gerade jüngere Entwickler, nicht dieses Bewusstsein, dass das ja auch später jemand betreiben muss. Jemand muss das verstehen, der, der nach ihm kommt oder wie auch immer.

Das heißt, diese Betriebs Komponente, diese Langfristigkeit hat er leider nicht im Auge, sondern in dem Moment hatte erst mal nur seinen eigenen Vorteil oder seinen eigenen Spieltrieb nachgegeben und das fällt dem Projekt hinterher auf die Füße. Das sind nicht nur Tools. Also es gibt Projekte, wo ich erlebt habe, dass auf ihr für verschiedene Test Frameworks eingeführt worden sind. Im schlimmsten Fall hätte einer nicht mehr erkannt was das sollte und baute sein eigenes Ding. Machen hat seins drüber gestülpt.

Schwuppdiwupp hast du diese 400 Frameworks drin und es ist einfach nur noch Kraut und Rüben. Und das mal der ganzen Komplexität, die jedes Buch für sich mitbringt. Security Patches, Versions Upgrade, was du erwähnt hast und so weiter und so fort. Oder es wurde entschieden. Okay, Kafka ist es cool in aller Munde. Lass uns Kafka, nutze dem Projekt. Dann wurde das einfach eingeführt, dass das jemand betreiben muss, dass da zu einem Kafka viel mehr gehört als in Docker Run.

Das wird halt ausgeblendet. Aber nachher muss die Software drauf laufen. Und wenn dann tatsächlich Probleme auftauchen, blickt keiner durch. Eine schlimmsten Fall ist der, der das einführt. Hat 3, 4, 5, 6 Monate später weg und dann läuft das Ding halt irgendwo.

Ich bin auch auf jeden Fall dafür, dass man so eine Art Architektur Verantwortlichen hat im Team, der die Langfristigkeit der Anwendung im Blick hat, der den Application Lifecycle kennt, also dem bewusst ist Wenn das hier ein Erfolg ist, dann muss das noch 5 Jahre erstens weiterentwickelt werden und dann gepflegt werden und irgendwann ist die heiße Entwicklungsphase vorbei. Dann geht es in den Betrieb und der ist eben nicht mehr so von neuen Werkzeugen geprägt, sondern da kommt es darauf an, dass die Werkzeuge, die man hat, möglichst lange eben supported werden.

Und oftmals kristallisiert sich in einem Team ja schon so jemand raus. Das Problem ist, wenn der formal nicht die Macht bekommen hat. Da kann man gleich noch zu Neiman Lektion zu sagen Okay, so machen wir das. Oder auch die Frage zu stellen Wenn da eine neue Technologie eingeführt wird, was bringt uns das, was kostet uns das? Also ich sehe auch die Lösung dieses Problems darin, dass man als guter Entwickler tendenziell mit möglichst wenig Abhängigkeiten auskommen sollte ein Testing Framework und dann ein möglichst branchenübliche, was halt wahrscheinlich noch lange Unterstützung findet.

Bewährte Tool Scheines einsetzen. Nicht unbedingt das neueste und heißeste, sondern etwas, was es. Einige Jahre gibt und was eine gewisse Verbreitung erfahren hat, dass man halt auch Infos zum Internet findet. Aber dennoch, ich meine, das muss uns ja auch klar sein. Einen gewissen Prozentsatz an neuen Technologien muss man in jedem Projekt einsetzen, sonst würde man ja stehenbleiben. Absolut.

Mir geht es auch weniger so, dass man sie hinterher betreiben kann. Es ist ein Punkt für sich. Ja, aber das größere Problem sich in der Komplexität. Ja, du hast ein System und dieses System hat ne gewisse Entropie. Und jedes Tool, jedes Framework, jedes Stück, was du dazu nimmst, erhöht die Entropie. Das heißt, das System wird komplexer und ihr komplexes wird es. Mehr Manpower Bausumme um das am Laufen zu halten.

Da kann ich wirklich auch aus meiner Historie sprechen in einem Projekt, das es noch gar nicht so lange her. Dann werden auch ich glaube zwei oder drei verschiedene Test Frameworks benutzt, das einem brauch Not und p.m. Als Abhängigkeit, damit es funktioniert. Das andere ist von Java STANDARD Framework und da sieht man richtig die verschiedenen Altersstufen des Projektes, wann mal was Neues probiert wurde. Und das führt dazu, dass irgendwann einer sagt Boah, wir müssen das alles neu machen, weil keiner mehr durchsteigen.

Also halte die Komplexität niedrig. Weniger Komplexität ist meiner Ansicht nach ein Genie Streich. Also jemand, der darauf achtet, da hat man schon so viel gewonnen. Weniger Komplexität heißt weniger Bugs, weniger Probleme, weniger Sicherheitslücken und generell ein besseres Software Verständnis von dem entwickelten Artefakt. Ein Aufschwung aus dieser Lektion hört man z.B. in der Skill BYD Podcast Episode Nr. 18, warum IT-Projekte so teuer sind. Die Komplexität führt nämlich dazu, dass die Preise irgendwann explodieren oder der Aufwand explodiert.

Also für mich bedeutet professionelle Softwareentwicklung auch nicht, jedem Trend ungefragt hinterherzulaufen, sondern primär eine konsistente Architektur anzustreben und Neuerungen gezielt einzubauen. Ich hab mal gelesen, dass man pro Projekt 15 bis 25 prozent an neuen Komponenten einsetzen kann, wo man hofft, dass die möglichst lange gewartet werden. Das wäre dann so ein guter Wert.

Es ist schwierig, das so in Prozenten auszudrücken. Ich glaube, jedes Projekt ist sehr spezifisch. Bei dem einen bedarf es mehr an neuer Technologie. Keine Ahnung. Wenn du sagst, ich möchte jetzt auf Echtzeit Streaming gehen, dann kommt halt nur ein oder zwei Tunes in Frage. Will sagen, es ist finde ich schwer nachzuvollziehen, so Prozentzahlen zu sagen. Drittel der Komponenten sollten neu sein. Also jetzt rein subjektiv. Aus meiner Erfahrung kann ich jetzt nicht an irgendwelche Zahlen festmachen.

Es ist immer individuell.

Das stimmt. Und wichtig wäre noch darauf zu achten, dass wenn man so eine Komponente einsetzt, sondern eine neue Technologie einsetzt, dass es eine saubere Schnittstelle gibt. Wenn du jetzt sagst Echtzeit Streaming, dann gibt’s ja irgendwie ein Interface, um diese Streaming Komponente anzusprechen, dass das halt sauber ist, dass man das nötigenfalls mal wechseln kann. Das sehe ich genauso. Also neue Tools können ausprobiert werden und jeder von uns hat natürlich den Drang, das zu tun und möglichst viele Sachen neu auszuprobieren.

Aber in einem professionellen Projekt muss man das abwägen, ob das wirklich immer sinnvoll ist. Die zweite Lektion stößt ja ein bisschen ins gleiche Horn. Der beste Code ist einfacher Code. Das ist meiner Ansicht nach auch ein Problem, wenn man die Entwickler sich selber überlässt. Also dieses Prinzip do not repeat yourself.

Die R ui, das kennt sie ja bestimmt auch. Das wird ins Extreme verkehrt. Also da werden Konfigurationen über Bilder Patterns gebaut und verschiedene Dinge, wo ein einfaches Textteil gereicht hätte. Ja, weil man diese Konfiguration nur einmal sozusagen einliest und dann nicht mehr braucht. Da werden Konstrukte aufgesetzt, die wahnsinnig komplex sind für eine einfache Sache. Und man guckt mehr darauf, ne Funktion nur wirklich einmal zu implementieren, statt dass man sagt Okay, is of reading ist hier wichtig.

So eine flache Konfigurationsdatei, auch wenn sich da irgendwie einen Wert doppelt. Ja, also Server für Datenbank und Server für sagen wir mal E-Mail ist jetzt vielleicht der gleiche, dann steht zweimal der gleiche Wert da drin, dass man trotzdem die beiden Werte einfach reinschreibt, anstelle dass man die Konfiguration dann wiederverwendet.

Also ich würde tatsächlich auch Einfachheit über Dry favorisieren, wenn es hart auf hart kommt. Sich entscheiden müsse ich mich persönlich immer wiederholen, als das Ganze kompliziert zu machen.

Würde ich auch so sehen. Also es gibt natürlich für jedes Pattern die Entwicklungspfad, dann haben natürlich ein Sinn. Ich möchte hier überhaupt nicht gegen Patterns wettern, aber ich habe es schon gesehen. Statt einer einfachen for-Schleife wurde ein komplexes Producer Consumer Pattern implementiert. Wurde dann irgendwie zehn Werte von irgendeinem Dienst consumers wurden, wo man denkt ja okay, die zehn Werte jetzt auch einfach als Liste übergeben können, da hätte jeder verstanden, was du willst. Und so muss man das erst ausgraben.

Man muss ja sagen, die Idee Unterstüzung ist ja auch tatsächlich so weit, dass sie auch q blöcke wär, wenn du sie wiederholst erkennt das sei es. Sowas lässt sich schneller auffinden, weil Dojo BDO Set kommt er dann zum Tragen, wenn du Code verändern willst? Und muss irgendeine Änderung reinnehmen, dass du seine Stelle machst und an der anderen Stelle vergisst. Hast du ein Bad drin? Sowas lässt die Idee dann schon erkennen, dass das die Unterstützungs entsprechend da.

Das spricht dann für mich auch eher dafür, dass sich das System mir einfacher halte oder mein Boot, als es zwingend unter allen Umständen auf Teufel komm raus diesem Prinzip gerecht werden muss. Genau.

Also ich glaube ein gutes Beispiel für Dohna Creepy yourself wird z.B. die Berechnung der Mehrwertsteuer, die aktuell bei 16 prozent statt bei 19 prozent liegt. Wenn das natürlich komplett durchs Programm verstreut ist, wird es sehr aufwendig, alle Stellen zu erwischen. Da will man natürlich eine Methode haben, die dann überall aufgerufen wird.

Aber gerade bei Configuration Klassen oder Klassen, die so Rest Calls aufrufen oder so. Da kann man sich dann doch sehr Fahrkünste an Was mir zu diesem Thema sofort einfällt ist eher so diese wie sich verschachteln Stream Map Filter Konstrukte über mehrere Zeilen gehen. Das ist für mich ja. Man mag sich dann hip vorkommen, weil man tolle neue Features benutzt hat, die in anderen Programmiersprachen schon länger da sind. Und es mag shiny sein, aber kann man argumentieren wie man will?

Es macht den Code schwer lesbar und das ist es mir definitiv nicht wert. Dann hab ich lieber drei Bout Blöcke, was man einfach lesen kann wie ein Buch statt sich da so einzudecken. Weil es ist ja so, du hast ja eine anonyme Funktion hinter der anderen. Diese Ketten, die aus dieser JavaScript Server Seuche herkommt. Und du musst ja wenn du das bitte folgen willst mit dem Kopf, dann musst du ja quasi ins Deck bilden. Der Rekursive ist und das strengt mich so an und Leute, das hat nix mit meinem Alter zu tun, sondern das ist einfach Mist.

Das fällt jedem schwer, als wenn ich das quasi in einfachen Zeilen hab.

Ja dieser Landa Notation, die verführt halt dazu, dass man immer ach und man filtert das. Achja und dann sortiert man es noch. Achja und dann macht man noch das Ding und dann dies und dann jenes und dann entsteht so eine Kaskade. Und in der Sekunde wo man da drinne ist ist das toll, weil man einfach da so runter schreiben kann. Aber ich hab auch schon mal eine lange Landa Funktion in zwei oder drei Blöcke aufgeteilt, weil ich einfach dann so ein Zwischenergebnis haben wollte und sage Okay, das ist die gefilterte Liste beim nächsten Mal.

Okay, das ist jetzt das tilgte Liste. Okay, das nächste Mal, da sind die gefundenen Treffer drin oder so. Sodass man dir dann eben folgen kann, wenn das irgendeiner mal anfassen muss.

Das ist also sehr richtig gesagt. In dem Moment, wo du selber dich quasi diesem Kontext aufgebaut hast und drin bist, dann lässt sich das relativ einfach runterschreiben. Aber der nächste muss ja auch da rein und der übernächste.

Also meine Regel ist, wenn der Quellcode nicht direkt auch von den Junior Entwicklungs Kollegen verstanden werden kann, was da passiert ist, dann ist er zu kompliziert. Punkt. Also klar, dass man mal ein Pattern erklären muss oder dass man sagen muss Oh, hier hab ich eine neue Funktion benutzt, dies in der neuen Version gibt. Das verstehe ich aber da Verschachtelung Stephen und irgendwelche wilden typisierten.

Ja genau das ist das nächste Ding.

Funktionen, die sich dann selber aufrufen. Ja, dann wird’s ein bisschen zu wild und man muss sagen hör mal, was machen wir eigentlich? Weil meistens mag man ja nur Daten irgendwie aufeinander, wenn man programmiert und arbeitet. Nicht immer Spaceshuttle, Steuerung und auch die Map letztlich nur Daten, auch sehr beliebt.

So typisierte Methoden Rückgabewert mit Wildcards und auch sehr Nies nicht.

Also nochmal Patterns haben natürlich ihren Sinn, aber man muss immer gucken ist das hier die richtige Hammerl Größe für das richtige Problem? Ich glaube das ist ganz wichtig.

Man muss einfach auch an andere denken, die dann kommen, vielleicht nicht nur den Skill Level haben.

Ich habe auch festgestellt, die besten Entwickler wenn eine Lösung entwickelt haben, dann hören die nicht auf und committen das einfach, sondern die lesen das dann nochmal von oben nach unten durch und vereinfachen auch komplizierte Funktionen. Also es gibt diesen Spruch Jeder Schwachkopf kann Dinge kompliziert machen, aber es braucht ein Genie um Dinge einfach zu machen. Und die gehen wirklich nochmal diese extra Runde, dass sie sagen Okay, jetzt hab ich zwar eine Lösung, die funktioniert. Aber was mache ich hier eigentlich nochmal?

Okay, das ist ein Zwischenschritt, der logisch. Das ist ein Zwischenschritt des logisch und zergliedern. Das entweder in einzelne Methoden oder einfach in logische Blöcke. Manchmal recha das Einführen von Leerzeile schon, weil du kennst ja bestimmt zu klickst in einer Datei auf nach so ne Wall of Text 300 Zeilen ohne eine Leerzeile dazwischen. Da denkt man schon Boah, was ist hier passiert? Da ist es wichtig, dass man auch diese logischen gedanklichen Schritte dann eben voneinander absetzt und dann möglichst ein einfachen Fluss hinbekommt.

Da kommen wir zur dritten Lektion und da bin ich ganz sicher, wirst du ganz viel zu sagen können. Die dritte Lektion Gutes Projektmanagement ist wichtiger als das Vorgehens Modell.

Was meinst du damit mit Vorgehens Modell? Das Vorgehens Modell könnte das agile Vorgehens Modell sein. V Modell x t Wasserfall Modell ganz klassisch oder irgendeinen meißtens wenn die Vorgehens Modelle ja nicht in Reinform ausgeführt, sondern es entsteht so eine mehr köpfige Hydra, die sich an allen Vorgehens Modellen irgendwie bedient und dann ein neues Monster erschafft. Nachdem das Team dann arbeitet nein, es soll gar nicht so negativ sein. Also natürlich gibt’s kein Vorgehens Modell in Reihenfolge. Es muss auch immer zur Firma und zum Projekt passen.

Aber ich glaube, nach den Jahren kann man schon sagen, dass man gutes Projektmanagement von schlechtem Projektmanagement unterscheiden kann.

Aber Moriz Projektmanagement gibt’s doch gar nicht mehr. Ist doch alles agil.

Ja, auch ein Kilis Projektmanagement ist ja Projektmanagement. Was ich festgestellt habe ist Es gibt so Projektmanagement, das sich so im Unternehmen entwickelt hat und was dann so implizit durchgeführt wird oder was du von oben aufgestört wird. Agil wäre z.B. ein Beispiel für Da kommt eine Entscheidung und das wird häufig von oben aufge stülpt. Ja, wir haben das jetzt gehört. Wir machen es jetzt alle. Aber diese von oben aufgestellten Modelle scheitern oft an der Realität. Also das agile Paradigma wird ausgerufen, es wird ein Sprint geplant, die Leute fangen an zu arbeiten und nach zwei Tagen kommt jemand rein und sagt Nee, das ist aber jetzt ganz wichtig.

Dann sagt man Ja, schreibs ins Backlog. Gucken wir uns zwei Wochen an So, und jetzt hasst der Lackmustest. Gelingt das jetzt? Oder sagt jemand Ja, Moment. Ich bin aber der Geschäftsführer. Ich will das jetzt sofort. Und so sterben dann die guten agilen Ansätze dann auch ein. Also die verwässern so nach und nach. Ich will das gar nicht so negativ klingen lassen, aber dann landet man meistens bei irgend so einer Zwischenform. Also um Priorisierung von oben.

Notfälle passieren. Naja, Hacker-Angriff, Sicherheitsprobleme. Das Leben bewegt sich ja auch. Es ist ja auch nicht so stark, dass es sich in ein Modell quetschen lässt. Schlüsselpersonen geht. Neue Mitarbeiter kommen, die noch keine Vorkenntnisse haben. Jemand wird krank. All das kann während der Projekte geschehen und es gibt keinen Plan, der alle Eventualitäten abdecken kann. Das ist die Realität. Wie löst man das gut?

Grundsätzlich ist es ja bei dem agilen Vorgehen. Es ist eigentlich eine Wohltat für die bisherige Softwareentwicklung gewesen. Gar keine Frage. Wir alle oder nicht alle? Vielleicht die? Die jüngeren Zuhörer nicht. Dieses Modell, das man sich vorher im Prinzip schon qualmende Ingenieuren, die Anforderungen genau holen musste, niederschreiben musste und abschätzen musste oder Modell Werkvertrag gemacht. Das hat alles nicht funktioniert. Insofern ist agil schon super. Aber ich glaube, dieses so völlig rigorose Agilität, wie das Agile Manifest sagt oder was daraus geworden ist, sag ich mal, das ist totaler Humbug.

Du kannst keinem Management erklären. Pass mal auf. Wir können dir nicht sagen, was es kostet. Wir können dir nicht sagen, wann es fertig wird. Wo hast du sowieso nichts zu melden, außer die Kohle da hinzulegen? Das funktioniert einfach nicht. Selbst wenn das Management von großen Firmen sagt Ja, wir führen das jetzt ein und egal was wir machen, ist agil, agil, agil. Trotzdem fragen sie immer nach Wann ist es fertig? Was kostet das?

Trotzdem wird Projektmanagement nicht mehr gemacht. Man merkt, dass Sie nicht loslassen können. Klar. Ich meine das selbst ich als Softwareentwickler dieses Modell ja mitgemacht hat und sehr froh ist, dass es das auch gibt, sagt. Das ist totaler Quatsch. Entwickler können machen was sie wollen. Hin und her. Das funktioniert einfach nicht. Deswegen vermischt sich das im Moment. Klar, wenn du nur diese Menschen sind, Firmen und Coaches und so weiter. Die verdienen ihr Geld damit, dieses Modell einzuführen.

Aber aus der Praxis, so wie ich es erlebe, entsteht irgendwie eine Mischform. Dadurch aber, dass diese Mischformen links beschrieben ist, vermisse ich das Alte mit dem Neuen. Und da kommen ganz komische Konstrukte raus. Mein Punkt ist jetzt gar nicht mal so finanziell und Management und Zeit, Berechnungen usw. Also auch das werden mit Sicherheit 99 prozent der Zuhörer zustimmen. Irgendwie schleicht es sich ein, dass die Komplexität Punkte plötzlich in Tagen weiter kommuniziert werden. Aber mein Punkt ist rein technisch im Moment.

Und dass sich diese Architektur Thema, dieses Setzen eines Rahmens, in dem man sich frei bewegen kann und nicht einfach blind vertrauen und sagen, dass die Macht es schon. Ah, braucht das Team einen Rahmen. Es fühlt sich wohler. Der Entwickler fühlt sich wohler, wenn ein Rahmen, in dem er sich bewegen kann, im Grunde wie ein Bauplan auf der Baustelle.

Na, da baut ja auch nicht einfach jeder drauflos, wie er lustig ist, sondern es gibt einen großen Plan und das so muss das am Ende zusammenpassen.

Genau, du gehst ja auch nicht, wenn du ein Haus bauen willst und schmeiß irgendwie schon haben wir kein Geld ins Gesicht und sagt so guck mal wir das OP’s aufbaut. Nee, du gehst mal schon denken als erstes. Genauso ist das mit der Softwareentwicklung. Es ist auch sehr schwer, wenn du als Dienstleister, was wir hier sind Verträge machen wollen. Weil wenn ich dem Kunden komme, sagt Ja. Wir arbeiten zwar als verlängerte Werkbank, das ist unser Modell, das nach timen Material.

Aber wenn wir Projekte machen und ich sage agil, dann kommen genau diese Fragen. Und wenn ich dem sage, jetzt mal nichts zu sagen, wir machen das und du kannst nur sagen Stopp nach allen 14 Fahnenmeer und Sprint Review hast. Mit dieser Zeit kannst du das Projekt stoppen. Toll. Deswegen entstehen diese Mischformen und auch Verträge. Was wir machen ist dann kein Dienstleistungs Vertrag, kein Werkvertrag, sondern agiler Vertrag. Also dieses Konstrukt gibt’s tatsächlich, wo man gewisse Rahmen festsetzt.

Ich hoffe, das wird noch ein bisschen dauern, bis das, was ich jetzt gerade sage, den Unternehmen auch tatsächlich bewusst wird und man erkennt. Rein so agil, wie es Groom oder diese Coaches einem propagieren, so geht’s einfach nicht. Das wird früher oder später kommen, spätestens wenn dann Projekte zeitlich und finanziell aus dem Ruder laufen. Wenn man sich wieder fragen warum, wieso, weshalb? Und dann, wenn das Argument auf den Tisch kommt, dann überlegt man sich etwas Neues.

Also das beste Projektmanagement, was ich erlebt habe. Es hat total problemorientiert. Das guckt wo sind die Stolpersteine oder was steht uns im Weg, was steht unserem Erfolg in weg und kümmert sich darum? Also es räumt im Grunde einfach nur Hürden aus dem Weg und lässt dem Team schon viel Autonomie. Aber kommuniziert die Ziele immer sehr klar. Also da wollen wir hin, da wollen wir hin. Da wollen wir hin und alles, was da im Weg steht. Probleme müssen gelöst werden.

Leute müssen überzeugt werden und darum kümmert sich das Projektmanagement. Und auf der anderen Seite schützt ist das Team, das das Team in Ruhe arbeiten kann und nicht in endlosen Meetings Runden verhaftet wird, um alle Stakeholder, die es irgendwie geben könnte, abzuholen. Das sind die effektivsten Projekte, in denen ich bisher gearbeitet habe, wo man einfach gesagt hat Okay, wir räumen alle Probleme aus dem Weg. Ihr könnt in Ruhe arbeiten, natürlich alle zwei Wochen oder je nach Sprint Ende wird gezeigt, woran ihr gearbeitet habt.

Und dann sagt der Kunde, wohin es als nächstes geht. Natürlich gibt’s so einen groben großen Plan, was man erreichen möchte. Mit den Schlüssel Features. Aber das war sehr zielorientiert und die Projekte, die ich so gemacht habe, waren sehr erfolgreich. Vielleicht können wir hier auch festhalten. Also das ist so mein Fazit aus dem Punkt gutes Projektmanagement. Wenn Projekte scheitern. Ich hab das noch nie erlebt, dass ein Projekt, eine Technologie scheitert, weil irgendwas nicht gegangen wäre oder so vielleicht.

Bei Raumfahrtunternehmen ist das so. Aber ganz oft sind es menschliche Faktoren, Firmenpolitik oder einfach nicht gut durchgeführtes Projektmanagement, wo dann hinterher das ganze Team demotiviert war. Das sind so die Gründe, warum Projekte scheitern.

Meiner Ansicht nach ja, ist schon so. Aber ich hatte auch. Also muss ich wirklich hervorheben einige Projekte, die wirklich super erfolgreich waren, wo gutes Projektmanagement stattgefunden hat, wo dem Team der Rücken gestärkt wurde und alle Probleme organisatorischer Art eben aus dem Weg geräumt wurden. Also super klasse gelaufen, muss ich wirklich sagen. So ein bisschen in die dritte Lektion Gutes Projektmanagement spielt die vierte Lektion hinein, würde ich sagen. Die ist nämlich Es ist sehr wichtig, eine verantwortliche Person zu benennen.

Was ist das Problem? Also das kennst du bestimmt auch bei Retro oder auch so werden Missstände benannt, was vielleicht nicht so toll ist, was man besser machen kann. Dann gibt’s eine Diskussion im Plenum, da spricht man darüber und dann wird darum gebeten, meistens von höherer Stelle, dass sich darum gekümmert wird, ohne explizit eine Person zu benennen. Vielleicht wird sogar noch ein Ticket erstellt im Backlog. So, und das wars. Und bitte kümmert euch darum.

Heißt für mich Keiner kümmert sich darum. Gerade wenn das ein heißes Thema ist. In erfolgreichen Projekten, so ist es meine Erfahrung, wird eine verantwortliche Person benannt, wenn das Thema wichtig ist. Wenn ein Thema nicht wichtig ist, dann wird keine Person benannt, aber dann braucht man es auch nicht aufschreiben. Und diese Person ist dann dafür verantwortlich, dass dieses Thema weiterverfolgt ist und hat dann die Themenführerschaft da drüber und kümmert sich auch. Und das ist gar kein Fingerprint Ding, das man sagt Okay, du kümmerst dich jetzt darum.

Sondern jeder hat ein paar Themen, für die er verantwortlich ist. Dadurch entfällt diese ganze Fragerei, wenn irgendwie Probleme in einen gewissen Themenkomplex fallen. Man weiß sofort Aha, Person X oder Epsilon ist dafür verantwortlich. Brauch halt nicht weiter zu fragen, hat sofort einen Ansprechpartner. Auf der anderen Seite hab ich ja selber drei Themen, für die ich verantwortlich bin, sodass da auch kein Ungleichgewicht entsteht. Ich weiß nicht, wie hast du das erlebt? Also auch da ist ja das Team kümmert sich.

Also wenn wir es beim Business-Modell Scrum bleiben, heißt es ja, das Team ist eigenverantwortlich und wenn ich eine gute Durchmischung hab von jüngeren und erfahrenen Entwicklern, dann erfolgt quasi alles im Team. Und die sollen sich selber organisieren. Faktisch aber auch jetzt organisatorisch, innerhalb. Selbst wenn man das Modell macht und man im Team Dinge bespricht, ist es ganz wichtig für jedes Thema Verantwortliche zu benennen. Das ist ja dieses Prinzip. Ja, das hat eine andere schon mal vielleicht gehört.

Ja, wenn du in einer Menschengruppe unterwegs bist und irgendeiner hat einen Herzinfarkt, wenn du sagst Kann jemand mal einen Arzt rufen, macht es am Ende keiner, weil sich jeder von anderen verlässt. Aber wenn du dann jemanden anguckst und sagst, kannst du einen Arzt rufen, dann ist die Wahrscheinlichkeit viel größer, dass derjenige oder vielleicht wenn du dir selber bis überlebt.

Genauso ist es in IT-Projekte vielleicht nicht weniger dramatisch. Man braucht vielleicht nicht so oft ein Arzt, wobei das auch vorkommen kann. Je nach Katastrophen Lage. Ja. Oh mein Gott, ich seh gerade das war ja ein wundervoller Übergang. Die fünfte Lektion Katastrophen werd passieren, stell dich drauf ein. Da können wir jetzt ja mal wirklich von ein paar Katastrophen erzählen, die wir bisher erlebt haben. Ich fange mal von meiner allerersten Katastrophe an, da war ich noch Student und hab.

Eine Webseite betreut und hub zu einem gewissen Zeitpunkt des Vormittags Club zehn oder elf Uhr morgens ein Update gemacht. Dieser Webseite und die Webseite gehört einen riesigen Dax-Konzern habe das Update eingespielt. Okay, und auf die Webseite und drücke 5 aus passiert gar nichts. Und das Rad dreht sich und das Rad dreht sich und das Rad dreht sich. Ich drück nochmal 5! Das Rad dreht sich, das Rad dreht sich. Man geht auf Google um zu gucken. Hat der Rechner kein Internet oder sowas.

Alles funktioniert. ernÃhren, Webseiten funktionieren. Nochmal zurück auf die eine Webseite Rad dreht sich das Rad dreht sich, kommt keine Webseite. Da wurde mir heiß, kalt, heiß, kalt in schneller Folge mich aufgestanden und zu meinem Manager gegangen und hab gesagt Hammerl, ich habe gerade in D dein Schild an die Webseite lädt nicht mehr und er macht seinen Browser auf, geht auf die Webseite und das Rad dreht sich. Das Rad dreht sich und das Rad dreht sich.

Das war so wie im Trance, muss ich wirklich sagen. Ich war total. Oh mein Gott, was soll ich machen? Und dann griff er zum Telefon, auch relativ hektisch dann und hat wild rum telefoniert. Wahrscheinlich hat es nur 10 Minuten gedauert, aber für mich gefühlt ne Ewigkeit. Und dann hat der Kunde angerufen und gesagt, dass er gerade eine Wartung von diesem Server macht, wo ich gerade drauf wie Pleul hatte. Ich war also gar nicht schuld.

Es lag gar nicht an meinem Release, sondern der Kunde selber hatte den Server neu gestartet und dann auch noch in andere Firmen auf diesem Server drauf. Also es war quasi eine kurze Downtime von paar Minuten, wo ich nichts konnte, weil ich einfach nicht wusste, dass da jetzt durchgestartet wird oder so. Das heißt, am Ende war ich nicht schuld, aber das will ich nie vergessen. Das war für mich eine Katastrophe und das wäre auch für die kleine Firma, für die ich damals gearbeitet habe, eine Katastrophe gewesen.

Am Ende des Tages ist alles gut ausgegangen, aber das weiß ich noch ganz genau. Das war so die erste Feuerprobe. Und ich bin sicher, jeder Entwickler kennt diesen Moment und kann von anderen Situationen erzählen, wo dieses Heiß kalt Gefühl aufgekommen ist. Also was ist die Lektion hier? Trotz aller Vorbereitung wird es irgendwann zur Katastrophe kommen. Downtime ganzer Produktionssystem durch Softwarefehler oder Datenbank Updates schlecht reproduzierbare Bugs. Ich weiß, wir haben mal in einem Projekt zusammen gearbeitet, da es alle sechs Wochen ein komplettes Rack ausgefallen.

Das inklusive braucht ein BIOS Update oder so. Aber wahnsinnig aufwendig zu reproduzieren. Und jedes Mal wenn der Fehler aufgetreten ist, ist das ganze System abgestürzt, sodass ein riesen Impact hatte. Datenverlust, Hardware, Defekte alles schon dagewesen. Betrug, Hacking, Diebstahl, DDoS also das wird passieren, da muss man darauf vorbereitet sein. Was war deine Katastrophe in jüngster Vergangenheit oder die größte, die du je erlebt hast?

Also ganz ehrlich, ich kann nicht sagen, es war jetzt eine große Katastrophe hier oder da. Der ganz normale Wahnsinn. Solche Ausfälle hier, da. Oh Gott, unser Gitt baut nicht und oh Gott, unsere Produktion Server ist down. Das ist eigentlich Normalität, dass das kommt. Ich muss ganz ehrlich sagen, es ist nichts dabei, was mich geschockt hätte. Ja so! Gerade wo ich angefangen hatte. Und so dachte ich Jo, hier in IT-Systemen.

Alles Ingenieure und komplexe Systeme. Wenn das läuft, dann läuft und da passiert nix. Wurde erst in ein, zwei Mal Sucks, du bist hier abwanderten. Also das ist wie Hartmut weißt. Klar werde ich nie vergessen. Irgendwie bei der großen Systemhaus am Anfang, wo wir Mailserver betreut haben für Kanal so 20000 Leute und die konnten keine Mails verschicken. Da ist gezittert und bibbert. Aber es kam danach noch schlimmere Dinge hinterher.

Wenn das Problem gelöst ist, kann man darüber lachen. Aber in dem Moment, wenn man nicht weiß, woran es liegt.

Es ist schon also das Gefühl, wenn du sunde gelöst, dass das ist. Ich weiß es nicht. Ich kann nicht sagen, es ist besser als beim Sex.

Aber okay, ja, ich weiß, was es so weit kommt sich vor wie Superman.

Ja, auf jeden Fall. Es ist halt klar die Endorphine, ein bisschen Aufregung und Spannung, Endorphine werden ausgeschüttet und wenn es dann gelöst und das andere Adrenalin weg ist, da fühlt sich einfach nur so Hey Vasile, das Widersprüchliche hier an der Lektion ist ja, dass die Unternehmen oder gerade auch Großunternehmen einen unglaublichen Aufwand betreiben, dass es eben nicht dazu kommt.

Also viele Back ups, redundante Systeme, 24/7 Support. Und trotzdem Irgendwann bist du fällig. Irgendwann passiert die Katastrophe. Ich weiß nicht. Gerade wenn man ein System schnell weiterentwickelt. Irgendwo ist ein Fehler drin, den keiner bedacht hat. Ob es ein Schaltjahr ist, das hatte ich auch mal bei einem System. Da fehlte der letzte Tag, weil das Jahr 366 Tage hatte statt 365. Das war nicht bedacht worden. So konnte am letzten Tag keine Buchung erfolgen.

Das sind alles so Dinge, die können passieren und das Wichtige ist, damit zu rechnen. Ich finde, daran erkennt man immer so supergut den Unterschied zwischen Junior Developer und Senior Development, weil da passiert das, was du beschrieben hast. Die einen haben die Hornhaut, die anderen haben die noch nicht. Pferde Junior Developer ist so wie ich damals schweißnass gebadet. Völlig paralysiert und weiß nicht, was er machen soll, und der Senior Developer zieht die Handschuhe an und greift ins Feuer.

So ungefähr. Bleibt ruhig. Okay, das Kind ist jetzt im Brunnen gefallen. Welche Optionen haben wir? Was können wir machen? Was man die letzten Schritte, die du getan hast? Welchen Impact hat das im Grunde? Wie gehen wir jetzt vor? Natürlich zügig, aber diszipliniert wird an einer Lösung gearbeitet.

Und das ist auch sozusagen die Lösung dieser Katastrophe. Das ist auch ganz wichtig, dass das Management mitspielt. Task Force zusammenstellen, alles stehen und liegen lassen und sich um das Problem kümmern. Den Rücken dieser Task Force freihalten. Ja, vielleicht alle paar Stunden mal den Status abfragen, damit man das entsprechend kommunizieren kann. Richtung Vorstand oder Kunden, den Fortschritt und das aktuellen Problem Status Monitoren. Was kann man machen? Wo befinden wir uns und wirklich sehen, dass das Team die volle Konzentration auf das Problem werfen kann und nicht gestört wird?

Kein Telefon und so weiter. Also außer zur Problemlösung dann erlaubt und auch dem Team dann die nötigen Ressourcen, also Experten z.B., die sich mit einer Technologie ganz besonders gut auskennen, die dann eben Hilfestellung geben können, in kritischen Situationen zur Verfügung stellen. Und Annas Team muss man einfach sagen Bleib dran, ihr müsst durchhalten. Es gibt ein tolles Zitat von Winston Churchill. Das fällt mir in diesem Zusammenhang immer wieder ein If you going to hell, keep going.

Also nicht stehenbleiben, weitermachen, dranbleiben, das Terrier gehen, auspacken und einfach weiter daran arbeiten, bis das Problem gelöst ist. Und unterwegs Schadens Minimierung betreiben. Natürlich.

Aber ich kann es immer noch nicht glauben. Du hast keine Katastrophe erlebt.

Nee, ich überlege echt die ganze Zeit. Aber wie gesagt, es ist halt relativ Katastrofe.

Also ich weiß, dass wir schon in Projekten gearbeitet haben, wo Leute panisch über den Flur gelaufen sind, weil die Webseite offline war. Wenn das dich nicht aus der Reserve gelockt hat, dann hast du auf jeden Fall mehr Hornhaut als ich.

Die Sache ist eine Sache der Perspektive. Willst du brauchst einen kühlen Kopf bewahrt.

Ich weiß, einmal ist ein Manager aus dem Urlaub zurückgekommen, hat sein Notebook eingesteckt, dann auf dem Notebook lief noch irgendwas Server Komponente vom Produktiv System, die in der Entwicklung dann noch gestartet war und dann klappt das Notebook auf. Und dadurch, dass er eine Zeitlang im Urlaub war, zieht das Notebook alle Events von Zeitpunkt. Ich gehe jetzt in Urlaub bis Zeitpunkt. Ich bin wieder da. Nach dem Produktionssystem und blockiert das ganze Produktionssystem stundenlang und keiner wusste, woran es liegt, weil keine Änderung erfolgt ist, außer dass dieser Mensch aus dem Urlaub zurückgekommen ist, was man ja auch erst nicht weiß.

Das war auch eine heiße Phase, diesen verkehrssicher auf Rädern, weil sie rausgefunden haben, da haben nicht wir geschwitzt, da hat er dann geschwitzt, aber das weiß man dann erst nicht.

Es sind einfach so Sachen. Technologie ist manchmal wunderbar wie Magie und manchmal auch sehr einfach. Und sehr dumme Fehler passieren. Das muss man auch sagen. Na ja, ich freue mich, mit dir im zweiten Teil über die Lektionen 6 bis 10 zu sprechen, nachdem wir jetzt die Lektionen 1 bis 5 durchgegangen sind.

Ja, sehr gerne freue ich mich auch. Bis dahin ganz schön nochmal überlegen, ob wir noch ähnliche Katastrophen erleiden wollen.

Genau da greifen wir den Faden wieder auf und machen noch so einen Marsyas Katastrophen Blog am Anfang. Sehr schön bin ich gespannt, wo die die meiste Hornhaut gewachsen ist. Wenn unsere Zuschauer Fragen haben oder Feedback zur aktuellen Podcast Episode, können Sie uns eine E-Mail schreiben an Podcasts. Geh weiter. Wir freuen uns immer über Bewertung oder Weiterempfehlung des Podcasts an eure Freunde und Kollegen. Schaut darauf, dass Gilbert Jopp Seite vorbei. Wenn ihr mehr spannende Technologie Themen lesen möchtet, schaut auch auf der Skjelbred Website Slash Blog vorbei und abonniert natürlich unseren Podcast.

Ja, es war wie immer eine Freude. Ich wünsche noch einen schönen Abend.

Bis dahin.

Maurice KnoppSkillbyte Podcast #39: 10 Lektionen, die wir in 40+ Jahren Softwareentwicklung gelernt haben (Teil 1)
Mehr

Skillbyte Podcast #33: Traumjob IT?! – 10 Dinge die dir keiner sagt!

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Traumjob IT?! – 10 Dinge die dir keiner sagt!

// Inhalt //
01:52 – Punkt 1: Verstehe das Problem exakt BEVOR du eine Lösung konzipierst
07:09 – Punkt 2: Wie du eine Problem löst, ist meist zweitrangig
10:56 – Punkt 3: Du liest mehr Code als das du schreibst
14:31 – Punkt 4: Nach Abschluss der Entwicklung, startet die Entwicklung er richtig (aka Softwareprojekte sind nie fertig)
19:21 – Punkt 5: Du verschätzt dich beim Entwicklungstempo – IMMER!
23:56 – Punkt 6: Es wird sehr stressige und extrem ruhige Phasen geben
28:19 – Punkt 7: Mit weitreichenden Rechten, kommt große Verantwortung
33:42 – Punkt 8: Du wirst eine Menge Spaß haben und viel lernen!
36:31 – Punkt 9: Du wirst unglaublich schlaue Leute treffen; (sind besser als du)
39:05 – Punkt 10: Du verbringst sehr viel Zeit mit Detailproblemen

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Man muss sich ja vorstellen, man selber hat vielleicht Stunden an der Tafel gestanden, um die Prozesse durch zu planen und jetzt kommt der Computer hin und kann diese Prozesse tausendfach millionenfach pro Sekunde ausführen und Zehntausende, hunderttausende Nutzer gleichzeitig versorgen mit den Prozessen, die man sich selber überlegt hat. Ich finde das nach wie vor auch nach 15 Jahren noch immer ein ganz besonderer Moment wie bei Cast Away. Ich habe Feuer gemacht.

Herzlich Willkommen zu unserem skillbyte Podcast Episode Nr. 33 Traumjob IT 10 Dinge, die dir keiner sagt. Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld. Wenn ihr Entscheider oder IT-Fachkräfte seid, wenn ihr Hörer Fragen im Verlauf des Podcasts habt, sendet uns gerne eine E-Mail an Podcast Skill D Wir freuen uns auch immer über Bewertungen oder wenn ihr den Podcast Freunden und Kollegen weiter empfehlen. Heute bin ich mit einem ganz besonderen Gast hier am Start.

Meinem Bruder Nikolai. Hallo Nikolai, hallo Maurice. Nikolai und du arbeitest ja auch für einen großen internationalen Softwarekonzern und ich bin sicher, dass die 10 nachfolgenden Punkte uns beiden seit vielen Jahren mehr als geläufig vorkommen werden. Ja, auf jeden Fall. Wie lange arbeitest du im IT-Bereich jetzt auch schon?

Ja, tatsächlich arbeiten seit knapp acht Jahren knapp acht Jahren. Wahnsinn, wie die Zeit vergeht. Unglaubliche acht Jahre. Klingt irgendwie gar nicht so lang. Aber wenn man mal überlegt, wie lange acht Arbeitsjahre sind, dass es auf einmal schon wieder eine ganze Menge.

Bei mir waren es letztens 15 Jahre und da habe ich auch schon gedacht Oh mein Gott, das ist auch ne ganz schöne Zeit. Viele Probleme haben sich verändert in der Zeit, aber viele grundlegende Konzepte sind auch gleich geblieben. Was auch schön ist im schnelllebigen IT-Bereich, dass sich nicht alles von heute auf morgen verändert.

Nein, es ist interessant, wie sich die eigene Perspektive auf dieselben Dinge in der Zeit verändert. Absolut. Möchtest du mit dem ersten Punkt beginnen? Aber sicher. Verstehe das Problem exakt, bevor du eine Lösung konzipiert. Ach, die Beispiele sind endlos. Ein kleines Beispiel Als Praktikant habe ich damals eine kleine Aufgabe zur Implementierung einer Web API gekriegt. Die hatte so zirka zehn Befehle, die abgebildet werden mussten in Python und ich dachte Oh, da kann man doch mit Sicherheit aus der Beschreibung der API von der Webseite automatisch die Methoden generieren.

In Python ist ja alles dynamisch. Geil machst du das. Wenn dann nämlich noch irgendwas dazukommt in der Zukunft, dann muss man einfach nur Copy Paste machen. Und dann sind die neuen Methoden auch direkt drin, ohne dass man weiteren Code schreiben muss. War vielleicht eine ganz tolle Idee, wenn man an der Uni irgendein Quiz lösen möchte. Aber für diese API, die sich nie wieder verändert hat und die eigentlich nur so an einem Nachmittag implementiert werden sollte, habe ich dann halt zwei Wochen dran gesessen und hatte am Ende eine total verschnörkelt Lösung, die auch an sich nur noch ich dann wirklich pflegen konnte.

Also super Ding, was sich unersetzlich gemacht bei deiner eigenen Aufgabe.

Es war hervorragend und es hat dann zwar am Ende funktioniert, aber ich habe viel zu lange gebraucht und es war auch einfach eine Ende schnoddrige Lösung. Aber sie hatte ne coole Idee.

Es war halt irgendwie so richtig schöner Schnörkeln und ich hab mich dann auf dieses wackelige Konstrukt darunter gesetzt, statt es einfach beide Burk zusammen zu schmeißen. Und es funktioniert und nie denkt wieder jemand drüber nach. War mir ziemlich sicher. Da hat so ein oder anderer noch ganz schön lange drüber nachgedacht und mich verflucht, als ich weg war. Ja, ich finde das ist so ein Punkt. Da sieht man ein bisschen die Seniorität des Entwicklers. Also man sieht sofort, ob die Leute sich direkt in die Lösung stürzen, die nicht vielleicht die ganzen Anforderungen verstanden haben, sondern direkt losstürmen an die Tastatur und anfangen Code zu schreiben.

Oder die Leute, die sie schon sehr lange machen. Meiner Erfahrung nach. Die stellen erst einmal sehr viele Fragen, also teilweise richtig lästig, viele Fragen für die Fach Seite oder für die anderen Kollegen, die, wenn sie zum Beispiel zu einem Team hinzu stoßen Warum machen wir das? Welchen Nutzen hat das? Welchen Vorteil bringt das? Warum nutzen wir nicht einen STANDARD, den alle schon benutzen? Warum machen wir das selbst also wichtig? Bohren Und früher, als ich angefangen hab, hab ich gedacht, das sind die Verweigerer und Meckerer.

Mittlerweile sehe ich das ganz anders. Java Mit vielen Fragen tötet man halt auch ein Projekt dann oder schnelle Entwicklung. Aber es ist ganz entscheidend, dass man weiß Was möchte ich denn hier eigentlich lösen? Ändert sich die RPI noch? Ja? Nein. Hätte man da vorher drüber nachgedacht, ist das jetzt eine ganz wichtige Information. Also Erweiterbarkeit. Wer setzt das ein? Erwarte ich 100 Requests am Tag da? Oder 10 000 pro Sekunde? Das sind ja alles Parameter, die es zu bedenken gilt und sich wirklich intensiv mit dem Problem auseinanderzusetzen, um dann zu sagen Okay, ich hab jetzt verstanden, was sie eigentlich wollt, wie eine Lösung aussehen muss und dann erst anfangen, diese Lösung zu entwickeln.

Also in der Skorbut Podcast Episode Nummer 9 Bulls Software Development gehen wir da auch schon ganz im Detail drauf ein, aber ich halte das für ganz, ganz wichtig und auch wie du das sagst.

Das sind die Verweigerer usw.. Wenn ich da an meine jetzt wirklich noch nicht lange Karriere zurückdenke am Anfang dachte ich mir Fragen stellen, da kommt man dumm rüber oder man weiß es ja nicht. Und jetzt denke ich immer die Leute, die dann mit so einer Frage so richtig in den Kern dessen, was ich übersehen hab, rein schießen. Ich liebe es mit Menschen zu arbeiten, weil da hab ich mir wochenlang oder im schlimmsten Fall mir und anderen Leuten wochenlang die falsche Richtung gehen erspart.

Einfach weil jemand die richtige Frage gestellt hat und keine Angst hat, die zu stellen.

Das muss natürlich auch die Situation hergeben, dass man so mutig ist und auch die unangenehmen Fragen stellen kann.

Und ich hab ein paar Kollegen, die haben das zur Perfektion getrieben. Wenn die irgendwie zu einem Design was fragen dachte am Anfang war Boah er die hassen mich, weil die wollen mich einfach. Kriegen, weil die auf jeden Fehler eingehen und inzwischen weiß ich, dass diese Menschen Schätze sind, weil sie sofort sagen Das ist unklar oder Das kann so nicht funktionieren. Sie attackieren mein schlechtes Design und nicht meine Persönlichkeit und das hat lange gedauert, bis ich das gemerkt habe.

Aber ich finde es endlich wertvoll und halt diese Fragen auch fragen zu können und sie zu erkennen.

Was ich als Hinweis hier noch geben kann, ist. Ich bin ein sehr grafischer Typ und habe auch festgestellt, dass das interdisziplinären Teams oder Teams mit sehr unterschiedlichen Wissen ständen. Auch hilft ist, sich einfach mal die Problemstellung zu verbildlichen. Also entweder an einer Tafel oder jetzt wo alle im Homeoffice sind. An so einem Online Whiteboard oder auch bei so einem Diagramm Tool also Druckpunkt AIO z.B. ist ein Online Diagramm Tool, wo man dann eben gemeinsam Diagramme erstellen kann, um einfach das Problem die einzelnen Fälle, die Unterscheidungen durchzugehen und möglichst viel von dem Problem zu verstehen, bevor man eben eine Lösung implementiert und konzipiert.

Weil die Lösung ist dann idealerweise sehr viel weniger Code und das freut mich auch wenn ich Softwareentwickler bin. Sehr viel weniger Kodes und weniger Backs ist weniger Wartung ist bessere Software wie z.B. eine automatische AWI Pasing Schnittstelle ist bei uns ähnlich.

Man schreibt oft bei komplexeren Sachen erst einfach Design Document. Und das wird dann könnte jetzt sagen zerrissen oder reviewed. Und diese ganzen Diskussionen schleifen sparen dann einfach viel Zeit, weil am Ende schreibt man genau das, was man denkt, was man braucht. Und das kann sie im Nachhinein dann immer noch zeigen, dass man etwas übersehen hat. Aber es ist so viel weniger vergeudete Zeit, auch wenn man vielleicht im Design Review eine Woche gebraucht hat. Aber dann weiß man das wäre vermutlich, wenn er sonst drei Monate Implementierung für die Katz gewesen.

Der zweite Punkt, wie du ein Problem löst, ist meist zweitrangig. Der konterkarierte jetzt ein bisschen in erst, sehe ich. Aber es gibt immer Umstände, Zeitdruck, Kostendruck. Gewisse Schlüsselpersonen mit Fähigkeiten, die gebraucht werden, sind gerade nicht da, die dazu führen, dass man auf sehr kreative Art und Weise ein Problem löst, was so nicht unbedingt vielleicht ins Lehrbuch schaffen sollte. Aber solange die Lösung funktioniert, wird sich außerhalb der IT niemand darüber aufregen.

Ist meine Beobachtung aus meiner Zeit.

Ja, oft stimmt das. Also ich denke, es kann einem das gleiche Problem mehrfach begegnen. Aber es ist nicht unbedingt immer die gleiche Lösung, die man dann braucht. Weil wie du schon sagst manchmal für die richtige Lösung sind die Personen oder die Ressourcen nicht da. Ich würde sagen, es ist zweitrangig, ob man das jetzt nach dem Lehrbuch macht. Das ist oft nicht das, was man braucht, aber es ist halt genau, dass man auch abschätzt.

In welchem Kontext brauche ich diese Lösung? Brauche ich jetzt einfach nur eine kurze kleine Lösung, die dieses Problem, was ich jetzt habe, aus dem Weg räumt? Oder wenn ich damit fertig bin, kommt der nächste. Dann kommt der Nächste. Meinst diese Broken window Theorie? Also eine Unsauberkeit zieht die nächste an, zieht die nächste an, zieht die nächste an und irgendwann kannst du das ganze Projekt wegschmeißen, weil es so kaputt gehuscht wurde, dass man es neu schreibt.

Ich finde neu schreiben nicht schlimm. Es gibt Leute, die fürchten sich sehr davor. Ich denke, dass man jede Software, die sich hinreichend bewährt im Einsatz und die sich weiterentwickelt, weil sie einfach ein wertvolles Problem löst, irgendwann neu geschrieben werden muss. Weil man einfach zu einem gegebenen Zeitpunkt, wenn man sich Jahre schon mit dem Problem beschäftigt hat, viel mehr weiß als zu dem Zeitpunkt, als die Software ursprünglich entwickelt wurde. Man hat das Problem einfach besser verstanden.

Da sind wir auch bei Punkt 1 wieder und da kann dann eben eine bessere Lösung implementieren.

Aber wie gesagt, man muss gucken, quick and dirty ist oft gut, aber man möchte halt auch nicht ein Problem für andere Leute hinterlassen. Aber ich habe oft gesehen, dass es so ganz nach dem Lehrbuch machen different man sich oft in Probleme, die man sonst nicht hätte. Genau.

Und Hauptsache es funktioniert. Ich möchte vielleicht mit einem Negativbeispiel den zweiten Punkt abschließen, und zwar, dass ist wirklich jetzt schon viele Jahre her. Also bestimmt 12 oder 13, da gab es eine Änderung in einer Software. Es war eine Website und das System in PHP geschrieben und ich sollte die Erweiterung machen und stieß im Source Code auf eine IF Abfrage und da stand wirklich sowas wie if I die gleich 214 und dann Block und da drüber stand ein 5 heiliger Kommentar.

Sorry, sorry, sorry ich weiß, das ist total dreckig was ich hier mache, aber ich habe in 2 Stunden 3 Wochen Urlaub und ich kann mich jetzt echt nicht damit beschäftigen, das hier sauber zu lösen. Entschuldigung für denjenigen, der das hier mal finden wird. Immerhin ehrlich, immerhin ehrlich nicht unbedingt toll, aber es ist mir im Gedächtnis geblieben. Auf jeden Fall. Und die Lösung lief zu dem Zeitpunkt. Ich glaube schon. 3 Jahre. Also das ist ein Extrembeispiel für sollte nicht ins Lehrbuch.

Funktioniert irgendwie und keiner köpft einen sofort. Aber vielleicht 3 Jahre später holt einen ein.

Wobei da jetzt auch da fühle ich mich verpflichtet aufzuweisen. Nochmal. Der Kontext ist ganz wichtig. Im Bereich Security ist in der Regel das Lehrbuch der richtige Weg, weil wenn es funktioniert, ist es nicht unbedingt immer noch sicher. Das ist ja auch offen, wenn jetzt Internet of Things usw. deswegen in manchen Bereichen, also hab ich für mich daraus gezogen, ich weiß. Hab ich zu wenig Ahnung. Deswegen versuche ich mich da gar nicht erst dran. Außer ich nehme irgendeine fertige Lösungen aus dem Schrank.

Genau da wäre die gleich 214 glaub ich. Wenn das im Anmelde Prozess ist, hätte ich da bissi Bauchschmerzen.

Security ist so ein Thema, wo man auch das Problem ganz genau verstehen sollte, bevor man irgendetwas macht. Und Security. Ich glaube das ist so ein Thema. Entweder du widmest dem dein Leben oder du nimmst, was andere clevere Leute, die diesem Thema ihr Leben widmen, bereits produziert haben. Dritter Punkt.

Du liest mehr Code als du schreibst. Ja, das ist auch. Außer man fängt bei Null an, weil man gerade Ich nehme mal an, ich habe noch nie ein Startup gegründet, aber ich denke, wenn man mal mit einem Projekt von Null anfängt und es ist noch gar nichts da, dann schreit man vielleicht tatsächlich mehr als man liest, bis die ersten 2, 3, 4, 5 Mitarbeiter oder Mitarbeiterinnen dann auch daran rumpfuschen, weil dann liest man ja auch deren Zeug.

Ich glaube sogar am zweiten, dritten Tag liest du schon mein Herz, dass du schreibst, weil du ja wieder liest, was du gestern geschrieben hast, damit du das wieder verstehst und dann da weitermachen kannst. So ist das gedacht.

Ja gut, dann wäre es jetzt gut. Chris von tÃnt fast Fingers, da war ich zu lange allein gemacht. Aber ja, gerade wenn man in ein Projekt einsteigt, wo man nicht von Anfang mit dabei war. Und ich meine, ich hab bei einem großen Konzern angefangen und war leider nicht Mitarbeiter Nr. 3 und kann mich jetzt darauf ausruhen. Da ist Lesen, Lesen, Lesen und Sezieren und die Dokumentation, wenn es denn welche gibt, finden und durcharbeiten.

Und dann? Am Ende setzt man quasi wie der Chirurg mit dem Skalpell den einen Schnitt und dann liest man wieder. Also die Menge an Recherche verstehen, verzweifeln, experimentieren, die dann da reingeht, bis am Ende dann oft die relativ kleine Änderungen, die es braucht, rauskommt. Das habe ich am Anfang auch nicht so erwartet. Ich dachte, als Programmierer macht man vor allem eins Programmieren. Aber ich glaube, der Begriff ist deutlich weiter, als man das denkt.

Ja, und es geht ja nicht darum, Code nur zu lesen. Also für mich ist das so ein mehrstufige Prozess. Für mich ist die erste Stufe ich lese den Code und orientiere mich so ein bisschen und gucke Okay, was passiert hier eigentlich? Die zweite Stufe ist Ich gehe wirklich mit dem Debugger Schritt für Schritt durch die Zeilen und gucke Was passiert hier? Also gerade wenn ich eine Änderung machen muss. Da möchte ich ja verstehen, was ist der neue Zielzustand und was ist der bisherige Zielzustand oder was produziert der Code und wie ist das Delta?

Was muss ich hier an dieser Stelle ändern? Das wundert mich immer wieder, wie viele Leute nicht in die Bagger benutzen, um genau das nachzuvollziehen, weil das so einfach Zeile für Zeile. Man kann überall reingucken, kann alles lesen. Man liest dann noch mehr, weil man auch noch die ganzen Variablen sieht. Aber man kann sehr genau das Detail Problem verstehen und dann eben zielgerichtet die Änderungen durchführen.

Ja, ich muss sagen, ich benutze die Bagger jetzt auch beim entwickelnd relativ wenig, weil wenn dir jetzt bei Dingen, die irgendwie als Server Prozess woanders laufen, also entweder im Testsystem, wo man dann überhaupt mit dem Bagger sich einklinken kann, ist es dann teilweise auch etwas schwierig sich da einfach dran zu hängen. Aber ich kenne es halt oft, sodass man dann, wenn man sich nicht klar ist wie der Code funktioniert, dann guckt man Unit Tests, die es hoffentlich geben sollte an, weil die so ein bisschen auch als ausführbare Dokumentation eingeben, was zu erwarten.

Oder wenn der Code komplizierter ist, hat hoffentlich jemand ein Kommentar dagelassen, der erklärt warum. Es ist so kompliziert, dass man sich die Mühe macht, erst den Code ob jetzt die Bagger oder ob man per Kopf das durchgeht, erstmal zu verstehen, was macht der Code? Vielleicht bin ich auch einfach manchmal vom Ergebnis getrieben. Je häufiger ich direkt achte, machst du hier mal schnell, dass das rechtlich eigentlich oft, weil dann a eine Randbedingung hin misst.

Ja, genau deswegen, dass sich einfach jemand vor das weiße Blatt Papier setzt und sofort das runter rockt. Man muss viel kombinieren und knobeln.

Deshalb lohnt es sich auch ordentlich zu kordon. Nicht unbedingt, weil man selber dann besonders toll das geschrieben hat, sondern weil es eben mindestens zehnmal gelesen wird. Wahrscheinlich auch von anderen Menschen. Und man macht denen ihr Leben leichter und kommt eben schneller voran. Ne Code sauber strukturiert ist und den abgesprochenen Guidelines folgt.

Ich glaube, das kann man vermutlich schon so sagen, dass die Kolleginnen und Kollegen auf jeden Fall wissen, wer den schludrige Code und wer den hervorragend schönen Bilderbuch Code schreibt.

Alle machen doch Bilderbuch Code um und die dies nicht machen. Das merkt man.

Der vierte Punkt Nach Abschluss der Entwicklung startet die Entwicklung erst richtig. Auch bekannt als Software. Projekte sind nie fertig. Jetzt stöhnen ganze Legionen von Managern auf. Wahrscheinlich bei diesem Punkt. Das ist eine da meine Vorbereitung noch drüber gesprochen. Es kommt ein bisschen darauf an. Man kann natürlich eine Software abschließen, wenn sie lediglich innerhalb einer Firma benutzt wird und z.B. nicht mit dem Internet in Kontakt kommt und dies dafür macht, was sie soll. So ein Converter wäre z.B. ein gutes Beispiel.

Oder wenn du eine Schnittstelle angesprochen wird, die irgendwie SMS verschickt oder so. Dann ist diese Software sehr wenig volatil. Aber alle Software Projekte, die Kontakt zum Internet haben und es dürften wohl die meisten sein, die sind nie abgeschlossen. Denn es tritt neue Sicherheitslücken auf. Browser bekommen neue Fähigkeiten, alte Fähigkeiten gehen verloren oder alte Technologien werden Dupree Created werden abgeschaltet, werden nicht mehr unterstützt. Das heißt, dass es ein fortlaufendes Monitor. O-Ring und mindestens minimale Anpassung der Anwendung an die aktuellen Gegebenheiten und das sind nur die Dinge, die man nicht in der Hand hat.

Weil ich glaube, sobald Endnutzer ein System nutzen, kommen natürlich auch Begehrlichkeiten auf wie Ach, könnte das nicht auch diese und jene Funktion haben? Oder ich nehme an, auch in-house. Wenn einfach die Nutzergruppen groß genug sind. Man kann sie natürlich vorher viel überlegen, aber ich glaube, dass man von Anfang an perfekt weiß, was die Anforderungen der Nutzerschaft am Ende sind. Das glaube ich, das gibt es selten. Und dann muss man natürlich auch gucken, dass man nachschieben kann.

Genau deshalb hat er diese ganze agile Softwareentwicklung so einen riesen Schub erfahren und tut es immer noch, weil man eben gemerkt hat Na gut, das funktioniert nicht, dass jemand Spezifikationen aufschreibt, anderthalb Jahre Software entwickelt wird und dann hinterher hat man etwas, was man gar nicht mehr braucht, weil sich die Welt ein Stück weitergedreht hat, sondern dass man kontinuierlich nach steuert. Wie auch? Wenn du mit dem Auto in die Kurve fährst, dann fängst du ja auch nicht so ein.

Das ist eine 40 Grad Kurve. Dann schlage ich mein Lenkrad um 40 Grad ein und mach die Augen zu, bis ich hinten wieder rauskomme, sondern du steuerst ja im Grunde durch die Kurve durch. Und genau das macht der Scrum Prozess eben bei deinem Software Projekt. Aber wichtig ist nach der Entwicklung ist vor der Entwicklung bei allen Themen, die mit dem Internet zu tun haben und die dann eben auch betrieben werden müssen. Es gibt Monitoring System, es muss geguckt werden, ob Sicherheitslücken zu stopfen sind, ob ne neue Version erschienen ist und solche Sachen.

Ja und vielleicht auch noch. Also ja Software Aktualisierung einfach von außen nötig werden. Aber was ich jetzt auch schon mehrfach erlebt habe, ist gerade wenn man Infrastruktur baut Infrastruktur, Software.

Dann werden Dinge ermöglicht, die vorher nicht gingen. Und dann kommen auf einmal Ah, jetzt, weil wir das können, können wir dann auch diese und jene ist. Wenn z.B. eine Sorte Datenspeicher ist, können wir auch das und das da drin unterbringen. Ja, das war eigentlich so nicht vorgesehen. Aber gut, müssen wir mal gucken. Und das klar.

Man kann sich nicht für alle Eventualitäten rüsten, aber oft wird man vom eigenen Erfolg auch überrascht, dass dann auf einmal das geschnitten Brot da liegt. Und jetzt will jeder etwas haben. Und mit so viel Anfragen und so weiter hat man gar nicht gerechnet. Da können sie sich dann auch einfach, weil man dann auf einmal das Problem besser versteht. Ist immer wieder bei Punkt 1, glaube ich. War es. Also kann quasi das ein riesiges Luxusproblem sein, dass man auf einmal jetzt wieder richtig rein klotzen muss, weil man einfach gemerkt hat, man hat richtig Nerv getroffen.

Was schön ist. Natürlich.

Genau das kann natürlich ungünstig sein, wenn man eigentlich gedacht hat, man ist damit fertig oder wenn man das Projekt gehasst hat. Ist natürlich auch nicht mehr echt. Aber das etwas fertig ist. Ich glaube außer man brennt es am Ende auf den Raum und dann läuft es irgendwo als Aufzugs Steuerungen und wird nie wieder angepackt. Ich denke es ist hatten’s große Systeme.

Ja oder Daten Converter. Also du hast ein System A in Betrieb und möchtest zu System B migrieren. Und einmal müssen alle Daten übersetzt werden aus System A im System B und dann Bausteine Software, die einmal produktiv läuft und diese Konvertierung durchführt und dann es das so, in dem Fall wäre es dann schon fertig.

Genau. Und da hab ich auch erlebt, dass manchmal, wenn man sowas im Vorfeld so einschätzt, dass es eine solche einmal und dann Schlussakte ist. Ist auch oft ne gute Idee, das so zu kommunizieren, dass man sagen Okay, wir bauen euch das. Wir machen das. Und dann sind wir aber auch da raus, weil ansonsten kann es passieren. Dann. Ach nee, aber eigentlich wir müssen jetzt doch noch ein paar Migrationen machen.

Könne da nochmal genau da gab es bei einem Projekt, wo ich vor vielen Jahren mal gearbeitet habe. Das war ganz interessant. Da gab’s in der Firma den Namespace Quand, also CU Ant. Und alle Projekte aus dem Namen Space Quand durften nicht verwendet werden für das eigene Projekt ohne umfangreiche Anpassungen. Dann mussten sie auch aus dem Quand namespace rausgenommen werden, sondern alles, was in Quand war, war quasi abgeschlossen und nicht für die Weiterverwendung gekennzeichnet. Und irgendwann habe ich gefragt Warum heißt es denn Corinth?

Es ist quick and dirty. Also wenn du was von dem Quand Stapel nimmst, bist du dafür verantwortlich, dass erst einmal eine Form zu bringen, die Wartburg ist.

Aber da sind wir ja auch schon bei Punkt 5 Du verschätzt die ich beim Entwicklungstempo immer. Ich bin jetzt selber kein Projektmanager, habe aber als Entwickler selbst schon ich sag mal meinen Anteil an absolut hanebüchenen Schätzungen abgegeben. Ich schätze mich immer nach unten. Das ist so AIA. Das ist 4 Stunden Arbeit. Sag mal lieber Safe und sagst zwei Tage.

Ja und dann nach zwei Wochen ist es dann auch endlich rum. Ich bin sicher, es gibt Leute, die sind da besser drin als ich. Aber prinzipiell hab ich auch vom Gespräch mit Projektmanagerin bei uns mein größeres Projekt hatten wir alles sehr genau durchgeboxt wurde. Hab ich dann auch irgendwie gehört. Ja, wir nehmen eure Schätzungen und dann machen wir da mindestens mal Faktor 2 oder 3, dann hoffen wir, dass es so einigermaßen passt.

Wir nehmen eure Schätzung und machen Faktor 2 oder 3, das heißt ja, dass man selber sich immer deutlich nach unten verschätzt.

Das scheint wohl so zu sein. Man ist ja auch optimistisch. Man will ja dass schnell erledigt.

Ja. Ich glaube, selbst wenn man die tatsächliche Arbeit, die man selber reinzustecken hat, irgendwie einschätzt und sagt Ja, hier, da die Komponente umbauen. Ich weiß in etwa, wie die aufgebaut ist. Und dann hat man aber im Rechenzentrum auf einmal nicht die Kapazitäten oder derjenige, der einem die Zugänge gibt, ist nicht da. Dann ist auf einmal irgendetwas anderes, ist auch selten an genau einer einzigen Sache nur dran und dann hat man irgendwie drei Meetings mehr als man dachte.

Es gibt tausend Gründe, die man nicht in der Hand hat. Und ich glaube, niemand sagt ja gerne stottert Trauer drei Monate her, wenn man denkt, es ist halt zwei Tage lang.

Nein, ich glaube, viele Dinge werden einfach unterschätzt. Alleine, dass man einen Zeitpunkt kommuniziert, ist glaube ich, nicht gut. Im Grunde müsste eine realistische Schätzung, müsste man sagen Ja, ich gehe davon aus, mit einer Wahrscheinlichkeit von 50 prozent, der sich zwei Tage brauchen werde. Wenn du es mit einer 75 prozentigen Wahrscheinlichkeit fertig haben möchtest, dann müsste ich von vier Tagen ausgehen. Also dass man quasi so ein Zeitfenster angibt, indem es fertig wird, weil Software Projekte sind ja Individual Projekte.

Wenn das nicht der Fall ist und die Software schon gibt, dann muss man sich fragen warum programmiere ich das, was es schon gibt? Wenn es geknackt ist oder gelöst ist, dann kann man oft nehmen, was vorhanden ist. Das geht sowieso viel schneller und hat eine höhere Qualität als sich selber etwas auszudenken. Und keiner schreibt auf die Zeitplanung. Unerwartete Treiber Probleme 2 Tage BIOS falsch eingestellt, einen Tag. Du hast es eben schon angesprochen. Ansprechpartner ist im Urlaub, deshalb bekomme ich kein Datenbank Zugriff.

Völlig normal 2 Tage, weil derjenige, der die Berechtigungen vergeben kann, nicht da ist. So, das sind aber in großen Firmen und wahrscheinlich auch in vielen kleinen genau die Punkte, wo die Zeit bei draufgeht.

Ja und ich würde schon sagen, dass so die Softwareentwicklung auch ein sehr kreativer Prozess ist. Leute, die nicht viel damit zu tun haben, schmunzeln jetzt vielleicht, aber es ist genau wie gesagt sagtest, wenn die Lösung von vornherein klar ist, dann stellt sich die Frage Warum muss man sich damit überhaupt beschäftigen? Es ist auch einfach schwierig, glaube ich genau abzuschätzen, welche Sachen auf dem Weg alle sind. Inkompatible Version oder irgendeine Abhängigkeit ist auf einmal nicht erfüllt.

Also es gibt ja tausend Dinge, die dazwischen kommen können und manchmal steht man auch einfach auf dem Schlauch und ist ein Tag irgendwie matt. Es ist halt nicht einfach Fliessband, wo man genau weiß. Pro Stunde schreibe ich 40 Zeilen Code und es braucht 200 Zeilen Code. Also brauche ich 5 Stunden. Ich hoffe meine Mathematik stimmt. Ich habe auch großen Respekt vor Projektmanagerin, die auf solchen ich sag es jetzt mal flach Müll daten. Ich meine nicht wie riecht kriegt trotzdem, weil so ein Projekt irgendwie durchziehen können.

Weil das wäre für mich wäre das ein Albtraum, wenn das mein Job wäre, weil ich einfach damit nicht umgehen kann. Ich glaube, es ist auch mit Du hast ein bisschen bewegendes Ziel. Du hast natürlich viele Aussagen. Es ist ein kreativer Prozess. Das wäre mal ein interessanter Vergleich. Künstler werden ja auch nicht gefragt oder selten gefragt Wann ist dein Bild fertig? Ob deren Voraussagen ungefähr der Qualität entsprechen, wie das bei IT-Projekte der Fall ist? Aber ja, ich gebe dir Recht.

In der IT ist es eigentlich sehr einfach. Entweder muss eine Lösung selber entwickelt werden und man schätzt den Lösungsweg ab, ohne ihn genau zu kennen. Das ist aber im Grunde wie eine Wanderung in einem Gebiet wurde noch nie warst, oder? Es gibt eine Komponente, die ist fertig. Die kannst du im Grunde mit minimalem Aufwand direkt verwenden und das sollte man immer machen. Wenn da sind wir wieder bei. Verstehe das Problem exakt, wenn teile Probleme deines großen problem schon gelöst sind mit Komponenten.

Nimm diese Komponenten.

Das spart am meisten Zeit und auch indirekt, wenn man etwas nimmt, was schon eine Weile existiert, von anderen Leuten vielleicht auch gebaut wurde. Die hatten auch schon alle ihre Bugs drin und haben viele gefixt. Ist natürlich immer noch genug drin, aber wenn man selber von Null anfängt, hat man das doch alles vor sich. Manchmal ist dann vielleicht auch einfach das bisschen, was es länger braucht, sich mit etwas anderem bekannt zu machen. Das spart man hintenraus, weil viel.

Ich sag mal stad. Krankheiten sind einfach schon raus gebügelt.

Der sechste Punkt Es wird sehr stressige und sehr sehr ruhige Phasen geben. Dem kann ich voll und ganz beipflichten. Das Problem mit den stressigen Phasen ist, dass in IT Projekten. Das kennt jeder. Wenn etwas nicht funktioniert, funktioniert es jetzt nicht sofort nicht und zwar für alle Benutzer. Und je nachdem welche Prozesse da dranhängen, hat man sofort ein großes Problem. Also wie bei einem Flugzeug, wenn beide Motoren gleichzeitig ausfallen. Unter Strom hat man sofort ein großes Problem, um das man sich kümmern muss.

Und das sorgt natürlich für Stress. Das sind die stressigen Phasen. Die ruhigen Phasen sind, wenn alles funktioniert und man nicht angerufen wird. Man wird auch nicht gelobt. Niemand meldet sich. Aber das ist das bestmögliche Zeichen, was ihr in einem IT-Projekte haben kann. Weil wenn sich niemand meldet und alle sich nicht um euch kümmern, dann läuft die Software ideal. Wenn sich keiner beschwert.

Ich glaube das ist so, wie du es beschreibst. Von wegen wenn. Wenn sich niemand meldet, ist alles gut. Ja, ich glaube, das macht auch ein bisschen den Unterschied. In was für einem bei Anwender Software oder in was für einem Umfeld, in was für einer Firma das ist. Weil in meinem Fall ist Software das Hauptgeschäft. Da ist natürlich auch einfach die Aufmerksamkeit glaub ich eine andere.

Ich nehme nur an, wenn Firmen, wo IT an sich so ein Mittel zum Zweck ist, um. Ich weiß nicht Content online bereitzustellen oder sowas, aber eigentlich das Hauptgeschäft Content. Dann ist natürlich, wenn alles läuft, dann hat man mit dem Software Gedöns nichts zu tun, weil das macht ja was es soll. Der Content ist da. Deswegen kommen die stressigen Phasen dann halt nur, wenn auf einmal das Hauptprodukt gefährdet ist, wo Software.

Wicklungen quasi das Kerngeschäft ist natürlich die Aufmerksamkeit immer da. Nur ist der Unterschied da oft ist das Projekt, an dem man gerade arbeitet, ist das intern oder extern sichtbar? Ich meine, es gibt viele Projekte. Jetzt kann man sich fragen Ja, wenn das nicht sichtbar ist, warum interessiert sich dann überhaupt einer dafür? Ich meine, die Rohre an meinem Waschbecken sind auch nicht sichtbar, aber solange die tun, kümmert es auch niemanden. Aber sobald auf einmal externe Interessen, gerade wenn es dann irgendwelche Verträge sind mit anderen Firmen oder man muss die bedienen, sonst gibt es irgendwelche Fristen, die verstreichen.

Da habe ich gemerkt, das ändert den Ton im Projekt aber ganz entscheidend, weil dann ist auf einmal das Weihnachtsgeschäft vor der Tür und das Ding muss raus. Dann kommen wir wieder zu Punkt 1. Dann wird halt auf einmal dann doch irgendwie egal, wie man es macht, Hauptsache es ist schnell und man kann irgendetwas schicken. Dann sind eventuell die Gesichter im Hintergrund lang, weil dann die Qualität natürlich gelitten hat. Aber unter Druck entstehen Diamanten oder es ist nicht so gut.

Ich mag die ruhigen Phasen dann durchaus mehr, weil es eben auch einfach die Möglichkeit gibt.

Ich sag mal bessere Arbeit zu machen.

Ich bin da vielleicht so ein bisschen Software bipolar. Also ich habe gemerkt, diese stressigen Phasen, die gehen extrem an die Substanz. Allerdings lernt man in drei Tagen so viel wie sonst in einem halben Jahr. Also das kann durchaus passieren, weil man einfach so voller Adrenalin ein Problem nachjagt. Also so ein Fokus hat man wirklich selten. Was natürlich unangenehm ist, weil man das Problem lösen muss. Und in ruhigen Phasen, da kommt es auch ein bisschen darauf an.

Viele Entwickler fangen dann an, technische Schulden abzubauen, wenn ihnen die Zeit dazu gegeben wird, was total sinnvoll ist. Ich bin eher so der Typ, der sich dann weiterbilden möchte. Ich gucke mir dann Themen an, die strategisch vielleicht interessant sind und sage Okay, das ist eine neue Technologie, davon hab ich gehört. Können wir die hier einsetzen, um direkten ganzen Problemen Kontext zu erschlagen oder wie funktioniert das? Was können neue Technologien? Wie helfen die dabei, unser Business besser zu machen?

Was hab ich bisher verpasst, wenn man das so sagen möchte? Bin eher so der Typ, der über den Tellerrand schaut und sagen würde Okay, was gibt’s da draußen noch außerhalb meines Stress Kosmos? Was ich mir jetzt anschauen kann.

Ich denke mal in ruhigen Phasen ist insbesondere der kreative Teil dieses Prozesses. Der kann sich dann austoben, wie du sagst weiterbilden oder halt auch Pflege. Wenn jetzt gerade nichts Brennendes ansteht, dann kann man die ganzen Ecken und Kanten, die man weiß, die hatte man drin. Die kann man dann pflegen, weil oft sagt man Na gut, wenn jetzt irgendwie ein wichtiges dringliches Ding da liegt, dann ist dieses kleine Feature, das kann dagegen einfach nicht anstehen. Aber er weiß sehr gut, wenn man das jetzt macht.

Die Benutzer haben dann eine kleine Verbesserung ihres Alltags. Das hat dann Platz. Die stressigen Phasen manchmal auch sehr spannend, weil wie du schon sagst, man lernt viel, gerade wenn man sieht, was für Unwetter man abgewandt hat. Vielleicht. Mir persönlich ist einfach wichtig, dass diese stressigen Phasen, wenn sie auftreten, auch von ruhigen Phasen wieder abgelöst werden. Wenn man das Gefühl hat, man rennt vom ein Chaos ins nächste. Das ist, glaube ich, kein gutes Zeichen für den Allgemeinzustand der Umgebung.

Wie auch hier die Dosis macht das Gift. Ja, zu den sieben Punkt ansprechen.

Ja, mit weitreichenden Rechten kommt große Verantwortung. Das ist oft. Als Softwareentwickler besteht man im Maschinenraum der Irmer. Was wir eben schon gesagt hatten, insbesondere wenn die IT das Werkzeug ist, was den eigentlichen Firmen Betrieb aufrecht erhält, dann hat man natürlich auch Zugang zum Maschinenraum dessen, was den ganzen Laden am Laufen hält. Da kann sowohl mit den Passwörtern, die man jetzt hat, zum einen böswillig eine ganze Menge Schaden anrichten. Und was halt auch durchaus vorkommen kann, ist, dass man mit Unachtsamkeit versehentlich ganz schön Schaden anrichten kann.

Dann ist auf einmal nicht die Tests, sondern die Produktions Datenbank gelöscht. Und das ist der Stoff, aus dem Albträume gemacht sind. Da gibt es Geschichten im Internet, die genau diese Horrorvisionen beschreiben. Es geht hier bei dem siebten Punkt einfach darin, dass man merkt Okay, die Firma vertraut dir als Person, dass du ihr dabei hilfst, ihre Geschäftsidee zu erreichen mithilfe von Technologie. Du bist da der Experte und natürlich hast du dann Zugriff auf sensible Infrastruktur.

Wir haben eben die hektischen Phasen Angesprochener. In den hektischen Phasen bewegt man sich vielleicht auf Systemen, die man sonst nicht gut kennt oder ist gezwungen, in der Datenbank zu gucken, um zu schauen. Also gar nicht einmal einem die Daten interessieren, sondern weil man einfach wissen möchte, ob man ist dieser Eintrag an einem Schalttag von dem Schaltjahr erfasst worden ist, dass das Problem. Also da muss man einfach relativ schnell sich dadurch hangeln, um zu gucken Okay, ich muss das Problem hier lösen, dann spürt man schon, dass man eine große Verantwortung hat, einfach weil man da am Nervensystem von Firmen oder von technischen Systemen arbeitet und man das vertrauen, was einem die Firma gibt.

Und man muss aber auch gucken, wenn die Firma ein Produkt hat, dann hat man ja an sich auch implizit das Vertrauen der Nutzer, weil die Nutzer natürlich davon ausgehen, dass die Firma mit den Daten kein Schindluder treibt oder zumindest nicht mehr als man der Firma zurechnen. Also es ist manchmal unheimlich, wenn man bedenkt, welchen Zugriff man teilweise einfach haben muss und die Arbeit machen zu können und einem vertraut wird, dass man nicht links und rechts nebendran guckt. Klar, es kann sein, dass es Audit Systeme gibt.

Das heißt, wenn man Schwachsinn macht, bleibt es nicht unerkannt. Also gerade diese versehentlich etwas umzustoßen ist natürlich da.

Tippt man ganz vorsichtig auf der Kommandozeile und guckt zweimal auf den Befehl, bevor man ihn durch. Ja, das hab ich tatsächlich häufiger schon gesehen, dass man dann einfach bei ich sage mal kretischen Sachen dann auch per Programming macht oder so. Zweiter Vorsitz, dass dann einer sein kann. Also diese Leerzeichen vergessen und auf einmal löscht man das Verzeichnis statt irgendwie den Pfad.

Man wollte ja oder auch so ein Tink laut, dass man sagt, der eine sagt so, ich zeige jetzt den Inhalt des Verzeichnisses an, jetzt verschiebe ich das Verzeichnis lib und dann sagt der Nachbar Ah, du musst Punkt lieb schreiben und nicht Slash lieb, oder? Also ganz natürlich, wie in allen anderen Bereichen und Branchen auch, dass man so ein Vier-Augen-Prinzip einführt und sagt Wir arbeiten jetzt hier am offenen Herzen und wir müssen hier vorsichtig sein.

Und ich meine, es wird immer noch etwas schief gehen. Da hab ich auch gesehen, dass wenn was schief geht, wenn man es dann noch versucht zu vertuschen, dann nein, wenn’s schief geht, sofort Alarmglocken. Gut, leicht kommt das auch auf die Position des Jeweiligen an, aber ich sag mal, in einem funktionierenden Umfeld sollte das am Ende so ein oh Mist alle Hände auf Deck Moment sein. Und dann, wenn die Wogen geglättet sind, dann kann man mal gucken, was eigentlich schiefgelaufen.

Da hab ich eine Horror Story aus meinem Entwickler leben. Genau zu dieser Situation. Und zwar, dass es auch schon viele Jahre her. Da hab ich an Diplomen durchgeführt auf einen Webserver, der aber nicht einer Firma gehört, sondern einem ganz großen Unternehmen. Und alle Agenturen haben die Inhalte, die sie zugeliefert haben, eben auf diesem Server abgelegt. Und so hab auch ich meine Inhalte abgelegt und ich hab den Installations Prozess gestartet, gucke und gucke und gucke der Server weg, gucke auf die Webseite von der ganz großen Firma der Server weg, gucke auf die anderen Dienstleistungs Agenturen, Verzeichnisse nichts.

Das war der Moment, wo wirklich mir heiß und kalt wurde. Da bin ich aufgestanden, zu dem Verantwortlichen gegangen, hab davon berichtet, der wurde auch ganz nervös. Dann hat er ganz panisch rum telefoniert und dann kam nach 5 6 Minuten raus, dass dieses ganz ganz große Unternehmen ein unangekündigte Wartungs Fenster für diesen Server durchgeführt hat. Genau in dem Moment, wo ich quasi die Installation gestartet habt. Es war also eine geplante Umstellung und ich banu zufällig genau in der Sekunde da und hab gedacht, es läge an mir.

Da war ich dann doch. Wieder habe ich einige Kilos abgenommen im Zuge dieses Anrufs.

Jetzt lacht man da drüber. Nee, aber ich glaube so 6 Minuten oder Herzschlag war damit ganz schön anstrengend.

Ja, also ich weiß noch, wie ich da saß. Ich weiß noch, was ich empfunden habe. Ich weiß noch, wie ich aufgestanden bin, mit dem Kloß im Hals zum verantwortlichen Manager gegangen und gesagt habe Des Ford Server XY Z lebt nicht mehr.

Und ich glaub, ich bin schuld.

Da kann man auch viel über das Management erfahren. Wie dann, wie die damit umgehen. Ja, es gab überhaupt keine Zeit, um mit dem Finger irgendwo drauf zu zeigen, weil man wusste, wenn das so ist, ist Katastrophe und dann muss jetzt reagiert werden. Es war denn Gott sei Dank so, dass sich dann hinterher auch dieses ganz große Unternehmen entschuldigt hat, bei all den Partnern, die halt diesen Server benutzt haben für die eigenen Komponenten, weil es gesagt hat Ja, irgendwie haben wir das nicht korrekt kommuniziert.

Oder es war eine kritische Sicherheitslücke, die ganz kurzfristig gestopft werden musste. Ich weiß es nicht mehr. Ich weiß nur das hinterher war alles in Ordnung. Es geht nicht dein Blut am Server. Ganau. Ich war nicht der Auslöser, sondern ich bin da reingeraten. Sozusagen. Kommen wir direkt zu Punkt 8 Du wirst eine Menge Spaß haben und viel Spaß haben wir ja jetzt, wo wir es überlebt haben.

Aber ich hatte nochmal so eine Katastrophen Situation, wo alle Leute die helfen konnten im Urlaub waren und ich das dann irgendwie alleine machen musste. Also heute ist das witzig und es macht mich auch stolz, dass sich das so geschafft habe nach einiger Zeit. Aber in der Situation selber war das nicht so angenehm. Ich meine, wie du schon vorher sagte ist unter Stress lernt man viel, aber oft hat man den Spaß dann auch, insbesondere wenn es ohne beinahe Herzinfarkt zwischendrin man irgendwie einen Milestone abgeschlossen hat, wenn irgendwie ein Projekt, was lange lief, vielleicht auch die eine oder andere Träne gekostet hat.

Am Ende wird es dann aber ausgeliefert und es funktioniert tatsächlich sogar. Da kann man dann viel rausziehen.

Für mich ist das immer wie Magie. Ich will jetzt nicht sagen, wie der Moment, wo Frankenstein von der Bahre aufsteht. Aber du hast viele Monate an einem System gearbeitet oder ein Team hat viele Monate an einem System gearbeitet, sich unfassbar viele Gedanken gemacht, viel Gehirnschmalz investiert und auf einmal sieht man, wie so aufersteht und wie es genutzt wird. Und man sieht halt den Nutzen, den es bringt für die Zielgruppe. Und man muss sich ja vorstellen, man selber hat vielleicht Stunden an der Tafel gestanden, um die Prozesse durch zu planen.

Und jetzt kommt der Computer hin und kann diese Prozesse tausendfach millionenfach pro Sekunde ausführen und zehntausende, hunderttausende Nutzer gleichzeitig versorgen mit den Prozessen, die man sich selber überlegt hat. Ich finde das nach wie vor auch nach 15 Jahren noch immer ein ganz besonderer Moment wie bei Cast Away.

Ich habe Feuer gemacht, gerade wenn man irgendwie dann auch sieht, wie Leute davon profitieren, was man gebaut hat. Der ewig lange manuelle Prozess ist endlich automatisiert. Oder wenn das Produkt in den Händen der Nutzer ist, erzeugt es Freude, weil es einfach Spaß macht zu bedienen. Also einfach, wenn das Ziel erreicht ist und man tatsächlich auch sieht, dass Leute die Früchte sehen. Auf jeden Fall oder auch davon profitieren, dass z.B. das habe ich relativ häufig, dass ein Arbeitsschritt dann entfällt.

Man erweitert eine Software und Dinge, die vorher manuell gemacht werden mussten, werden jetzt entweder das ist ideal vollautomatisch übernommen oder mit deutlich weniger Aufwand können sie durchgeführt werden. Und die Nutzer, wenn es jetzt Endnutzer sind, bedanken sich richtig dafür, dass man ihnen den Aufwand, diese mühevollen Aufwand dann erspart. Zukünftig superschön.

Gerade bei Infrastruktur Arbeit ist auch oft, dass am Ende das Ausbleiben von einer Sache das Ziel ist. Man hat diesen nervigen Schritt weg optimiert und jetzt kann die Person, die das vorher gemacht hat, sich anderen spannenden Dingen widmen. Oder man hat neue Möglichkeiten geschaffen, indem man irgendwie Flexibilität hergestellt hat, die vorher nicht da waren oder auch in einer anderen Art und Weise, wenn man endlich den Bug gefunden hat, der einen seit Tagen gefixt hat.

Das ist richtig.

Oh ja, und da EZA fehlten Coma oder irgendeinen Kast. Der Teufel liegt im Detail und dann auf einmal hat man erwischt.

Es ist schon oft, dass man so richtig Heureka Momente hat, weil man einfach A. Es hat geklickt. Sehr schön. Okay. Punkt neun. Du wirst unglaublich schlaue Leute treffen und von diesen lernen dürfen, weil sie besser sind als du. Genau das muss ich am Anfang ganz schön mit auch erst einmal umgehen können. Wenn man jetzt bei mir im Fall von der Uni kommt usw. Man denkt, man hat so viel gelernt und dann fängt man an zu arbeiten und stellt fest Boah, die Leute laufen alle Kreise um mich und ich lerne jetzt gerade erst, was man alles noch zu lernen hat.

Fand ich am Anfang ein bisschen schwierig mit umzugehen, aber mit der Zeit hab ich dann einfach gemerkt das ist einfach eine Riesenchance. Diese Leute haben schon viel Erfahrung. Vielleicht hätten die mir auch gesagt bauen nicht diese komplizierte Lösung, nur um hier irgendwie drei Anfrage irgendwohin zu schicken. Das ist wirklich. Diese Leute bereichern einen wirklich, weil man auch in diesem Umfeld natürlich schnell von denen sich viel abgucken kann. Ja und auf so viele Dimensionen. Also a Software technisch kannst du dir viel abgucken.

B Ich finde es mal ganz spannend zu gucken, welche Tools benutzt jemand und wie geht er damit um? Also auch da lernt man viel und auch methodisch. Wie gehen die an die Probleme heran? Beim Punkt verstehe, das Problem haben wir ja schon gesagt stellen die viele Fragen stürzen die sich in die Lösung? Dann gibt es Leute, hab ich festgestellt, die unglaublich viele Variablen im Kopf halten können. Richtig beeindruckend, wie viel gleichzeitige Informationen sie im Kopf halten können.

Dann gibt es so die Startblock Sprinter, die sofort losrennen. Dann gibt es die Leute, die das über die Distanz ordentlich Fahrt aufnehmen. Also es ist einfach interessant und inspirierend zu sehen, wie viele Arbeitsweisen es gibt, die zum Erfolg führen können.

Ja und gerade so bei unerwarteten Problemen, die dann auftauchen.

Sowas wie kühlen Kopf bewahren, aber dann auch genau wissen Ah, okay, ja, da sind wir jetzt außerhalb unserer Möglichkeiten. Dann wissen, zu wem man gehen muss. Also auch einfach das Verständnis von, wie ein Team Teil der Lösung sein kann und nicht nur man selbst jetzt da vor sich hin bastelt und quasi all diese Komponenten miteinander verknüpft. Das ist halt nicht einfach nur wie schon sagt ist, technisch ist, sondern das tatsächlich auch so ein bisschen Menschen dazugehören, dass man weiß Oh, das ist jetzt algorithmisch schwierig, da müssen wir jetzt hier das super Brain ist jetzt nicht so der beste Designer von großen Infrastruktur Sachen, aber Algorithmen voll dabei, diese Leute auch zu erkennen und dann auch zu wissen, wer welche Stärken hat.

Was man dann auch weiß, was man von wem lernen kann. Und einfach das wertschätzen. Ah, da weiß jemand was mehr als ich.

Wie macht er das? Das hält ja auch neugierig und fit, weil also zumindest mir geht es so, wenn ich dann das Gefühl hab, ich werde irgendwie abgehängt. Das ist nicht so. Da setz ich mich da lieber hin. Gerückt. Gerückte. Wie kann ich da dranbleiben? Also ich glaube vielleicht auch wenn einem das in einem gewissen Umfeld fehlt, wird man auch irgendwann, weil sie nicht bequem ist, mir jetzt noch nicht passiert. Aber es wäre schon schade, wenn jemand da ist, der irgendwie beeindruckt und mitzieht.

Punkt 10 Das kann man gar nicht überbetonen. Du verbringst sehr viel Zeit mit Details, Problemen und mit Detail Problemen, meine ich. Der Treiber passt nicht zur Datenbank. Das Encoding stimmt nicht. Kein Platz mehr auf der Festplatte. Die API ist Version 4, aber meine Ansteuerung Software nutzt noch Version 3, das muss ich migrieren. Hier passen irgendwie die Pfade nicht aufeinander. Die Konfiguration Einstellungen sind nicht korrekt und und und und Authentifizierung in jeglicher Couleur zähle ich auch mit dazu.

Also die Arbeit als Softwareentwickler macht viel Spaß. Aber diese Detail Probleme, die können auch sehr nervenaufreibend sein, weil die stehen auf keinem Projektplan. Aber die kosten sehr viel Energie. Wo liegt das Lock Fall? Schreibt der ein Fehler ins Lock Fail schreibt er nicht. Wo kann ich noch gucken? Kann ich mir im dieBürger dran gehen? Hab ich die Zugriffsrechte? Und und und und.

Oft kommt einem das so unnötige Probleme. Diese Version, dass die nicht zusammenpassen. Das hat auch mit meinem eigentlichen Problem nichts zu tun. Ja, aber leider halt doch, weil es irgendwie im Weg steht. Wenn dein Zug die Reifen zu breit für die Schienen freut und mit rauf fahren muss, war das Pech. Dann musste irgendwie basteln.

Ich glaube, das kann man mit dem Gefühl vergleichen, wenn die Bahn ausfällt oder bestreikt wird und du nicht zur Arbeit kommst. Du hast ein Problem, bevor du deine eigenen. Arbeit überhaupt beginnen kannst und ich glaube, das findet man drin, dass man man kann gar nicht zur Datenbank sich verbinden, weil die Treiber Version nicht passt. Oh Mann. Und eigentlich möchte man ja auf die Datenbank zugreifen und Dinge abspeichern und wieder rausholen. Und jetzt muss man sich mit diesen Treiber Problem beschäftigen.

Netzwerk Problemen in allen möglichen Facetten.

Ja, die Lösung könnte ganz einfach sein, wenn man einfach nur auf die andere Version updaten könnte. Aber leider hängt all der andere Kram, der schon läuft von der alten Version ab. So etwas macht man. Sieht man das parallel auf, kann man die alten Sachen mit updaten lassen. In der Regel auch die weniger schönen Probleme zu lösen, weil es einfach Mist ist, durch den man irgendwie durch muss. Aber ich glaube, das gibt’s überall. Das ist halt auch einfach die ich will ich unbedingt sagen Undankbaren.

Aber die, die kosten sehr viel Kraft und man sieht sehr wenig Fortschritt.

Und am Ende des Tages kann man sagen Ich habe den Zugriff auf die Datenbank ermöglicht, heute in acht Stunden und man kriegt einfach keinen Applaus, außer von den Leuten, die es vorher versucht haben und aufgegeben haben, verdient man da hinten der, der am allermeisten Wadenbeißer geblieben ist, sonst noch irgendwie weg probiert hat.

Diese Probleme sind an sich täglich Brot, weil ich auch, dass es die IDF Lichtarbeit von nix kommt.

Nix. Manchmal muss man halt auch sich mit so einem Dreck rumärgern.

Wenn unsere Zuhörer Fragen haben, können sie uns gerne eine E-Mail an Podcast etc. bei DE senden. Bitte hinterlasst uns eine 5-Sterne Bewertung und abonniert unseren Podcast für weitere spannende Themen. Wir freuen uns auch über Weiterempfehlung an Freunde und Kollegen. Für mehr spannende Technologie Themen könnt ihr auch auf Skill bei T. Slash Blog vorbeischauen. Nikolai, ich danke dir heute ausgesprochen für das Gespräch mit den 10 Punkten. Vielen, vielen Dank! Ja, danke.

Maurice hat echt Spaß gemacht. Ja, fand ich auch gut. Was besser?

Maurice KnoppSkillbyte Podcast #33: Traumjob IT?! – 10 Dinge die dir keiner sagt!
Mehr