#49 Die Zukunft: Software Repository Mining

Die Analyse von Metadaten aus dem Software-Entwicklungsprozess: Yey or Ney?

Die wenigsten kennen den Begriff des Software Repository Minings, doch die meisten benutzen Features, die darauf zurückzuführen sind. Zum Beispiel der automatische Vorschlag von den richtigen Pull Request Reviewern.

Es geht darum, auf Basis der Daten aus dem Softwareentwicklungsprozess neue Erkenntnisse zu gewinnen, um diesen einfacher und produktiver zu gestalten.

In dieser Episode klären wir, woher die Daten kommen, wie man an diese gelangt, welche Anwendungsfälle es gibt, was die Herausforderungen dabei sind und wie ihr damit starten könnt.

Bonus: Ob Andy bereits 50 Jahre alt ist und warum gute Architektur auch als Selbstschutz dient.

Sprungmarken

(00:00:00) Intro

(00:00:48) Das heutige Thema: Software Repository Mining

(00:02:15) Warum kann Andy was zum Thema Software Repository Mining sagen?

(00:04:03) Worum geht es beim Software Repository Mining?

(00:05:48) Wie kommt man an die Daten der Software Repositories? Data- und Web-Mining

(00:07:29) Klassische Anwendungsfälle von Software Repository Mining: Software Metriken, Velocity (Scrum) und womit wurde die Website gebaut?

(00:13:07) Anwendungsfall: Analyse von Commits

(00:15:12) Wer schaut sich solche Metriken? Wer kümmert sich um das Software Repository Mining?

(00:17:40) Anwendungsfall: Analyse von Kopplungen von einzelnen Dateien

(00:19:08) Ab wann macht Software Repository Mining Sinn? Wie schwierig ist es, sowas einzuführen?

(00:22:35) Anwendungsfall: Der geeignete Code-Reviewer

(00:23:36) Research: Nachvollziehbarkeit und Qualität von Source-Code

(00:27:06) Anwendungsfall: Automatische Versioning auf Basis von Semantic Versioning

(00:32:13) Anwendungsfall: Hot Topic Analyse

(00:33:24) Anwendungsfall: Kontextbasierte Informationen in der IDE

(00:37:27) Anwendungsfall: Review-Cycles im Pull Request als Datenpunkt fürs Mentoring und Coaching

(00:39:28) Ranglisten und Gamification aus Basis von Code Contributions

(00:41:14) Herausforderungen von Software Repository Mining: Unsaubere Daten, Data Storage, Cross-Linking und die Interpretation von Ergebnissen

(00:48:21) Wie startet man am besten mit Software Repository Mining?

(00:50:20) Andys Bachelor-Arbeit als Podcast

(00:51:18) Warum ist Software Repository Mining ein Nischen-Thema?

(00:54:00) Outro: FOSDEM Konferenz

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:00 - 00:00:40)

Kennt ihr Software Repository Mining? Wenn nicht, verwendet ihr es vielleicht aber trotzdem schon. Und damit willkommen zu einer neuen Episode im Engineering Kiosk, in der wir in die Metawelt der Softwareentwicklung eintauchen. Andi, der bereits vor Jahren seine Bachelorarbeit zu diesem Thema geschrieben hat, erklärt uns, wo wir heute schon Software Repository Mining einsetzen und welche Informationen in unseren Git Histories versteckt liegen. Denn diese versteckte Information kann uns schon heute im Programmieralltag helfen, aber auch in Zukunft die Basis für mehr Intelligenz im Entwicklungsprozess oder dem Co-Pilot der Zukunft sein. Neben der aktuellen Forschung erklären wir aber auch, wie ihr sofort mit dieser Zukunft für euer Projekt loslegen könnt. Also ab, zurück in die Zukunft zu Andis Bachelorarbeit. Straßen?

Andy Grunwald (00:00:40 - 00:00:43)

Wo wir hinfahren, brauchen wir keine Straßen.

Wolfi Gassler (00:00:48 - 00:00:54)

So, an die Episode 49. Bist du schon aufgeregt kurz vor der Episode 50?

Andy Grunwald (00:00:54 - 00:01:02)

Ich wäre aufgeregt, wenn ich 50 Jahre alt wäre, beziehungsweise kurz davor. Aber nein, ich bin nicht aufgeregt, ich bin stolz auf uns.

Wolfi Gassler (00:01:02 - 00:01:27)

Ich werde dich noch mal daran erinnern, wenn wir dann mit 50 unsere Episode 348 oder so machen. Also das ist wahrscheinlich noch mehr. Dann können wir richtig feiern. Ich bin gespannt, ob wir dann auch noch auf diesen Computerbild-Themen herumreiten, so wie letztes Mal Docker. Mit dir als Computerbild-Experte haben wir uns mal gedacht, wir gehen heute auf ein Developer-Thema zurück, also wirklich zurück in die Software.

Andy Grunwald (00:01:27 - 00:01:35)

Das heutige Thema ist halt schon eine direkte Nische, finde ich. Oder hast du von dem Thema, worüber wir heute sprechen, vorher gehört, bevor du mich kennengelernt hast?

Wolfi Gassler (00:01:36 - 00:01:39)

Traust du dir jetzt den Namen nicht zu sagen von diesem Nischenthema?

Andy Grunwald (00:01:39 - 00:01:41)

Ich wollte dir die Ehre überlassen.

Wolfi Gassler (00:01:41 - 00:01:58)

Also meine Frage wäre mal, warum heißt es MSR, Mining Software Repositories und nicht Software Repository Mining? Das wäre ja viel sinnvoller. Warum gibt es da überall nur MSR, MSR Konferenz? Der Wikipedia-Eintrag heißt Mining Software Repositories.

Andy Grunwald (00:01:58 - 00:02:10)

Ich habe keine Ahnung, warum es in dem einen Spektrum Software Repository Mining heißt. Ich habe keine Ahnung, warum es dann ab und zu Mining Software Repository heißt. Vielleicht ist es irgendwie die eine, das eine ist irgendwie das Research-Feld, was andere die Aktivität oder ähnliches.

Wolfi Gassler (00:02:10 - 00:02:31)

Du bist mir schon mal ein Spezialist. Die erste Frage kannst du schon mal nicht beantworten. Aber fangen wir mal vielleicht vorne an mit einer leichten Frage. Nachdem ich dich schon angekündigt habe als Spezialist im Software Repository Mining, warum bist du denn Spezialist? Wie kommst du denn in dieses ganze Thema rein? Ist ja jetzt nicht unbedingt so ein Standard-Thema, würde ich mal sagen, was jeder jetzt irgendwie im Auge hat.

Andy Grunwald (00:02:31 - 00:02:41)

Ist kein Standard-Thema, ist eher meines Erachtens ein Nischenthema. Und ob ich darin ein Experte bin, bezweifle ich auch, weil du weißt ja, umso mehr man weiß, desto mehr weiß man, was man nicht weiß.

Wolfi Gassler (00:02:41 - 00:02:44)

Du kannst mir auf jeden Fall mal erklären. Für mich bist du schon ein Experte.

Andy Grunwald (00:02:44 - 00:03:04)

Warum ich mich seit fast über zehn Jahren mit dem Thema beschäftige, ist relativ einfach. Ich hab da unter anderem meine Bachelorarbeit drüber geschrieben. Ich hab die gestern noch mal rausgeholt. Über 60 Seiten nur diesem Thema gewidmet. Und da sind ein paar Stunden Research-Arbeit in der Düsseldorfer Unibibliothek reingeflossen.

Wolfi Gassler (00:03:05 - 00:03:09)

Ist es schon so lange her, dass es kein Internet gegeben hat, dass du in der Bibliothek warst?

Andy Grunwald (00:03:09 - 00:03:24)

Da ging es ganz einfach um Arbeitsfokus, weil zu Hause konnte ich mich nicht fokussieren, da hätte ich lieber irgendwie World of Warcraft gespielt oder Counter-Strike. Und die Unibibliothek hatte auch bis 24 oder bis 2 Uhr nachts sogar auf, das hat sehr gut gepasst. Und die hatte einen kontinuierlichen guten Kaffeeautomaten.

Wolfi Gassler (00:03:25 - 00:03:27)

Das möchte ich mal bezweifeln, aber ja, okay.

Andy Grunwald (00:03:28 - 00:03:43)

Es gab auch noch ein paar wissenschaftliche Bände, die ich dann nur durch meinen akademischen Zugang von der Universität als Buch zur Uni Düsseldorf hinsenden lassen konnte, weil es die irgendwie nur in München gab oder ähnliches, und deswegen war ich halt sehr oft da.

Wolfi Gassler (00:03:43 - 00:03:50)

Das klingt so richtig, richtig oldschool, Bücher irgendwo hinsenden lassen. In was für einem Jahrhundert war denn das?

Andy Grunwald (00:03:50 - 00:04:00)

Das war 2013, aber diese Materialien, diese Konferenzpaper hab ich online so nicht gefunden zumindest nicht mit den wissenschaftlichen zugängen die ich hatte.

Wolfi Gassler (00:04:00 - 00:04:09)

Oh jetzt wollten wir das als hippes thema bewerben und jetzt kommst du mit sowas das da nicht einmal im internet irgendwas gibt aber erklär mal worum es eigentlich geht bei dem ganzen thema im blog.

Andy Grunwald (00:04:09 - 00:04:24)

Meines erachtens nach ist das ein super hippes thema ja nur diese ganze research akademik geschichte ist alles ein bisschen eingestoppt meines erachtens nach ist das ein thema was 100 prozent in den schadlöchern steht und wovon wir in naher zukunft viel viel viel mehr sehen werden und zwar.

Wolfi Gassler (00:04:25 - 00:04:29)

Und das steht seit 2013 in diesem Startloch, nur um das nochmal klarzustellen.

Andy Grunwald (00:04:29 - 00:04:31)

Eigentlich schon seit 2004, meines Erachtens nach.

Wolfi Gassler (00:04:31 - 00:04:34)

Okay, steht schon lange in diesem Loch. Okay.

