i04.md

R1: So genau. Also wir fangen mal an mit einer kurzen Einleitung, Ziele des Interviews klar auszuheben und dann… geht's eigentlich auch schon fast los. Also genau, wir wollen und wirklich herausfinden, ich habe es glaube ich vielleicht schon in der Email gesagt, wie Software und einschließlich Infrastructure as Code konfiguriert wird, aber halt nicht nur Infrastructure as Code, auch ganz normale Software, welche Probleme dabei auftreten, wie diese behoben werden und wobei bei diesen Prozessen Verbesserungsbedarf besteht. Das heißt wir wollen praktisch Probleme sammeln in der Industrie und dann wissen, wo man hingehen kann praktisch in der Forschung.

Genau, im akademischen Bereich ist es oft nicht ganz klar welche Rolle Konfiguration in der täglichen Arbeit spielt—also ist das jetzt viel, wenig und so weiter, kommen wir noch dazu—und generell welche Probleme mit bezüglich Konfigurierung auftreten. Meistens werden bekannte Open-Source-Projekte von GitHub genommen und dort Issues untersucht und nach Konfigurationsproblemen gesucht. Das ist jetzt so praktisch wie man Forschung macht, aber das ist natürlich selten was, was da überhaupt landet bei den Issues. Und wir wollen halt lieber direkt mit den Entwicklern sprechen und nicht auf solchen, sagen wir mal gefilterten Daten, agieren und so weiter. Genau, und am Ende haben wir vielleicht noch mal so ein bisschen Interesse so wie so Teamstrukturen aussehen, weil Teamstruktur hat ja häufig auch Auswirkungen—Convey’s Law—auf die, also Organisation bildet ja irgendwie dann den Code auch wieder und das ist halt dann auch, was das für einen Effekt hat sozusagen. Genau, mit den Antworten hier werden wir immer weiter diesen Fragebogen, also es kann sein, dass wir dann beim nächsten Interviewpartner dann schon wieder neue Fragen haben, die sich hier praktisch aufgeworfen haben. Deswegen gibt es auch hier schon mehr Fragen als bei den anderen, voherigen Interviews hatten. Und für Nutzen vielleicht, nehmen wir direkt vielleicht eine Kooperation, die sich danach ergibt, ist es auch so… ist es natürlich auch so, dass man selber in der Arbeit reflektieren kann—also was mache ich denn jetzt wirklich den ganzen Tag und so weiter. Das haben eigentlich viele Interviewpartner als extrem interessant mal gesagt. Genau, gibt es irgendwelche Fragen? Ansonsten würden wir anfangen.

Okay, also ja, in welcher Domäne arbeitest du hauptsächlich?

I4: Ich würde sagen vom Entwickler, also Software-Entwickler/-Architekt, über Testingenieur, also sprich auch Tests entwickeln und also ich mache so die ganze Bandbreite, alles was so testen betrifft. Also vom Einsetzen von verschiedenen diversen Frameworks bis hin zum Entwickeln der Frameworks und zum Teil halt auch als DevOps, wenn es darum geht die Frameworks dann in CI zu integrieren.

R1: Okay, also ganze Bandbreite. Genau, was ist dann so die Rolle dann, die man—also Entwickler haben wir schon, Tester gehört. Also Projektleiter auch? Oder eher.

I4: Technischer Ansprechpartner. Eher dann wenn es mal was gibt Technical Lead.

R1: Welcher Anteil ist dann an der täglichen Arbeit wirklich Software-Entwicklung/Programmierung?

I4: Kommt auf die Tage drauf an, aber an einem guten Tag sind es schon so 75 %.

R1: Okay und das ist jetzt auch der average Case der gute Tag?

I4: Ne, es schwankt halt so. Also dadurch, wir sind halt keine wahnsinnig große Firma und dann hatte ich, dann hat man halt, also wir haben jetzt letztens mal einen Artikel rausgebracht und dann habe ich mich halt mal zwei Wochen mit einem Artikel für DZone beschäftigt, was dann natürlich keine Entwicklungsleistung hat, aber wenn so ein normaler Entwicklungstag sind wahrscheinlich so zwischen 50 und 75 % und integrieren.

R1: Okay. Wie viele Jahre hast du denn schon so Erfahrung in Software-Entwicklung?

I4: 15? Also 10, 15 Jahre. Irgendwas dazwischen. Also durch das Studium und danach hat—

R1: Und wie lange schon in der Firma?

I4: In der Firma bin ich jetzt seit vier Jahren.

R1: Und in der aktuellen Position, so als Lead-Technical…

I4: Naja, das ist ja projektspezifisch der technical Lead. Beziehungsweise dann halt, also dadurch, dass wir klein sind, wir haben halt, jeder hat so seinen Fokus. Also wir sind halt organisiert—also jetzt kommen wir doch schon auf die Strukturen. Bei uns gibt es halt quasi einen Teamleiter und der halt die Entwicklung im Team mehr oder weniger koordiniert für die Sachen, wo halt auch sein Fokus und wo er mit drin steckt, aber ich habe zum Beispiel ein Open-Source-Projekt, wo ich halt auch dann der technical Lead bin, weil da steckt er nicht so drin und dann wird halt eher nur mal über Aufwände gesprochen. Also sprich, was ist gerade priorisiert, das heißt müssen wir das gerade machen? Brennt es grad wo mehr, dass man halt einfach dann switched und die Rolle halt wechselt.

R1: Und mit welchen Frameworks und Tools arbeitet man so gewöhnlich?

I4: Wir arbeiten unglaublich viel mit alles, was im Rahmen von Selenium stattfindet. Also quasi alles in dieser Bandbreite ist das, was man, also das was unseren Stack am besten beschreibt. Und alles was damit hochkommt und runterfährt.

R1: Gibt es da Beispiele?

I4: Naja, wir haben, wenn ich zum Beispiel das Open-Source-Framework entwickle, dann basiert das auf Selenide. Selenide ist eine API um quasi Selenium wieder zu verwenden. Damit steuert man den Browser, dazu gehören halt die Chrome-Treiber, dazu gehören dann Projektstrukturen mit denen das ganze macht.

R1: Okay und dann mit, das andere, also die richtigen Anwendungen, die man ja testen würde, die sind dann eher nicht so, also Datenbanken, habt ihr dann damit zu tun, oder weniger?

I4: Also dadurch, dass wir Datenbanken an sich testen wir selten, weil wir sind, wir kommen meistens ein bisschen später. Also sprich, dadurch dass wir als externe eingekauft sind, sind wir meistens im Bereich von Acceptance-Tests oder quasi Integrationstests halt zu finden oder in der Testautomation. Oder funktionale Tester haben wir auch. Aber dadurch kommen wir—es kann sein, dass wir in bestimmten Punkten, also bis auf die Datenbank-Ebene kommen selten runter. Also dann muss schon, also dann geben wir das eher wieder an die Entwickler weiter. Also sprich wir könnten dann, es gibt mal so Fälle wo man die Vermutung hat, dass das quasi an der Datenbank liegt wenn man irgendwelche Performance-Issues hat, wenn man einfach sagt hier das kann, das muss irgendwie einem ganz anderen Layer liegen, das kann jetzt hier da nicht mehr dran liegen, weil das haben wir alles ausgeschlossen, aber eher selten. Also Datenbank eher selten. Es sei denn quasi im Rahmen von unseren eigenen Entwicklungssachen, wo wir dann halt auch mal irgendwelche… aber selbst da ist man ja, also dann testet man ja eher seine Funktionalität und nicht die Funktionalität der Datenbank an sich.

R1: Okay, das waren so ein bisschen so die allgemeinen Fragen, jetzt geht’s dann tatsächlich in den Konfigurationsbereich rein. Was verstehst du denn unter dem Begriff Konfiguration überhaupt?

I4: Unglaublich viel. Wir haben einen… eines unserer Hauptprodukte ist ein Testframework, was für Last- und Performancetests werden. Und das wurde jetzt seit über 10 Jahren entwickelt. Das heißt, man kann sich vorstellen, dass die Bandbreite an Features und Sonderlösungen, die man irgendwann mal braucht bei so einer Software, dass es einfach wächst und wächst und wächst. Man möchte natürlich auch alles ein- und ausschaltbar machen, weil nicht jedes irgendwelche immer laufen sollte, sondern muss halt deine Spezialfälle, die du unterstützt, halt auch konfigurierbar machen. Und Konfiguration kann einfach sein, es kann aber auch unglaublich komplex sein, weil du halt dann einfach dann bei 10 Jahre alter Software, wo Features hinzugekommen sind, einfach mal dann einen eigenes Lexika brauchst oder ein eigenes Kompendium um zu verstehen welcher Schalter was macht. Welcher Schalter läuft auf welchen Ebenen? Weil das Tool kann wieder auf verschiedenen Ebenen laufen, also das ist quasi so, ich sag mal eine Konfigurationsherausforderung.

R1: Was bedeutet jetzt Ebenen in dem Kontext?

I4: Na das Tool kann, das kann halt in verschieden Modi laufen. Es gibt halt so Modi, da wird das über einen HTML-Unittreiber gesteuert, dann hat man halt relativ viel Zugriff auf die ganze Infrastruktur, auf den Code, auf das DOM und was passiert oder man kann das jetzt dann mit einem normalen Webtreiber laufen lassen. Da hat man dann, das ist dann so als hätte man dann einen richtigen Browser laufen, wo man dann relativ wenig Möglichkeiten hat und damit, wenn man weniger Möglichkeit hat, dann kann man nicht alle Sachen und Daten rausziehen, die man sonst hätte. Das heißt, bestimmte Schalter, die in dem einen Modus laufen und funktionieren, sind auf den anderen einfach nicht anwendbar, weil die Möglichkeiten, die technischen Möglichkeiten nicht gegeben sind. Sei es aus fehlenden APIs oder auch aus Security-Gründen.

R1: Okay, jetzt hast du ja sehr über Konfiguration in deinem fachlichen Feld, also die fachliche Software ist ja das Testing-Framework, hast du… wie weit stehst du eigentlich so in der Rolle zu technischer Konfiguration, also Infrastructure-Configuration?

I4: Vor allen Dingen—

R1: Ist das für dich auch Konfiguration erstmal?

I4: Es ist auf jeden Fall Konfiguration. Also es ist halt, also quasi, es muss—ich bin dann meistens auf Projektebene Infrastruktur-Konfiguration. Das heißt ich konfiguriere mal einen Jenkins-Job, gucke dass der halt die Post-Steps, die Pre-Steps, dass die ganzen, dass die Sachen zur richtigen Zeit gerufen werden. Also das ist natürlich eine Konfiguration. Die ist aber in der Regel viel einfacher als die technische, also quasi als die Konfiguration des Projekts selbst, weil da einfach mehr Parameter offen sind. Also im Vergleich zu so einer… Was schon wieder schwieriger wird, wird wenn man dann Infrastruktur-Konfiguration mit Projekt-Konfiguration verbinden muss. So ein beliebtes Thema ist ja in der IT grad Docker. Und jeder baut sich einen Docker für alles. Das Problem ist halt einfach, dass die… den meisten Leuten ist halt gar nicht bewusst, dass die Art, wie es gebaut wird meistens… also man sieht dann immer so Probleme und die Probleme drehen Kreise. Das heißt man findet irgendwann was über ein Problem heraus und man sieht dieses Problem alle zwei Wochen immer wieder auftauchen in der selben Art und Weise. Zum Beispiel—also ein beliebtes Problem—ich kann meinem Chrome, den es in einem Dockercontainer gibt, weil es ist ja ganz toll meinen Chrome im Docker zu haben, den kann ich nicht anständig automatisieren, weil ich dazu halt meinem Docker sagen muss du musst als Admin laufen oder ich muss meinem Chrome sagen du darfst jetzt nicht im Sandbox-Mode laufen. Also das sind halt dann, das sind halt auch so Konfigurationen, wo sich halt dann Infrastruktur-Konfiguration und Projekt-Konfiguration überschneiden, wo man dann halt auch wirklich in den Projekten teilweise Konfiguration für die Infrastruktur mitgeben muss, damit halt der DevOps überhaupt in der Lage ist das auszuführen. Weil der halt von dem System her in dem Docker gar nicht die Möglichkeiten hat bestimmte Sachen. Also wenn der jetzt nicht wirklich dann jemand ist, der den Dockercontainer aufmacht, der den entsprechend anpassen kann, der dann quasi Umgebungsvariablen so setzen kann, dass die halt immer mitziehen. Das sind ja die meisten Leute auch nicht. Das heißt die verwenden zwar Docker, weil es cool und hip ist, aber wenn Docker dann macht Mäp, dann ist es vorbei.

