i04.txt

R1: So exactly. So let's start with a short introduction, clearly set out the goals of the interview and then ... it almost starts.
So exactly, we want to and really find out, I think I may have already said in the email how software and including Infrastructure as Code is configured, but not just Infrastructure as Code, also normal software, what problems occur, how these are remedied and there is a need for improvement in these processes. That means we want to collect practical problems in industry and then know where to go, practically in research.

Exactly, in the academic field it is often not entirely clear what role configuration plays in daily work - so that is a lot, little and so on, let's get to that - and generally what problems arise with configuration. Most of the time, known open source projects are taken from GitHub and issues are examined and configuration problems are searched for. Now that's as practical as doing research, but of course that's rarely what ends up with the issues at all. And we prefer to speak directly to the developers and not act on such, let's say filtered data, and so on. Exactly, and in the end we might have a little bit of interest again in the way team structures look, because team structure often has an impact — Convey's Law — on that, so organization somehow forms the code again and that's it what kind of effect it has. Exactly, with the answers here, we will continue to expand this questionnaire, so it may be that we then have new questions at the next interview partner that have practically arisen here. That's why there are more questions here than in the other previous interviews. And for use, maybe, let's take a cooperation that arises afterwards, it is so ... it is of course also that you can reflect on the work yourself - so what am I really doing all day and so on . Many interview partners actually said that as extremely interesting. Exactly, are there any questions? Otherwise we would start.

Okay, so yes, which domain do you mainly work in?

I4: I would say from the developer, that is software developer / architect, to test engineer, that is to say also to develop tests, and so I do the whole range, everything that relates to testing. So from the use of various diverse frameworks to the development of the frameworks and sometimes also as DevOps when it comes to integrating the frameworks into CI.

R1: Okay, so whole range. Exactly what is the role then, that is - we have already heard developers, testers. So project manager too? Or rather.

I4: Technical contact. Rather when there is something Technical Lead.

R1: What part is software development / programming in the daily work?

I4: It depends on the days, but on a good day it's 75%.

R1: Okay, and is that the average case for the good day?

I4: No, it just fluctuates. Because of that, we are not an insanely large company and then I had, then we stopped, so we recently published an article and then I spent two weeks working on an article for DZone, which of course is not a development effort has, but if such a normal development day are likely to be between 50 and 75% and integrate.

R1: Okay. How many years do you have experience in software development?

I4: 15? So 10, 15 years. Something in between. So through your studies and afterwards—

R1: And how long in the company?

I4: I've been with the company for four years now.

R1: And in the current position, as lead technical ...

I4: Well, that's the technical lead for the specific project. Respectively then, because we are small, we have, everyone has his focus. So we are organized - so now we can get to the structures. We basically have a team leader and he or she coordinates the development of the team more or less for things, wherever his focus and where he is involved, but I have an open source project, for example, where I stop even then I am the technical lead, because that is not what it is in, and then people just talk about expenses. So what is prioritized right now, i.e. do we have to do that right now? Is it burning where else that you just switch and then change roles?

R1: And which frameworks and tools do you usually work with?

I4: We work a lot with everything that takes place in the context of Selenium. So basically everything in this range is what you, that is, what best describes our stack. And everything that comes up and goes down with it.

R1: Are there any examples?

I4: Well, if we develop the open source framework, for example, it is based on selenide. Selenide is an API to reuse quasi selenium. This controls the browser, which includes the Chrome drivers, and then includes project structures that do the whole thing.

R1: Okay and then with, the other one, i.e. the right applications that you would test, they tend not to be so, so databases, do you have to do with it, or less?

I4: Well, because we rarely test databases per se, because we are, we usually come a little bit later. So in other words, because we are bought in as external, we can usually be found in the area of ​​acceptance tests or quasi integration tests or in test automation. Or we also have functional testers. But this is where we come from - it may be that we rarely come down to certain points, down to the database level. So then we have to, so we'll pass it on to the developers. So we could say, there are cases where you suspect that it is almost due to the database if you have any performance issues, if you can just say that here, it must be somehow a completely different layer, that can no longer be here because we have excluded everything, but rarely. So database rather rare. Unless it is in the context of our own development work, where we sometimes have some ... but even there you are, so you test your functionality rather than the functionality of the database itself.

R1: Okay, that was kind of the general question, now it's actually going into the configuration area. What do you mean by the term configuration at all?