Andy Grunwald (00:04:34 - 00:04:56)

Software Repository Mining, was ist das eigentlich? Es geht um die Analyse von Daten und Metadaten, die während eines Softwareentwicklungsprozesses entstehen. Also du codest Software, du machst ein Sideproject oder von mir aus auch in deiner Produktfirma oder in deiner Agentur. Und während du dann da irgendeine Website machst, eine App codest und so weiter, fallen halt links und rechts eine ganze Menge Metadaten raus.

Wolfi Gassler (00:04:56 - 00:04:57)

Was wäre das zum Beispiel?

Andy Grunwald (00:04:57 - 00:05:50)

Ganz klassisch erstmal alles das, was du ins Versionskontrollsystem einsteckst. Einmal der Sourcecode, einmal die SVN-Comment-Message, Git-Comment-Message, deine Bug-Tracking-Issues, Mailing-Listen-Einträge, Code-Review-Daten, welche Kommentare an welcher Zeile in deinem Pull-Request gemacht wurden. an welchem Unit-Test der Jenkins oder GitHub Actions failt, also CI-Daten, Wiki-Einträge, aber auch deinen Firmen-Chat, wie zum Beispiel Slack, oder wenn's eine andere Community ist, IRC, oder wenn's eine größere Community ist, vielleicht sogar eine Open-Source-Community, irgendwie Events, so was wie Meetups und Konferenzen und Co., ja? Also das sind alles die Datenquellen und wenn wir von Software-Repository-Mining sprechen, dann heißt Software-Repository ist jetzt nicht unbedingt das Git-Repo, sondern jeder dieser Datenquellen, Mailinglisten, Code-Review-Daten, wird als ein Software-Repository bezeichnet in dieser Hinsicht.

Wolfi Gassler (00:05:51 - 00:06:04)

Und wie, wenn du jetzt zum Beispiel von Meetup sprichst, wer da im Meetup irgendwo gesprochen hat, wie komm ich auf diese Daten, das Version Control System verstehe ich noch, die Git-Daten sind alle verfügbar, aber so externe Events?

Andy Grunwald (00:06:04 - 00:07:06)

Naja, also die Daten sind halt schon verfügbar, ne? Du hast halt ein Tables of Content und allem drum und dran und wer spricht wann wie wo. Der Unterschied ist halt nur, wie die Daten verfügbar sind. Auf der einen Seite hast du natürlich recht strukturierte Daten und dann hast du natürlich die Herausforderung, die ganzen unstrukturierten Daten aus klassischem Fließtext und Co. Also wir bewegen uns hier schon, deswegen heißt es auch Software Repository Mining, wir bewegen uns schon im großen Teil im Bereich Data Mining und da in primär zwei Kategorien Text Mining und Web Mining. Das ist so das Hauptfeld, wo wir uns bewegen. Und da geht's natürlich ... Ich glaub, heutzutage würde man das als Data Analysis oder vielleicht schon Data Science benennen, weiß ich grad nicht. Aber damals gab's halt die ganzen Begriffe noch nicht, sondern da hieß es einfach nur Data Mining. Aber da kommt's auch ein bisschen drauf an, Datenquellen man zur Hand nimmt. Also wenn du jetzt deine Slack-Chats analysieren möchtest, dann bist du natürlich im Text-Mining. Wenn du jetzt zum Beispiel deinen Source-Code analysieren möchtest, dann kannst du auch sagen, okay, du bist jetzt hier nicht im Data-Mining, sondern schon eher so im Bereich statische oder dynamische Code-Analyse.

Wolfi Gassler (00:07:06 - 00:07:13)

Und die Events holen wir dann, Web-Mining klassisch, auf irgendwelchen Webseiten, die Speaker von den Events oder Meetups scrollen.

Andy Grunwald (00:07:14 - 00:07:31)

Ja, genau. Also als Webmining wird ja unter anderem auch, du dumpst dir irgendeine API runter und sowas in anderen Data Storage. Also das bedeutet, du meinst das Web nach Informationen und holst dir da die entsprechenden Daten, Informationen, Konferenzseiten, Meetups, Wikidaten, Pull-Request-Daten oder ähnliches.

Wolfi Gassler (00:07:32 - 00:07:37)

Und was macht ihr dann mit die Daten im Endeffekt? Dann haben wir mal die Daten gecrawled oder irgendwie explodiert. Aber was macht ihr dann damit?

Andy Grunwald (00:07:37 - 00:08:54)

Jetzt kannst du sagen, okay, Software Repository Mining ist die Analyse von Daten und Metadaten, die während eines Softwareentwicklungsprozesses entstehen. Aber die Frage ist auch, okay, was macht man denn damit? Ja, das Ziel ist damit auch, den Entwicklungsprozess und das Projekt kontinuierlich zu verbessern. Also jetzt nicht das eine Spezifische, sondern im Allgemeinen. Und zwar, wenn man zum Beispiel aus den Daten wirklich neue Erkenntnisse zieht und daraus Aktionen tätigt und daraus was lernt. Die ganz klassischen Anwendungsfälle, also die wirklich heute Standard sind, kann man eigentlich auch sagen, sind Software Repository Minings. Wie zum Beispiel Softwaremetriken. Also wir reden hier von zyklomatischer Komplexität, Endpath-Komplexität oder irgendwie die durchschnittliche Vererbungstiefe. Das sind jetzt eigentlich ganz klassische Metriken, die du durch Software Repository Mining, indem du statische Codeanalyse betreibst, herausfindest und sagst, Diese Klasse oder diese Methode überschreitet einen gewissen Schwellenwert der zyklogrammatischen Komplexität. Nur noch mal ganz kurz zur Info. Zyklogrammatische Komplexität bedeutet, wie viele Entscheidungspunkte innerhalb einer Methode sind. Also das bedeutet, eine Methode hat erstmal eine zyklogrammatische Komplexität von 1 und sind innerhalb der Methode 2 IF-Abfragen, dann ist das eine zyklogrammatische Komplexität von 3. Und umso höher die zyklogrammatische Komplexität ist, umso schwieriger ist es, diese Methode zu maintainen. Ja, zum Beispiel.

Wolfi Gassler (00:08:54 - 00:08:56)

Und man will dann ein niedrigere erreichen.

Andy Grunwald (00:08:56 - 00:09:24)

Genau. Wenn man solche Informationen hat, kann man natürlich innerhalb des Teams oder innerhalb der Firma vielleicht sogar gewisse Regeln feststellen, hey, pass mal auf, wir sollten keine Methode mit einer zyklomatischen Komplexität über 10 haben. Und dann kann man sehen, okay, wie splitten wir diese Methode auf, wie refactoren wir diese, und dann wird die natürlich auch leichter testbar, weil umso mehr Entscheidungsmöglichkeiten da sind, umso schwieriger sind natürlich auch die Testcases, Ich sage nicht, man muss überall eine hundertprozentige Testcoverage haben, aber um eine hohe Testcoverage zu kriegen.

Wolfi Gassler (00:09:24 - 00:09:37)

Jetzt hast du gerade erklärt, das ist ein Nischenthema, aber die Softwaremetriken werden ja in jedem sinnvollen Team oder professionellen Team, würde ich mal sagen, was ein bisschen größer ist und was von sich hält, wird das Ganze ja eingesetzt. Das heißt, wir haben das eigentlich schon überall.

Andy Grunwald (00:09:38 - 00:10:00)

Ja, das ist richtig, aber niemand kennt das als Software-Repository-Mining. Jeder sagt, okay, das ist irgendwie jetzt da und toll. Und das ist auch eher so der Standard-Case, ja, den jeder kennt. Nischenthema bezeichne ich das, weil das ganze Potenzial dieses Themas vornherein nicht ausgelebt wird. Und da kommen wir jetzt gleich zu. Zum Beispiel, welche Anwendungsfälle gibt's denn noch und wo können wir uns mal wirklich den Benefit von diesem Thema abholen?

Wolfi Gassler (00:10:01 - 00:10:04)

Was gibt es dann noch abseits dieser Standardsoftwaremetriken?

Andy Grunwald (00:10:04 - 00:11:35)

Ein weiteres Beispiel ist die Projektmethode, wie dein Team Software entwickelt. Sehen wir einfach mal Scrum oder Kanban. Bei Scrum wäre es zum Beispiel eine klassische Velocity, weil wenn du es mal herunterbrichst, hast du Sprints über zwei Wochen. zu diesem Sprint Assigned-to-Tickets, die ihr machen wollt. Und vorher im Planning habt ihr irgendwie die Komplexität von diesem Ticket geschätzt. Und die Summe der Komplexität von den Tickets, die ihr innerhalb eines 2-Wochen-Sprints geschafft habt, nennt man Velocity. Theoretisch könnte man auch sagen, okay, die Velocity ist somit auch Teil vom Software Repository Mining, weil man ja ähnlich wie bei den Softwaremetriken eine Metrik über den Progress der letzten 2 Wochen misst. Die andere Geschichte ist halt zum Beispiel bei Kanban. Bei Kanban versuchst du immer, relativ schnell ein Ticket von links, von der To-Do-Column nach rechts, auf die Done-Column zu schieben. Und du möchtest eigentlich den Speed, den Ticket-Flow, relativ hoch halten. Also relativ kurz halten, dass ein Ticket möglichst schnell von links nach rechts geht. Das ist halt ebenfalls eine Metrik, die du aus dem Software-Repository von deinem Bug-Tracker liest. Und ein dritter Case, vielleicht haben viele Leute schon mal sowas gesehen wie, womit wurde diese Webseite gebaut? Da gibt es so Chrome-Plugins und auch so Webseiten, da kannst du einfach eine URL eingeben und dann steht da, diese Webseite wurde mit WordPress gebaut und dieses WordPress-Plugin und diese jQuery-Version ist da und so weiter. Und dann werden so große Rankings erstellt, wie viel der Fortune-500-Firmen eigentlich jQuery einsetzen oder ähnliches. Das kann man ebenfalls dem Bereich von Software Repository Mining zuschreiben.

Wolfi Gassler (00:11:35 - 00:11:50)