R1: Wie lange arbeitest du da so prozentual pro Woche an Konfigurationssachen?

I4: Das ist so phasenabhängig. Zum einen hat man so eine initiale Konfiguration für so ein Projekt, die ist… meistens überschaubar, das ist… mal so am Anfang so eine Stunde, wo man URLs einträgt, bestimmte Settings und die htaccess, also quasi die Authorisierung für die Systeme. Und dann meistens noch mal wenn das ganze auf die CI geht, weil ja jeder hat verschiedene CI-Lösungen. Das heißt, da kannst du von BitBucket über einen einfachen Jenkins, über irgendwelche Teamservices bei Microsoft, da gibt es so viele unterschiedliche Sachen und da muss man halt auch auf jeder Ebene fängt man eigentlich wieder… also dem selben Gebiet an, aber man hat andere Probleme. Weil halt dann Sachen ein bisschen anders wieder funktionieren in den Umgebungen.

R1: Und auch wenn man jetzt die fachliche Konfiguration sehen, wie ist da, also ist das prozentual die Woche? Das war jetzt ja eher die technische, oder?

I4: Naja, das kann man… also quasi, da geht mal ein Tag drauf. Also ich kann es halt nur so in fixer Zeit ungefähr sagen, weil pro Woche, also so viel bin ich nicht in den Projekten drin. Ich kann halt sagen so initiale Konfiguration ist eine Stunde, also für das Projekt und für so eine CI kann da mal ein Tag draufgehen bis man dann die Fehler alle behoben hat.

R1: Hast du typischerweise mit der Konfiguration eines monolithischen Systems zu tun oder eher so mit Framework- oder Tool-Konfiguration—

I4: Vor allem Framework- und Tool-Konfiguration. Monolithisch eher selten.

I4: Wie siehst du da eigentlich so den Stellenwert oder die Wichtigkeit von Konfiguration im Software Engineering oder Softwareentwicklung?

I4: Unglaublich hoch. Also jetzt kann ich wieder sagen—das ist zu unserem Lasttest-Tool—wir fahren da ja in irgendwelchen Cloudrechenzentren irgendwelche Server hoch und müssen die dann halt einfach mit unserer Automation bespielen, damit wir dann quasi Last auf denen Endsystemen ausüben können. Und wenn wir das nicht über eine einfache Konfiguration, also quasi im Rahmen des Möglichen, einfache Konfiguration abbilden könnten, dann wäre man da allein mit der Konfiguration von so einem System, wenn man das alles einzeln nacheinander machen würde, würde man nicht fertig werden.

Also, weil wenn man sich vorstellt, man fährt irgendwie dann hunderte von Maschinen hoch und müsste die alle einzeln konfigurieren und könnte die halt nicht über eine Automation oder automatisierte Lösung einfach bespielen. Oder selbst auch im Rahmen von Projekten und Testprojekten lohnt es sich manchmal auch Automation oder Konfiguration zu automatisieren, weil man möchte ja eine gewisse Testbarkeit erreichen, das heißt die Systeme müssen immer gleich aufgesetzt haben. Wenn man jetzt ein komplexes System, wie einen Onlineshop hat, mit verschiedenen Paymentanbietern, mit verschiedenen Quotas, die man einstellen kann, mit verschiedenen Produkten, mit Verfügbarkeit von einem Produkt und jetzt hat irgendjemand vielleicht einen Schritt vergessen und das löst dann ein Problem im Caching aus oder beziehungsweise lässt ein Problem im Caching nicht auftreten, weil das vielleicht erst ab 24 Produkten auftritt und nicht ab 23. Also jetzt, komisches Beispiel, aber gibt manchmal echt komische Sachen. Und wenn man sowas dann nicht automatisiert, damit man wirklich immer die selbe Voraussetzung hat um einen Test auszuführen, dann hat man halt schon verloren, weil die Ergebnisse, die man halt liefert, nicht vergleichbar sind. Also grad so in unserem Bereich ist Konfiguration und Vorkonfiguration ein großes Thema. Das wäre ja in einer perfekten Welt, wäre man ja  als, wenn man ein System testet, würde man ja immer wieder dasselbe System vorgesetzt kriegen. Also sprich, immer wieder ein neues System mit der selben Vorkonfiguration damit man halt auch vergleichen kann, ist das auch das, was ich gestern hatte. Aber tatsächlich laufen ja so Testprojekte, da läuft relativ viel parallel, meistens kommt das Testen noch mitten in der Entwicklungsphase, also eigentlich wir sagen halt wir hätten gerne irgendwie dann, wenn ihr mit eurem Code zufrieden seid, dann kommen aber Projektmanager, die sagen ne, das ist zu spät, wir müssen da ja live gehen, also müsst ihr eher anfangen und dann kommt man da zu irgendwelchen Race-Conditions und… also in sofern hat man halt nie dieses System, sodass es halt fertig ist, sondern man arbeitet immer auf einer sich wechselnden Welt und dann muss man auch, also auch im Code hat man da einfach viele Stellen, wo man dann halt einfach schnell eine Konfiguration austauschen muss um halt das nicht ständig und überall zu machen. Also auch das sehe ich quasi als Konfiguration, wenn man halt seinen festen Code-Teil hat, also sprich man automatisiert, ich gehe durch so eine Shop über Warenkorb bis hin zu meine Bestellung zu machen. Dann ist für mich auch ein Teil der Konfiguration, wie ist jetzt der Selektor von so einem Warenkorb-Button. Also das ist jetzt zwar eine sehr spezifische Konfiguration, aber im Endeffekt ist es halt auch eine Variable, die man einfach austauschen muss, die vielleicht jetzt nicht unbedingt in einer Konfigurationsdatei als solche steht, aber halt auch so einem Setting gehört, was halt einfach… weil der Rest bleibt ja fest und der Teil ist halt auch eine Konfiguration, also das heißt eigentlich so im Testbereich hat man halt eigentlich ständig ist man am Konfigurieren. Also man probiert seinen Code so generisch und dynamisch wie möglich zu halten um halt schnell [?] zu können.

R1: Jetzt hast du ja vorhin gesagt, dass du ja eher weniger konfigurierst. Heißt das, dass deine Kollegen das dann mehr machen, oder?

I4: Die machen sehr viel, also quasi im Rahmen von solchen Lasttestprojekten. Da wird halt wirklich jedes Mal so ein ganzer Shop durchkonfiguriert.

R1: Und die machen prozentual dann schon—

I4: Die machen mehr Konfiguration. Also die machen wirklich mehr Konfiguration, weil die bereiten ja dann auch die… also da gibt es ein initiales Setup. Das dauert halt in so einem Lasttest vielleicht so ein, zwei Stunden. Also dauert schon mal das initiale Setup ein bisschen länger. Dann hat man sein festes Template. In dem Template werden dann Sachen angepasst. Manchmal werden ganze Abläufe anders, weil sich halt Onlineshops auch unterschiedlich verhalten. Manchmal sind es aber tatsächlich—wenn die nah an ihrem Standard bleiben—sind es halt eher nur noch solche Selektoren anzupassen. Und dann kann es sein, dass so ein Projekt, wenn es nur Selektoren sind, dann geht es halt relativ schnell. Wenn es, wenn dann noch Flüsse angepasst werden müssen und Abläufe, dann dauert es halt länger. Dann ist es halt auch wieder mehr Programmieraufwand in dem Sinne.

R1: Vielleicht mal so… du hast ja gesagt sehr hoher Stellenwert Konfiguration in Softwareentwicklung oder Software Engineering. Hat dich eigentlich so deine Uni oder deine akademische Ausbildung darauf vorbereitet?

I4: Ne.

R1: Ok. Hättest du dir da mehr gewünscht da in deiner Ausbildung?

I4: Weiß ich nicht, ob das in dem Maße möglich ist. Also quasi als ich das gemacht habe, da war es noch cool einen Raytracer per Hand zu programmieren. Also das ist halt der Klassiker, aber so in Richtung von Konfiguration war da relativ wenig auch so IO-Sachen war auch wenig. Also das sind, ich glaube das finde ich, ist halt die Uni in dem Teil zum Teil auch so ein bisschen der falsche Platz. Also zumindest wenn es um das reine Handwerkszeug geht, weil ich finde halt, man sollte dann lieber irgendwie in der Lage sein die Abläufe zu verstehen und programmieren zu können, weil das ist halt viel wichtiger, weil wenn man, also wir machen halt auch viel mit Praktikanten und quasi Uni, also Studenten von der Uni. Und wenn du dann erst anfangen musst, denen das programmieren beizubringen, das ist schwieriger als denen zu erklären ja, es gibt diese Konfigurationen und da musst du halt so und so damit arbeiten also quasi, das ist schon einfach so, das ist ein neues Zwiebel-Layer oben drauf, also dann finde ich, das kommt dann nach dem eigentlichen Handwerkszeug. Also natürlich wenn alles davor fertig ist, dann würde ich mich natürlich auch freuen, wenn irgendjemand kommt, der halt quasi auch die Konfigurationssachen schon versteht und dafür ein Bild hat, aber meistens sind Konfigurationen je nach Projekt oder je nach Anwendung so speziell. Ja.

R1: Okay, da haben wir so grob jetzt die Konfiguration, jetzt gehen wir mal so wie man damit arbeitet. Jetzt haben wir es schon ein bisschen gehört, aber noch mal so genau die Frage, ob die Konfiguration von Systemen, Tools, Infrastruktur, Frameworks dich vor Probleme stellt und wenn ja, welche sind so mit die schwerwiegendsten Probleme, die halt so vielleicht die meiste Zeit mit in Anspruch nehmen?