I4: Incredibly much. We have one ... one of our main products is a test framework, which are used for load and performance tests. And that has been developed for over 10 years now. That means you can imagine that the range of features and special solutions that you will need at some point in such software that it simply grows and grows and grows. Of course, you also want to make everything switchable on and off, because not every one should always run, but you just have to make your special cases that you support also configurable. And configuration can be simple, but it can also be incredibly complex, because then you simply need your own lexicon or compendium to understand which switch does what with 10-year-old software where features have been added. Which switch runs on which levels? Because the tool can run on different levels again, so that's kind of like that, let me say a configuration challenge.

R1: What does layers mean in the context now?

I4: Well the tool can, it can run in different modes. There are modes, because it is controlled by an HTML unit driver, then you have relatively much access to the entire infrastructure, to the code, to the DOM and what happens, or you can now run it with a normal web driver . There you have it, it's like having a real browser where you have relatively few options and therefore, if you have less options, you cannot pull out all the things and data that you would otherwise have. This means that certain switches that run and function in one mode are simply not applicable to the other because the possibilities, the technical possibilities are not available. Be it for missing APIs or for security reasons.

R1: Okay, now you have a lot about configuration in your technical field, so the technical software is the testing framework, did you ... how far do you actually stand in the role of technical configuration, i.e. infrastructure configuration?

I4: First of all—

R1: Is that configuration for you too?

I4: It is definitely configuration. So it is, so to speak, it has to be - I am mostly at the project level infrastructure configuration. That means I configure a Jenkins job, see that it stops the post-steps, the pre-steps, everything, that things are called at the right time. So of course that's a configuration. However, this is usually much easier than the technical, i.e. the configuration of the project itself, because there are simply more parameters open. So compared to such a ... What will be difficult again if you then have to connect infrastructure configuration with project configuration. Docker is such a popular topic in IT. And everyone builds a docker for everything. The problem is simply that ... most people are not even aware that the way it is built is mostly ... So you always see problems and the problems turn circles. That means you find out something about a problem at some point and you see this problem reappear every two weeks in the same way. For example — a popular problem — I cannot automate my Chrome, which is in a Docker container, because it is really great to have my Chrome in Docker, because I have to tell my Docker to do so run as admin or I have to tell my Chrome you are not allowed to run in sandbox mode now. So those are just that, they are configurations, where infrastructure configuration and project configuration overlap, where you really have to give configuration for the infrastructure in the projects, so that the DevOps stays in the Able to do that. Because the system in the Docker does not have the possibility of certain things. So if he is not really someone who opens the Docker container, who can adapt it accordingly, who can then set environment variables so that they always keep up. Most people are not. That means they use Docker because it's cool and hip, but if Docker does Mäp then it's over.

R1: How long do you work on configuration things as a percentage per week?

I4: It depends on the phase. On the one hand you have such an initial configuration for such a project, which is ... mostly manageable, that is ... sometimes an hour at the beginning where you enter URLs, certain settings and htaccess, so to speak the authorization for the systems. And then mostly again when the whole thing goes to the CI, because everyone has different CI solutions. That means, you can go from BitBucket through a simple Jenkins, through any team services at Microsoft, there are so many different things and you have to start at every level ... actually the same area, but you have different ones Problems. Because then things just work a little differently in the surroundings.

R1: And even if you now see the technical configuration, how is it there, so is it a percentage of the week? That was more technical, wasn't it?

I4: Well, you can ... well, so it takes a day. So I can only say it in a fixed time, because a week, so I'm not that much in the projects. I can just say that the initial configuration is an hour, so for the project and for such a CI it can take a day to fix all of the errors.

R1: Are you typically dealing with the configuration of a monolithic system or rather with framework or tool configuration—

I4: Above all framework and tool configuration. Rarely monolithic.

I4: How do you see the importance or the importance of configuration in software engineering or software development?

I4: Incredibly high. So now I can say again - this is our load test tool - we are starting up some servers in some cloud data centers and then simply have to use our automation so that we can then practically put loads on the end systems. And if we could not map this through a simple configuration, that is to say as far as possible, a simple configuration, then you would be alone with the configuration of such a system, if you did all of this one by one, you would not be able to finish it.

