"Ein guter Softwerker ersetzt 30 Durschnittliche"
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 ?!
Bradward B. schrieb:> Wenn man die Leistung eines Softwareentwicklers in abgelieferten> Code-Zeilen misst,
dann ist man sehr naiv.
Bradward B. schrieb:> 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, ...
Bradward B. schrieb:> Wenn man die Leistung eines Softwareentwicklers in abgelieferten> Code-Zeilen misst
dann misst man Mißt
Bradward B. schrieb:> 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.
Bradward B. schrieb:> 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. :)
Bradward B. schrieb:> weil kein Entwickler 30-Mal schneller tippt als der Durschnitts-Profi.
Du musst einer von den 30 sein.
Ahnungslos, planlos.
Wie viele Chorknaben braucht es, um einen Freddy Mercury zu ersetzen ?
Einige Leute können es halt einfach, Talent, da kommen andere ihr Leben
lang nicht hin.
(prx) A. K. schrieb:> von 10 bis 50 Codezeilen je Mitarbeiter und Tag
Bei der Entwicklung neuer Features kannst du da ein bis zwei Nullen dran
hängen.
Anders sieht es beim Troubleshooting aus, da kann es unter ein einziges
Zeichen pro Tag sein.
Bradward B. schrieb:> "Ein guter Softwerker ersetzt 30 Durschnittliche"
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.
Bradward B. schrieb:
> [...]
alles zusammen und mehr.
> 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.
Michael
Gustl B. schrieb:> 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.
Ist ja auch gut, die arme Wirtschaft.
Bradward B. schrieb:> Also Tool-kenntniss und das Einmaleins
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.
Bradward B. schrieb:> "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.
Eine KI wirft nur dann was Brauchbares aus, wenn sie vorher eine
identische Kopie in ihrer Internet-Datenbank gefunden hat. Innovationen
kommen so nicht zustande. KI's schlussfolgern nicht, KI's "lernen
auswendig":
https://www.heise.de/news/KI-Modelle-lernen-auswendig-und-schlussfolgern-nicht-9800916.html
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.
Dieter D. schrieb:> 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!
LG, Sebastian
> > 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.
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.
Bradward B. schrieb:> 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.
Hannes J. schrieb:> 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.
* https://en.wikipedia.org/wiki/An_Open_Letter_to_Hobbyists
* https://www.heinzawards.org/pages/steve-wozniak
*
https://www.heise.de/news/Linus-Torvalds-wettert-gegen-Compiler-Collection-GCC-4-9-2268920.html
Libs und andere ReUse-Grundlagen für die breite Masse der
"Durchschnitter" fallen hat nicht vom Himmel.
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.
Was die Gruppen angeht:
Bradward B. schrieb:> Die optimale Gruppengröße soll ja bei 5-7 liegen:
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.
Michael D. schrieb:> 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.
Rolf S. schrieb:> 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.
Hannes J. schrieb:> Bradward B. schrieb:>> HAM-Spirit>> Danke, jetzt weiß ich Bescheid. Ich habe mich schon gewundert warum du> so merkwürdig drauf bist.
??? Ich bin nicht Stephen Gary Wozniak !
> Solche Dummy Aussagen von irgendeinem Inder, der selber schon lange> nichts mehr programmiert, sind einfach nur Quark!
Vorsicht Fettnapf, der Zitierte (Saijad Khan) ist nicht Inder sondern
Pakistani (geb. 1973 in Karachi).