Also das sind so Seiten wie buildwith.com ist glaube ich einer der größten, wo man das dementsprechend nachschauen kann und das fällt dann auch eher in das Web Mining, was du am Anfang erwähnt hast, dass man so wirklich Public Data crawlt und daraus Informationen zieht.

Andy Grunwald (00:11:50 - 00:13:14)

Ja, genau. Und wenn wir das Ganze jetzt nicht nur mal auf Webseiten betreiben, sondern einfach zum Beispiel auf Libraries, NPM, JavaScript-Libraries, die ihr einsetzt, dann könnt ihr das eigentlich inzwischen auch auf GitHub tun. Ihr habt eine NPM-Library veröffentlicht und ihr wollt wissen, wie viele Leute oder andere Projekte setzen in meine Library ein. Dann könnt ihr einfach mal nach eurem Library-Namen suchen, begrenzt die Suche auf package.json und somit habt ihr ein Listing von Projekten, die eure Library einsetzen, was super interessant ist. Und dann kann man natürlich nochmal weitergehen. Dann kann man sich ansehen, welche Features von eurer Library werden denn eigentlich genutzt. Weil jetzt geht es nämlich ins wirkliche Software Repository Mining. Und jetzt kommt der Punkt, da wo ich sage, es ist ein Nischenthema und das Potenzial ist noch ungenutzt. Nehmen wir mal an, wir gehen auf buildwiz.com. und holen uns die 50 meistbesuchten Webseiten im Internet, die jQuery nutzen. Und wir analysieren diesen JavaScript-Code mit der Frage, welche Funktionalität wird denn von jQuery hier eingesetzt? Und welche? Und viel wichtiger auch, welche eigentlich nicht? Diese Information kann für das jQuery-Projekt natürlich unglaublich sinnvoll sein in Bezug auf, müssen wir oder sollten wir darüber nachdenken, die Performance von dieser Funktionsreihe zu verbessern zum Beispiel. Ja, das kann dir also ein bisschen so den Produktfokus durch Software Repository Mining geben. Und okay, wie sieht denn die nächste Roadmap aus, um einen größeren Impact zu haben?

Wolfi Gassler (00:13:15 - 00:13:44)

Okay, diese Metriken und Informationen gehen ja schon relativ weiter ins Produktentwicklungsfeld als für Product Manager zum Beispiel oder wenn ich eben wirklich eine Library für meine User entwickle, Open Source Library zum Beispiel. Aber was für Anwendungsfälle gibt es denn für Teams an sich? Also was abseits dieser klassischen Softwaremetriken, gibt es irgendwie Anwendungsfälle, wo ich das als Team oder als Firma intern besser nutzen kann von meinem eigenen Entwicklungsprozess?

Andy Grunwald (00:13:44 - 00:13:57)

Da gibt es etliche Beispiele. Man unterteilt hier zwei große Bereiche. Und zwar schaut man sich ein einzelnes Software-Repository, also eine einzelne Datenquelle an oder schaut man sich mehrere Datenquellen in einem Analysevorgang an.

Wolfi Gassler (00:13:57 - 00:14:06)

Und mit Datenquellen meinst du jetzt weder, das kann auch eine Wiki sein oder andere Datenquellen und nicht nur das Software-Repository, also kein GitHub-Repository oder Git-Repository?

Andy Grunwald (00:14:06 - 00:15:20)

Ja, ganz genau. Zum Beispiel schauen wir uns die Pull-Requests an oder die Logs vom CI-System oder die Slack-Chat-Protokolle oder Ähnliches. Das ist jetzt eine Data-Source. Wenn wir uns mal nur auf eine Data-Source beschränken, kann man zum Beispiel sagen, okay, wir machen eine ganz klassische Commit-Analyse und aus dieser Commit-Analyse wenn wir jetzt uns die Git-Commit-Messages nehmen und wir haben irgendwie so eine Art Regel, wir prefixen zum Beispiel immer diese Git-Commits mit Bugfakes, Feature, Docs für Documentation oder ähnliches, dann kann man da schon mal erstmal die ersten Erkenntnisse rausziehen, indem man einfach nur ein klassisches Git-Log und ein Grab macht und dann das vorkommende zählt, wie ist eigentlich die Balance in den letzten drei Monaten zwischen Feature-Entwicklung, Bugfixes und Documentation oder welche Dateien in meinem Projekt wurden eigentlich in letzter Zeit vermehrt geändert. Weil, nehmen wir mal die Theorie, eine Datei, die sehr oft geändert wird, hat ein höheres Risiko, existierende Funktionalität zu brechen. Da könnte man drüber nachdenken, wenn an diesen Dateien immer konstant Änderungen sind, sollten wir die Testcoverage für diese Dateien nicht hochdrehen, damit wir sicherer sind, dass wir keine existierende Funktionalität brechen.

Wolfi Gassler (00:15:21 - 00:15:49)

Kleine Frage auf der Meta-Ebene dazu, wer schaut sich denn deiner Meinung nach im Team solche Metriken an? Oder wer kümmert sich denn um genau diese Fragestellungen? Weil ich denke da jetzt gerade so an ein Entwicklerteam und die programmieren alles so dahinten und probieren ihre Sprints fertig zu bekommen. Wer kümmert sich denn um so Meta-Themen und checkt da, okay, wo können wir was verbessern? Weil es klingt ja schon nach so einem Use-Case, wo es eher darum geht, so die letzten zwei Prozent irgendwie rauszuholen, gefühlt.

Andy Grunwald (00:15:49 - 00:17:01)

Also nehmen wir mal an, wir machen eine Comet-Analyse, wie viele Bugfixes wir gemacht haben in den letzten drei Monaten. Und nehmen wir mal an, wir analysieren diese Bugfixes und stellen fest, 30% unserer Bugfixes waren Regression-Bugfixes. Also Fixes, wo wir einen Fehler behoben haben, ihn aber wieder irgendwann mal eingeführt haben. Dann weiß ich jetzt nicht ganz, ob es wirklich um die Optimierung von 2% geht. Kommt natürlich auf deine Kadenz drauf an, wie viele Comets ihr habt, wie schnell sich die ganze Sache weiterentwickelt. Kommen wir auf deine Frage, wer sollte sich so was ansehen? Meines Erachtens nach sollten ab-Mid-Level-Engineers wenigstens mal die Hand heben, hey, wär das nicht mal cool, wenn wir uns so was ansehen? Und ab Senior, also Senior Plus, das bedeutet Senior Engineers, Staff Engineers oder Ähnliches, die sollten so was dann schon mal entweder nach vorne treiben oder halt sehr technische Engineering Manager, weil nicht jeder Engineering Manager muss ja einen technischen Background haben. diese leute da würde ich schon die verantwortung sehen sowas nach vorne zu treiben natürlich nicht wenn die hütte brennt und alle sind irgendwie nur am löschen ja dann löscht man natürlich erst für mich zählt das alles so prozessoptimierung und meines erachtens nach ist das auch eine verantwortung auch von senior engineer ich glaube dass.

Wolfi Gassler (00:17:01 - 00:17:42)

Das auch ganz wichtig ist dass das vom team selbst kommt weil auch erfahrungsgemäß sobald da was von der management seite kommt engineering manager seite oder auch womöglich noch drüber oder oder product dann fallen da sofort die Scheuklappen zu und alle Entwickler und Entwicklerinnen haben irgendwie Angst, Überwachung, man wird da irgendwie kontrolliert und da wird sofort geblockt. Also das war meine Erfahrung, immer wenn es in irgendeiner Form in Richtung Metriken geht, egal was es dann eigentlich ist, wird ziemlich schnell geblockt. Da muss man auch auf Manager Seite extrem aufpassen, wenn man sowas einführt oder wie du richtig sagst, im Idealfall kommt es einfach von den Senior Leuten und dann bildet das Team das im Idealfall auch.

Andy Grunwald (00:17:42 - 00:19:11)

Aber nehmen wir mal vielleicht einen Use Case, der eigentlich auch zu den Hard Skills von Software Engineers gehört. Und da geht es um Software Architektur. In der Regel hat man in einer Software mehrere Pakete, Module, Packages, Plugins, wie auch immer das in eurer Sprache und in eurem System heißt. Und jetzt geht es um die Architektur. Also man kann natürlich auch sagen, man analysiert die Kopplung von einzelnen Dateien oder von einzelnen Modulen. Wie macht man das zum Beispiel? Hier ist die Idee, wenn für Features oder Bugs häufig die gleichen Dateien angefasst werden, also welche Dateien werden innerhalb eines Commits oft zusammengeändert? Und wenn man dann eine zweite Frage stellt, von diesen häufig zusammengeänderten Dateien, wie viel liegen denn im selben Package und wie viel liegen in verschiedenen Paketen? Paketen, Packages, Module, Plugins, Klassen, Was weiß ich nicht. Mit diesen Informationen können dann Entwicklern feststellen, ob sie hier eine implizite Kopplung haben. Ja, weil speziell für neue Entwickler ist das relativ schwierig. Du kommst in eine neue Codebase und du änderst eine Klasse und du denkst, ah, okay, cool, jetzt ist mein Feature drin. Aber nur der Senior Entwickler weiß, hey, ja, Moment, wenn du diese Klasse änderst, dann musst du aber die Klasse auch da hinten ändern. Und wie soll man das wissen als Neuentwickler? Weil die Kopplung ist ja nicht explizit. Durch so eine Analyse, wie viele Dateien oder welche Dateien werden häufig zusammengeändert, kann man diese impliziten Kopplungen auflösen und vielleicht sogar mal ein bisschen die Architektur verbessern, dass du halt wirklich eine einzelne Verantwortlichkeit pro Klasse oder pro Datei hast.

Wolfi Gassler (00:19:12 - 00:19:46)