I4: Ich glaube so Fehlerbehebung. Also das sind halt eher dann so also das ist [?] Misskonfiguration oder quasi Unwissenheit über Wichtigkeit verschiedener Konfigurationen. Also es gibt—also das ist halt das, was ich vorhin so gemeint habe—es gibt halt, eigentlich gibt es den meisten Softwareteilen gibt es für irgendwas einen Schalter, aber die sind dann halt nicht so dokumentiert, dass man sie einfach findet. Also es geht ja schon los, wenn man irgendwelche Standardtools verwendet und die haben halt irgendwelche CLIs und halt auch quasi wie man einen Aufruf von einer CLI dann macht. Also quasi Commandline-Interface. Das ist ja auch eine Art von Konfiguration, wo du dem dann halt jetzt sagst du machst das jetzt im Batch-Mode um ein neues Setting zu schreiben. Also quasi ein Setting zu setzen, was du sonst gar nicht anders konfigurieren kannst. Und bis man halt solche Sachen findet, damit man halt irgendwie mal etwas wegkonfigurieren kann, wo man sich sicher ist, es muss total einfach sein. Also Beispiel letzte Woche: Ich sollte ein Logging wegkonfigurieren. Also man stellt sich das sehr einfach vor. Log4J ist ein gutes Framework, das wird da untendrunter verwendet. Also gut, Loggingkonfiguration nehmen, ich muss jetzt nur dann an die und die Stelle das folgende schreiben. Mache ich. Geht nicht. Okay, ich habe herausgefunden ich muss in meinen Systemkonfigurationen irgendwas umschreiben, also wirklich in meinem Path, was dann wieder auch nicht geht, weil das sind ja wieder irgendwelche Docker-Container. Also sprich, wenn ich dann als Testingeneur hintendran nur die Software liefere, dann kann ich den DevOps unterstützen, aber wenn der DevOps halt auch nur ein Softwareentwickler ist und nicht der DevOps der Container, dann kommt der halt da nicht ran. Das heißt ich muss dann wieder gucken, wie ich die Konfiguration irgendwo umsetzen kann oder speziell setzen kann ohne, dass ich halt auf Systemebene konfigurieren muss. Wo dann halt einfach für mich ein sinnvoller Schalter vergessen wurde in der Software. Also, das sind dann halt so Sachen. Das dauert halt. Da denkt man sich okay, das ist eine Zeile Code, ich google kurz, ich finde es, okay ne, das scheint mehr zu sein. Ich probiere das aus, ich probiere das aus, dann versucht man sich irgendwie über Try and Error durch die nicht dokumentierten Lösungen durchzusuchen bis man halt irgendwann eine Variante findet, die funktioniert. Und auch wenn man die Software entwickelt und in der Open-Source-Welt hat man ja relativ viele, also es gibt viele gute Einzellösungen. Es gibt wenig gute komplexe Lösungen. Also wir haben ja ein Tool geschrieben, womit man eine Testautomation im Web schreiben kann und da haben wir viele so von den guten Einzellösungen genommen und haben die halt damit verbunden, damit man halt einfach wirklich die Webseite automatisieren kann um zum Schluss einen anständigen Report rauskriegt, von irgendwie einem brauchbaren Reporting-Framework, was überall bekannt ist und was auch verwendet wird. Das heißt damit man den Leuten auch ein ähnliches Look and Feel und einen gewissen Komfort bietet, damit die sich halt nicht auf irgendwelchen XML-Dateien zum Schluss—wenn man einen Projektmanager auf die XML-Dateien loslässt, dann kriegt man nur ein Fragezeichen und kein Verständnis. Und dann weiß man, okay diese Open-Source-Lösung wird von dort und dort entwickelt, okay das ist In-House. Das heißt, die entwickeln ihr Projekt und machen ihre Lösung und geben halt ihre API frei. Das ist relativ safe, weil die sind eine große Firma. Läuft. Dann hast du irgendjemanden, der dafür eine Erweiterung geschrieben hat. Oder quasi in sein Framework eine Erweiterung dafür hinzugefügt hat, die natürlich dann auf einer Version weiter zurück sind als das Hauptframework. Das heißt man muss gucken, wie weit kann ich das Hauptframework updaten damit ich quasi nicht den Support innerhalb von meinem zweiten Framework verliere. Das heißt allein dieses Dependency-Management ist halt auch schon gar nicht so einfach und ist halt auch eine Konfiguration. Das heißt da muss man halt auch sein Toolset dann kenne. Wie schalte ich bestimmte Dependencies aus? Wie ermögliche ich? Wie gucke ich da? Was muss ich alles gucken? Was muss ich mir merken, wenn ich jetzt an dem Framework ein Update mache? Was sind die Key-Features, die danach noch funktionieren müssen? Die ich vielleicht nicht durch einen Test abbilden kann, weil der Test einfach… den kann man halt nicht mocken, sondern dafür muss man wieder ein eigenes Testsystem schreiben um sein Testsystem—das ist ja dann, das ist dann bei uns so ein Henne-Ei-Problem: Wir schreiben Testsoftware und wir müssen unsere Testsoftware auch testen und können halt nur bis zu einem gewissen Grad auf unsere eigene Infrastruktur zurückgreifen, weil wir müssen dann halt irgendwie wieder was anderes verwenden damit wir halt einfach bei uns Fehler ausschließen können oder quasi einfach nicht sagen können ja der Fehler kommt durch uns selbst, sondern wir müssen halt uns auch gut testen.

R1: Vielleicht gibt es da so ein Beispiel, so ein besonderes Tool/Framework, was so besonders Probleme oder Sachen verursacht?

I4: Ne, das ist eigentlich bei allen gleich. Also das ist tatsächlich bei allen gleich und meistens hängt es an der Dokumentation. Also wir benutzen zum Beispiel relativ gerne Selenide. Und Selenide ist an sich einfach zu benutzen, ist aber schlecht… was heißt schlecht? Schlecht bis wenig dokumentiert, weil die halt einfach sagen unser Tool ist so einfach zu benutzen, braucht man keine Dokumentation. Ich lasse die Aussage einfach mal so stehen—für gewisse Sachen braucht man einfach Dokumentation. Wir probieren zum Beispiel für unser Open-Source-Tool, wir haben das bei GitHub, nutzen da die Wiki-Funktionalität und probieren halt dort auch für alle wichtigen Teil halt auch Dokumentation mitzugeben um halt auch die Nutzer dann nicht gegen die Wand laufen zu lassen.

R1: Habt ihr da eigentlich schon mal so Feedback von Nutzern bekommen bezüglich Konfigurationsschwierigkeiten?

I4: Ja, wir haben ja auch quasi—unser eigenes Tool setzen wir ja selbst ein und das heißt wir kriegen dann halt auch von unseren Anwendern, also von vor allen Dingen von uns selbst, so Sachen. Oder wir haben halt auch bei GitHub dann mal irgendwie Empfehlungen von irgendwelchen Nutzern bekommen. Die halt dann geschrieben haben, hier, ich hätte gerne das Feature. Wo man dann halt auch—also ich verstehe dann warum sie das haben—das war auch so ein, tatsächlich war das so ein, die haben sich ein Feature gewünscht, was halt Konfigurierbarkeit, also einen Teil der Konfiguration wegnimmt, weil das halt dann bestimmte Sachen einfach selbst macht, was man aber quasi in unserem größeren Zusammenhang ist es halt dann schwieriger umzusetzen, weil du dann zum Beispiel deine CIs, deinen CI-Support verlierst, weil in einer CI kann es ja sein, dass der DevOps den Chrome und irgendwas auf irgendeine gewisse Version gepinnt hat. Und dazu halt auch passend den Chrome-Treiber. Und wenn du jetzt die Automatisierung einbaust, dass halt standardmäßig das alles automatisch gezogen wird, also quasi latest, latest and greatest, dann machst du das halt so ein bisschen kaputt. Das heißt dann machst du zwar an der einen Stelle, also für die einfache Testausführung oder für die initiale Setup, machst du es einfacher, aber für den komplexen Anwendungsfall musst du dann wieder Weichen einbauen, musst das dann wieder verhindern. Das wird dann…

R1: Ja okay, sehr interessant. Genau. Also, was ich auch so ein bisschen rausgehört habe ist ja auch, dass die Kombination auch die großen Probleme macht auch zwischen Frameworks. Und was ist da so das größte Problem? Ist da so ein bisschen das Problem das Deployment, das Testing, oder die Zusammenentwicklung, oder den Stacktrace zusammenzubauen bei der Kombination? Oder alles? Also gibt es da bestimmte Sachen, die da wirklich rausstechen?

I4: Schwer. Also quasi es sind halt immer wieder so Einzelprobleme. Also man hat halt wirklich man, also bei den einen ist es halt quasi das Dependency-Management, was schwierig ist, beim Nächsten ist es halt die Dokumentation der Konfiguration. Manchmal auch dann Defaults zu überschreiben oder manchmal reicht es auch schon einfach zu wissen, dass man es konfigurieren kann. Allein das ist schon manchmal schwierig, weil man das halt einfach nicht weiß. Also es gibt da keinen, also gerade dadurch, dass ich halt in vielen und verschiedenen Rollen… also meistens lässt sich halt, also relativ viele Sachen lassen sich auf Konfiguration zurückführen, also viele Probleme. Das heißt es gibt immer eine Konfiguration, die funktioniert oder man hat halt den einen Fall gefunden, der halt noch nicht supportet ist. Also und dann muss man irgendwas einbieten(?) und entweder ist es halt wirklich mal ein Software-Fehler oder es ist halt wirklich mal ein Konfigurationsfehler, dass halt, also dass man einfach die Möglichkeit hat irgendwas noch nicht zu sagen, hier in dem Fall möchte ich das aber nicht, weil das dann zu einem Fehler führt. Aber das ist halt, es lässt sich halt nicht so generalisieren in meinem Fall, weil ich halt an vielen Stellen bin, ich kann nicht sagen das ist immer mein Pain-Point, weil manchmal, bei manchen Frameworks geht es gut und dann ist es halt auch einfach auch zum Beispiel das schlecht dokumentierte Framework, ist es sehr einfach denen ihre Konfiguration zu überschreiben, wenn man weiß wie die arbeiten, wenn man das Framework so ein bisschen verstanden hat. Also das ist jetzt für mich kein Pain-Point in dem Sinne mehr, weil ich halt einfach das Prinzip dahinter verstanden habe. Aber am Anfang quasi herauszufinden, dass das halt mehr im Code dokumentiert ist, das einem bewusst ist, dass es die Klasse gibt und wenn man dann halt einfach zwischen verschiedenen Modis wechseln möchte, dann… das zu finden.

R1: Gehört das dazu wenn man konfigurieren muss, dass man eigentlich schon ein tiefes Verständnis von den einzelnen Frameworks hat, oder?

