Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Heute bei mir zu Gast Sebastian Dietrich Kurz-Sebi und er hat einen ganz besonderen Job. Er ist Gerichtssachverständiger oder so. Das erklärt er uns aber gleich ganz genau und zwar für Software. Er bewertet, ob Software State of the Art ist, wie wichtig da Qualität und Co sind, das erzählt er uns gleich. Viel Spaß bei der Folge. Hallo Sebi, schön, dass du da bist.
Hallo Richi, schön dich zu sehen. Ja, ich bin ja ganz aufgeregt wegen unserer Folge heute, muss ich ehrlich gestehen. Zum einen, weil wir uns ja, also du bist einer der Gäste, die ich, glaube ich, am längsten kenne. Das sind ja schon, ich weiß nicht… Jahrzehnte. Ja, 15, 20 Jahre irgendwie sowas muss es sein, wo wir gemeinsam damals noch bei der Firma
Anacon gewirkt haben. Und ja, und hin und wieder kreuzen sich unsere Wege und dann, bei unserem letzten irgendeinem Gespräch und irgendwann, da kamen wieder Dinge, was du jetzt eigentlich so machst und ich sage es jetzt mal salopp, du bist Gerichtssachverständiger. Genau. Für Software. Das ist natürlich sehr spannend. Jetzt habe ich es wahrscheinlich falsch gesagt, aber du wirst uns da gleich aufklären. Sag mal, was machst du denn?
Okay, also Gerichtssachverständiger ist quasi der kurze Begriff, offiziell heißt es allgemein beeideter und gerichtlich zertifizierter Sachverständiger. Und allgemein beeidet heißt, ich habe einmal einen Eid abgelegt vor der Präsidentin des Handelsgerichts, das heißt, ich muss bei einem Gerichtsverfahren nicht noch einmal beeidigt werden, ja,
erspart man sich fünf Minuten vor Gericht. Und gerichtlich zertifiziert heißt, ich habe eine Prüfung ablegen müssen vor einer Richterin und vor zwei Fachprüfern, das waren Universitätsprofessoren, zu meinem Fachgebiet und bei der Juristin, also bei der Richterin zu diversen Rechtsthemen, aber ganz trivial, also da muss man nicht just studiert haben, um das zu schaffen, diesen
rechtlichen Teil. Und die Idee dahinter ist, dass wenn es einen Rechtsstreit gibt und die beiden Parteien sagen, sie haben beide recht, wie es so üblich ist, und der Richter kennt sich aber technisch nicht aus und dann schlägt er vor aus der Liste der Gerichtssachverständigen, wir könnten doch den Herrn XY nehmen, der kann uns da jetzt Klarheit schaffen und wenn sich dann beide einigen, ja, das ist okay, dass wir den nehmen, hier geht es ja nicht um Strafprozesse,
sondern um Zivilprozesse, die einigen sich dann, ja, den nehmen wir und dem glauben wir dann beide, was der dann sagt, dann wird der halt beigezogen vor Gericht, um halt zu sagen, wie es so Sache ist. Jetzt ist ja deine große Besonderheit, dass du ja da für den Bereich Software dann angefragt wirst, also da ist die Software ja irgendwie der Streitpunkt und dann natürlich die Qualität und deswegen auch in diesem Podcast. Genau, genau, also das ist mein Spezialgebüro.
Genau, was sind denn da so deine typische Fälle, wo du dann quasi kontaktiert wirst und in den Einsatz kommst? Also vor Gericht ganz, ganz selten. Warum? Weil die meisten Leute wollen gar nicht vor Gericht gehen mit ihren Softwareproblemen. Stell dir vor, du bist eine große Firma und hast eine Software eingekauft, bist unzufrieden mit der Software aus was auch immer,
was für Gründen und möchtest dich jetzt dann darum streiten. Du möchtest aber eigentlich nicht haben, dass deine Kunden wiederum wissen, dass du ein Problem mit deiner Software hast. Und Gerichtsprozesse sind ja prinzipiell eigentlich öffentlich, das heißt, du kannst es auch nicht verheimlichen, wenn du dich nicht, also wenn du dich vor Gericht dann erst einigst. Deswegen
werden die meisten Sachen außergerichtlich bestritten. Es gibt aber einen Spezialfall und stell dir vor, du hast ein Unternehmen, das im Staatsdienst ist oder sehr staatsnahe ist, dieses Unternehmen, dann könnte dir der Rechnungshof vorwerfen, du hast dich da außergerichtlich geeinigt, naja, da wird irgendwo illegal Geld geflossen sein bei dieser Einigung.
Deswegen möchten die sich sehr wohl gerichtlich einigen, aber meistens ist es so, dass die sich in Wirklichkeit schon vorher ausgestritten haben und bei einem Zivilprozess ist das Allererste, was ein Richter mal fragen muss, können sie sich vielleicht außergerichtlich einigen? Und die Antwort ist dann, nein, wir brauchen sehr wohl eine gerichtliche Einigung, aber hier haben wir schon die Dokumente vorbereitet, wir sind eigentlich fertig, wir brauchen nur noch
die Unterschrift. Und der Richter ist dann natürlich auch recht froh, weil er weniger Arbeit hat. Also bei solchen Themen bin ich sehr wohl dabei, wo mit den Juristen all das abgestritten wird schon im Vorfeld. Ja, aber du machst ja dann auch diese außergerichtlichen Termine, da bist du ja auch Sachverständiger dann in dem Fall.
Genau. Und die holen dich da zu jetzt. Und da geht es also immer um irgendwelche, also meistens so Mängel in Software, der eine kauft Software oder lässt programmieren und ist nicht zufrieden mit dem, was er bekommt. Ja, genau. Oder hat den Schaden dadurch auch. Genau, genau. Also genau darum geht es. Softwarequalität, das ist eben mein Thema, dass ich eben prüfe, ob eine Software dem Stand der Technik entspricht und da schaue ich mir dann einfach diese Software an, wie die Qualität so ist.
Das sind eigentlich zwei Themen, weil einerseits die Qualität ist etwas, was man bewerten kann und ob etwas dem Stand der Technik entspricht, ist ein bisschen was anderes, weil der Stand der Technik inkludiert auch die Prozesse, mit denen etwas gemacht worden ist. Also wenn ich mir nur das Endprodukt anschaue, kann ich noch nicht genau sagen, ob es dem Stand der Technik entspricht. Ich muss eigentlich auch die Entwicklungsprozesse mir anschauen,
mit welchen Tools, Technologien und so weiter ist das gemacht worden. Also wenn ich jetzt nur prüfe, ob die Software jetzt gut genug ist, ob sie quasi in Einsatz gehen kann. Also das ist sehr oft
Abnahmeprüfungen, ist oft so ein typisches Thema. Zum Zeitpunkt der Abnahme hat man dann schon alles getestet und die Software kann auch fachlich das, was man haben möchte, aber man ist trotzdem sich nicht sicher, ob das technisch auch okay ist und dann holt man eben so einen Sachverständigen her und ich prüfe dann beispielsweise, wie viele Fehler in der Software doch unentdeckt drinnen sind. Das kann man mit Formeln ausrechnen, wie viel grob natürlich, das sind dann zwischen 5000
und 12.000 Bugs sind noch drinnen in der Software, sind noch unentdeckt. Ist das viel oder ist das wenig? Und da gibt es beispielsweise eine Aussage, wenn man auf die Defect Density geht, also die Fehlerdichte, wie viele Fehler pro 1000 Lines of Code in einer Software noch drinnen sind. Wenn das, daumen mal bi, über zwei Fehler pro 1000 Lines of Code drüber ist, gilt die Software noch als unreif und somit noch nicht für den Einsatz geeignet. Wenn bei der Software auch Menschenleben am Spiel
stehen, dann ist es sogar noch weniger, 0,5 Bugs pro 1000 Lines of Code. Das heißt, du führst da eigentlich auf Basis, du kriegst dann quasi einen Haufen Zahlen auch wahrscheinlich von den Tests, die dann schon gelaufen sind, von den Abnahmetests, weil du brauchst ja irgendwie eine Basis,
auf der du das berechnen kannst. Genau, also die Basis natürlich, wie viele Fehler sind schon gefunden worden, das kann ich mal abziehen von dem und wie viele Fehler prinzipiell in einer Software stecken, hängt sehr stark von der Größe einer Software ab, von der Komplexität
der Software und auch interessanterweise von den automatisierten Tests. Also wenn ich automatisierte Tests habe, die dauernd laufen, werden ja über diese automatisierten Tests bereits Fehler gefunden, die dann üblicherweise nicht in einem Bug-Tracking-Tool erfasst werden.
Diese Fehler werden auch gefixt. Also basierend auf dem komme ich auf eine Zahl, wie viele Bugs vor dem Test, also vor dem eigentlichen Test, drinnen gewesen sind und dann schaue ich mir an, wie viele Fehler sind denn jetzt schon gefunden worden durch Tester oder teilweise natürlich auch schon durch den Probebetrieb oder teilweise gibt es auch schon einen Echtbetrieb, bevor eine
Software überhaupt abgenommen wird. Und da kommt man oft auf erstaunliche Zahlen, auch bei Situationen, wo Menschenleben dran hängen können. Ja, also das ist ja, wie wirst du denn, das kommst du dann, also du hast ja dann auf einmal als Externer einen totalen Einblick in die, auch in die Software des Herstellers. Also der muss sich ja da auch quasi darlegen, der will ja auch quasi, sie haben sich ja darauf geeinigt,
dass sie dich nehmen und dass sie das jetzt klären. Also du hast ja da, ich stelle mir das ganz schön schwierig vor, dadurch, wenn das ein großes Software-System ist, sich da jetzt mal alles irgendwie mal zu Gemüte zu führen, was denn da ist. Also hast du da so Strategien, wie du dich da reinarbeitest? Ja, also ich schaue mir natürlich nicht im Detail jede Zeile Code an, das geht vielleicht bei 1000 Zeilen, aber ich schaue mir
oft Software an, die hat Millionen Zeilen Code. Das heißt, das was ich nehme, ich nehme üblicherweise Tools. Tools, die mir verschiedene Informationen liefern. Ein typisches Tool oder das bekannteste Tool ist SonarCube. Mit SonarCube kriegt man programmiersprachenübergreifend, das ist ein großer Vorteil, jede Menge Informationen. Natürlich über die technische Qualität auch.
SonarCube ist sehr low-level, also da sieht man eher so Code-Smells in der Art und Weise, also keine Architekturfehler oder Designfehler, aber man kriegt schon mal einen großen Überblick über die Größe, über die Komplexität der Software. Ich schaue mir natürlich auch die Architektur an. Bei der Architektur geht es aber seltener dann um die Frage, wie viele Bugs hat denn die Software,
sondern entspricht die Software überhaupt dem Stand der Technik. Weil das, was man in der Architektur oft sieht und in Wirklichkeit braucht man nur mit den Entwicklern reden, sie fragen ja, warum habt ihr denn diese Technologie verwendet, dieses Framework verwendet und die sagen dann oft, ja das hat sich ein Mitarbeiter eingebildet, der hat das cool gefunden und deswegen haben wir es jetzt drinnen und wir wissen eh nicht wozu. Und das sind natürlich
so gefundenes Fressen mehr oder weniger. Ja, das passiert leider oft. Softwarearchitektur ist meistens nicht passend, sondern das, was sich die Entwickler gewünscht haben, was cool und toll und super ist, mit dem man die Aufgabe lösen kann, ja, aber ich kann natürlich die Aufgabe mit vielen verschiedenen Sachen lösen, aber um am Stand der Technik zu sein, reicht es nicht, dass ich sie nur lösen kann, die Aufgabe, sondern ich muss sie auch effizient und effektiv lösen können und das
ist nur dann effizient, wenn ich auch die nächsten Jahre bedenke. Also beispielsweise, wenn ich eine Software schreibe, die die nächsten 10, 20 Jahre halten soll, dann sind die meisten JavaScript Web-Technologien, die es heute gibt, eigentlich nicht dafür geeignet, weil die sich dermaßen schnell ändern, dass sich allein und überhaupt keine typischen Long-Term-Support bieten. Das heißt, heute kommt eine neue Version und sechs Monate später oder ein Jahr später wird die alte Version
gar nicht mehr gewartet. Das ist etwas, wo man im Web-Bereich vielleicht leben kann, aber wenn die Software 10, 20 Jahre laufen muss, muss ich da ständig dahinter sein und muss dauernd ein Update machen, ansonsten kommen zum Beispiel sicherheitskritische Updates, sind einfach gar nicht mehr möglich. Ja, verstehe. Jetzt ist es ja so, ich kann mir das vorstellen, gerade bei Architektur, auch wenn man sagt, das ist Stand der Technik, da gibt es ja vielleicht heute mehrere
Stände der Technik, also nicht nur einen. Kommst du da auch immer wieder in Diskussion, dann dort mit den Architekten oder mit den Entwicklern, wo sie sagen, nee, die können das argumentieren, das ist durchaus auch eine Variante, also wie flexibel kannst du denn da agieren?
Das habe ich selber erst lernen müssen, weil für mich war Stand der Technik das, was für die meisten Entwickler auch Stand der Technik ist, nämlich ein neues Ding, das alle verwenden, das man vielleicht auf Konferenzen auch hört, wie gut das ist, wie gut es funktioniert, das alle auch lernen wollen, was auch stabil ist, mit dem ich mein Ding machen kann. Und das ist es aber nicht, weil Stand der Technik ist nämlich gar kein technischer Begriff, sondern eigentlich ein
juristischer Begriff. Und als juristischer Begriff wird er in vielen Gesetzen verwendet, also beispielsweise, wenn eine Software oder wenn irgendein Ding nicht Stand der Technik ist,
hat das Auswirkungen auf Gewährleistungsrecht, Schadenersatz und so weiter. Also ich kann sagen, ja, wir kennen alle diese zwei Jahre Gewährleistung, die gibt es natürlich in Business to Business auch, die kann man zwar reduzieren auf ein Jahr, aber trotzdem, wenn ich da zeige, das ist nicht Stand der Technik, dann muss das wie ein Bug behoben
werden. Und also es ist ein juristischer Begriff und es ist ein bisschen mehr. Also es ist Stand der Entwicklung, ja, okay, das gilt für viele Dinge, es ist neu, es wird auf Konferenzen besprochen, es ist fortschrittlich, ja, das gilt auch, es muss aber auch bewährt sein und bewährt in genau dem Anwendungsgebiet. Ich schreibe gerade eben einen Artikel gemeinsam mit einem Juristen über die Anwendung von Artificial Intelligence und in den meisten Projekten ist genau für die
Anwendung, wo man Artificial Intelligence verwendet, das Potenzial nicht bewährt. Das heißt, Artificial Intelligence ist zwar ein tolles Ding, aber nicht überall bewährt und somit eigentlich nicht Stand der Technik und natürlich zielgerichtet muss es auch sein, zielgerichtet effektiv und effizient muss es sein und da habe ich hier schon das erwähnt mit den Webtechnologien und vielen, vielen anderen Sachen, die halt cool klingen, die toll sind zu implementieren, aber halt vielleicht
nicht für das jeweilige Projekt sinnvoll sind. Und genau da gibt es dann eben mit den Architekten diese Diskussionsgeschichten, die sagen, ja was, wir haben jetzt das coolste, neueste Ding genommen und wir sind jetzt da am Stand der Technik und sagen, nein, sorry, der Stand der Technik ist
leider was anderes. Ja, also in dieser Falle tappe ich jetzt auch, merke ich gerade, für mich wäre das jetzt auch einmal automatisch das Neueste, der heiße Scheiß, der es gerade ist, aber so wie du das erklärst, ja, es ist natürlich nicht zwangsläufig so, da gibt es noch andere Faktoren,
die da mit reinspielen. Das ist eigentlich total einleuchtend. Jetzt ist natürlich aber so eine Architektur, wenn du sagst, die Jungs oder Mädels, das habt ihr jetzt von der Architektur, das ist jetzt nicht so prickelnd, das ist nicht Stand der Technik, das ist natürlich auch etwas, das kannst du ja nicht von heute auf morgen dann einfach so ändern. Worauf einigt man sich denn dann? Also kriegen die dann so eine, ich könnte ja mal noch zwei Jahre jetzt weitermachen oder was kommt denn
da so raus? Also wenn ich wirklich zum Streitzeitpunkt komme, also das funktioniert meistens so, irgendein Generaldirektor ruft mich an und sagt, ja, Herr Dietrich, es ist immer empfohlen worden, bitte kommen Sie vorbei, nächsten Mittwoch gibt es den Termin mit den Juristen, dann kann man meistens nicht Nein sagen, also ich muss immer gewerbefuß stehen und dann ist schon die Kacke
am Dampfen, wie man so schön sagt. Also sobald die Juristen eingeschalten sind und auch die gegnerischen Anwälte schon eingeschalten sind, dann geht es zunächst einmal nur ums Streiten. Also und mir geht es eben nicht darum, jetzt daher zu sagen, so ist es und aus und ihr könnt ihr könnt die Software wegschmeißen, das will keiner, also es will keine der beiden Parteien
möchte das, weil beide haben ja bereits sehr viel Zeit und Geld investiert in diese Software. Wenn sich dann herausstellt, das Ding ist nicht stand der Technik, dann versuche ich immer einen Weg zu finden, wo man sagt, was können wir denn noch machen, damit die Software, damit der Auftraggeber mit dieser Software noch leben kann. Also dann, üblicherweise gibt es ja eine bedingte Abnahme,
macht man dann üblicherweise. Eine bedingte Abnahme heißt, man kann es schon einmal einsetzen, aber es müssen diverse Dinge noch gefixt werden, innerhalb eines Jahres beispielsweise und dann erst erfolgt ein großer Teil der Zahlungen und während diesen eines Jahr, einem Jahr wird dann so viel, wie es halt nur geht, verbessert und ich achte dann darauf, dass dann Prozesse eingeführt
werden, dass die Qualität nachher nicht schlechter wird. Also immer mit den sogenannten Quality Gates versuche ich zu arbeiten, dass man einfach sagt, okay, folgende Punkte haben wir jetzt, wir wollen nicht schlechter werden. Ein typisches Beispiel ist die Test-Coverage von automatisierten
Tests. Da kann man natürlich immer streiten, sollte es 100% sein, das verlangt ja niemand, aber wenn es irgendwo in einer großen Software nur bei 13% beispielsweise liegt, von allen automatisierten Tests und sie sich aber vielleicht verpflichtet sogar haben, 70% zu erreichen, dann empfehle ich halt zu schauen, bei jeder einzelnen Release muss es besser werden. Es darf nicht schlechter, sondern es muss halt besser werden und bei Architektur versuche ich dann eben
die Hauptkriterien rauszubekommen. Also die Architektur ganz umstellen geht nicht, aber zumindest die aktuelle Version von Frameworks zu erreichen, das ist schon hilfreich. Vielleicht den einen oder anderen Teil rausschmeißen von den Dingern, die nicht notwendig sind.
Ich habe auch öfter Projekte begleitet, dann im Nachhinein und das dauert schon, wenn man sich nicht 100% darauf konzentriert, sondern wenn man natürlich auch Weiterentwicklungen macht, kann man schon oft mit drei, vier Jahren rechnen, bis all diese technischen Schulden aufgeräumt sind und die Software eigentlich dem Stand entspricht, den man zum Zeitpunkt der Abnahme gerne gehabt hätte. Verstehe, ja. Noch mal zurück auf das Thema, das andere Thema war ja das große
Thema Qualität. Es gibt ja jetzt nicht nur so eine Qualität oder wie definierst denn du Qualität in dem Kontext von den Kriterien her oder so was? Woran orientierst du dich da? Also für mich gibt es
zwei Arten. Zunächst einmal die fachliche Qualität. Also in Wirklichkeit gibt es drei Arten, nämlich macht die Software auch das, was das Business benötigt und das ist halt ganz schwer herauszufinden, weil die meisten in der agilen Softwareentwicklung sagt man, der Business Value ist ganz, ganz wichtig. Business Value kann man eigentlich erst messen, wenn das Ding in Einsatz ist. Vorher weiß man
den Business Value nicht. Vorher kann man noch schauen, wie zufrieden sind die Anwender damit, aber nur deswegen, weil Anwender zufrieden sind, heißt das nicht, dass man unbedingt Business Value geschaffen hat. Das ist jetzt natürlich etwas, was ich als Sachverständiger nie, nie wirklich prüfe, wenn der Auftraggeber etwas beauftragt hat, was seinen Business Value nicht erhöht,
dann ist er halt selber schuld. Ob etwas jetzt den Anforderungen entspricht in der agilen Softwareentwicklung, ob die Storys auch alle umgesetzt worden sind oder gibt es in der Pflichtenheft, Lastenheft, das ist ja genau die fachliche Qualität. Das ist ja genau das, was, um das sich der Test kümmert und da schaue ich natürlich den Testern auf die Finger, mehr oder weniger, wie gut ist denn der Test gelaufen, welche Testarten sind gemacht worden,
welche, wie viele Fehler sind denn gefunden worden. Also, ich versuche da eher von hinten herum zu kommen. Also, es gibt so viele verschiedene Testarten, die alle Stand der Technik sind und die alle sagen, meine Testart alleine reicht nicht. Du musst die anderen
Testarten auch machen. Also, der Mix ist hilfreich und ich prüfe dann, wie viele Fehler sind denn gefunden worden mit den Testarten, weil du kennst es selber als Tester, wenn du mit der Testart A einfach nichts mehr findest, heißt das nicht, dass du fertig bist, sondern dann probierst du es einmal mit einer anderen Art und Weise, was man denn machen kann. Also, die fachliche Qualität, da gehören natürlich auch die nicht-funktionalen Requirements dazu, die überprüft werden müssen
und die sind sehr oft schwer zu überprüfen, weil sie halt nur sehr visi-vasi formuliert sind. Also, zu Usability beispielsweise steht selten irgendwas dabei oder wird selten irgendwie konkret irgendwas gefordert, aber da gibt es natürlich Testmöglichkeiten, wo man sagt, naja, habt ihr überhaupt jemals geprüft, ob die Anwendung auch eine entsprechende Usability hat. Performance, genau das Gleiche. Oft steht nur drinnen, die Anwendung muss sich performant
verhalten. Ja, was heißt denn performant? Zwei Sekunden Reaktionszeit? Ja, schon, aber wenn ich irgendwelche Sachen, große Sachen berechne, einen Jahresabschluss berechne, dann ist es völlig verständlich, wenn das nicht nach zwei Sekunden da ist, der Jahresabschluss. Also, das ist alles die fachliche Qualität und dann das andere, was ich eben prüfe,
das ist dann eben die technische Qualität. Da geht es um den Stand der Technik, wie, also da gibt es hunderte Kriterien, also von den Low-Level-Sachen sind die Naming- und Coding-Convention eingehalten worden. Ja, das ist dermaßen Low-Level, das schaue ich mir eigentlich fast gar nicht mehr an, aber natürlich gibt es der Code-Smells oder Code-Stench, also Code-Stench ist etwas, der stinkt nicht nur, sondern das ist wirklich grauslich und führt mit hoher
Wahrscheinlichkeit jetzt oder in Zukunft zu einem Bug. Und also typischerweise irgendwelche Null-Pointer-Geschichten oder in Java, wenn man bei einem Vergleich nicht mit Doppel-ist-gleich vergleicht, sondern mit einem Einfach-ist-gleich in einer if-Geschichte, das ist sicher, also mit hoher Wahrscheinlichkeit kein bewusst geschriebener Code, auch wenn er läuft. Achtung, das einfach so quer durchs Beet ausbessern ist auch nicht gut. Es kann sein, dass dadurch dann
Bugs entstehen, weil bislang hat man sich auf dieses Fehlverhalten eigentlich verlassen. Und dann, das geht natürlich dann ganz hinauf bis Zyklenprüfungen, Abhängigkeitszyklen, Dead-Code-Analyse, Doppelter-Code-Analyse, Architektur. Ist die definierte Architektur
überhaupt eingehalten worden? Also das ist alles dieser technische Bereich, ob das Werke innen und außen schön ist, ob das Auto mich von A nach B sicher bringt, ist das eine, und das andere ist, ich mache den Motorhaube auf und schaue, ob die Schrauben auch fest sitzen oder ob da nicht eine Holzschraube statt einer metrischen Schraube irgendwo drinnen steckt. Sehr spannend. Und also deine ganzen Prüfungen führen ja im Endeffekt dann zu irgendeinem Art
Bericht, nehme ich an, also ein Gutachten. Genau, ein Gutachten. Ein Gutachten, das ist dann dieses… Und wenn das außergerichtlich ist, man hat sich geeinigt auf dich und so, wie ist denn, ist das dann, wenn du dein erstes Mal das Gutachten bringst, sagen die, ja okay, nehmen wir es so oder fängt dann nochmal so eine Diskussionsrunde häufig an, sagen sie, ja nee, aber wir machen das eigentlich eh super und nee, wir wollen das doch anders,
wie ist das so bei, kann man sich das vorstellen? Also es ist unterschiedlich. Es gibt, also im Streitfall ist es so, also ich schreibe bei allen Gutachten ein bisschen mehr, als man üblicherweise
in ein Gutachten hineinschreibt. In ein Gutachten schreibt man hinein zunächst einmal eine Bestandsaufnahme, also was haben wir, was für Kennzahlen existieren denn und dann aus dieser Bestandsaufnahme basierend die gutachterliche Aussage, die vor Gericht verwendet werden kann, mehr oder weniger entspricht es oder entspricht es nicht oder in welchen Teilen ist es zu schlecht, die Software. Aber ich schreibe immer noch einen dritten Teil, nämlich eben eine Empfehlung,
wie mit diesen Sachen umzugehen ist und es gibt einige Punkte. Ein typisches Beispiel ist eben die Coverage von automatisierten Tests. Wie viel Code oder wie viel Funktionalität ist denn jetzt durch automatisierte Tests, insbesondere durch Unit-Tests gecovert. Die Empfehlung ist aus meiner Seite niemals, ja dann schreiben wir halt mehr Unit-Tests, dass wir eine höhere Coverage haben, weil das führt zu extremen Verschlimmbesserungen in Wirklichkeit. Damit zementiere ich etwas ein,
was ich gar nicht einzementieren möchte. Das heißt, auch wenn rausgekommen ist, es gibt so wenig automatisierte Tests, ist niemals die Empfehlung, schreibt mehr automatisierte Tests, sondern die Empfehlung in dem Fall ist, bei jeder Änderung des Codes, also wenn ich neuen Code dazu schreibe oder Code ändere, dann muss ich vorher idealerweise Tests dafür schreiben,
damit genau nur diese Änderung überprüft wird und bitte intelligente Tests. Also und auch das ist natürlich, die Code-Coverage sagt überhaupt nichts über die Intelligenz eines Tests aus. Da wird dann halt gesagt, ja all das muss mit intelligenten Tests versehen werden. Und auf das kann man sich dann meistens einigen. Ob das dann gemacht wird oder nicht, das muss in Wirklichkeit laufend weiter geprüft werden. Es gibt auch sehr oft die Situation, wo ich von
Auftraggebern geholt werde für interne Software, also die haben es gar nicht extern vergeben. Der sagt, ich bin Abteilungsleiter jetzt geworden in der IT-Abteilung und vorher bin ich woanders gewesen und jetzt möchte ich einfach mal wissen, was habe ich denn da? Meine Programmierer sagen mir, ja das muss alles wegschmeißen, das müssen wir neu schreiben, das ist alles schlecht. Die Tester sagen aber, naja, aber das haben wir individuell, ist das gemacht worden, das entspricht
genau dem, was die Kunden haben wollen. Ich glaube nicht, dass das so einfach sein wird, das neu zu schreiben. Der will wissen, woran er ist und beim Wissen, woran er ist, ist halt die Frage, was dann mit dem Gutachten schlussendlich passiert. Idealerweise natürlich macht er dann was mit dem Gutachten, aber ich gebe mich keiner Illusion hin. Selbstverständlich gibt es auch Gutachten von mir, die nur dazu dienen, dass irgendjemand seine Position festigt und das
Gutachten verschwindet schlussendlich im Ladel. Und zehn Jahre später rufen sie mich wieder an. Ja, das kann ich mir gut vorstellen. Ich war in einem ähnlichen Projekt mit Softwaremetriken, da sollten wir auch ganz viel messen, weil es um die Weiterentwicklung ging, Komplexität,
Qualität und Quantität von den Systemen messen, um zu sehen, welches pflegt man weiter. Also man hat ganz viel gemessen und dann hat ganz viele Zahlen gehabt und war dann sehr froh, aber es ist dann so, wie ich mitbekommen habe, danach nie was passiert damit. Ja, es ist auch zunächst ein Riesenhaufen. Also man kommt ja auf viele, viele Dinge drauf und ich erkläre den Leuten immer, wir stehen vor Mount Everest und wie geht man am besten auf einen Berg?
Auf einen Berg geht man am besten, indem man geht und darauf achtet, dass man nicht abstürzt. Das ist das Allerwichtigste. Geht einfach, versucht einzelne Maßnahmen zu machen und einfach immer nur weitergehen und irgendwann einmal werd sehen, wir sind jetzt schon auf der Zugspitze, eigentlich reicht uns das. Wir müssen nicht auf den Mount Everest kommen. Inzwischen, das Werk ist immer noch schwerfällig, aber ja, es reicht jetzt schon von der Qualität her.
Das ist eine ganz schöne Metapher, finde ich. Du hast vorher Sonar Cube erwähnt. Ich sehe das so häufig, dass das in Unternehmen, entweder sie haben es schon oder sie holen es sich dann, dann legen sie einen großen Schalter um und dann kommt da ein Report raus, der alles zerreißt, wo da tausende von Dingen sind und die wissen, das ist wie Mount Everest. Alle in Schockstarre sind davor und dann wird, vielleicht sollte man mal die Regeln abschalten, so dann ist es wieder
weniger. Das ist natürlich nicht der richtige Weg, sondern einfach mal Step by Step sich dem Ganzen zu nähern und in das Tun zu kommen. Genau, deswegen ist der Sonar Cube besonders gut, weil das kann eben so diese Quality Gates machen, wo ich sage, besser als. Also ich schaue mir nur den geänderten, den Neukot an und sage, nur dort müssen die Regeln eingehalten werden und bei allgemeinen Metriken wie Coverage oder was auch immer, was doppelter Code, da soll es
niemals schlechter werden, sondern immer sukzessive besser. Das ist dann hilfreich, aber auch wie gesagt, Sonar Cube ist schön und gut, aber es ist Low Level, es ist wirklich Low Level. Auch wenn ich super toll in Sonar Cube bin, habe ich deswegen immer noch keine Software, die wirklich super toll ist. Es gibt leider wenig Tools und da braucht man auch, glaube ich, mehr Intelligenz als ein Tool aufbringen kann, um zu überprüfen, ist dieses Framework überhaupt
geeignet, um diese Software die nächsten 10, 15 Jahre zu unterstützen. Das kann ein Tool nicht, da muss ich mir die Historie von dem Framework anschauen, wie viele Committer gibt es bei dem Framework, was auch immer. Ja, verstehe. Ja klar, du hast ja jetzt sehr über die Jahre, also wir kennen uns schon so lange und du warst damals für mich schon so ein Senior Software Entwickler, Architekt. Du hast immer schon verstanden, wie die Dinge irgendwie zu laufen.
Also ich finde, du hast hohe Expertise in dem ganzen Bereich und jetzt siehst du quasi von außen immer in so Softwareunternehmen rein, wie die das so machen und wie die so ihre Qualität haben und wie, rein aus dem Bauhaus, wie siehst du denn das Thema Qualität in Softwareentwicklungshäusern? Tut sich da was? Wird das besser? Ist das ein Thema, was wir im Griff haben oder denkst du
dir manchmal, mein Gott, mach doch am besten den Laden zu? Also ich merke, dass es agiler wird und ich meine, ich habe im 99er Jahr mit agiler Softwareentwicklung mit Extremprogramming angefangen. Es wird schon langsam Zeit, dass es auch wirklich agiler wird, auch wenn oft, was nur am Blatt Papier agiler wird. Das Mindset ist doch vorhanden, dass die Leute agiler denken und eben nicht stupide irgendwelche Testreports ausfüllen, sondern auch wirklich intelligent an die Sache
herangehen. Aber was ich sehr wohl sehe, ist, dass Agilität zu höherer Geschwindigkeit und höherer Produktivität führt, aus meiner Sicht nicht zu höherer Qualität. Früher hat man halt wahnsinnig viel Zeit investiert und Tonnen an Papier erzeugt und ist auf zumindest die gleiche fachliche und auch technische Qualität gekommen, wie man jetzt mit weniger Aufwand auch kommt. Das heißt, aus meiner Sicht wäre man nicht besser und zwar auch
aus meiner Sicht branchenübergreifend. Also ich bin auch in der Flugindustrie tätig, ich bin im Gesundheitsbereich auch tätig und die kochen genauso auch nur mit Wasser. Das heißt, da ist alles viel teurer, weil viel mehr dokumentiert noch wird, weil viele Dinge halt nicht so agil laufen. Aber de facto so viel besser ist dort auch nicht das, was
erzeugt wird. Und das ist halt problematisch natürlich, weil früher hat man halt vielleicht, keine Ahnung, in den 70er Jahren, wenn man mit den Lochkarten gearbeitet hat, da hat man halt ganz andere Personenstunden gehabt und hat dann zig Millionen wo hinein investiert und jetzt ist es, jetzt inflationsbereinigt, vielleicht günstiger geworden, aber die Qualität sehe ich nicht, dass sie wirklich besser geworden ist.
Ah ja, das ist spannend. Interessantes Bild. Finde ich echt cool, dass du uns da noch so einen Einblick gibst. Ja, vielen lieben Dank Sibi für diesen interessanten Ausflug mal in eine andere Welt. Wir sind hier von den Hörerinnen und Hörern ganz viele Entwickler,
Programmierer, Tester, die so in ihren Projekten arbeiten. Und ich glaube, man macht sich manchmal gar nicht die Gedanken, was für Auswirkungen das auch in der Juristerei haben kann da hinten und worauf es dann eigentlich ankommt und wie wichtig das eigentlich ist, dass wir da auch einen sauberen Job machen. Also danke dir schön, dass du dir die Zeit genommen
hast, hier mal Rede und Antwort zu stehen. Gerne. Also was ich auch wirklich raten kann ist, nicht nur juristisch anschauen, sondern einfach geht mal dorthin, wo eure Software eingesetzt wird, fünf, sechs, sieben Jahre nachdem ihr fertig seid und schaut euch an, wie wird denn die Software gemacht und dann oder was wird damit gemacht. Und dann wird ihr vielleicht sehen, ja, das war wirklich ein tolles Projekt. Das war cool, hat auch
etwas geliefert, was was bringt oder es war ein tolles, cooles Projekt. Aber eigentlich inzwischen haben sie es schon weggeschmissen, weil es damit nicht arbeiten können die Leute. Ja, das ist ein schöner Tipp. Ja, Sibi, vielen lieben Dank. Ich wünsche dir alles Gute für die Zukunft und bis bald. Danke schön. Danke. Toi, toi, toi. Ciao. Ciao. [Musik]