Was glaubst du denn ab wann sowas Sinn macht, ab welcher Teamgröße, weil auch das, um da jetzt wieder herumzureiten auf diesem Optimieren der letzten drei Prozent, das klingt schon sehr sophisticated würde ich sagen und die wenigsten Team achten auf sowas. Jetzt macht es Sinn in einem kleinen Team sich sowas schon anzuschauen oder würdest du sagen okay es macht nur Sinn wenn man irgendwie jetzt 10 Teams hat oder sowas oder ab welcher Größe macht sowas Sinn? Und vielleicht auch da gleich mitgestellt die Frage, wie schwierig ist denn das sowas einzuführen in einem Team jetzt rein von der technischen Seite?

Andy Grunwald (00:19:46 - 00:20:00)

Ich weiß gar nicht, ob man das anhand der Teamgröße festlegen kann oder ob es nicht eine Kombination ist aus Teamgröße, Abteilungs- und Firmengröße oder auch Wichtigkeit der Software und Größe der Software.

Wolfi Gassler (00:20:00 - 00:20:12)

Oder vielleicht anders gefragt, wenn ich jetzt so ein 2-3-Leute-Team bin, würdest du dann sowas schon empfehlen? Ich arbeite an dem Projekt immer an derselben Software, an dem Produkt über Jahre.

Andy Grunwald (00:20:12 - 00:20:30)

Wenn es eine Codebase von einer Million Zeilen ist, ja, warum nicht? Weil gute Architektur ist auch Selbstschutz. Das heißt ja nicht, dass man nur konstant mit 10.000 Leuten daran arbeiten muss, sondern das heißt auch einfach nur, weil ich in dem Bereich des Codes nicht so flüssig bin, heißt das nicht, dass eine gute Architektur mich nicht hier auch beschützen kann, Fehler zu machen.

Wolfi Gassler (00:20:30 - 00:20:32)

Das heißt erst ab einer Million Zellen.

Andy Grunwald (00:20:32 - 00:20:49)

War jetzt einfach nur mal ein Indikator für eine große Codebase. Aber es kommt halt auf die Komplexität an, auf die Wichtigkeit und Co. Ist schwierig zu sagen. Also diese Benefits werden natürlich deutlich sichtbarer, umso größer und komplexer die Software ist und umso mehr Leute an diesen Teams arbeiten. Das ist korrekt.

Wolfi Gassler (00:20:49 - 00:21:02)

Und wenn man das jetzt konkret einführen will, gibt es da Software dafür, wenn da jetzt ein Team losstarten will und sagt, unser Zeug ist eh alles so komplex und überall Abhängigkeiten, ich will da mal einfach ein bisschen Visibility reinbringen in das Ganze.

Andy Grunwald (00:21:03 - 00:21:09)

Software gibt es wie Noch und Löcher, professionelle, proprietäre Software, aber auch Open Source Software.

Wolfi Gassler (00:21:09 - 00:21:12)

Was wäre dann so ein Beispiel für Open-Source-Software?

Andy Grunwald (00:21:12 - 00:21:46)

Also wenn wir jetzt auf die Kopplungen selbst eingehen, mit der Architektur, was ich gerade gesprochen habe, kenne ich nur proprietäre Enterprise-Software, die dann aber auf sprachspezifische Features gehen, wie Java oder ähnliches, die das anhand der Architektur-Diagramme geben. Wenn wir auf die Analyse der Kopplungen sind, gibt es sowas wie CSV-Analysie. Verlinken wir in den Shownotes. Ist so ein kleines Python-Skript, was hier die ganzen Daten, die ganzen Git-Comet-Messages in der SQL-Tabelle packt. Und dann kannst du da ein paar Queries drauffahren und in dem Repository gibt es auch ein paar Example-SQL-Queries.

Wolfi Gassler (00:21:46 - 00:22:00)

Das heißt aber ich muss mir das schon selber zusammenbauen wenn ich da jetzt zumindestens opensourcemäßig unterwegs sein will und jetzt nicht irgendein enterprise tool einsetzen will da gibt es jetzt nicht sowas wie sonar cube das mir das alles einfach out of the box liefert.

Andy Grunwald (00:22:00 - 00:23:02)

Deswegen sag ich es ist noch ein Nischenthema es ist noch nicht in der in der globalen community angekommen. Ich selbst entwickle ein ähnliches Seitenprojekt, was sich mit sowas beschäftigt, was sowas einfach macht, aber auch nur, weil ich mich mit diesem Thema einfach sehr verbunden fühle und sehr viele Passion darüber habe. Aber es ist jetzt nicht so, hier, kauf dieses Tool und geht darüber. Es gibt eine Firma, die nennt sich Betergia, die macht sowas professionell für große Open-Source-Projekte, wie zum Beispiel OpenStack oder Wikimedia oder ähnliches. Die sind da schon sehr gut, weil die ist auch eine Truppe von ehemaligen Universitäts-Researchern und Doktoren, die sich nur mit diesem Thema beschäftigen. Aber kommen wir mal ein bisschen weg wieder von diesen klassischen Architektenrollen. Was fast jeder schon mal gesehen hat, ist ein Feature, was GitHub eigentlich macht. Und zwar stellt euch vor, ihr macht einen neuen Pull-Request und ihr wisst nicht, wer ist denn die geeignete Person, um einen Pull-Request hier zu reviewen. Ganz klassisch ist, du schaust dir ein Git-Blame an und schaust nach, wer hat denn diese Datei oder diese Zeile oder diese Methode die letzten zwei, drei Male eigentlich geändert.

Wolfi Gassler (00:23:02 - 00:23:11)

Moment, ich hol mir da immer meinen Kollegen, der jeden Bully-Request mit Looks good to me approves. Das ist wohl viel der schnellere Weg.

Andy Grunwald (00:23:11 - 00:23:38)

Ja, das ist super. Ich glaube, ihr solltet auch mal eine Commit-Analyse machen, wie viel Bugfixes ihr macht. Aber das macht zum Beispiel auch GitHub. Wenn ihr ein Pull-Request macht und ihr habt ein Repository, wo ein bisschen Leben drin ist, dann schlägt euch GitHub die richtigen Leute vor, die diesen Pull-Request reviewen sollten, anhand der Änderungen, die an der Datei oder an den Zeilen gemacht wurden. Das ist zum Beispiel auch Software-Repository-Mining, weil in der Regel diese Informationen aus dem Git blamen oder aus dem Git-Comet-Log.

Wolfi Gassler (00:23:38 - 00:23:56)

Okay, jetzt hast du einige Dinge erklärt, die es schon gibt, die teilweise auch gemacht werden. Gibt's irgendwas next level, wo du sagst, das wäre cool oder da kennst du jetzt keine Umsetzung, aber es wäre cool, wenn man sowas aus den Informationen rauslesen könnte und auch dann dementsprechend nutzt?

Andy Grunwald (00:23:57 - 00:24:22)

Also gibt's noch nicht und Next Level ist eine schwierige Kategorisierung, weil die meisten Themen in dem Bereich Software Repository Mining sind halt wirklich wahre Research-Themen und da haben sich dann irgendwelche Doktoranden damit beschäftigt und haben irgendwo enorm komplizierte Python-Skripte rumliegen, die dann die Analyse machen, aber die sind dann in der Regel nicht frei zugänglich. Du kennst das ja am besten mit Research-Ergebnissen und Research-Code, der ist meist nicht reproduzierbar.

Wolfi Gassler (00:24:22 - 00:25:59)

Also da muss ich jetzt mal einspringen. Nicht reproduzierbar, das kann sein, aber mittlerweile recht viele Konferenzen verlangen eigentlich, dass man den Source Code online stellt, verfügbar macht. Ich hoffe mal, das ist bei dieser MSR, bei der Mining Software Repository Konferenz, die es schon ziemlich lange gibt. Und zwar gibt es die schon seit 2004 in dem Fall. Läuft immer noch. Nächstes Jahr ist in Melbourne zum Beispiel. Und ich hab mir da mal auch angeschaut, was da so gemacht wird auf der Konferenz. Ist ganz interessant für alle, die jetzt weniger wissenschaftlichen Background haben. Man kann einfach auf diese Konferenz nochmal gehen und unter dem Program findet man meistens dann eine Auflistung von den ganzen Themen und Papers, die dort präsentiert worden sind. Also erst schreibt man ja ein Paper, 8-seitig, 16-seitig, je nachdem, zu den ganzen Bereichen BDF und dann präsentiert man das auf diesen Konferenzen. Und da gibt es so Themen wie, ganz hip natürlich, auch GitHub Copilot, Analysen dazu, was die verändert haben, oder auch so Dinge wie Analyse von Python Notebooks, wie die die Python-Programmierung verändert haben. Also es sind viele solche Metathemen, weil es halt bei dem Thema auch einfach um Metainformationen geht, aus den verschiedensten Datenquellen. Und da gibt es wirklich interessante Papers aus den verschiedensten Bereichen und Themen, Bereichen und meistens kann man sich das PDF dann auch jeweils durchlesen, um da die Details noch rauszuholen und im Idealfall ist dann auch ein GitHub-Link dabei zum Source-Code und ist natürlich meistens halt alles sehr experimentell, muss man auch dazu sagen. Also bei einer großen Firma das dann einfach zu klonen und einzusetzen, das spielt sich meistens nicht, aber man kann zumindest mal reinschauen, was da so gemacht wird.

Andy Grunwald (00:26:00 - 00:26:29)

Bei diesem ganzen Research-Code habe ich immer das Gefühl, man muss genauso viel Arbeit da reinstecken, um das Ding ans Fliegen zu kriegen, wie wenn man sich eine Lösung selbst überlegen würde. Weil oft hat man irgendwie so, also das ist natürlich eine Lüge, weil diese Researcher packen unglaublich viel Arbeit da rein, ja, aber ich sag nur so, wenn ich ein GitHub-Repository sehe, mit 20 Python-Files, mit jeweils über 400.000, 500.000 Zeilen, und da ist dann immer so ein Readme dabei, und ich hab keine Ahnung, was ich hier mache, oder was, wie, wo gestartet werden muss, dann ist es halt schon echt schwierig, das zu reproduzieren.

Wolfi Gassler (00:26:29 - 00:27:02)

