Ich habe ein paar Gedanken zu Musks “neuem” Entwicklerteam. Es sagt, er hat mehr als 5x so viele Features wie das Alte Entwickler Team mit 5x weniger Leute umgesetzt. Als Person die eine ganze Menge Erfahrung in Entwickler Teams und mit dem Management dieser hat kann ich mir ganz genau vorstellen wie diese Entwickler Teams aussehen.

Normalerweise existiert in jedem Softwareteam mindestens 0,5 Stellen pro Entwickler, die dafür sorgen, dass die Entwickler reibungslos entwickeln können. Fast am wichtigsten sind z.B. die sogenannten Anforderungsspezifikatoren (Applikation-Manager), die jedes neues Feature “auf dem Papier” entwickeln. sie geben vor wie ein neues Feature auszusehen hat und wie es zu funktionieren hat. Klassischerweise sind diese Leute die einzigen im Team der mit dem PO (product-owner), dem Chef des jeweiligen Projektes/Softwareteil reden. Zusätzlich gibt es noch viele andere stellen wie den Softwarearchitekten und die Tester, Deployer, Git-Manager und so weiter. Ein gut funktionierendes Entwickler Team ist vor allem Arbeitsteilung. Lass die Person die am besten DB-Abfragen schreiben kann keine Zeit mit Oberflächen, Dokumentation oder Testung verschwenden, sondern lass das andere Leute machen. Deshalb hört man auch von Firmen wie Google, dass sie 10.000 Leute in der Entwicklung angestellt haben. Davon sind aber vermutlich nicht mal 50% Entwickler.

Da man über Musks “Führungsstil” durch Tesla und SpaceX eine menge weiß, kann man mit ziemlicher Gewissheit sagen, dass für Musk nur Entwickler was in der Entwicklung zu suchen haben. Er hat quasi alle Leute die nicht aktiv coden direkt in der ersten Welle rausgeschmissen, was auch die damalige Head of Development gegenüber ,ich meine, CNN bestätigt hat. Musks Stil ist es die Tür aufzureißen einen “Elevator pitch” einer Software reinzuschreien und dann zu warten bis das Feature fertig ist. Sowas ist für eine gute Entwicklung tödlich. Oftmals gehen nicht mal 50% der Gesamtzeit eines Features in die Entwicklung, sondern in die Planung, die Definition, den Tests und dem ausrollen. Dadurch dass der Entwickler nur die Infos “Der Nutzer soll seine Impressionen sehen” bekommt, baut er es nach bestem Wissen und Gewissen so ein wie er es aus der Entwicklerbrille am besten findet, ein. So kommt es z.b. dass dieses Feature sehr gut ist und auch sehr gut aussieht, aber Katastrophal platziert ist. Eben weil es nicht von jemandem kommt, der ein möglichst gutes Feature aus der Bedienersicht plant, sondern aus der Entwickler-Innensicht. Solche “Schienenlegen während der Zug fährt” Prozesse sorgen nur dafür, dass das Feature länger dauert und mehr entwicklerzeigt verschlingt, weil Musk das Feature z.B. Blau haben will, aber nie gesagt hat dass es blau sein soll, es wird also zeit verschwendet das Perfekte rot zu finden nur um es dann wieder umzufärben.

Dazu passt es sehr gut, dass sie sich nicht trauen ihren Code zu veröffentlichen, weil er nicht gut aussieht. Das Stichwort hier ist Technical Debt. Jede Anpassung oder Erstellung eines Codes muss wie z.B. auch beim Hausbau genau gemacht werden, da man ihn sonst schlechter warten kann oder mehr zeit für die Fehlerbehebung braucht als zum Einbau. Wenn man den Keller beim bau nicht gründlich abdichtet wird er irgendwann volllaufen. Vielleicht nicht heute, vielleicht nicht morgen, aber in ein paar Jahren wird es passieren. Und dann braucht das Beheben des Probleme deutlich mehr Ressourcen als es ein ordentlicher Bau getan hätte. Dieser “Fusch am Bau” wird als Technische Schuld (Technical Debt) bezeichnet und ist ein Grund mehr, weshalb moderne Entwicklerteams länger für ein Feature brauchen und auch aus mehr Leuten bestehen. Meistens entsteht Technische Schuld durch “quick and dirty” Lösungen. Statt dass man z.B. seine Architektur aufbohrt und neue Klassen ordentlich einbaut, was tage dauern kann und etliche andere Baustellen aufmacht, werden die einfach dran geklatscht und sorgen so irgendwann für ein Fehler. Ähnlich wie wenn man eine Etage auf ein bestehendes Haus baut, aber das Treppenhaus und die Wasserleitungen nicht erweitert, sondern einfach Außen am Haus langlaufen lässt. “Klappt doch alles”. So wird es auch bei X gewesen sein. Musk will neue Features JETZT. Und das entfernen der Technischen Schuld bring einen eben nicht vorran. Es wird immer und immer mehr auf den alten code draufgeschaufelt und das von Leuten die den Code erst seit Wochen oder Monaten kennen. Klar wird er da zu Frankensteins Monster. Wenn sich dass dann jemand mit Expertise ansieht sieht man direkt wie instabil und wackelig das alles doch ist.

Das ist leider Typisch mid 50ger Entwickler. Sie haben das Spaghetti-Coding (Nach Markus Bühl: Muss nicht schmecken, muss wirken) verinnerlicht und bekommen das nicht mehr raus. Für sie sind die ganzen Modernen Konstrukte wie Clean Code, Code Mentoring, CI oder TDD die dafür sorgen sollen das der Code auch von einer fremden Person zu verstehen ist, nur Zeitverschwendung “es hat ja auch immer ohne funktioniert”.

Zwei Gedanken:

1. Der Code war ihnen auch schon vor einem halben Jahr peinlich. Als großartig angekündigt wurde, ihn vollständig zu veröffentlichen, was ja dann nicht passiert ist, wie wir alle wissen. Und da hammse jetzt immer noch nicht geschafft, den zu bereinigen? Woran das wohl liegen könnte.
2. Reichweite beschränken hilft ja auch überhaupt nicht, weil Leute, die antisemitischen/rassistischen etc Dreck lesen wollen, einfach direkt auf die Profile gehen können, wenn die nicht gesperrt werden. Und übrigens dann auch Plattform-übergreifend die Inhalte teilen können und sei es in irgendwelchen dunklen Telegramkanälen. Es geht doch bei Moderation nicht nur drum, die Augen ganz fest zuzukneifen (und die Augen aller anderen), sondern schädliches Gedankengut als solches zu brandmarken und zu löschen. Meine Fresse, ist das alles grrrrrrr.