I4: Also in meinem Fall schon, also gerade wenn ich die Open-Source-Frameworks miteinander verbinde, dann muss ich zu großen Teilen einfach auch wissen, was die tun. Und muss halt auch dann mal gewillt sein, die auch zu erweitern oder quasi Lösungen zu finden oder mich halt auch mal mit Sachen auseinanderzu—also wenn ich jetzt in einem Framework einen Fehler finde, dann muss ich halt den auch zu denen zurückcommiten, das heißt ich muss denen sagen es existiert der Fehler. Wenn die jetzt eine Build-Structure haben, die irgendwie angenehm ist, dann bin ich auch gern dazu gewillt da mal einen, quasi einen Pull-Request zu machen und quasi wirklich denen was reinzukippen, wenn die jetzt eine Build-Struktur haben, die irgendwie meinem eigenen System nicht matched, ist es halt wieder schwierig, weil dann, man möchte ja sein eigenes System auch nicht unglaublich belasten. Also weil dann hat man eine neue Build-Infrastructure, die braucht natürlich auch wieder Ressourcen, die hat vielleicht wieder andere Dependencies als deine eigene. Dann funktionieren manche Sachen nicht mehr. Also gerade auch wenn—das ist jetzt ein anderes Thema—aber gerade wenn man wieder in Richtung Virtualisierung geht und mit Docker arbeitet und wenn man jetzt seinen Docker nicht auf einem Linux betreibt, sondern irgendwie im Windows oder auf einem Mac, dann ist man wieder vor ganz neue Hürden gestellt, weil man hat da seinen Docker…Umgebung, die da einfach mitgeliefert wird, aber plötzlich wird dir halt gesagt na wenn du das machst, dann laufen aber deine Virtual Machines nicht mehr, weil die halt einfach die Rechte dafür in deinem System, also es gibt halt nur eins was das haben kann, also entweder du hast Virtual Machines oder du hast Docker. Ja, was machst du? Also das ist dann, das sind so Sachen, was halt auch so, also im Endeffekt ist das auch nur eine Art von Konfiguration. Halt die Konfiguration deines Systems. Du brauchst halt beides, weil du brauchst halt die Virtual Machine um halt irgendwas zu testen damit du halt nicht dein eigenes System zumüllst. Du möchtest ja auch nicht irgendwie dann, also gerade wenn man halt viel mit Betriebssystemsbefehlen arbeitet und Sachen hin und her schiebt oder mal irgendwie im Zweifelsfall sich vertippt und plötzlich sind die Rechte auf irgendwelchen wichtigen Ordnern einfach mal umgesetzt. Unwiederbringlich. Oder man seinen eigenen Admin einfach mal aussperrt. Gibt es relativ, also gibt es so eine kleine Menge an Linux-Befehlen, die das sehr einfach möglich machen ohne, dass man irgendwie, man denkt nicht drüber nach in dem Moment. Man findet eine Lösung, mach guckt, man möchte es ausprobieren, versteht vielleicht nicht ganz was man da bei StackOverflow in dem Moment gelesen hat, weil derjenige es vielleicht auch nicht ganz verstanden hat und schon hat sich jemand ausgesperrt aus seinem System. Und das möchte man natürlich nicht in seinem Hauptsystem machen, sondern dann möchtest du halt lieber eine VM haben. Und wenn du dann aber in deinem parallel dazu einfach einen, also quasi dass du das Docker auch noch in deinem System brauchst um bestimmte Sachen hochzufahren, dann bist du halt schon wieder aufgeschmissen.

R1: Gut, wie verwaltet ihr eigentlich eure ganzen Konfigurationen und dokumentiert—okay, dokumentiert haben wir so ein bisschen…

I4: Wir haben für unsere Softwareprojekte, die konfiguriert werden müssen, haben wir halt Wikis, wo wir dann wirklich die Wikis oder halt Dokumentationstools, wo halt dann einfach die Konfigurationen enthalten sind. Wir dokumentieren Konfigurationen im Code zusätzlich, also sprich mit irgendwelchen Templatedateien oder im Code jetzt an der entsprechenden Stelle, wenn man reingucken kann, dass halt da auch noch mal steht, wer was macht. Also das ist so einmal Dokumentation auf verschiedenen Ebenen und die, ein Großteil unserer Dokumentationen, also wir haben eigentlich relativ viel unterschiedliche Formate. Also je nach Anwendungsfall. Für so Standardsachen Property-Dateien. Also wir sind eine Java-Firma, da sind Property-Dateien einfach so der Standard für viele Sachen. Wenn es jetzt um Lokalisation geht, sind Property-Dateien nur begrenzt hilfreich, weil die einfach vom Format her dir nicht nicht die Möglichkeiten bieten. Das heißt dafür nehmen oft dann halt LaTeX, ähm nicht LaTeX… YAML. Dann nehmen wir halt quasi YAML-Dateien, weil die halt von der Struktur das einfacher wieder abbilden können. Da kannst du einfach Pfade hinzufügen, kannst die erweitern, kannst die überschreiben und kannst dir ein relativ einfaches Toolset machen und kannst das halt auch Leuten einfach erklären. Das heißt die müssen nicht die Property-Hölle und sich die Keys merken und das und dort, sondern es ist halt dynamischer. Wenn es jetzt zum Beispiel geht, wenn man (?) Testdaten haben möchte, was halt die nächste Ebene sind, die möchtest du weder in Property-Dateien, noch in YAML-Dateien haben, weil da wird die Struktur schon wieder—also YAML bietet zum Beispiel, die haben das Problem, das YAML einfach Sachen eine Autoconversion macht und wenn du dann vielleicht einfach nur auf Strings arbeiten möchtest oder auf irgendwas anderes und du schreibst halt vorne, das ist halt einen schon weiter bei einer Lokalisation, du schreibst halt vorne im String „Yes” hin und machst den nicht als String, sondern einfach nur als Wort. Dann wissen die wenigsten Leute, dass das einfach ein festes Keyword ist in YAML und dass das einfach auf True gemapped wird und plötzlich hast du ein Mapping von wo halt einfach deine Localization, wo du Yes einfach nur zu Ja machen wolltest, von True auf Ja. Findest du? Nein. Runtime Exception. Also das sind halt auch so Konfigurationssachen, wo man die Spezifikation bis ins letzte wieder kennen müsste im YAML bis man halt mal sowas dann versteht. Oder dann im—also wir benutzen dann für die Daten, da war ich eigentlich stehen geblieben—für die Daten nutzen wir oft halt JSON-Formate. Weil wir machen halt unsere Rahmen, also unser Testrahmen ist meistens das Web. Das heißt man kommt immer mit JavaScript in Kontakt. JSON ist ein einfaches Format, man kann einfach Keys hinzufügen. Man hat die verschiedenen Datentypen, also Array, Objekte, man kann es relativ gut strukturieren, es gibt wieder auf der Seite gibt es in den meisten Programmiersprachen guten Support um halt dann einfach wieder Sachen zu serializen, deserializen. Also quasi das ist dann einfach, das heißt unsere Konfiguration ist auch schon wieder vielfältig.

R1: Und wie speichert ihr… habt ihr da richtige Repositories, die Konfiguration speichern?

I4: Na das ist ja meistens im Projekt. Das heißt im Projekt, jedes Projekt hat halt sein eigenes Git und da kommt das halt auch die Konfiguration rein.

R1: Und liegen die Configuration-Files dann an einer Stelle oder muss man sich die praktisch auch zusammensuchen?

I4: Naja, das… also wenn wir jetzt die Sachen, die wir selbst geschrieben haben, haben wir halt quasi einfach einen Config-Ordner und haben halt dort drin die Config-Sachen, was einfach für uns logisch ist und was für uns so ein bisschen historisch gewachsen ist. Das ziehen wir so durch unsere Projekte durch. Wenn es jetzt aber darum geht, dass ich für mein Projekt einfach mal so ein Logging-Framework einbinden möchte, dann muss ich da schon wieder die Konventionen des Logging-Frameworks kennen und kann meine Konfiguration für das Logging nicht mit in meinen Config-Ordner legen ohne das ich wieder Handstände machen muss, sondern dann lege ich den halt am einfachsten dort hin, wo das Logging-Framework den erwartet. Also es wäre schön wenn man alles an eine Stelle legen könnte. Oder wir machen das manchmal ja, also gerade bei Testdaten haben wir auch noch mal eine andere Konvention. Weil wir haben Testdaten auf verschiedenen Ebenen, weil man—Javacode, Package-Ebene ist bekannt?—genau, also das heißt wir strukturieren ja unseren Code und haben bestimmte Teile liegen in bestimmten Packages und für bestimmte Packages braucht man dann vielleicht für bestimmte Konfigurationen, die man woanders nicht haben möchte. Und damit man sich nicht sich so einen Global Space zumüllt, sondern die wirklich spezifisch dort hat, wo man hat, haben wir halt Konfiguration auf Package-Ebene. Das heißt da müssen dann natürlich auch die einfachste Variante das abzubilden ohne, dass man Leute dann irgendwelche Pfade in Dateien anpassen lässt, ist halt einfach, man legt die halt in Java in den Resource-Ordner parallel dazu. Das heißt dann liegen halt auch die Konfigurationen für bestimmte Testfälle, also Datenkonfiguration halt auch wieder parallel dazu. Also das sind auch so Muster. Oder wo wir es zum Beispiel, manche Konfigurationen im Jenkins, liegen sie halt im Jenkins und im Zweifelsfall werden sie halt noch mal irgendwo hin dokumentiert, also gerade wenn man dann irgendwas zum ersten Mal macht und man möchte, dass das irgendjemand noch mal nachvollziehen kann. Oder wenn man viel in Amazon-Cloud oder der Google-Cloud arbeitet und man baut sich da dann halt irgendwelche Cluster auf, man muss die konfigurieren, dann ist ja auch erstmal einer, der sich durcharbeiten muss und man möchte ja nicht, dass… der braucht halt dafür dann bei einem komplexen System halt mehrere Woche bis er halt dann die Zusammenhänge verstanden hat. Also gerade in dem Bereich wird es ja dann, was gibt es da für Services, wie ziehe ich mir da mein Kubernetes-Cluster her, wie mache ich da meine, wie baue ich meinen Loadbalancer auf und solche Sachen. Da gibt es ja alles Lösungen und Konfigurationen, aber man muss sie erstmal finden. Man muss sie sich merken, man muss sie aber auch für die Nachwelt dokumentieren, damit man halt nicht irgendwann in so einem (?) ein Unternehmen hat.

R1: Was würdest du denn jetzt so wie ihr es macht, jetzt (?) sagen? Ist das der größte Vorteil oder der größte Nachteil oder?

I4: Ich glaube der… ein Vorteil ist, dass wir es überhaupt machen. Der größte Nachteil ist, dass wir auch intern erstmal wissen müssen, wo es steht oder ob es schon irgendwo steht. Also wir probieren das zu machen, aber es kostet halt auch Zeit. Und das ist natürlich dann, wenn man so im Unternehmensumfeld, man ist ja auch so ein bisschen vom Geld getrieben. Das heißt man möchte ja auch irgendwie effizient sein. Man kann dann auch nicht zu viel Zeit auf die Dokumentation von sowas verwenden, weil dann. Also halt so viel, dass man noch damit klar kommt. Also ist es vielleicht dann nicht so, dass es gleich auf den ersten Blick wieder alles komplett verständlich ist. Das heißt man braucht dann auch wieder den Hintergrund.

R1: Das schließt ja so ein bisschen so die Frage vielleicht an: Wie kommuniziert ihr denn im Team jetzt habe ich vielleicht eine neue Konfigurationsoption reingemacht oder jetzt habe ich eine Konfiguration hier festgelegt oder so?

I4: Kommt drauf an. Also es kommt, das kommt dann wieder so auf das Tool drauf an und auf den Fokus. Also man informiert schon die Leute, die direkt davon betroffen sind.

R1: Geht ihr rum oder schreibt ihr Email oder?

I4: Na, wir… unterschiedlich. Also manchmal schreibt man Emails. Jetzt bei dem Open-Source-Projekt, da schreibe ich natürlich Release-Notes. Das heißt da steht halt da, was als neues Feature drin ist mit Verweis auf Issues. Mache dann halt Updates in den Dokumentationen, die frei verfügbar sind. Probiere dann halt auch die Dokumentation wieder zu verlinken um halt auch die Release-Notes einfach so ein bisschen… ist manchmal so eine undankbare Aufgabe, weil man irgendwie feststellt, dass Dokumentation ist im Endeffekt nur für einen selbst. Weil du kriegst halt dann so „Ja, warum soll ich denn die Dokumentation lesen wenn ich weiß, dass ich dich fragen kann?” 

R1: Wenn ich das mal so ein bisschen so zusammenfassen kann—also wir kommen gleich zu Konfigurationsfehlern—aber wenn ich das richtig verstanden habe auch mit der Cloud, man muss sich mehrere Wochen einlesen, ist es vielleich so, weil wir haben ja vorhin über prozentualen Anteil der Arbeit gelesen, wenn man es erstmal verstanden hat, geht es dann schnell, aber bis man denn rausgefunden hat, gibt es denn Konfigurationsmöglichkeiten, das braucht immens viel Zeit.