Du musst es so sehen, alle Entwickler wollen sowieso immer alles selber programmieren. Stell dir vor, die Researcher würden das auch noch schön programmieren, dann wäre das auch alles umsonst, weil jeder Entwickler sagt, ich mach das sowieso selber, wir machen das mit einem anderen Tool, wir haben ein anderes internes Toolset. Das machen wir selber. Also die Idee ist ja bei Grundlagenforschung, wobei das wird jetzt mal nicht als Grundlagenforschung bezeichnet, aber trotzdem bei Grundlagenforschung die Idee mal zu überprüfen, ob sie funktioniert und dann den ganzen Markt reif zu machen, das ist eine Aufgabe der Wirtschaft, muss man auch ganz klar sagen.

Andy Grunwald (00:27:02 - 00:27:21)

Aber kommen wir mal zu dem heißen Scheiß und was ich gerne sehen würde, was ich so noch nicht gesehen habe. Und zwar geht es hier um die automatische Versionierung von Software. Stell dir mal vor, du hast eine Software und du bringst sie jetzt in Version 1 raus und deine Software 1.0.0 und deine Software folgt dem Semantic Versioning.

Wolfi Gassler (00:27:21 - 00:27:24)

Klär mal schnell, was Semware genau ist für alle, die es nicht kennen.

Andy Grunwald (00:27:25 - 00:27:58)

Semantic Versioning befolgt einem Versionsschema, wie du deine Software versionierst anhand der Änderungen. Du hast drei Zahlen. Major Version, Minor Version, Bugfix Version. Zum Beispiel 2.0.0. Wenn du jetzt bei der Version 2.0.0 nur einen Bugfix machst, wäre deine nächste Version 2.0.1. Wenn du jetzt ein neues Feature hinzufügst, wäre deine nächste Version 2.1.0. Wenn du jetzt zum Beispiel ein Breaking Change machst, dann wäre deine nächste Version eine 3.0.

Wolfi Gassler (00:27:58 - 00:28:01)

Das heißt, Breaking Changes sind nur auf der ersten Ziffer, oder?

Andy Grunwald (00:28:01 - 00:28:16)

So, Semantic Version. Da gibt es noch ein paar mehr Regeln, wann du welche Versionsnummer, Major, Minor, Bugfix, wann du die erhöhst. Der Punkt ist aber, dass du anhalt der Versionsnummer sehen kannst, wie kritisch dein Upgrade ist oder ob du da mehr Arbeit reinstecken musst oder ähnliches.

Wolfi Gassler (00:28:17 - 00:28:43)

Ist übrigens alles ganz schön auf samware.org definiert, beschrieben auf Englisch, auf Deutsch, inklusive einer Sprachendefinition, was das genau ist, wie man das definiert. Also ist super genau definiert und hilft mir als User zum Beispiel extrem weiter, weil ich sofort an der Nummer sagen kann, ist das ein Problem für mich oder nicht. Und wenn man sich darauf verlassen kann, kann man sofort sagen, okay, das kann ich einfach drüber spielen, Patch Version, sollte kein Problem sein.

Andy Grunwald (00:28:43 - 00:29:05)

Passt aber bitte auf, nicht jede Software benutzt Semantic Versioning. Beispiel, die Datenbank MySQL ist unglaublich berühmt dafür, in der Bugfix-Version, also in der letzten Versionsnummer, irgendwelche Breaking Changes reinzupacken oder irgendwelche Features zu debriketen oder was weiß der Geier, nicht automatisch. Die folgen einfach keinem Semantic Versioning. Also schaut da bitte vorher nach, welche Software von euch Semantic Versioning benutzt.

Wolfi Gassler (00:29:06 - 00:29:10)

Also drei Zahlen in der Versionsnummer heißt noch lange nicht, dass das Semantic Versioning ist.

Andy Grunwald (00:29:10 - 00:30:27)

Wenn wir jetzt aber Semantic Versioning mit Software Repository Mining verbinden, dann könnten wir ja in der Theorie sowas machen wie die automatische Bestimmung der Versionsnummer für deine zukünftige Software Version, für dein zukünftiges Software Release anhand der Changes zum letzten Release. Weil, nehmen wir mal eine ganz normale Programmiersprache, PHP. Und wir machen zum Beispiel eine Library mit einem externen Interface. Und jede Programmiersprache hat ja eine gewisse Syntax und gewisse Sprachfeatures. Und je nachdem, welche Sprachfeatures man nutzt oder nicht nutzt, kann man halt sagen, okay, das ist für das externe Interface ein Breaking Change oder nicht. Nehmen wir mal an, wir haben eine Library, die ein excellentes Interface und ihr fügt einen neuen Parameter an eine Methode hinzu. Und dieser Parameter hat keinen Default-Wert. Dann ist das automatisch ein Breaking-Change, weil jeder, der diese Methode nutzt, muss beim Upgraden einen neuen Parameter hinzufügen. Das bedeutet, man kann nicht einfach die Library upgraden und hat alle Bugfixes drin, sondern man muss seine eigene Code anpassen. Wenn die Sprache aber Default-Werte für neue Parameter supportet, wie zum Beispiel jetzt PHP, und man editt einen Default-Wert, falls dieser Parameter nicht bei den Methodenaufruf übergeben wurde, dann ist das kein Breaking-Change.

Wolfi Gassler (00:30:27 - 00:30:36)

Oder du verwendest JavaScript, da kannst du einfach alles machen, weil es eh komplett egal ist. Aber in Java wäre das natürlich ein Problem, wenn du da einfach ein Parameter hinzufügst.

Andy Grunwald (00:30:36 - 00:31:40)

Natürlich muss man das alles pro Sprache irgendwie implementieren. Zum Beispiel Golang hat jetzt keine Default Values für Parameter. Da muss man natürlich schon gucken, welche Sprache man da nutzt. Aber dadurch kann man natürlich so ein Vorschlagsmechanismus bauen. Mein letztes Tag war auf Comet 4711 und ich bin jetzt auf 5011. Analysier doch mal bitte alle Pull-Requests, die da reingegangen sind und sag mir doch mal, schlag doch mal bitte vor, was wäre die nächste Versionsnummer anhand des Semantic Versioning, anhand der Kontrolle dieser Regeln. Natürlich ist das alles ein bisschen komplizierter, wenigestens ein Edge Case und was ist, wenn ich eine externe API habe und was ist, wenn meine Applikation irgendwelche Dateien schreibt und die Struktur des geschriebenen Inhalts ändert sich von XML nach JSON und so weiter. Alles richtig, diverse Edge Cases kann man halt nur sehr schwer abbilden, aber es geht ja nicht darum, dass man der Technologie 100 Prozent vertrauen soll, sondern, dass man wichtige Dinge nicht übersieht. Und das, eine automatische SemWare-Analyse, habe ich so noch nicht gesehen. Fände ich aber mal ziemlich cool.

Wolfi Gassler (00:31:40 - 00:31:43)

Weißt du, ob es das im wissenschaftlichen Bereich schon gegeben hat irgendwo?

Andy Grunwald (00:31:43 - 00:31:44)

Ich meine, ich habe da mal ein Paper zugelesen.

Wolfi Gassler (00:31:45 - 00:31:53)

Ja, vielleicht haben wir jetzt mit GPT und so weiter in Zukunft Möglichkeiten, dass man da vielleicht ein bisschen Intelligenz auch reinbringt.

Andy Grunwald (00:31:53 - 00:33:20)

Aber das geht halt schon relativ in die strukturierte Datenanalyse, weil du hast ja relativ strukturierte Daten, weil du hast ja einen Abstract Syntax Tree, wenn du deinen Code auseinandernimmst, du hast ja Tokens und so weiter und so fort. Das kannst du schon relativ gut machen. Wenn wir aber mal so ein bisschen in die Textmining-Ecke gehen, dann kannst du natürlich ganz andere Themen machen, wie zum Beispiel eine Hot-Topic-Analyse, und die finde ich sehr interessant. Stell dir mal vor, du hast eine Community, oder eine Community kann auch deine Firma sein, und du hast eine ganze Menge an Text, das bedeutet entweder Mailing-Listen oder Chat-Protokolle, IRC oder Slack oder MetaMouse oder was es da nicht alles gibt. Und jetzt nimmst du dir einfach mal den ganzen Content aus den Public Channels, jagst ihn durch so einen Textprozessor, wo erstmal alle Stoppwörter, alle Artikel und so weiter, also erstmal die ganzen Füllwörter rausgenommen werden, Maps die ganzen Wörter gegen eine technische Wortliste, um einfach mal die relevanten Wörter für dein Produkt oder für deine Firma rauszufiltern und merkst auf einmal, hey, wieso sprechen wir eigentlich super oft in den letzten drei Wochen über Vererbungshierarchien oder über die Logging Library. Es kann halt so ein Indikator sein, dass das ein Thema für Unverständnis ist, sozusagen. Wenn da ziemlich viel Kommunikation um ein Thema ist, dann könnte man drüberlegen, okay, muss ich dazu eine bessere Architektur machen? Muss ich dazu mehr Tutorials machen? Muss ich das leichter gestalten? Muss ich dafür Knowledge Sharing Sessions machen? Oder, oder, oder.

Wolfi Gassler (00:33:20 - 00:34:11)

Ich habe so einen ähnlichen Anwendungsfall mal in dem Wiki gesehen. Ich habe leider vergessen, welches Wiki das war und ob es nur eine wissenschaftliche Umsetzung war. Vielleicht weiß es noch jemand. Und zwar war die Idee, dass man zu Wikieinträgen, wo du ja die normale Dokumentation machst, zu deinen grundlegenden Dingen, deiner Software oder anderen Bereichen, dass man zusätzlich unter dem Wikieintrag passende Mailinglisten-Einträge anzeigt. dass man zum Beispiel den Support-MitarbeiterInnen auch die Möglichkeit gibt, zu sehen, was läuft denn aktuell in den Mailinglisten zu diesem Thema ab. Also, dass man nicht nur die Grunddokumentation hat, sondern diese lebende Dokumentation, die ja inhärent in Mailinglisten, in Diskussionen vorhanden ist, dass man die automatisch unter diesen Wikieintrag reinpackt und man hat dann so auch zusätzliche Informationen abseits von der Standarddokumentation.

