Dieses Zitat wird Saijad Khan, Ex-Softwarechef bei Mercedes-Benz und jetzt CTO bei Porsche zugeschrieben (irgendwo in dem langen Interview: https://www.youtube.com/watch?v=3iFCXlepUZc ) .
Wenn man die Leistung eines Softwareentwicklers in abgelieferten Code-Zeilen misst, würde das bedeuten, das der Top-Entwickler hauptsächlich von geklauten (nicht selbst geschriebenen) Code lebt, weil kein Entwickler 30-Mal schneller tippt als der Durschnitts-Profi.
Oder ist es der wegfallende Kommunikations-Wasserkopf, der einen einzelnen Programmierer effizienter macht als eine Gruppe aus dreißig? Die optimale Gruppengröße soll ja bei 5-7 liegen: https://www.qsm.com/team-size-can-be-key-successful-software-project
Der einzelne Top-Entwickler liefert, während die Hammelherde noch im Meeting steckt und debatiert, wie sie sich am Besten organisiert und die Arbeitspakete verteilt.
Oder hat der Top-Entwickler in seiner Zeit vor dem Top-Status all die Fehler bereits durch intensives Coding selbst durchgemacht und vermeidet diese, während die Durchschnichtstippser noch am Sammeln von Erfahrung sind, wie es eben nicht geht ?!
Oder hat der Top-Entwickler in seiner Zeit vor dem Top-Status all die
Fehler bereits durch intensives Coding selbst durchgemacht und vermeidet
diese
Ja, auch. Er kennt und nutzt die Werkzeuge besser, macht weniger Fehler und weiß wie man schneller und gründlicher Fehler findet. Hauptsächlich hat er aber wohl gelernt wie man Programme bauen muss damit man sie gut warten kann, wie man Komplexität gering hält, wie man die Testbarkeit maximiert, ...
Der einzelne Top-Entwickler liefert, während die Hammelherde noch im
Meeting steckt und debatiert,
dann wäre er kein Team-Mitglied
Ein guter Entwickler vermeidet Fehler, indem er seine Erfahrung einsetzt. Er stellt die wichtigen Fragen, um sie zu klären, bevor man in eine Sackgasse läuft. Er ist schnell, weil er seine Code-Struktur nicht mehrmals verwerfen muss. Andererseits hat er aber auch keine Hemmungen, nützliche Restrukturierungen vorzunehmen, weil er die dazu nötigen Tests schon lange vorher automatisiert hat.
Wenn dich das Thema wirklich interessiert kauf dir ein entsprechendes Buch. Einige erfahrene Programmierer haben ihre Ratschläge für den Nachwuchs aufgeschrieben.
kein Entwickler 30-Mal schneller tippt als der Durschnitts-Profi.
Einen Zusammenhang zwischen Anschlägen pro Minute und Programmier-Produktivität war mir bisher neu. Interessant.
"Üblicherweise rechnet man mit einer Produktivität – inklusive aller Projekttätigkeiten – von 10 bis 50 Codezeilen je Mitarbeiter und Tag." (Wikipedia zu LOC).
So gesehen geht es. 30*30=900 Zeilen pro Tag sind zu schaffen. Wenn man den Projekt-Wasserkopf eindampft. :)
Die Aussage war nicht gegendert. Vergeßt diese daher. Diese steht im Widerspruch zum aktuellen Mainstream. Der Link und dieser Satz zitiert wäre ein typisches Thema das genausogut von Falk hätte kommen können.
Wenn man die Leistung eines Softwareentwicklers in abgelieferten
Code-Zeilen misst
Viele Code-Zeilen zu schreiben ist nicht das was Zeit kostet.
Wenn jemand solch eine Produktivitäts Metrik aufstellt, dann jage ihm zum Teufel. Solche Metriken haben einen negativen Einfluss auf die Code Qualität!
Im Gegenteil, weniger Code Teilen sind besser zu verstehen, zu testen und zu pflegen.
Es gilt die einfachste passende Lösung zu finden (KISS) unter Verwendung existierenden Codes.
Wir haben bei uns eine sehr zentrale Komponente die ca. 100 Zeilen Code hat. Der Code wurde nach 2 Jahren um ca. 30 Zeilen erweitert.
Das Design ist sehr einfach und dennoch robust. Ein Anfänger hätte das sehr viel komplizierter und größer gemacht.
von geklauten (nicht selbst geschriebenen) Code
Das nennt sich Recycling oder Wiederverwendung und sollte durch Referenzierung (verwenden von libraries) und möglichst nicht durch Kopieren geschehen.
Er kennt und nutzt die Werkzeuge besser, macht weniger Fehler
und weiß wie man schneller und gründlicher Fehler findet. Hauptsächlich
hat er aber wohl gelernt wie man Programme bauen muss damit man sie gut
warten kann, wie man Komplexität gering hält, wie man die Testbarkeit
maximiert, ...
Also Tool-kenntniss und das Einmaleins des Software-Engineering wird doch auch bei einem Durchschnittsprogrammier (abgeschlossene programmierausbildung/-studium, ~4 Jahre Berufserfahrung) vorausgesetzt. Das sind jetzt IMHO keine Kennzeichen eines Top-Programmierers.
Ist doch schon lange so, in vielen Berufen müssen die alten guten Mitarbeiter durch mindestens 3 neue ersetzt werden.
Irgendjemand hat einen Job 30 Jahre gemacht, der hat die Abteilung alleine gerockt. Es wurde niemand mehr gefunden der die Bereitschaft und das KnowHow hatte um das alleine zu machen.
Am Ende sind's 5 in der neuen Abteilung die Däumchen drehen, Zeit haben stundenlang Meetings abzuhalten und sich an der Freizeit erfreuen.
Nun, wenn jemand das Einmaleins kann und Tools bedienen kann muss der noch lange nicht gut oder sehr gut sein.
Tool Kenntnisse sind nie vollständig. Auch nicht bei Top Leuten. Dafür gibt es zu viele Tools und jedes kann sehr komplex sein. Gute Leute kennen da aber mehr als das Mittelmaß.
Das fängt schon bei der Zielarchitektur an. Die kann sehr komplex sein. Dann der Kompiler den man natürlich kennen sollte aber auch den gut zu kennen kann sehr schwer sein. Dann die Sprache. Auch da gibt es hohe Komplexität. Dann die IDE mit Projektverwaltung, Debugger, Testautomatisierung, ...
Das ist einfach alles irre viel und es ist auch OK nicht alles zu wissen.
Vermutlich zeichnet es einen guten Entwickler aus, dass der schnell Lösungen finden kann. Er also gut im Suchen ist. Ja, richtig, in Datenblättern schnell die wichtigen Informationen finden oder auch schlicht schnell zu googeln und dann eine Lösung zu haben sind wichtige Fähigkeiten. Es ist nicht nötig Alles zu wissen.
Und dann gehören da persönliche Eigenschaften dazu. Sowas wie Gründlichkeit. Dass man sich eben nicht damit zufrieden gibt, dass etwas funktioniert, sondern dass man versucht das wirklich fehlerfreien, modularen und wartbaren Code zu schreiben. Eben damit man kein kompexes Monsterprojekt baut das dann irgendwann zusammenkracht und dann schlecht debuggbar ist. Module sollten klein sein, nach dem KISS Prinzip möglichst nur eine Sache machen und einzeln testbar sein. Dafür brauchen die klare Schnittstellen.
Und um sowas zu bauen braucht man eben Erfahrung und Weitsicht.
Wichtig finde ich auch:
Nimm eine einfache Lösung mit Code der leicht zu verstehen und zu testen ist.
Wenn du also die Wahl hast zwischen einer einfachen Lösung und einer vielleicht im Code kürzeren und eleganteren und akademisch wertvolleren Lösung mit Rekursion und so, dann nimm die einfachere Lösung.
Die kann auch in 5 Jahren dein Nachfolger verstehen der dein Projekt geerbt hat. Oder auch wenn du da in 5 Jahren nochmal ran musst. Außerdem ist bei der eleganteren Lösung die Wahrscheinlich größer, dass du da einen Fehler drinnen hast.
Dein Code ist für den Kompiler. Der gibt dir keinen Orden für akademisch hochtrabenden Code.
"Ein guter Softwerker ersetzt 30 Durschnittliche"
Dieses Zitat wird Saijad Khan, Ex-Softwarechef bei Mercedes-Benz und
jetzt CTO bei Porsche zugeschrieben
Auf diese geistige Meisterleistung sind schon unzählige andere Leute schon vor 50 Jahren gekommen.
Willst du hier Schleichwerbung für diesen miesen Podcast machen?
Und bald steht dort eine halbe Stunde Aufwand, was erreicht werden soll, einer KI erklärt, die dann in 10min den geänderten Code oder die geänderten Skripte auswirft.
Und bald steht dort eine halbe Stunde Aufwand, was erreicht werden soll,
einer KI erklärt, die dann in 10min den geänderten Code oder die
geänderten Skripte auswirft.
Ich geh aber davon aus, das gerade Top-Entwickler gut in der Selbstreflexion und damit im - Schlüße aus der eigenen Erfahrung ziehen - sind, während Durchschnittsprogrammierer eher dazu neigen, immer nach "Schema F zu verfahren". Ein Frage des (fehlenden) "Mut zum Risiko" ?
Huch, wann hat sich die Zahl denn verdreifacht? Denn die klassische Scheißhausparole seit den 60ern, 70ern lautet 10:1 nicht 30:1.
Wobei sich in den meisten seriösen Studien herausstellte dass das Verhältnis gar nicht an den Programmierern selber liegt, sondern an der Umgebung in der sie programmieren müssen. Setz die Leute in ein muffiges, lautes Großraumbüro mit einem Haufen Bürokratie und keinen Supportorganisationen und du hast 1/10 Leistung.
Das ist der Grund, warum man selten ein Verhältnis von 10:1 innerhalb einer Organisation findet. Organisationen stellen immer wieder ähnliche Personen ein und behandeln sie ähnlich.
Daher wird der Herr Manager mit seiner modifizierten 30:1 Scheißhausparole eine Überraschung erleben, wenn er versucht nur "Top Talent" anzuwerben. Im Alltagsgeschäft werden die ganz schnell auf den Standard in der Firma eingenordet.
Obwohl, der Sajjad ist ja ein smarter Typ. Der weiß das sicher und blökt 30:1 nur raus um Aufmerksamkeit zu generieren und als Macher, erfahrener Software-Manager und tiefsinniger Denker zu erscheinen.
Und bald steht dort eine halbe Stunde Aufwand, was erreicht werden soll,
einer KI erklärt, die dann in 10min den geänderten Code oder die
geänderten Skripte auswirft.
Probier doch mal das Phonecode-Beispiel. Aber ehrlich bleiben!
Das nennt sich Recycling oder Wiederverwendung und sollte durch
Referenzierung (verwenden von libraries) und möglichst nicht durch
Kopieren geschehen.
Interessanter Aspekt, fällt diese von den Durchnittsprogrammieren verwendete Bibliothek vom Himmel ?
Oder braucht es letzlich nicht einen Top-programmierer der diese library anpasst (oder auch erstellt) und pflegt, damit diese von 30 Durchschnittsprogrammieren ohne größeren Aufwand genutzt werden kann?
Also ein Top-Programmiere wird dann (einige) andere Programmierer ersetzten, sobald er (zentralen) Code (zum Re-Use) bereitstellt, der von anderen Team-Mitgliedern zeitsparend eingesetzt werden kann.
Eben durch geschickte Konzentration zentraler Code-Bestandteile bei einem Top-Entwickler und darauf aufbauende Nutzung dieser durch möglichst viele Team-Mitglieder können partielle Einspar-Effekte erreicht werden.
Um mal bei dem Zahlenbeispiel zu bleiben, aus einer Firmenabteilung von 60 Durchschnittern könnte man durch Aufnahme eines Top-Entwickler in die "Core-Gruppe" ein kleineres aber effizienteres Team von 31 Mitgliedern formen.
Um mal bei dem Zahlenbeispiel zu bleiben, aus einer Firmenabteilung von
60 Durchschnittern könnte man durch Aufnahme eines Top-Entwickler in die
"Core-Gruppe" ein kleineres aber effizienteres Team von 31 Mitgliedern
formen.
Um dann gnadenlos zu scheitern. DeMarco und Lister haben das in Peopleware in den 80ern glaube ich das Chirurgen-Team genannt. Ein Top-Performer, der Chirurg, steht am wichtigen Code (dem Patienten) und alle anderen unterstützen ihn (machen die langweilige Arbeit wie wieder zunähen).
40 Jahre später gibt es keine glaubhaften Berichte darüber dass das irgendwo langfristig und zuverlässig in nicht-trivialen Bereichen funktioniert hätte. Einzelfälle sicherlich, aber mehr nicht.
Ein Grund, Top-Programmierer sind häufig Arschlöcher. Um es höflicher zu sagen, sind nicht teamfähig, können nicht kommunizieren, können sich nicht integrieren und können nicht mit anderen Leuten.
Daher nimmst du als Manager an der Front, nicht wie der Sajjad als Manager ganz oben in seinem Wolkenkuckucksheim, lieber einen Durchschnittsprogrammierer statt einen Hotshot.
Manche echte Chirurgen sollen auch ziemliche Arschlöcher sein. Aber in der Medizin kommt eine starke Hierarchie, der Glaube an die Sache und der moralische Aspekt (wir können den Patienten nicht sterben lassen nur weil der Chirurg ein Arschloch ist) hinzu, der das Ganze zusammenhält. Beim Programmieren hast du diese Verhältnisse nicht.
Ach, und noch was, wer wenig Code abliefert ist nicht notwendigerweise unproduktiv. Das mag durchaus eine Schlüsselperson sein, die die Problemdomäne wirklich verstanden hat. Die die meiste Zeit daran arbeitet dass das so beleibt, der Ansprechpartner im Team dafür ist und ihr Wissen verteilt. Ja und die gelegentlich ein paar Zeilen Code abliefert weil es sich gerade so ergibt.
40 Jahre später gibt es keine glaubhaften Berichte darüber dass das
irgendwo langfristig und zuverlässig in nicht-trivialen Bereichen
funktioniert hätte.
?!?
Alle herausragende (innovative, ihr Genre definierende) Software ist von 'Helden' erdacht worden und wenn nicht selbst entwickelt so die Entwicklung geleitet worden.
Das liegt einfach daran dass auch eine Horde von Durchschnittlichen eben nur durchschnittliches produzieren kann.
Nicht ohne Grund gibt es im Bauwesen den Architekten und die Maurer.
Ein
Top-Performer, der Chirurg, steht am wichtigen Code (dem Patienten) und
alle anderen unterstützen ihn (machen die langweilige Arbeit wie wieder
zunähen).
40 Jahre später gibt es keine glaubhaften Berichte darüber dass das
irgendwo langfristig und zuverlässig in nicht-trivialen Bereichen
funktioniert hätte. Einzelfälle sicherlich, aber mehr nicht.
Ein Grund, Top-Programmierer sind häufig Arschlöcher. Um es höflicher zu
sagen, sind nicht teamfähig, können nicht kommunizieren, können sich
nicht integrieren und können nicht mit anderen Leuten.
Müssen sie auch nicht, zum Austausch zwischen Top-Programmer und "Durchschnitter" oder script-Kiddie gibt es die Software-Engineering collaborations-tools wie git, github, jira und Co..
Und die "Arschlochquote" bei Entwicklern ist auch nicht anders als anderswo: Linus Thorvals kann seinen Frust über die "Durchschnitter" auch nicht immer für sich behalten, trotzdem ist Linux prächtig gediehen. Andere wie Steve Wozniak gelten fast als Musterbeispiele für Top-Programmieren und verbindenden HAM-Spirit. OK, zu Zeiten des Apple gabs die Persönlichkeits-makel-firewall Internet (oder eben git, svn, etc.) noch nicht. Dunnemals musste man mit offenen Briefen etc. kommunizieren.
Und mancher war eben gefrustet, kein Geld für seine Arbeit zu sehen.
Solche Dummy Aussagen von irgendeinem Inder, der selber schon lange nichts mehr programmiert, sind einfach nur Quark!
Wenn es um Qualität und die richtige Lösung geht, ist die Idee eines Einzelnen überhaupt nicht durch Menge zu ersetzen.
Wenn es um Quantität geht, ergeben sich Spannen um +/-30% - mehr nicht! 5 Leute bringen immer mehr, als 3 und oftmals auch mehr als 4 - egal wie gut die jeweils anderen sind.
Hängt alles von der Aufgabe ab. Das Ziel muss immer sein, möglichs wenige zu befassen, weil sich ein jeder mit sich selber am Besten organisieren kann.
Ein Paket von 1000 Mannstunden, wird man aber nicht auf eine Person verteilen, weil die 6 Monate sitzt. Dann nimmt man eben die Abstimmung in Kauf, investiert 1200 Mannstunden, verteilt auf 4 und hat es in 2 Monaten.
Das nennt sich Recycling oder Wiederverwendung und sollte durch
Referenzierung (verwenden von libraries) und möglichst nicht durch
Kopieren geschehen.
Wieder so eine pauschale Ausage!
Wenn eine LIB modifiziert wird, weil man dort was ändert, dann würden sich die Sourcen für alle anderen abhängigen Projekte ändern und müssten disbezüglich bei Erweiterungen an anderer Stelle auch hierfür durchgetestet werden.
Das ist Unsinn! Man macht Softreferenzen ohne tatsächliche Abhängigkeit. Dann hat jede SW eindeutige Sourcen. Ansonsten müssten die Sourcen im damaligen Stand in ein Archiv eingecheckt werden.
Wenn es um Quantität geht, ergeben sich Spannen um +/-30% - mehr nicht!
5 Leute bringen immer mehr, als 3 und oftmals auch mehr als 4 - egal wie
gut die jeweils anderen sind.
So dachte man bei VW Cariad auch mal, als es gegründet wurde unter Diess.
Viel Geld, viele Leute, sollte ja was bringen, leider bekam man nur Durchschnittsleute weil die Cracks ja schon einen Vertrag woanders hatten, egal, dann eben mehr.
Unter Blume prakisch wieder aufgelöst, weil riesiges Geldgrab ohne Ergebnis.
Diess grosses Vorbild Musk machte es anders: den einen Helden, der es kann, und dem dann genug Workforce finanzieren. Klappt.
Jetzt werden die wenigen Cracks gesucht, weltweit, für Cariad.