I4: Genau, das ist dann der Pain-Point ist meistens das Finden der Konfiguration und quasi das ausmerzen, also man, das Finden der Konfiguration geht halt mit dem Entdecken von einem Fehler einher. Man hat ein Problem oder einen Fehler und möchte den wegkriegen und gerade bei den komplexen Sachen ist es inzwischen, also ein Programmierfehler ist meistens etwas einfaches. Weil ein Programmierfehler, den findest du, den kannst du lösen. Einen Konfigurationsfehler bist du halt, also da musst du dich halt einlesen. Musst du herausfinden wo der Fehler liegt. Was gibt es für Alternativen? Musst die Konfiguration testen, musst gerade bei den komplexen Sachen kontrollieren, dass halt auch die, dass wirklich nicht nur das testest, was du gerade haben möchtest, sondern auch das, was davon betroffen sein könnte.

R1: Genau, gehen wir zu den Konfigurationsfehlern—sind wir eh schon da—gleich über. Was sind denn genau für dich Konfigurationsfehler? Also wie würdest du denn das so für dich definieren?

I4: Zum Beispiel… Konfigurationsfehler sind einfach Sachen, die das verhindern oder das Laufen des Systems verhindern oder halt zu Nebenwirkungen führen, die man so nicht haben möchte. Das sind so Konfigurationsfehler.

R1: Also Programm, also Code-Fehler irgendwie ist ja auch dann irgendwie ähnliche Auswirkungen. Wie würdest du denn da versuchen die Grenze zu ziehen? Es gibt wahrscheinlich eine graue Area oder so…

I4: Naja, der Code, also im Quellcode ist es eher so, das sind Abläufe und quasi das sind eher so dynamische Sachen sage ich mal, weil man da einen Einfluss drauf hat und während die Konfiguration in den meisten Fällen, ich sag mal in 99 Prozent der Fälle eher statisch ist. Also es gibt auch Konfiguration, die zur Laufzeit sich verändert, aber das ist eher für unsere Testumgebung was spezielleres. Also das ist jetzt weniger, dass man jetzt sagen kann das ist so ein Standard. Also da muss man ja auch so Laufzeitkonfiguration, Systemkonfiguration, Toolkonfiguration, das sind ja so viele Ebenen.

R1: Was sind denn, was du jetzt schon selber vielleicht, du hast ja selber damit schon Konfigurationsfehler erlebt. Was ist denn so der schwerwiegendste Fehler gewesen? Und warum?47:52 

I4: Ich glaube ein Konfigurationsfehler mit dem ich mich am meisten beschäftigt habe, war… wir haben, also der wirklich relativ, also das ließ sich tatsächlich dann—wir benutzen Maven—auf Konfiguration in Maven zurückführen. Also quasi die Lösung war dann einfach die richtige Mavenkonfiguration und da habe ich einfach probiert in unserem Open-Source-Framework Cucumber einzubauen in Kombination mit Allure-Framework, also quasi Allure Report, und Allure benutzt im Endeffekt, die benutzen halt eine Art von Reflection, das man halt dann einfach auf bestimmten Aktionen noch mal reinspringen kann und dann ziehen die sich ihre Daten raus. Und die haben aber auch verschiedene Wege, die haben halt Unterstützung für Cucumber und für Java und jetzt musste man irgendwie herausfinden… wir haben halt unser Tool und unser Tool sollte halt alles können. Wir haben halt so unser Open-Source-Tool, das soll einfach in der Lage sein für Leute, die Cucumber benutzen wollen, die sollen halt einfach Cucumber benutzen um halt ihre Tests zu beschreiben und Leute, die halt auf einer technischeren Ebene sitzen, die sollen halt einfach in der Lage sein Java zu benutzen. Und das halt am besten—ich möchte die halt vor der Konfigurationshölle bewahren, das heißt ich kümmere mich darum, dass die Tools miteinander arbeiten. Das ist so unser (?) plus halt noch Daten. Datenhaltung. Und erstmal zu lernen, dass die beiden Sachen halt nicht miteinander funktionieren. Also gar nicht. Dass man eine Konfiguration für das eine braucht und eine Konfiguration für das andere und das, wenn ich das eine anschalte, das halt einfach dazu führt, dass das andere umfliegt, umfällt. Also ich könnte zwar das eine mit dem einen betreiben, aber ich könnte nicht das andere, also… ja. Das tut sich dann halt einfach gegenseitig weh und das ist zum Beispiel, das kam aus keiner Konfiguration in dem Sinne raus, weil natürlich dieser Anwendungsfall nie von irgendwelchen Anwendern auch bedacht wurde. Weil die denken sich halt „gut, das ist jetzt der eine. Entweder schreibt der seinen Code in Java, dann nimmt er das. Da habe ich ja hier diese Konfiguration, da habe ich das bisschen beschrieben. Und dann findet man auch Lösungen für die einzelnen Probleme. Oder der benutzt halt Cucumber, dann finde ich halt die Lösung für Cucumber.” Aber die Kombination von beiden, das war halt nie von jemandem bedacht. Und das halt dann erstmal herauszufinden, wo der Fehler liegt, wo der herkommt. Man führt das dann ja, das ist ja was, das wird nur bei maven run wird das nur produziert, dieses Problem. Das heißt ich muss dann auch eine Möglichkeit finden das Maven zu debuggen. Das heißt Java ist ja ganz einfach. Man hat sein Eclipse, ich mache da mein Pünktchen, drücke auf den Käfer und ich halte an der Stelle an. Jetzt hast du aber dein externes Tool. Für dein externes Tool musst du entsprechend wieder eine Konfiguration finden, wie du mit deinem externen Debugger arbeiten kannst. Das heißt das musst du konfigurieren, musst wissen an welchen Stellen du dein Pünktchen setzen kannst, damit du dann wirklich nicht zu spät oder zu früh oder nicht schon auf die Schnauze gefallen bist, wenn du an der Stelle bist und das hat halt tatsächlich relativ lange, das war aber wirklich so ein Konfigurationsproblem, wo ich einfach unglaublich lange gebraucht habe. Bei vielen Sachen findet man schnell Sachen. Was auch ein Konfigurationsproblem ist, ist wenn… das ist eher so im Webtreiber-Umfeld. Wenn Konfiguration oder Konfigurationsmöglichkeiten so misused werden. Das heißt wenn man denkt das wird damit gemacht oder es wurde dann auch von den Webtreibern mal kurze Zeit so gemacht, dann haben die festgestellt „ne, die Webtreiber-Spec gibt eigentlich dieses Feature nicht her”, alle Welt braucht das, aber es gibt keine Lösung dafür das sinnvoll zu machen und das klassische Beispiel ist quasi ein Proxy mit einem Webtreiber. Also sprich einen Proxy und eine Proxy-Authentifikation des Proxys über einen Webtreiber zu konfigurieren ohne, dass man halt einen System-Proxy davorschalten muss. Gibt es einfach keine Konfigurationsmöglichkeit ist die Antwort.

R1: Aber es macht trotzdem…

I4: Ne, es gibt einfach keine sinnvoll Möglichkeit ohne, dass man sich wieder irgendwas anderes in seinem Stack kaputt macht oder… aber das erstmal herausfinden auf den Ebenen. Weil man probiert ja dann viele verschiedene Sachen aus. Das ist auch so ein Konfigurationsding, was ewig… bis man zu diesem Wissen gelangt, dass halt keine Lösung auch die Lösung ist.

R1: Wenn man so eine Projekthistorie sieht—ja, man setzt das auf und so weiter und dann arbeitet man—wann treten denn meistens so typischerweise Konfigurationsfehler auf? Beim Aufsetzen oder eher wenn man dann später mehr so was macht?

I4: In unserem Fall meistens bei der Ausführung. Also das ist noch mal ein neuer Aspekt wahrscheinlich für euch. Also da spreche ich jetzt eher quasi so der Standard-Fall, also jetzt so für meine Sachen, eher so am Anfang beim Aufsetzen, aber bei uns in unserem Lasttest-Projekt ist das meistens eher so beim Ausführen. Weil man hat ja, man entwickelt die Tests ja lokal, das heißt man ist auf seiner Dev-Instanz und hat dort ein paar andere Settings oder man überschreibt manchmal bestimmte Settings, die dann zur wirklichen Laufzeit anders laufen soll, wie zum Beispiel ich brauche jetzt—simples Beispiel—ich möchte Infinite Scroll, möchte ich später auf der Webseite nur einem von fünf Fällen machen. Das heißt ich habe zwanzig Prozent. Das bringt mir natürlich nichts, wenn ich das gerade entwickeln möchte, sondern da möchte ich, dass das zu hundert Prozent angefordert wird, damit ich halt auch wirklich das entwickeln kann. Jetzt entwickelt man so, setzt vielleicht die Sachen nicht wieder zurück, weil man vielleicht immer noch einen bestimmten (?54:27) hat und auch mit so einem bestimmten Seed arbeitet, damit man halt auch den Zufall ausschaltet und immer wieder in der selben Bahn läuft, damit man das auch nachvollziehen kann. Jetzt kann es natürlich sein, wenn man in solchen Seeds arbeitet, dass man halt bestimmte Sachen nie sieht. Das heißt man kommt halt, in bestimmte Fehler läuft man nicht rein, weil halt einfach die Konfiguration, die man sich für sein Dev aufgesetzt hat, ist halt nicht das, was später zur Laufzeit passiert, weil dann halt mehr mit einem gewollten Zufall gearbeit wird. Weil halt auch, wir können ja nicht zwanzig Testsfälle um alle zwanzig Kategorien in einem Onlineshop durchzusuchen mit einer gewissen Verteilung, sondern wir schreiben dann natürlich es gibt diesen Selektor für die Kategorien, hol dir alle möglichen Links raus, wähle davon jetzt einen davon aus oder hole davon noch die Subkategorien und das, wie auch immer. Und sowas führt dann halt zu Fehlern, das halt dann gerade bei den ersten Ausführungen halt einfach Szenarien auftreten, die halt einfach in der Entwicklung nie vorgekommen sind. Das ist glaube ich noch mal so ein für euch neuer Aspekt. Weil das passiert sonst nicht so, ich glaube so die klassischen Sachen wurden bei euch schon alle man genannt, aber das ist was, was bei uns speziell ist.

R1: Ja, stimmt.