Andy Grunwald (00:34:11 - 00:35:07)

Und das ist ein unglaublich schönes Beispiel für einen Anwendungsfall von kombinierten Software-Repositories, von kombinierten Data-Sources. Weil das, was du da gerade ansprichst, ist nämlich die Königsklasse von Software-Repository-Mining. Ich hatte gerade gesagt, das Ziel von Software-Repository-Mining ist, die Erstellung von Software und von Software-Projekten zu vereinfachen. Stell dir mal vor, du bist in deiner IDI und hast rechts so ein Kontext-Window. Und dieses Context-Window zeigt dir anhand der Datei, anhand der Methode, anhand der Klasse, in der du gerade bist, Links zu Wiki-Pages an, Links zu Open Issues im Bug-Tracker, Links zu relevanten Slack-Threads und ähnliches. Wenn du das alles miteinander verknüpft, ähnlich wie du gerade gesagt hast, du hast ein Wiki mit den Mailing-Listen-Einträgen, Das ist ja wohl Königsklasse, wenn du zu der Zeile oder zu dem Bereich, in dem du gerade programmierst, mehr Kontakt kriegst. Was sind die Fallstricke, was sind die aktuellen Probleme oder was ist der aktuelle Produktfokus hier gerade?

Wolfi Gassler (00:35:07 - 00:36:08)

Also es geht eigentlich immer weiter in Richtung GitHub Copilot, dass man automatisch Informationen zur Verfügung gestellt bekommt. Vielleicht, falls es jemand noch nicht weiß, GitHub Copilot versucht mit einem sehr umfangreichen Language Model vorzuschlagen, was man denn als nächstes programmieren soll oder macht eine Autovervollständigung der Kommentare anhand des Codes. Also versteht wirklich den Code und probiert Zusatzinformationen aus dem Netz zu geben. Also vielleicht, dass man in Zukunft gar nicht mehr auf Stack Overflow gehen muss, sondern das eben automatisch bei CoPilot angezeigt bekommt in seiner IDE. Aber was natürlich CoPilot nicht kennt, sind die ganzen internen Datenquellen. Weil ganz oft ist es ja hinter einer Mauer versteckt in der internen Firma. Und das ist aber auch leichter zugänglich, weil man braucht da kein extrem komplexes Machine Learning Model dahinter, sondern vielleicht auch nur eine normale Suche. Und wenn man das schon schafft, intern alle Datenquellen sinnvoll anzuzapfen, dann kann man da natürlich auch dementsprechend die Entwicklung beschleunigen intern.

Andy Grunwald (00:36:08 - 00:37:02)

Ja, der Unterschied zum GitHub Copilot zu der kontextbasierten Anzeige in IDEs ist natürlich der, dass GitHub Copilot meines Erachtens nach eher für den Erstellungsprozess ist. Das bedeutet, du willst etwas Neues schreiben oder neue Funktionalitäten hinzufügen. Und die kontextbasierte Anzeige in existierendem Code ist halt was ganz anderes, wenn du Bugfix machen möchtest, wenn du die in existierende Logik ändern möchtest. Deswegen ist das halt schon nicht wie GitHub-Copilot, sondern da geht's halt wirklich um das Teure, die Maintenance von Software und die Änderung von Software. Weil ich denke, sehr guter Software- und sehr guter Software-Code ist es, wenn Leute mit weniger Kontext, mit weniger historischem Wissen Änderungen sicher durchführen können. Und ich denke, eine kontextbasierte Anzeige von IDEs mit Links zu Wikipages, Issues und Slackthreads, also Sheds, kann da schon sehr helfen.

Wolfi Gassler (00:37:02 - 00:37:21)

Das heißt eigentlich diese Anzeige, die ich zum Beispiel in VS Code habe, vermute es ist ein Plugin, es ist gar nicht direkt VS Code, aber dass ich ein Git Blame bei jeder Zeile angezeigt bekomme zum Beispiel, das wäre dann eigentlich schon Software Repository Mining, wenn ich das richtig sehe. Und es geht schon in diese Kontextrichtung, die du jetzt erklärt hast.

Andy Grunwald (00:37:21 - 00:37:36)

Das ist ein Start, ja. Aber was ich zum Beispiel mal cool finde, wenn du es mal weiterdenkst, stell dir mal vor, du wärst Engineering Manager und stell dir mal vor, dein Ziel ist es, dein Team weiterzuentwickeln und zu einem performanten Team zu kriegen. Das ist hoffentlich einer deiner Ziele.

Wolfi Gassler (00:37:36 - 00:37:43)

Übrigens haben wir da in Episode 44 auch darüber gesprochen, der Weg zum hochperformanten Team, aber mehr auf einer Meta-Ebene.

Andy Grunwald (00:37:43 - 00:38:27)

Ein Indikator für ein gut funktionierendes Team könnte sein, wie viele Iterationen pro Pull-Request gemacht werden müssen. Weil wenn es nämlich konstant Knatsch und Zankerei in Pull-Requests gibt, wie man etwas zu lösen hat und das ist nicht richtig und dies und das und jeder Pull-Request braucht irgendwie 25 Ping-Pongs, dann könnte man sagen, okay, wir müssen mal irgendwie über unsere Arbeitsweise reden. Wenn man jetzt einfach mal sagt, wir messen einfach die Review-Cycles und die Iterationen pro Pull-Request und feststellt, hey, immer wenn eine Person im Team ein Pull-Request macht, gibt es da ganz viel Knatsch und irgendwie sind wir da bei 25 Iterationen, dass man sich diesen Fall mal genauer ansieht und einfach mal Mentoring beginnt und einfach mal ein bisschen tiefer schaut, okay, was ist denn hier los? Haben da zwei Leute im Team vielleicht ein bisschen Knatsch?

Wolfi Gassler (00:38:27 - 00:38:39)

Das könnte man gut verbinden, vielleicht dann auch mit einem Check, ob die Pull-Requests immer nur LCTM looks good to me sind und einfach durchgewunken werden. Das wäre so der andere negative Case.

Andy Grunwald (00:38:39 - 00:39:24)

Also was, das bedeutet aber durch Software Repository Meinung können wir hier auch das Team hochcoachen, ja, oder beziehungsweise man findet Bereiche, wo vielleicht man von technischer Ebene das Team ein bisschen hochcoachen kann, die vielleicht gar nicht so aus dem Engineering Management, aus der Vogelperspektive immer so sichtbar sind. Natürlich kann man da weitergehen. Da gibt es zum Beispiel eine Studie über den Linux-Körnel, wo jemand ein Modell entwickelt hat, um die Frage zu beantworten, würde mein Patch im Linux-Körnel gemerged werden? Und wenn ja, wie schnell? All solche Analysen kann man natürlich machen, um das Team nach vorn zu bringen. Und das finde ich halt tierisch interessant. Da würde ich aber jedoch bitten, nicht nur auf die blanden Zahlen zu gucken, sondern wirklich mal ein bisschen Empathie da reinzubringen und sich die einzelnen Fälle anzusehen, ob das jetzt ein Ausreißer war oder ob das jetzt hier Standard ist.

Wolfi Gassler (00:39:25 - 00:39:33)

Wie stehst du zu dem ganzen Thema, irgendwelche Ranglisten aus diesen Daten zu erstellen oder das auch öffentlich zu machen?

Andy Grunwald (00:39:33 - 00:39:33)

Was meinst du damit genau?

Wolfi Gassler (00:39:34 - 00:39:41)

Ja, dass ich zum Beispiel dann auch öffentlich stelle, bei wem die Pull-Requests schneller gehen, wer am meisten contributed, solche Dinge.

Andy Grunwald (00:39:41 - 00:40:25)

In einer Firma finde ich das schwierig, weil diese Zahlen dann sehr schnell missbraucht werden können. In einem Kontext von einem Open-Source-Projekt könnte es sehr sinnvoll sein, wenn man zum Beispiel sogenannte Leaderboards erstellt, wer contributed. Angenommen, wir packen so ein bisschen Gamification drauf. und sagen, okay, für jeden Girlfriend-Pull-Request, für jeden Code-Review und ähnliches gibt's ein paar Punkte, und da kann man sagen, okay, pro Monat hat diese Person irgendwie so und so viel Punkte gesammelt. Und warum finde ich das in so einem Kontext recht nützlich? Weil man zum Beispiel im Open-Source-Kontext dann mit diesen Leuten ein Gespräch anfangen könnte und vielleicht so neue Core-Contributor finden kann, oder vielleicht sogar neue Mitarbeiter, oder einfach diese Leute mal zu Sprints oder Hackathons von Open-Source-Projekten einladen kann.

Wolfi Gassler (00:40:25 - 00:40:27)

Kennst du irgendwelche Open-Source-Projekte, die das aktiv betreiben?

Andy Grunwald (00:40:28 - 00:40:45)

Ja, TYPO3, das Contact Management System, geschrieben in PHP, betreibt das und auch ganz gut. Und eben, soviel ich weiß, machen die auch die Entdeckung von Experten dadurch. Die schauen sich dann hier und da ein bisschen an, okay, wer ist in welcher Komponente am aktivsten. Da können wir auch mal so ein Leaderboard unten verlinken.

Wolfi Gassler (00:40:46 - 00:40:54)

Ich bin ja immer beeindruckt, dass es Typo 3 immer noch gibt. Aber wenn ich auf dieses Leaderboard schaue, da gibt es schon Companies, die sehr viel contributen.

Andy Grunwald (00:40:55 - 00:41:16)

Man muss vorsichtig sein von Gamification und Leaderboards. Man muss sich immer bewusst sein, dass jedes System und jedes Punktesystem getrickt werden kann, also gesheeted werden kann. Und in geschlossenen Teams, in Organisationen ist das, glaube ich, auch die falsche Metrik, auf die man gucken sollte. Aber in Homesource mit dem Ziel, neue Core-Container zu finden, finde ich das schon ein interessanter Anwendungsfall.