So, because if you imagine that you somehow start up hundreds of machines and would have to configure them all individually and couldn't just use automation or an automated solution. Or even in the context of projects and test projects, it is sometimes worthwhile to automate automation or configuration, because you want to achieve a certain testability, which means that the systems must always have the same setup. If you now have a complex system, such as an online shop, with different payment providers, with different quotas that can be set, with different products, with availability of a product and now someone may have forgotten a step and that will solve a problem in caching or does not allow a problem in caching, because this may only occur from 24 products and not from 23 \. So now, weird example, but sometimes there are really weird things. And if you don't automate something so that you really always have the same prerequisites to run a test, you've already lost because the results you are delivering are not comparable. So in our area, configuration and pre-configuration is a big issue. That would be in a perfect world, if you were like testing a system, you would get the same system over and over again. So, always a new system with the same preconfiguration so that you can also compare, that's what I had yesterday. But actually test projects are running, there is a lot of parallel running, mostly testing comes in the middle of the development phase, so we actually say we would like to have somehow if you are satisfied with your code, but then project managers will come along who say ne , it's too late, we have to go live there, so you have to start earlier and then you get to some race conditions and ... so you never have this system so that it is finished, but you always work on a changing world and then you have to, so there are just a lot of places in the code where you just have to quickly swap a configuration so that you don't have to do it constantly and everywhere. So I also see that as a configuration, if you just have your fixed code part, so you say automated, I go through such a shop to shopping cart to make my order. Then for me is also part of the configuration, what is the selector of such a shopping cart button now. So this is a very specific configuration, but in the end it is also a variable that you just have to replace, which may not be in a configuration file as such, but also belongs to a setting, which is just ... because the rest remains fixed and the part is also a configuration, which means that in the test area you actually have to configure. So you try to keep your code as generic and dynamic as possible in order to be able to [?] Quickly.

R1: Now you said earlier that you tend to configure less. Does that mean that your colleagues will do more then, right?

I4: They do a lot, so basically in the context of such load test projects. So a whole shop is really configured every time.

R1: And they'll do it as a percentage -

I4: They do more configuration. So they really do more configuration, because then they also prepare the ... so there is an initial setup. It might take an hour or two in a load test. So the initial setup takes a bit longer. Then you have your fixed template. Things are then adjusted in the template. Sometimes entire processes become different because online shops also behave differently. But sometimes it really is - if they stay close to their standard - it’s just a matter of adjusting such selectors. And then it can be that such a project, if they are just selectors, is relatively quick. If there are rivers and processes that need to be adjusted, then it takes longer. Then it's just more programming effort in that sense.

R1: Maybe so ... you said yes, configuration configuration in software development or software engineering is very important. Did your university or academic training prepare you for this?

I4: Ne.

R1: Ok. Would you have wished for more in your training?

I4: I don't know if that is possible to that extent. So basically when I did that, it was still cool to program a ray tracer by hand. So that's the classic, but in the direction of configuration there was relatively little, and IO things were also little. So these are, I think I think, the university is a bit the wrong place in the part. So at least when it comes to pure hand tools, because I think it should be somehow better able to understand and program the processes, because that is much more important because if you, so we do a lot with interns and quasi university, i.e. students from university. And when you have to start teaching them how to program, it's more difficult than explaining to them - yes, there are these configurations and you have to work with them so and so - so to speak, it's just like that, that's a new onion -Layer on top, so I think that comes after the actual tools. So of course if everything is ready before then I would of course also be happy if someone comes who basically also understands the configuration matters and has a picture for it, but mostly configurations are so special depending on the project or application. Yes.

R1: Okay, we have the configuration so rough now, let's go the way we work with it. Now we have heard it a bit, but again the question of whether the configuration of systems, tools, infrastructure, frameworks presents you with problems and if so, which are the most serious problems, perhaps the most Take time with?