I4: Und da kann es dann natürlich auch noch mehr, dann kommt es halt quasi wenn man dann die Laufzeitumgebung, also die wirkliche Laufzeit, dann kommen halt die Maschinen. Die erste Maschine ist halt auch nur lokal. Das heißt das kann man noch lokal machen. Weil man dann halt nur sagt mein eigener Rechner ist meine Lastinstanz und ich möchte ja erst mal nur so ne Art Try-Run haben. Ich möchte mal gucken, wird das alles grün. Aber selbst dann hast du ja quasi vielleicht nur zwanzig Ausführungen pro Testfall und damit kann man ja Zufall nicht beschreiben. Also Gesetz der großen Zahlen ist einfach noch nicht drin. Das heißt zur Laufzeit, wenn dann wirklich hunderttausende von Pageviews gemacht werden auf einer Webseite, dann hat man halt, dann sehen die Szenarios anders aus. Und Zufälle anders aus. Genau, das ist sowas, was bei uns immer noch mal kommt. Oder dann kann es halt sein, dass mal so eine Konfiguration einfach… lokal funktionieren Sachen und dann benutzt man aber irgendwelche Features, wo man weiß, die könnten rechenintensiv sein. Man macht so seine Voranalysen und sagt könnte passen so Pi mal Daumen. Jetzt musst du natürlich dann noch mal zurückgehen, muss gucken, stimmen denn meine Zahlen? Habe ich denn die Last erreicht, die ich erreichen wollte? Ne? Also muss ich vielleicht die Anzahl der Lastmaschinen hochfahren. Oder ich habe meine Lastmaschinen, die waren alle nur zu fünf Prozent ausgelastet. Okay gut, ich kann viel weniger nehmen um halt dasselbe zu erreichen. Wo dann halt auch Konfiguration wieder einen monetären Aspekt hat, weil Rechenzeit kostet und wenn man viele Maschinen laufen lässt, dann kann man ja auch viel Geld sparen, wenn man die Konfiguration entsprechend anpasst, halt nicht zu viel, nicht zu wenig. Man möchte ja nicht mit Kanonen auf Spatzen schießen.

R1: Habt ihr da in dem Zusammenhang Wissen bezüglich, welche Option wie viel Performance? Ist das so ein, würdet ihr euch da lieber so ein Modell haben, was man dann konfiguriert und das wird dann so eine Vorhersage machen?

I4: Wir haben dafür eine, ich sag mal, sophisticated Excelsheet.

R1: Ja, das ist der Standard glaube ich bei Firmen.

I4: Ne, wir haben da quasi, das ist ja immer relativ speziell. Das heißt du weißt, du hast deine Grundannahmen für dein System: Du weißt die Maschinengrößen, du hast ja mal ein bisschen exploriert, du weißt mit welchen Maschinengrößen du für was arbeiten musst, du weißt wie viele Agenten du darauf laufen kannst, wie viele gleichzeitig laufen können. Wenn du jetzt echte Browser brauchst, brauchst du halt viel mehr Maschinen, weil die halt viel leistungshungriger sind und solche Sachen. Und da können wir halt dann einfach entsprechen unseren—wir haben halt auch Standardszenarien. Das heißt wir haben halt Szenarien, die besuchen nur. Die sind halt immer relativ kurz. Das heißt die brauchen auch, für die brauche ich nicht so viele Maschinen zu reservieren, weil die haben halt einen viel kürzeren Zyklus. Da können auch drei Maschinen also plötzlich hunderttausende davon machen. Während hingegen wenn ich ein Szenario habe, was halt einfach eine ganze Bestellung macht, das läuft dann halt nicht nur fünf Sekunden, das läuft dann halt im Zweifelsfall mal irgendwie drei, vier Minuten. Das heißt ich muss, um da eine Last auf Bestellung zu erhöhen, brauche ich halt viel mehr Maschinen, die halt gleichzeitig für dieses Szenario da sind. Also das heißt, da sind halt so die Konfigurationen, da kommt man zum Schluss auf so eine Pi-mal-Daumen-Regelung, wo man sagt okay ich habe halt hier, da gibt es dann verschiedene Modelle mit denen man arbeiten kann: Möchte ich eine fixe Zahl erreichen? Möchte ich pro Stunde so und so viel erreichen? Möchte ich einfach so viel erreichen, wie ich möchte? Wir haben ja meistens auch noch damit zu kämpfen—was heißt du kämpfen? Wir haben halt Vorgaben. Wir machen zwar Lasttests, aber ich sage mal wir dürfen ein System zum kotzen bringen, aber es sollte vielleicht nicht umfallen, weil ein Umfall bedeutet halt, dass dann halt noch mehr in Mitleidenschaft gezogen wird. Das heißt du hast dann halt auch nicht—wir haben zwar, manchmal testen wir halt auch bis wirklich ein System tot ist. Auch das ist eher die Ausnahme, weil da halt dahinter auch noch eine ganze Infrastruktur hängt. Heutzutage sind ja auch Onlineshops liegen in irgendwelchen Cloud-Zentren oder in irgendwelchen Rechenzentren und auf so einer Infrastruktur ist natürlich nicht nur einer. Das heißt wenn wir das System zum brechen bringen, dann ist das, also beziehungsweise bis zum Schluckauf, dann ist das vielleicht für den einen mal kurz unangenehm. Wenn wir aber das System zum umfallen bringen, dann ist da nicht nur der Kunde, den wir testen, sondern vielleicht auch der Kunde, der da nebendran liegt, der davon gar nichts weiß, dass wir…

R1: Okay, habt ihr schon sowas erfahren, oder?

I4: Ja, das passiert. Also naja, das kann gerade so in der ersten Zeit—so ein Softwaresystem ist ja natürlich auch in der Entwicklung, also das heißt—und manchmal, was heißt in der ersten Zeit, das kann ja immer mal wieder sein, das heißt irgendjemand findet jetzt einen neuen Technologie-Stack, stellt halt fest, dass die API von dem Tool viel viel toller ist und dass es halt schöner oder einfacher ist und ersetzt halt einfach mal so einen Stack an der Stelle. Der eine Stack war getestet. Das heißt der war safe, der war vielleicht nicht einfach zu nutzen, hatte nicht alle Features, aber den haben wir halt schon zwanzig mal draufgeschossen, alles gut. Jetzt kommt der neue Stack und der hat vielleicht intern hat der vielleicht einen Memory Leak, was halt der Entwickler gar nicht gesehen hat. Und natürlich kann es dann halt sein, dass durch solche Seiteneffekte mal irgendwas zerschossen wird.

R1: Ja, okay.

I4: Oder auch wenn man… die Systeme sind ja heutzutage hochintegriert. Das heißt an einem Onlineshop hängen zwanzig, dreißig Subsysteme dran, das heißt angefangen vom Payment über Lagerverwaltung über Customer-Management, über Produktinformation, über Content-Management, also quasi alles mögliche und die müssen ja dann natürlich auch alle miteinander agieren. Und das heißt wenn die Systeme schlecht konfiguriert sind, wie die miteinander interagieren, dann kann es halt einfach mal sein, du einfach eine Queue an Prozessen aufbaust, die halt nicht mehr abgearbeitet werden kann, die halt einfach ein ganzes System in Mitleidenschaft zieht. Also kann passieren. Muss nicht passieren, aber kann passieren.

R1: Okay, wie gehst du denn typischerweise vor—also ein bisschen haben wir es ja schon rausgehört—um Konfigurationsfehler zu finden und zu beheben, was ist sind so deine typischen Aktionen?

I4: Ich glaube der Klassiker ist, ich benutze die Suchmaschine meiner Wahl, arbeite mit der… also mit der Zeit lernt man ja—also das ist zum Beispiel was, was man an Unis vermitteln könnte—kreatives Nutzen einer Suchmaschine. Also das ist tatsächlich echt was, das wünsche ich mir manchmal, dass sowas vermittelt wird. Wie gehe ich in der Software-Entwicklung mit einem Fehler um und wie nutze ich danach die Antwort? Weil ich bin immer kein großer Freund von „Ich nehme die Antwort, packe die in meinen Code und dann geht’s”. Weil in der Regel baut man sich damit Seiteneffekte ein, die man einfach nicht, die man nicht kennt, weil man den Code dahinter nicht verstanden hat. Aber, also quasi, ich nenne das so StackOverflow-Driven-Development. Das ist so Panic-Development. Du machst dir damit viel kaputt und ich sehe das ganz oft von Leuten, dass die halt dann einfach die Lösung nehmen und einfach hinnehmen und nicht verstehen, was sie damit machen oder was danach passiert und das nicht hinterfragen. Natürlich mache ich das auch. Also ich schaue es mir an, ich suche verschiedene Issues, ich nehme nicht erst die erste Lösung, sondern gucke noch mal. Was ich auch angefangen habe aus dem Wissen heraus, dass ich meine eigene Dokumentation schreibe, ich gucke noch mal bei den Entwicklern von dem vermeintlichen Bestandteil gucke ich halt rein und sage halt „Hier, das ist gerade schief, wie sieht’s denn aus?” Manchmal schreibe ich auch die GitHub-Projekte an, also mache halt da ein Issue auf. Wenn es halt, manchmal wird mir halt gesagt ne, gibt es keine Lösung oder musst du, manchmal helfen sie auch, und sagen Konfiguration, oft gibt es auch keine Antwort, weil Open-Source-Projekte.

R1: Welche Strategien haben sich dann bei euch vielleicht schon entwickelt um Konfigurationsfehlern vorzubeugen?

I4: [Überlegt] Sind glaube ich so Spezialsachen. Ich glaube im Lasttest-Bereich haben wir dann unser Tool, wo wir bestimmte Sachen schon mal, damit wir so ein Minimalsetup haben, dass wir dann tweaken können. Da haben wir halt so Tools. Jetzt in der Entwicklung wenn man gerade neue Sachen, also neue Tools miteinander integriert oder Sachen schreibt, also für das Open-Source-Projekt, ich gucke halt, dass ich meine Properties und die ich halt an meinen Konfigurationsmöglichkeiten, die ich schaffe, dass ich die global verfügbar mache auf verschiedenen Ebenen. Halt für DevOps auf Kommandozeilenebene, mit einer dev-Datei für den lokalen Entwickler, weil der möchte ja quasi die eigentliche Konfiguration, die halt dann in das System reingeht, was es ausführt, die möchte ich ja nicht ständig anpassen. Also ich möchte halt in der Lage sein, einfach für meine lokale Entwicklung eine Konfiguration zu haben, die halt später nicht ausversehen mit reinwandert. Weil git commit—Düm! Und plötzlich laufen, das ist halt zum Beispiel bei uns der Klassiker ist zum Beispiel ich habe meine Testumgebung, meine Testumgebung ist natürlich irgendein Server. Wenn ich dort einen Chrome hochbringe, dann sagt der Chrome „Nö, will ich nicht. Ich habe hier ja nicht mal einen Bildschirm. Ich habe kein Display.” Das heißt du musst halt erstmal sicherstellen, entweder du hast wieder ein System, wo du ein Virtual Frame Buffer hast oder du hast halt inzwischen, das ist jetzt seit letztem Jahr so, sind die Webtreiber in der Lage im Headless-Mode zu fahren, sodass du halt einfach keinen Framebuffer mehr brauchst und somit kannst du halt auch auf Mac- und Windowssystemen einfach einen Headless Mode fahren. Und natürlich ist der zum entwickeln nur bedingt sinnvoll, weil du ja, wenn du jetzt deine Automation nachvollziehen möchtest, du siehst nichts, weil der Browser halt im headless ist, da bringt es dir nichts. Aber dann möchtest du halt auch nicht jedes Mal die Konfiguration anpassen. Also das sind so Schemen, wie ich die probiere, also quasi in der Softwareentwicklung zu vermeiden. Dass ich halt die Konfiguration auf vielen Ebenen ermögliche, sodass die halt auch je nach Anwendungsfall verwendet werden können. Weil es ist ja, gerade im DevOps-Bereich ist es ja, du möchtest nicht, also ein guter DevOp möchte eigentlich nicht auf IO-Ebene Dateien verändern um halt dann Konfiguration nur für seine lokale Variante oder Ausführung zu verändern. Sondern der sagt dir „Ich hätte da gerne einen Schalter für. Gib mir irgendwie was, womit ich eine Systemvariable setzen kann oder irgendwas. Weil ich möchte nicht in deinen Code rein. Dein Code ist dein Tanzbereich. Also der geht mich nichts an, weil ich möchte auch dir nicht durch meine Konfiguration irgendwas kaputt machen.” Das heißt da muss man halt so verschiedene Ebenen finden. Ansonsten beim Entwickeln selbst, ist glaube ich ins Blaue hinein. Also das ist dann der Klassiker: Du schaust erst mal und guckst erst mal, was erwarten mich denn für Probleme? Weil man es… du arbeitest erst mal auf gut dünken, schaust dir vielleicht die Optionen an, die du hast, und gehst mal durch welche könnte am besten passen und dann schaust noch mal wie die dokumentiert sind und dann bei manchen Sachen, wo du denkst das sollte straight-forward sein, dann guckst du halt erst mal, ob es läuft oder nicht. Also, weil man möchte ja auch nicht in jedem Fall, also eine gute Default-Konfiguration, die halt so ich sage mal 80 % abdeckt und dann musst du halt gucken einfach nur, ob du der Spezialfall bist.