Wolfi Gassler (00:41:16 - 00:41:28)

Nachdem du jetzt schon mit einem negativen Punkt angefangen hast, weil man diese Daten eben missbraucht in gewisser Weise. Gibt es andere Herausforderungen oder Probleme oder negative Punkte von dem ganzen Bereich?

Andy Grunwald (00:41:28 - 00:41:58)

Den negativen Punkt, den ich gerade angesprochen habe, war ja in der Auswertung, in der Interpretation dieser Daten, die man da jetzt herausgewonnen hat. Bei der erstellung dieser ergebnisse gibt es natürlich ein paar herausforderungen auf der einen seite ist die datenqualität nicht so wie ich sage mal klassische software engineers sie erwarten würden auf der einen seite ist es natürlich toll weil ein großteil dieser daten ist halt unbiased ja also source code hat halt kein bias nach links und rechts Comment Messages drehen sich in der Regel auch nur um die Sache.

Wolfi Gassler (00:41:58 - 00:42:21)

Was man natürlich aufpassen muss, ist glaube ich, wenn man die ganzen Sachen zählt, weil ganz viele Metriken basieren natürlich auf diesen harten Zahlen und wenn man halt einfach nur etwas misst, wie viel Comment Messages oder wie lange etwas gebraucht hat, dann kann es natürlich immer in die falsche Richtung gehen. Also auch da ist glaube ich auf der moralischen, ethischen Seite schon auch immer darauf Acht zu geben, meiner Meinung nach.

Andy Grunwald (00:42:21 - 00:43:18)

Alles richtig, da sind wir aber wieder bei der Auswertung der Daten, wie man diese betrachtet. Ich rede eher von der Datenqualität, die wir gerade analysieren. Und da dreht sich es halt in der Regel um Unbiased Daten. Das ist positiv, meines Erachtens nach, aber die Herausforderung ist hier, dass die meisten Daten wirklich noisy sind, unstrukturiert und gegebenenfalls sogar unvollständig. Besonders wenn wir von unstrukturierten Daten wie Mailinglisten, Bug-Tickets, Chat-Einträgen oder Comet-History sprechen von einem Projekt, was sehr, sehr lange existiert. Was vielleicht sogar schon mal Migrationen gemacht hat. Das bedeutet, wo früher Comet-Messages auch Subversion sind und die dann in Git überführt wurden und dann später vielleicht man auf Conventional-Comets umgestiegen ist und so weiter. Also wenn man wirklich eine verschiedene und historische Struktur hat, schwierig, da muss man halt sehr viel Arbeit ins Data Cleaning stecken oder halt die Skripte sehr sophisticated schreiben, dass man auch mit unseren unsäuberen Daten arbeiten kann.

Wolfi Gassler (00:43:18 - 00:43:53)

Und ich glaube, es ist halt wichtig, einfach zu wissen, dass man mit unsauberen Daten arbeitet und dann halt dementsprechend auch mit den Daten so umgeht. Aber das ist halt auch so ein klassisches Problem. Umso weiter das nach oben wandert in der Hierarchie, zum Beispiel in der Management-Hierarchie, umso weniger ist dann klar, woher kommen die Daten eigentlich. Und plötzlich wird das irgendwie als Fakt angesehen, obwohl das irgendwelche noisy Daten als Grundlage hat. Und da muss man, glaube ich, aufpassen, einfach was man mit den Daten macht und dass man das halt auch richtig kommuniziert. Aber ich glaube, es wäre schade, wenn man sagt, okay, ich habe noisy Daten, daher verwende ich sie gar nicht. Man muss halt einfach wissen, dass sie noisy sind und dementsprechend auch damit umgehen.

Andy Grunwald (00:43:53 - 00:43:57)

Ich finde halt, die geben in der Regel einen guten Kontext und sind gute Indikatoren.

Wolfi Gassler (00:43:57 - 00:44:12)

Das ist so ähnlich wie mit dem GitHub Copilot oder GPT oder auch Stack Overflow. Man muss halt wissen, was dort steht. Man darf nicht allen blind vertrauen. Man muss halt schon noch selber den Überblick haben und das Wissen haben, dass man das dementsprechend verifizieren kann.

Andy Grunwald (00:44:12 - 00:44:54)

Eine andere Herausforderung ist der Data Storage zur Analyse. Es ist zum Beispiel, also es macht in der Regel Sinn, deine unstrukturierten Daten aus dem Kompositor rauszuziehen und in irgendeine Datenbank zu packen, um dann da weitere Queries draufzuführen. Was jetzt abhängig von deiner Analyse gegebenenfalls keinen Sinn macht, ist alles immer in relationale Datenbanken oder alles immer nur in Graf-Datenbanken zu packen. Klassische Sum-Funktionen und Gruppierungsfunktionen und Co. sind natürlich in relationalen Datenbanken sehr gut aufgehoben. Analyse von sozialen Netzwerken sind zum Beispiel dann eher ein besserer Anwendungsfall für Graf-Datenbanken. Und wenn man jetzt hier gegebenenfalls sogar mit derselben Datenquelle mehrere Analysen fahren möchte, dann muss man natürlich schon zwischen mehreren Datenbanken hin und her schaffen, was natürlich schon eine Herausforderung sein kann.

Wolfi Gassler (00:44:54 - 00:45:08)

Oder man löst es halt einfach mit einem klassischen Data Warehouse oder irgendeiner Analyse-Datenbank, wo man die Sachen rein importiert aus den verschiedenen Datenquellen durch einen ETL-Job, wie es halt heutzutage so üblich ist. Und dann kann man darauf dementsprechend die Analysen fahren.

Andy Grunwald (00:45:09 - 00:46:12)

Wo natürlich das Wort einfaches hier ganz stark in Anführungszeichen ist. Weil das ist nicht umsonst ein eigener Job, deswegen ist es in der Regel ja nicht so einfach. Meines Erachtens nach die größte Herausforderung bei der Analyse von diesen Data Sources, von diesen Software Repositories, ist jedoch das Cross-Linking. Das bedeutet, wie verbinde ich eigentlich ein Git-Comet mit einem Bug-Ticket, mit einem Shed-Eintrag? Weil nur durch die Verbindung kriegst du halt auch den wirklichen Mehrwert, wie diese verschiedenen Data Sources zusammenhängen. Natürlich kann man jetzt sagen, ja, aber jeder meiner Git-Commits hat ja immer eine Ticket-ID. Kurze Frage, ist das wirklich so? Und da muss man sich halt schon wirklich ein bisschen Gedanken machen, wie man diese Data-Sources miteinander verbindet. Eine Ticket-ID in Git-Commit ist natürlich eine gute Nummer, weil dann weiß man, okay, da ist dieses Ticket in Jira. Eine Verbindung zu Wikis und Chats, sowas wie Slack, ist natürlich dann schon ein bisschen schwieriger. Sowas kann man zum Beispiel mit Links über Pull-Requests lösen, wenn dann viele Links geshared werden und dann auf die Dateien, auf die Commits gehen. Also da muss man sich natürlich schon auch einen Graph aufbauen und je nachdem, welche Datasource man da hat.

Wolfi Gassler (00:46:12 - 00:46:33)

Und heutzutage ist es auch, glaube ich, relativ schwierig, an Daten teilweise überhaupt dran zu kommen. Gerade wenn man jetzt an Slackchats oder so denkt, ist es ja nicht mehr so einfach, dass man überhaupt Zugriff auf die Daten hat. Wenn das irgendwelche SaaS-Tools sind, die irgendwo in der Cloud liegen, dann hat man da meistens gar keinen einfachen Zugriff. Und das macht es natürlich dann umso schwieriger, noch gewisse Sachen zu verlinken.

Andy Grunwald (00:46:33 - 00:46:55)

Generell würde ich halt auch die möglichen Gefahren als eine Herausforderung sehen, aber das ist jetzt nicht spezifisch zu Software Repository Mining, sondern das ist eher so spezifisch generell auf Metriken. Nicht einfach irgendwelchen blinden Zahlen vertrauen, sondern immer fragen, okay, woher kommen diese Daten, was machen diese Daten und wie relevant sind diese Daten überhaupt und welche Entscheidungen und Aktionen zieht man denn aus diesen Daten, ja?

Wolfi Gassler (00:46:55 - 00:47:27)

Ich glaube, das ist ein ganz klassisches Problem mit Daten und Zahlen, weil man irgendwie gefühlsmäßig sofort Zahlen vertrauen will, aber man hat keine Ahnung, woher die kommen. Und dann kommt irgendein Manager und sieht auf einer Ampel, dass das von grün auf gelb geswitcht hat aus irgendeiner Metrik. Und man hat keine Ahnung, woher die Metrik kommt, aber scheinbar ist es kritisch und es muss jetzt behandelt werden. Also da ist wirklich, glaube ich, auch viel Kommunikation und auch Education nötig, dass man den Leuten wirklich klar kommuniziert, woher kommen die Daten. Das ist ganz, ganz wichtig, meiner Meinung nach.

Andy Grunwald (00:47:27 - 00:47:34)

Du sagst jetzt gerade immer die bösen Manager, aber so ist das ja nicht, weil auch, Jeder Mensch kann falsche Entscheidungen aufbauen.

Wolfi Gassler (00:47:34 - 00:47:36)

Ja, ja, Manager sind auch Menschen, das stimmt schon.

Andy Grunwald (00:47:36 - 00:48:19)

Aber auch ganz klassische Softwareentwickler können sagen, das steht da, die Endpasskomplexität ist aber jetzt hier viel zu hoch und so weiter. Ja, vielleicht gibt es da auch einen Grund für einen Co, ja, und ein bisschen Kontext dahinter zu setzen, das ist jetzt nicht nur eine Manager-Sache, sondern das ist generell die Gefahr, wie interpretiere ich die ganze Thematik. Man muss ja auch sagen, sich einfach auf eine Zahl, die auf einem Screen steht, zu verlassen, ist auch sehr einfach, ja? Und es ist anstrengend, darüber nachzudenken, wie stark man dieser Zahl vertraut. Von daher, das ist halt einer der größten Gefahren. Und ich denke auch, dass dies zur Akzeptanz beiträgt. Aber da haben wir ja schon gesprochen, umso eher diese ganzen Prozessverbesserungen aus dem Team herausgefordert werden, desto größer könnte die Akzeptanz dafür sein.