I4: I think so troubleshooting. Well, that's more of a misconfiguration or a lack of knowledge about the importance of different configurations. So there is - so that's just what I meant earlier - there is, actually there is a switch for most software parts for something, but they are not documented in such a way that they are easy to find. So it starts when you use any standard tools and they have some CLIs and quasi how to make a call from a CLI. So quasi command line interface. This is also a kind of configuration, where you tell it to do it now in batch mode to write a new setting. In other words, to set a setting that you cannot otherwise configure otherwise. And until you find such things, so that you can somehow configure something away where you are sure it has to be totally simple. Example last week: I should configure logging away. So you imagine that very simply. Log4J is a good framework that is used underneath. All right, take the logging configuration, I only have to write the following here and then. I do. It does not work. Okay, I found out that I have to rewrite something in my system configurations, really in my path, which is not possible, because these are some Docker containers. So, if I as a testing engineer only supply the software behind it, then I can support the DevOps, but if the DevOps is just a software developer and not the DevOps of the containers, then it just won't get there. That means I have to look again how I can implement the configuration somewhere or can specifically implement it without having to configure at the system level. Where then just a sensible switch was simply forgotten in the software. So that's just the way things are. It just takes. You think okay, that's a line of code, I google it briefly, I find it, okay ne, that seems to be more. I try it, I try it, then somehow you try to try through the undocumented solutions until you find a variant that works. And even if you develop the software and in the open source world you have quite a lot, so there are many good individual solutions. There are few good complex solutions. So we wrote a tool with which you can write a test automation on the web and we took so many of the good individual solutions and connected them with it so that you can really just automate the website to get a decent report at the end , somehow a usable reporting framework, what is known and what is used everywhere. That means that you also offer people a similar look and feel and a certain comfort, so that they don't just end up on any XML files - if you let a project manager loose on the XML files, you only get a question mark and none Understanding. And then you know, okay, this open source solution is developed from there and there, okay, that's in-house. That means they develop their project and make their solution and just release their API. This is relatively safe because they are a big company. Running. Then you have someone who has written an extension for it. Or has added an extension for it in its framework, which of course is then one version further back than the main framework. That means you have to see how far I can update the main framework so that I practically do not lose support within my second framework. That means that this dependency management is not that easy and is also a configuration. That means you have to know your toolset. How do I switch off certain dependencies? How do I enable? How do i look there What do I have to watch? What do I have to remember if I now update the framework? What are the key features that have to work afterwards? Which I may not be able to map with a test, because the test is simply… you can't mock it, but you have to write your own test system for your test system - that's it, that's what we call a chicken egg -Problem: We write test software and we also have to test our test software and can only use our own infrastructure to a certain extent, because then we have to use something else again so that we can simply exclude errors from us or quasi simply not being able to say yes, the mistake comes from ourselves, we just have to test ourselves well.

R1: Maybe there is such an example, such a special tool / framework, which causes problems or things in particular?

I4: No, that's actually the same for everyone. So that's actually the same for everyone and mostly it depends on the documentation. For example, we like to use selenide relatively. And selenide is easy to use in itself, but it's bad ... what does bad mean? Bad to little documented, because they simply say our tool is so easy to use, you don't need any documentation. I just leave the statement as it is - for certain things you just need documentation. We try, for example, for our open source tool, we have it at GitHub, use the wiki functionality there and try to also provide documentation for all the important parts so as not to let the users run against the wall .

R1: Have you ever received feedback from users regarding configuration difficulties?

I4: Yes, we also have - we use our own tool ourselves, which means that we get it from our users, above all from ourselves, stuff like that. Or we got recommendations from some users at GitHub. Then they wrote, here, I would like the feature. Wherever you stop then - so I understand why they have it - that was one, in fact it was one, they wanted a feature that takes configurability, that is, it takes away part of the configuration, because that then determined it Just doing things yourself, but in our larger context it is more difficult to implement, because you then lose your CIs, your CI support, for example, because in a CI it may be that the DevOps the Chrome and something pinned to some particular version. And the Chrome driver also fits. And if you now incorporate the automation that everything is automatically pulled by default, so quasi latest, latest and greatest, then you are breaking it a bit. That means you do it at one point, i.e. for the simple test execution or for the initial setup, you make it easier, but for the complex application you have to install switches again, you have to prevent this again. Then that will be ...

R1: Yes okay, very interesting. Exactly. So what I also heard a little bit is that the combination also creates big problems between frameworks. And what's the biggest problem? Is there a bit of a problem with deployment, testing, or development, or assembling the stack trace in the combination? Or everything? So are there certain things that really stand out?

I4: Difficult. So it's kind of like individual problems again and again. So you really have one, so for some it is quasi dependency management, which is difficult, for the next it is just the documentation of the configuration. Sometimes overwriting defaults or sometimes just knowing that you can configure it is enough. That alone is sometimes difficult because you just don't know it. So there is none, especially because I hold in many and different roles ... so mostly you can stop, so a lot of things can be traced back to configuration, so many problems. That means there is always a configuration that works or you have just found the one case that is not yet supported. So and then you have to offer something (?) And either it is really a software error or it is really a configuration error, that is, so that you simply have the possibility not to say anything, in this case I don’t want that because it will lead to an error. But that's just it, it can't be generalized in my case because I'm in many places, I can't say that's always my pain point, because sometimes, with some frameworks it works well and then it is also simply for example the poorly documented framework, it is very easy to overwrite their configuration if you know how they work if you understand the framework a bit. So for me this is no longer a pain point in the sense that I simply understood the principle behind it. But to find out at the beginning that this is more documented in the code, that you are aware that there is a class and if you just want to switch between different modes, then ... to find it.

R1: Is that part of the process when you have to configure that you already have a deep understanding of the individual frameworks?

I4: Well, in my case, especially when I connect the open source frameworks with each other, I just have to know to a large extent what they are doing. 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? No. 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.