R1: Wie—vielleicht bei eurem Lasttesttool, wo ihr so viele Option auch habt—wie viel Interaktionen habt ihr denn da und gibt es denn so Constraints so dazwischen? Also wenn jetzt die an ist, dann muss die und die auch an sein und der dritte Wert muss auf über 80 gesetzt werden oder so. Habt ihr solche komplexen Bedingungen? Und wenn ja, wie kodiert ihr denn die?

I4: Äh, Property-Hölle. Es gibt komplexe Sachen, es gibt halt gerade wenn man zum Beispiel so Webtreiber konfigurieren möchte und man möchte sagen „Du hast den User-Agent” und möchtest das nächste Feature haben. Also auch bei dem Open-Source haben wir halt auch—zum Beispiel wenn ich sage du kannst die Ausführung in deinem Webtreiber in deinem Webtreiber verlangsamen, das ist ein Feature was wir gebaut haben, also quasi weil es halt ganz oft läuft das halt ganz schnell im Webtreiber ab, weil der natürlich alles als Rechner macht und du halt nicht in der Lage bist das dann so schnell nachzuvollziehen und du siehst vielleicht gar nicht, was er macht oder ob er das gemacht hat. Also hab ich halt ein Highlighting und eine Verzögerung eingebaut. Und dazu muss man halt quasi erst mal grundsätzlich das Highlighting anschalten um dann die Verzögerung zu beeinflussen. Also das sind so zweistufige Konfigurationen, wo man halt erst sagen muss das eine an und danach kann ich das andere konfigurieren. Das ist natürlich im Lasttest-Fall noch viel komplexer, weil es da einfach bei einem 10 Jahre alten Tool viel mehr Schalter gibt. Und da ist halt eher das Problem, dass man halt eher so Sachen hat, wo man erwartet, dass die miteinander funktionieren, weil die halt vielleicht ein ähnliches Naming haben und dann tun sie es aber gar nicht, weil die halt die Infrastruktur unten drunter was andere ist.

R1: Habt ihr da irgendwie… also gibt es da ein gutes… also beim Linux-Kernel gibt es ja so ein KConfig, wo dann geprüft wird, ob das eine valide Konfiguration ist. Und dann sagt mir ja diese Option darf nicht, ist das bei euch, habt ihr so was drunter liegen oder wenn… eher nicht?

I4: Bei manchen Sachen, also quasi wenn ich jetzt, ich habe letztens eine Konfiguration für einen Proxy geschrieben, da werfe ich jetzt mit entsprechenden, also quasi wenn das jemand falsch konfiguriert, dann werfe ich halt entsprechende Exceptions. Um halt den Nutzer, um das halt gar nicht die falschen—weil zum einen ist der Vorteil, den ich habe, ich möchte ein Testsystem aufsetzen und wenn das Testsystem nicht so läuft, wie du es konfiguriert, wenn du es falsch konfiguriert hast, dann sollte es gar nicht laufen. Also das sind dann so Presets und dann kann ich einfach sagen okay, ich bin in der Lage zu sagen—Runtime Exception. Mir ist egal in dem Moment, du hast falsch konfiguriert, mach noch mal. Also weil das einfach an einer bestimmten Stelle ist. Also das machen wir da auch. Wenn du so bestimmte Sachen hast, die gar nicht gut konfiguriert sind, dann können wir halt einfach mit einer Runtime Exception oder mit einem Fehlercode den Nutzer drauf hinweisen. Ansonsten haben wir kein Configtool, was alles testet. Weil allein dieses Tool, das… da wird man glaube ich nicht fertig. Also ich glaube weil die Konfiguration, also unsere Konfiguration ist ein weiterer Punkt, Konfiguration ist zum Beispiel bei uns, bei dem Lasttest, man kann Maschinen konfigurieren, man kann die Umgebung der Maschinen konfigurieren, die Agenten, also sprich wie viel RAM hat ein Agent, was ist dem seine Umgebung. Wir haben danach wird ja ein Report gerechnet, da können wir den Report konfigurieren. Möchtest du die folgenden Settings benutzen? Möchtest du die Settings, also wie gesagt, also 10 Jahre alte Toolchain, die halt einfach immer wieder neu Feature und da kommen natürlich auch immer wieder neue Features hinzu. Dann hat man halt Trends aus der Industrie, wenn es halt heißt „Ja, wir hätten gerne Lasttests und gerade sind Perzentile super modern und ich würde gerne wissen, wie halt einfach, wie das Perzentil zu 99,9 % für diesen Request aussieht.” Okay, dann bauen wir halt das Feature ein, dann ist es konfigurierbar, dann werfen wir halt auch Fehler, wenn es eine Miskonfiguration gibt oder halt nicht. Also das kommt dann halt auch auf den Entwickler drauf an. Das ist dann damit (?).

R1: Ja, gehen wir zum Verbesserungsbedarf irgendwie so. Also was, wenn du jetzt irgendwie Wünsche frei hättest bezüglich deines Jobs, also bezüglich der Entwicklung mit Konfiguration, was würdest du denn so wünschen? Was kann man da irgendwie, vielleicht was würde dir helfen schneller Konfigurationsfehler zu identifizieren und…?

I4: Ich glaube ich würde mir wünschen, wenn bei Konfigurationsfehlern mehr direkte Laufzeitfehler gew—also das ist finde ich, gerade so bei Konfiguration, also zumindest bei so statischen Konfiguration, also bei dynamischen Konfigurationen ist das noch mal was anderes, also wenn man so damit die Laufzeit, also die Ausführung selbst gestaltet—aber bei so statischen Konfigurationen würde ich mehr so Laufzeitfehler, also das halt gar nicht das (R1: gestartet wird das System) genau, dass es nicht so blind gestartet wird. Weil manchmal weiß man gar nicht, dass man was falsch konfiguriert hat. Also man hat irgendwie Werte gesetzt, die es vielleicht gar nicht gibt. Also zum Beispiel hat sich eine API geändert. Man nutzt halt irgendwie das Tool in der Version 3.1.2 und jetzt ist 4.1.5 und du hast halt, du startest das halt immer noch mit dem Parameter dem und dem und der war halt vielleicht vorher deprecated, das hast du nie gesehen, weil du es halt nur über Kommandozeile genutzt hast. Im Logging haben sie auch gar keine Warning dafür geschrieben „ist jetzt deprecated”—weißt du? Also so Sachen. Da wäre es halt schöner, wenn halt sowas passiert oder dass man dann halt auch entsprechend sagt hier, geht nicht. Es gibt nicht mehr den Wert active. Das haben wir umbenannt. Das muss jetzt so und so heißen. Also quasi so, ich fände es schöner wenn Entwickler mehr ihre Konfiguration also zum einen ein bisschen mehr dokumentieren, gerade weil ich halt auch so und dann vielleicht auch mehr so bei wirklich Sachen, wo man sieht das ist falsch konfiguriert, wie zum Beispiel du musst einen Port konfigurieren und du weißt dein Port kann nur ein Int sein, das mir da halt einfach, wenn ich da halt Not a Number reinschreibe, dass ich dann halt auch einfach mal einen auf den Deckel kriege.

R1: Passiert das tatsächlich, dass da…?

I4: Bei dem was ich jetzt geschrieben habe passiert es. Also weil ich auch, (?) halt so, ich möchte halt auch dem Nutzer, also quasi wir haben ja quasi ein Testtool und unser Testtool, das ist nicht für, mein Zielgebiet ist nicht der Java-Nerd. Für den brauche ich das nicht zu schreiben, der kann sich das auch selbst runtercoden. Der kann das auch selbst zusammenschreiben. Sondern meine Audience ist halt eher der geneigte Tester, der vielleicht schon mal so ein bisschen programmiert hat, der jetzt vielleicht auch im Studium gesagt hat „Ne, ich bin nicht der Coding-Guru. Also ne, Architekt könnte ich mir nie vorstellen. Aber ich kann, ich kriege zumindest if-then-else kriege ich hin und ich kann Abläufe machen. Also ich habe ein logisches Verständnis dafür”, das ist mein Zielpublikum. Und dem Zielpublikum ist eine komplexe Konfiguration einfach, die halt einfach zu groß wird und die halt von den Möglichkeiten, also alleine wie man konfigurieren kann, man kann ja alleine schon wenn man sich überlegt wie baut man Trennzeichen auf in seiner Konfiguration wenn es notwendig ist und wie sieht das aus? Das ist ja schon für viele zu komplex. Und ja.

R1: Ja, jetzt kommen wir bloß noch zu Teamfragen oder hast du noch zu Konfiguration irgendwas? (zu R2)

R2: Zwei Kleinigkeiten habe ich noch: Einmal bei der fachlichen und der technischen Konfiguration war ich mir nicht ganz sicher was du gesagt hast. Was für dich ist jetzt schwieriger zu konfigurieren? Du hattest glaube ich gesagt fachlich ist einfacher und im Satz danach klang es ein bisschen so als sei es doch andersrum. Nur ob ich das richtig verstanden habe. Was ist für dich schwieriger zu konfigurieren? Die fachlichen Sachen oder die technischen Sachen?

I4: Na wahrscheinlich… also für jetzt für mich persönlich oft die technischen, also quasi so das System, also quasi der Docker dahinter oder auch das Linuxsystem unten drunter. So der Server ist für mich persönlich schwieriger zu konfigurieren, weil das halt nicht meine Welt ist. Aber das ist eher so eine Wissensbasis. Das ist halt irgendwas, wo ich sage da hole ich mir gerne dann Hilfe von irgendjemandem. Von einem DevOps oder von jemandem, wo ich weiß der sich damit auskennt. Weil das halt einfach auch nicht so mein Fokus oder mein Spaßbereich ist. Das ist halt auch so, ich glaube das sind halt auch Vorlieben. Und deswegen ist halt oft dann so das fachliche ist halt in sofern einfacher, weil man halt, wenn man in dem Projekt drin ist weißt du ja einfach, okay ich brauche eine Start-URL oder ich muss halt jetzt, okay das ist ein komplexer Onlineshop, die haben ihr JavaScript nicht im Griff oder die haben ihre Elemente nicht im Griff. Das heißt ich muss jetzt gucken, dass ich halt JavaScript deaktiviere und muss halt darüber arbeiten. Muss halt Sachen viel mehr händisch machen. Das ist halt dann in sofern einfacher, weil du dich halt in dem Bereich bewegst als Entwickler. Also das ist eher so dein tägliches Brot. Wenn du jetzt ein DevOps bist, dann ist es wahrscheinlich wieder andersrum, weil du ja dann quasi dich auf den Linuxmaschinen, da kennst du halt einfach dein Befehlsset und weißt halt was du machst und beschäftigst dich wahrscheinlich auch mit dem Dockerzeug, weil du das halt so in deinem Rahmen jetzt immer wichtiger wird. Während hingegen, ich nehme das schon alles mit, wenn mir da was unterkommt und merke mir dann auch so Sachen, weil das halt auch wichtig ist, dass ich auch unseren Kunden wieder weiterhelfen kann, oder wenn ich halt Technical Lead bin, aber das ist halt eher so das, was für mich mühsamer ist. Was ich halt einfach sage, wenn ich mein Testtool anbiete, dann beginnt eigentlich der Support für mich ab dem Moment, wenn mein Testtool läuft. Und das davor ist halt so ein bisschen vor meiner Haustür. Wo ich Wissen haben kann, aber nicht muss.