Wolfi Gassler (00:48:19 - 00:48:42)

Okay, wenn jetzt Leute in irgendeiner Form mit Software Repository Mining oder Mining Software Repositories beginnen wollen, hast du irgendeinen Startpunkt, wo man mal reinschauen kann, starten kann, irgendwie vielleicht auch Software findet? Also alles, was vor allem abseits von diesem klassischen Static Code Analysis und so weiter ist, weil dazu gibt es ja genug Listen und Möglichkeiten, was im Netz zu finden.

Andy Grunwald (00:48:42 - 00:48:47)

Meines Erachtens nach solltet ihr mal erst selbst starten, ohne jetzt irgendwie eine große Software darauf zu schmeißen.

Wolfi Gassler (00:48:47 - 00:48:56)

Gute Möglichkeit, um ein Side-Project zu starten. Also wer ein Side-Project sucht oder vielleicht auch ein Produkt, eigentlich die ideale Produktkategorie.

Andy Grunwald (00:48:56 - 00:50:03)

Versucht einfach nur mal euer Git-Log mal zu parsen und dann einfach mal eine Datenbank reinzuhauen und dann einfach nur mal schauen, okay, was kriegt ihr denn da raus, dann spielt ein bisschen rum. bevor ihr dann irgendwie ein Tool da drauf schmeißt, weil diese Tools können sehr komplex sein, besonders in einem Branching-Modell und wie Git. Und dann beschäftigt ihr euch eigentlich nur, das Tool zu verstehen, anstatt die ersten Analysen rauszukriegen. Deswegen würde ich vorschlagen, Fangt einfach an, ein paar JavaScript- und Python-Skripte zu schreiben und einfach mal ein bisschen drüber zu iterieren. Natürlich gibt es auf GitHub eine ganze Menge Tools in diesem Bereich. Sehr viel von Researchern. Metrix Grimoire ist zum Beispiel so eine Toolchain, die analysieren auch Daten von meetup.com und von Mailinglisten und können das importieren in eine relationale Datenbank wie Postgre und MySQL. Oder es gibt so ein Projekt, das nennt sich Chaos. Das ist bis kurz für Community Health Analytics in Open Source Software. Die machen auch sowas. Deren Ziel ist es halt, Metriken und Metrikmodelle rund um Open Source Communities zu erstellen. Die Firma Bitergia macht da eine ganze Menge und hat auch super viel Open Source Projekte, um Dashboards für Kibana herzustellen und so weiter und so fort.

Wolfi Gassler (00:50:03 - 00:50:19)

Und wer das Startup von morgen entwickeln will, schaut mal bei der MSR-Konferenz rein, verlinken wir natürlich auch in den Shownotes. Da gibt es dann wirklich den neuen heißen Scheiß. Und wenn man daraus ein Produkt baut, ich glaube, da hat man dann durchaus große Companies, die da Interesse daran haben als Kunden.

Andy Grunwald (00:50:19 - 00:50:21)

Kommen wir zurück zum Anfang des Podcasts.

Wolfi Gassler (00:50:22 - 00:50:27)

Genau, ich wollte dir noch die Frage stellen, was war eigentlich deine Bachelorarbeit? Aber Andi, nur im Twitter-Format, 160 Zeichen.

Andy Grunwald (00:50:28 - 00:50:34)

Der Titel hieß Software Repository Mining Konzept und Potenziale und eigentlich habe ich mehr oder weniger.

Wolfi Gassler (00:50:34 - 00:50:43)

Ihr seht es leider nicht, aber Andi hat es jetzt gerade irgendwo links aus dem Schreibtisch rausgezogen. Hast du die immer herumliegen oder hast du die jetzt als Vorbereitung für diese Episode rausgesucht?

Andy Grunwald (00:50:43 - 00:51:01)

Ich habe die zur Vorwartung dieser Episode rausgesucht. Und man kann eigentlich sagen, meine Bachelorarbeit ist das Podcast-Transkript ein bisschen ausgeholt. Natürlich mit viel mehr akademischen Links und dies und das und warum das sinnvoll ist und Studien und blablabla. Eigentlich habt ihr gerade meine Bachelorarbeit in Kursform gekriegt.

Wolfi Gassler (00:51:01 - 00:51:04)

Du weißt jetzt, dass jetzt alle nach deiner Bachelorarbeit suchen und die lesen wollen.

Andy Grunwald (00:51:04 - 00:51:05)

Ich glaube gar nicht, dass die öffentlich ist.

Wolfi Gassler (00:51:06 - 00:51:09)

Ja, vielleicht können wir ja da was drehen und die veröffentlichen.

Andy Grunwald (00:51:10 - 00:52:15)

Wir schauen mal was wir da machen können aber ja vielleicht ist das mal wieder ein grund meinen blog anzuschmeißen kommen wir wieder zurück zum anfang des podcasts warum denke ich, dass dies ein nischen thema ist was bald kommt ich denke die welt wird immer komplexer ich denke irgendwann haben wir alle verstanden wie wir kommunikation teams und firmen strukturieren und dann suchen wir nach weiteren potentialen, mehr Performance aus unseren Teams, aus den Communities, aus Sourcecode rauszuholen. Und ich denke, dass die Metriken rund um Software Repository Mining enorm helfen, um zum Beispiel soziale Netzwerke zu analysieren, um die richtigen Leute an die richtigen Projekte zu setzen, um problematische Softwareareale zu finden und frühzeitig zu mitigieren. Sehr, sehr viele Startups gehen so ein bisschen in die Richtung, aber ich denke, dass zum Beispiel sehr viele große Open-Source-Projekte auch von so Hot-Topic-Analysen Vorteile rausziehen können, um die nächste Product-Roadmap zu designen. Wozu sie denn jetzt zum Beispiel mehr Content veröffentlichen, mehr Dokumentation schreiben und so weiter, um einfach die Software noch erfolgreicher zu machen.

Wolfi Gassler (00:52:16 - 00:53:14)

Also ich glaube, dass das auch immer wichtiger wird, weil auch in Firmen immer mehr Content und Inhalt produziert wird an ganz unterschiedlichsten Stellen. Es hat ja mal früher diese Google Appliance gegeben, ganz zu Beginn, wo man sich so einen Google Rechner in sein eigenes Datacenter stellen hat können und dann hat die interne Google Suchmaschine alle Informationen in der Firma durchsucht. Ist mittlerweile eingestellt worden, aber ich glaube, dass das sicher wieder kommt. Es gibt ja ein paar Ansätze in die Richtung auch Software, aber dass man das dann automatisch verknüpft, Ich glaube, das wäre das Next Level und das wird in Zukunft auch gebraucht, nicht nur bei der Entwicklung, weil es scheitert ja jetzt schon daran, dass irgendwo in größeren Firmen die eine Seite nicht weiß, was die andere macht, weil sie einfach keinen Zugriff auf die IT-Tickets zum Beispiel hat, aber da vielleicht relevante Informationen drinstehen würden. Also ich glaube, das Verknüpfen der Daten aus verschiedenen Datenquellen und dann das auch zur Verfügung stellen und das durchsuchbar machen, das ist sicher ein Hot Topic und kann glaube ich in Firmenprozesse wirklich beschleunigen und das sind nicht nur die Entwicklungsprozesse.

Andy Grunwald (00:53:14 - 00:53:31)

Die große Herausforderung wird natürlich sein, daraus Produkte zu bauen und erstmal Awareness für die Themen zu schaffen, weil ich glaube, dass ziemlich viele Entscheider nicht wissen, wovon wir beide hier gerade drüber sprechen. Und das ganze Thema massentauglich zu machen, ist, glaube ich, eine schwierige Herausforderung.

Wolfi Gassler (00:53:31 - 00:53:33)

Aber dafür sind wir ja da.

Andy Grunwald (00:53:33 - 00:53:40)

So sieht es aus. Wolfgang, bist du hyped? Hast du Bock, ein bisschen Data-Analysis, Data-Science auf Software-Repositories zu machen?

Wolfi Gassler (00:53:41 - 00:53:55)

Ja, ich würde am liebsten jetzt diese Startup gründen, was die ganzen Datenquellen anbindet und die super-duper-language-model-based-search-engine-kombinierungs-eierlegende-Wollmilchsau als Produkt macht. Würdest du kaufen, oder?

Andy Grunwald (00:53:57 - 00:54:13)

Ich bin dein erster Kunde. Ich hoffe, wir konnten euch so ein bisschen mein Passion-Thema der letzten zehn Jahre näher bringen. Wie ich auf dieses Thema gestoßen bin, könnt ihr auch in meinem Blog lesen. Es war nämlich eigentlich eine ganz lustige Story auf der FOSDEM, einer großen Open-Source-Konferenz.

Wolfi Gassler (00:54:13 - 00:54:23)

In Belgien, bei der wir uns hoffentlich dann alle sehen übrigens. Der Plan ist ja im Februar auf der FOSDEM zu sein und da hoffen wir auch, viele von euch zu treffen, im Idealfall.

Andy Grunwald (00:54:24 - 00:54:42)

Lasst eure Gedanken mal ein bisschen schweifen, welche Fragestellungen ihr an eure Metadaten aus dem Softwareentwicklungsprozess habt und welche Optimierungspotenziale euch noch so einfallen. Lasst es uns wissen, tweetet uns die gerne an at engkiosk oder wieder E-Mail an stetisch at engineeringkiosk.dev.

Wolfi Gassler (00:54:42 - 00:54:47)

Und tragt euch schon mal im Kalender ein, 4. und 5. Februar, FOSDEM in Belgien.

Andy Grunwald (00:54:47 - 00:54:50)

Bis dahin wünschen wir euch einen schönen.

Wolfi Gassler (00:54:50 - 00:54:51)

Tag, bis bald, tschüss. Ciao.