R1: Würdest du sagen in den letzten fünf Jahren oder so, wo es ja in diese Richtung hingeht Containerisierung und mehr Continuous Integration, dass du immer mehr dazu, nicht gedrängt wirst, aber vielleicht leicht geschoben wirst, dich mit solchen technischen Sachen zu beschäftigen, weil es einfach—

I4: Ja es kommt schon, es geht schon in die Richtung. Also man wenn man es komplett von sich wegschiebt, dann schiebt man halt so eine ganze Welt von sich weg. Das ist halt auch so eine Komplexitätsebene, die halt vor fünf, sechs Jahren noch gar nicht in dem Maße da war. Also gerade so wenn man jetzt irgendwie also so… wir sind eine kleine Firma, das heißt wir sind hier alle eine Art Full-Stack-Entwickler. Das heißt, es bleibt gar nicht aus, dass ich mich halt auch mit bestimmten Sachen beschäftigen muss. Und natürlich gibt es dann halt denjenigen von dem ich weiß, dass der sich mehr beschäftigt hat, den ich dann Fragen kann um halt auch Insights zu bekommen oder ich muss dann halt einfach mich einlesen und bestimmte Sachen. Also das bleibt nicht aus. Und wenn man sich davor verschließt, dann—ich glaube das geht nicht. Also kann man machen, aber dann entwickelt man sich halt selbst nicht weiter oder kann man halt in den nächsten fünf Jahren wird es halt immer schwieriger.

R1: Okay, eine zweite hast du noch? (zu R2)

R2: Ne, das hat sich glaube ich jetzt erledigt.

R1: Genau. Eigentlich, dann haben wir es hier mit diesem. Hier. Also, Organisation war noch der letzte Teil. So ein bisschen hatten wir es ja schon behandelt. Wir wollen da jetzt so ein bisschen auch sehen, wie gesagt Conway’s Law, wie weit das so aktuell ist mit den neuen Softwareentwicklungsprozessen, die es ja so gibt mit Scrum und sonstwas.

I4: Sind wir tatsächlich, sind wir wahrscheinlich noch ein bisschen eher… läuft bei uns noch ein bisschen anders. Weil wir haben an sich, wir sind, wir haben ja verschiedene Einheiten. Wir sind eine Testfirma, das heißt wir haben einmal eine Einheit, die testet—wir haben entweder wir testen richtig Kundenprojekte, also wo dann wirklich so ein Projekt hintendran steht oder wir haben eine ganze Abteilung die unterstützt einen Kunden testet für den und nimmt halt in dessen Auftrag wirklich dessen Software, Testaufgaben vom Management über das Schreiben von Tests, über Codereviews, über manuelles testen alles wahr. Also wo wir halt auch verschiedene Rollen haben. Wir haben einen Bereich, der kümmert sich vor allen Dingen so im Bereich von Testmanagement und funktionalem Testen. Das heißt wo halt wirklich noch Sachen händisch durchgeklickt werden, die halt einfach, wo halt bestimmte Sachen, also wo halt dann auch quasi so eine Mischung aus Konfiguration ist sehr aufwändig, das… Automation für diesen Test halt ein Mal durchzuführen, sowas zu schreiben ist halt viel zu lange. Das heißt das muss halt dann einfach jemand händisch machen, wo man dann halt so einen wirtschaftlichen Tradeoff hat. Also du hast halt nichts davon, wenn du da für das automatisierst und dann brauchst du für das automatisieren viel länger als das eine Mal wo du es durchgeklickt hast. Oder wo du vor allen Dingen nicht kreativ testen kannst. Weil wenn du kreativ testest hast du ja dann auch wieder so Sachen, wirst halt einfach Umlaute oder irgendwelche anderen Sachen ausprobierst oder plötzlich bist du halt, musst du halt einen chinesischen Shop nehmen und nimmst halt dann quasi mal ein falsches Zeichenset oder sowas. Also wo du… das kannst du schon in Automation reinbauen, aber dann wird deine Automation so lang und das bietet halt—also der Mehrwert ist halt nicht gegeben. Der finanzielle Mehrwert. Dann haben wir Lasttester, die sind halt quasi komplett Projektarbeit. Das heißt die kriegen im Rahmen, also so ungefähr alle zwei Wochen in der regel, einen neuen Kunden und da ist quasi immer eine Person für einen Kunden eigentlich so zuständig. Also manchmal auch zwei wenn es halt ein großes Projekt ist. Also da hat man eine relativ feste Bindung und wir sind mit den Tests meistens nachgelagert. Also wir sind nicht in die… selten in die Teams integriert haben wir auch, aber gerade so im Lasttest-Bereich bist du, stehst du so in deiner Position. Hast halt dein eigenes Team, wo du dich mal, wo du dir noch mal Feedback holen kann, wenn mal irgendwas komisch ist, aber hast halt ansonsten bist du in dem Team, also arbeitest du halt selbstständig für dich an einem Projekt. Also halt ein kurzlebiges Projekt oder ein Projekt, was später noch mal wiederkommt. Und im Developmentrahmen, da sind wir halt [zählt] 1, 2, 3, 4 plus unser Teamlead, weil der halt auch mitentwickelt, sind wir halt fünf Leute und da haben wir halt auch so, da haben wir halt verschiedene Projekte und die werden dann halt immer besetzt. Also quasi immer das, wo gerade was zu tun ist, wird halt jemand hingesetzt. Und dann gibt es natürlich immer Präferenzen.

R1: Hierarchiestufen habt ihr?

I4: Wir haben relativ wenig. Im Endeffekt haben wir die Hierarchiestufe Geschäftsführung, wir haben in der Regel einen Teamlead und dann halt drunter eigentlich so die Entwickler. Aber wir haben relativ flache Hierarchien, weil meistens auch so, also gerade jetzt für Projekte, die halt ich dann, also das Open-Source-Framework, da ist zwar mein Teamlead vielleicht mal, der kann mir sagen „es brennt woanders, ich brauche dich”, aber der ist halt in dem Sinne mein Teamleader/Technical Lead für das Projekt. So das bin halt dann ich. Und dann habe ich halt quasi nur die Geschäftsführung. Das heißt wir haben relativ flache Strukturen. Also wir haben wirklich mal das, was man klassisch unter nicht flache Strukturen verspricht, sondern wir leben das auch. Das heißt ich kann auch mit jeglichen Problemen zu meinen Chefs gehen wenn irgendetwas ist. Wenn ich jetzt zum Beispiel irgendwie… wenn es um einen Kunden geht und es geht um Vertragsangelegenheiten, gehe ich zu dem einen Chef. Wenn es jetzt um ein technisches Problem im Java geht und ich da noch mal irgendwie einen Hintergrund brauche und ich möchte wissen, was jetzt der Garbage-Collector dort macht, dann weiß ich halt, ich gehe zu meinem anderen Chef, weil das halt sein Steckenpferd ist. Und haben halt da sehr flache—

R1: Und das ist auch ein Vorteil, ja? Dass da so direkte—

I4: Ja, dadurch haben wir halt nicht so eine feste… wir haben schon Rollenverteilung dann auch im Dev-Team. Wir haben halt den einen, der halt unser DevOps und Admin auch für die Firmeninfrastruktur ist, der sich dann halt mit Sachen wie Ansible und solchen Sachen oder dem Jenkins oder unser GitLab, also unsere Firmeninfrastruktur aufbaut und dort das ganze Konfigurationsmanagement macht und Backups und alles, was da dranhängt. Was halt so eine feste Rolle ist. Und dann haben wir aber auch, der arbeitet aber auch ganz normal in den anderen Projekten mit. Also der macht nicht nur das. Das ist halt dadurch, dass wir, wie gesagt, wir sind da einfach zu klein als dass wir uns diese Spezialisierung leisten können oder wollen. Also weil das dann halt auch… zum einen nimmt es den halt vom Team weg. Jetzt so ist quasi das, was er lernt können wir halt auch wieder in unsere anderen Projekte mit einbringen. Also wir haben halt auch, was ich vorhin erzählt habe, wir haben ein Projekt, wo wir halt einfach einen Automations-, wo wir eine eigene Automationsumgebung aufsetzen, wo dann halt auch Sachen ausgeführt werden können. Also aktuell jetzt erstmal Monitoring und dann später dann auch Lasttest und später auch mal Testautomation oder halt auch einen… auch mal vielleicht einen Mailservice, also quasi einen Demo-Fakemail-Service, den man irgendwann mal gebrauchen kann. Solche Sachen.

R1: Hat das für dich jetzt auch irgendwie Nachteile vielleicht? Aufstiegschancen oder irgendwie sowas?

I4: Naja, der große Nachteil ist halt, dass man relativ viel springen muss und das man von allen Technologien ein großes Verständnis haben kann. Also quasi es ist halt, man kann halt nicht sagen… also du kannst dich halt nicht hinter deinem Titel oder hinter deiner Bezeichnung verstecken. Also genau so wie ich ja theoretisch ja, also ich bin Entwickler, Senior-Developer, bin ich aber genauso auch für mein Open-Source-Projekt bin ich halt auch der Architekt. Oder ich bin jetzt auch für mein Open-Source-Projekt jetzt haben wir einen Kunden, der das einsetzen möchte, also bin da auch der Testengineer. Also ich, es ist nicht so, dass ich eine feste Rolle habe. Oder wenn jetzt—

R1: Möchtest du lieber eine—

I4: Ne, ich finde das ganz gut. Ich mag das. Also ich komme damit ganz gut klar. Ich habe bei uns halt auch die Möglichkeit wenn ich halt mir ein Thema auf den Tisch ziehen möchte, dann mache ich das halt einfach. Also wenn ich jetzt zum Beispiel sage ich kümmere mich die Praktikanten, weil ich möchte, dass die irgendwie ein bisschen mehr mitnehmen und dass das ein bisschen geordneter ist, dann habe ich das halt auf dem Tisch.

R1: Okay… du hast fast alle Fragen schon beantwortet… Genau, also für verschiedene, je nachdem in was für Domänen du gerade bist, gehst du einfach zu anderen Leuten, weil die einfach da mehr wissen?

I4: Entweder das, beziehungsweise ich habe halt auch einen(R1: besser kann mit denen), ich habe halt dann auch ein eigenes festes Wissen. Ja, natürlich man geht immer zu den Leuten, mit denen man wahrscheinlich, also da hat jeder seinen Ansprechpartner. Wobei das halt manchmal auch nicht, also manchmal ist es halt auch, tatsächlich bei uns ist es ein relativ gutes Klima, da ist das nicht so richtig relevant. Also natürlich hat man so die Leute, die man immer fragt, weil man mit denen vielleicht ein bisschen mehr zu tun hat, aber es ist jetzt nicht so, dass es jetzt… wenn die nicht da sind, dann frage ich halt jemand anderes. Also wenn ich brauche.