Forum: Ausbildung, Studium & Beruf Entwicklung große Firmware. Kollegen einlernen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Flo (sandiegoo)


Lesenswert?

Hallo Zusammen,

ich möchte diesen Beitrag mal starten um zu erfahren wie man große 
Software/Firmwareprojekte (größer 100.000 Codezeilen) an andere Kollegen 
weitergibt, bzw. diese bereits während der Erstellung der Software mit 
einbezieht.

Hintergrund hier ist einen zweiten Entwickler zu haben, der bei Bedarf 
ohne große schwierigkeiten sofort am Code des anderen weiterarbeiten 
kann.

- Wie machen das andere Leute / Firmen?
- Wöchentliche Meetings bei dem man sich zusammensetzt und den Code 
bespricht?
- Eine sehr große Dokumentation bei der alles bis ins kleinste Detail 
beschrieben ist?
- ...?

von Bruno V. (bruno_v)


Lesenswert?

Das wichtigste ist "lesbarer" bzw. "navigierbarer" Code. Läuft eine 
Funktion in ein Assert oder einen unerwarteten Rückgabewert, dann sollte 
er dieses Detail im Code auch separat erforschen können.

Von da kann er mit wenigen Dokumenten die Struktur erforschen.

Ein Lehrbuch für C++ oder Stricken beginnt auch bei einfachen Dingen und 
wird immer komplexer.

Dokumentation ist nur hilfreich, wenn mehr Zeit ins Lesen fließt als ins 
schreiben. Zentrale Konzepte, globale Strategien, 
Schnittstellen-Beschreibungen, gegen die ein anderer Programmiert, 
Super.
10 Seiten Prosa, die der Entwickler runterschreibt und die niemand 
liest, sind hingegen oft wertlos für den Nächsten. Sie helfen eher dem 
Schreiber.

Stell Dir einen Supermarkt vor: Du brauchst vorab komplexe Konzepte und 
Strategien, da steckt sehr viel (uns unbekanntes) Know How drin. Der 
Neue Kollege kann sich den Supermarkt aber am Besten erstmal anhand der 
Ordnung der Produkte erschließen und sich von da in die Struktur 
einarbeiten.

von Steve van de Grens (roehrmond)


Lesenswert?

Flo schrieb:
> Wie machen das andere Leute / Firmen?

Wenn man sich von der Vorstellung löst, dass ein Programmierer für ein 
Projekt zuständig ist, geht das einfach. Die Team Mitglieder 
programmieren wechselweise teile der Software, ein anderer Kontrolliert 
das (Testen, Code-Review, Doku prüfen). So hast du automatisch für jeden 
Teilbereich immer mindestens zwei Leute, die sich damit einigermaßen 
auskennen.

von Oliver S. (oliverso)


Lesenswert?

Oder anders gesagt: wenn du der einzige Entwickler für das einzige Stück 
Software im Unternehmen bist, habt ihr noch ganz andere Probleme.

Oliver

von Lu O. (oszi45)


Lesenswert?

Eine kurze Dokumentation, die AKTUELL gehalten wird, wäre nützlich für 
den Einstieg. Wichtig wäre für mich, wie man mögliche Fehler frühzeitig 
erkennt und behandelt. Manches Programm prüft sich deshalb selbst.
Dokumentation sollte so sein, dass man in >20 Jahren noch etwas damit 
anfangen kann. Thema Voyager 
https://www.pcwelt.de/article/2114489/voyager-sonden-software-update.html

von Steve van de Grens (roehrmond)


Lesenswert?

Dokumentation ist wichtig.

Zu viel ist aber kontraproduktiv, weil
- das keiner lesen will
- das keiner pflegen will
- man es bei Geld-/Zeitmangel vernachlässigt

Wo ich gerade arbeite hat sich folgendes bewährt:

Der technische Projektleiter, der auch mit dem Auftraggeber verhandelt, 
sammelt die Anforderungen vom Kunden irgendwo für sich. Er zerlegt das 
in viele kleine Aufgaben (Tickets), die von den Programmierern und 
Testern abgearbeitet werden. Änderungen der Anforderungen werden in den 
Tickets dokumentiert.

Die Programmierer beschreiben alle Funktionen aus ihrer Sicht und für 
sich selbst bzw. ihr Team. Dazu gehören auch knapp formulierte 
Anleitungen zum Build-Pozess, Installation, Konfiguration und Erstellung 
der Lieferungen. Ein simples Wiki eignet sich dazu ganz gut. Die größte 
Herausforderung dabei ist, eine Form zu finden, die allen zusagt.

Beispiel:
1
Function sendNotificationMailAfterStatusChange()
2
3
This function is called whenever the status of a customer has been changed.
4
5
* Find a usable email address in this order
6
  * First choice is the email address of the customer, if set
7
  * otherwise use the email address of default contact partner of the customer
8
  * otherwise use the email address of the administrator of the customer
9
  * otherwise use the email address of any contact person of the customer who has an email address set
10
  * otherwise abort with error ...
11
* Load the email template from DB table ... where name is notifMail_<oldStatus>_<newStatus>
12
  * if there is no such template, then abort with error ...
13
* Call the sendMail() function (link) with the following arguments
14
  * ...
15
* Return 0 (success)

Man sollte nur die Funktionen dokumentieren, die für die Geschäftslogik 
relevant sind. Wie genau auf die DB Zugegriffen wird, ist eher 
uninteressant und sollte eh nach einem Standard Pattern ablaufen, dass 
die ganze Anwendung durchzieht. Nur bei besonderen Abweichungen muss man 
das detaillierter erklären. Eventuell gibt es eine separate Doku wo die 
Standard Patterns erfasst sind.

Projektleiter nutzen diese Doku wiederum als Basis, um künftige 
Änderungen zu planen und Fragen zu klären (warum passiert hier dies und 
nicht das?). Auch die Manuals für die Kunden basieren darauf.

: Bearbeitet durch User
von Michael B. (laberkopp)


Lesenswert?

Flo schrieb:
> Wie machen das andere Leute / Firmen?

Keep it simple, nicht den allerneuesten C++23 Quatsch einbauen, lieber 
einfachere Strukturen in common knowledge.

Dokumentiere die Schnittstellen exakt, je nach dem wo Schnittstellen 
sind, Libraries, Klassen, Programme etc. mit Aufrufbeispielen. Auch 
externe Anforderungen klar formuliert mit abheften.

Baue automatisierte Tests, damit jeder Fehler den er einbaut gleich 
auffällt, baue sie auf eine Art die auch von anderen leichtverständlich 
zu erweitern ist.

Nein, dokumentiere nicht jede Codezeile, bespreche nichts was man wegen 
der schieren Menge wieder vergisst weil es in dem Moment unwichtig ist.

von Xanthippos (xanthippos)


Lesenswert?

Softwareentwicklung ist immer noch Kunsthandwerk.

In allen anderen Bereichen hat sich das von James Watt entwickelte 
Konzept durchgesetzt. In seinem System lassen sich die Ingenieure 
beliebig austauschen.

Bis 2000 rum war die Vorgehensweise zur Softwareentwicklung durchaus 
sinnvoll. Die Hardware was viel zu teuer. Du brauchtest geniale 
Kunsthandwerker, die auf der viel zu schlappen Hardware ein nützliches 
Programm zustande brachten.

Heutzutage hast du ein Henne-Ei-Problem. Würden alle Firmen die 
Softwareentwicklung nach Watts Konzept organisieren, könntest du die 
Entwickler beliebig austauschen. Aber für das alte Kunsthandwerk gibt es 
nicht genug Entwickler. Du bekommst nur fähige Entwickler, wenn du dich 
auf deren Forderungen einlässt.

von Bruno V. (bruno_v)


Lesenswert?

Xanthippos schrieb:
> Bis 2000 rum war die Vorgehensweise zur Softwareentwicklung durchaus
> sinnvoll. Die Hardware was viel zu teuer. Du brauchtest geniale
> Kunsthandwerker, die auf der viel zu schlappen Hardware ein nützliches
> Programm zustande brachten.

Myth. Schon 1968 hinkte die SW hinterher.

https://de.wikipedia.org/wiki/Softwarekrise

(Man denkt immer, dass davor nur Nerds vor sich hin programmierten. Seit 
den 50ern arbeiten Teams mit tausenden Programmierern an einer SW.)

: Bearbeitet durch User
von Xanthippos (xanthippos)


Lesenswert?

> Seit den 50ern arbeiten Teams mit tausenden Programmierern an einer SW.

"Die Seele einer neuen Maschine" oder folklore.org . Das wurde von ein 
paar Genies entwickelt, nicht vom Fußvolk. Auch Fred Brooks musste 
zugeben, ein exzellenter Entwickler bringt 10 mal so viel zustande, wie 
ein guter Entwickler.

Ingenieure wie Gustave Eiffel oder Rudolf Diesel gibt es heutzutage 
nicht mehr. Aber es gibt immer noch Softwareentwickler wie Linus 
Torvalds.

Das Problem wurde schon 68 erkannt, aber immer noch nicht gelöst. Einen 
Linus Torvalds kannst du immer noch nicht ersetzen.

von Ali K. (teddy50)


Lesenswert?

Was mir sehr hilft ist keine Dokumentation bis ins kleinste Detail 
sondern:

-> Erstmal verstehen, was das Produkt überhaupt macht!?
-> Was bietet das Produkt einem Anwender?
-> Welche Schnittstellen gibt es zum Anwender?
-> Kann der Anwender das System parametrieren bzw. Daten abfragen?
-> Wie hängen die Schnittstellen und andere Systemkomponenten zusammen?

Die Punkte im Hinterkopf würde mir das Einarbeiten in eine Firmware 
vereinfachen.

von Bruno V. (bruno_v)


Lesenswert?

Xanthippos schrieb:
> Das wurde von ein paar Genies entwickelt, nicht vom Fußvolk.
Schon klar, dass da nicht 1000 Entwickler ein SCRUM-Team bilden.

> Auch Fred Brooks musste zugeben, ein exzellenter Entwickler bringt
> 10 mal so viel zustande, wie ein guter Entwickler.
Dann weißt Du auch, warum die Performance eines Garagenstartup nicht 
skaliert.

> Einen Linus Torvalds kannst du immer noch nicht ersetzen.
Unglückliches Beispiel: Eher Allen/Gates oder Wozniak, die sich nicht in 
ein gemachtes Nest gesetzt haben.

Aber klar: In jeder Branche gibt es führende Talente. Auch einen Neuer 
kannst Du nicht ersetzen. Oder mit Turek, Maier oder Illgner 
vergleichen. So what.

Hier geht es um eine (vermutlich ältere) SW, die von einem Maintained 
wird und wo ein zweiter dazu kommt. Das war vor 50 Jahren vermutlich die 
gleiche Herausforderung wie heute.

von Xanthippos (xanthippos)


Lesenswert?

In der Softwareentwicklung haben wir immer wieder komplett neu 
angefangen.

Immer wieder das selbe. Die Neuen verstanden die Altlasten nicht, 
wollten sie auch nicht verstehen und fingen mit neuen Ideen wieder von 
vorne neu an.

Als die Entwickler der Großrechner in Rente gingen, kamen Apple II und 
IBM PC auf. Das Visicalc konnte ein einzelner Kunsthandwerker 
entwickeln. Novell Fileserver entwickelten auch ein paar einzelne 
Künstler.

Als die PC Netze zu komplex wurden, fingen wir mit den TCP/IP Standards 
neu an.

Als Firmenintranet zu komplex wurde, versuchten wir es mit Cloud 
Services und Smartphone Apps.

Jeder gute Softwareentwickler kann dem Chef sagen "Den alten Schrott 
übernehme ich nicht, wenn ich das nicht neu machen kann, suche ich mir 
einen anderen Job."

Vergleich das mal mit Automobilbau, Maschinenbau, Bauwesen... Stell dir 
vor, ein Statiker sagt den Chef "Verstehe ich nicht, will ich nicht 
verstehen. Ich will das Haus abreißen und ganz anders neu bauen".

von Mark B. (markbrandis)


Lesenswert?

Xanthippos schrieb:

> Jeder gute Softwareentwickler kann dem Chef sagen "Den alten Schrott
> übernehme ich nicht, wenn ich das nicht neu machen kann, suche ich mir
> einen anderen Job."

Es ist ja nicht der alte Code allein. Oftmals gibt es auch keine 
vernünftig dokumentierten Anforderungen dazu, keine sauber definierte 
Architektur, keine Design-Dokumente, und die Schnittstellen zwischen den 
Software-Modulen sind auch nirgends richtig beschrieben. Dementsprechend 
schwer ist es, sich überhaupt einigermaßen zurechtzufinden.

Qualitativ schlechten Code sollte man tatsächlich besser wegwerfen als 
beibehalten.

: Bearbeitet durch User
von Purzel H. (hacky)


Lesenswert?

Es geht doch gar nicht um den Code. Code ist trivial, kann man bald 
durch KI erzeugen lassen. Es geht um Loesungen. Die werden nicht per - 
Schnipp - hingeworfen.

Und vor Jahrzehnten war nicht die Hardware zu teuer und konnte nichts. 
Die Probleme waren anders. Wenn das Problem der Welt darin besteht mit 
einem Transistor einen Ballon aufzublasen benoetigt man eben Jemanden 
der den Transistor und Ballon versteht, und die Beiden zusammenhaengen 
kann. Ob das jetzt 10'000 Mark kostet ist egal. Das Problem ist nachher 
geloest, alle sind happy und applaudieren. Der Konstrukteur wird vom/mit 
dem Buergermeister praesentiert und bekommt eine Auszeichnung.
Heutzutage wird millionenfach dupliziert, man kassiert millionenfach, 
der Buergermeister wird nicht mehr benoetigt. Den Konstrukteur benoetigt 
man trotzdem.

: Bearbeitet durch User
von 900ss (900ss)


Lesenswert?

Mark B. schrieb:
> Es ist ja nicht der alte Code allein. Oftmals gibt es auch keine
> vernünftig dokumentierten Anforderungen dazu, keine sauber definierte
> Architektur, keine Design-Dokumente, und die Schnittstellen zwischen den
> Software-Modulen sind auch nirgends richtig beschrieben. Dementsprechend
> schwer ist es, sich überhaupt einigermaßen zurechtzufinden.

Genauso sieht es aus. Habe ich auch so erlebt. Es ist schlicht grausam 
und völlig demotivierend, auch für neue Mitarbeiter.

Mark B. schrieb:
> Qualitativ schlechten Code sollte man tatsächlich besser wegwerfen als
> beibehalten.

Volle Zustimmung.

: Bearbeitet durch User
von Dergute W. (derguteweka)


Lesenswert?

Moin,

900ss schrieb:
> Mark B. schrieb:
>> Qualitativ schlechten Code sollte man tatsächlich besser wegwerfen als
>> beibehalten.
>
> Volle Zustimmung.

Ach. Arm dran ist besser als Arm ab.
Nur dummerweise sollte man den qualitativ schlechten Code erst dann 
wegwerfen, wenn man:
a.) einen anderen Code hat, der compiliert.
b.) belastbar sichergestellt hat, dass der auch wirklich "qualitativ 
besser" ist.

und nicht schon vorher, denn sonst guckt die Fertigung etwas schmal.

Gruss
WK

von Martin S. (sirnails)


Lesenswert?

Flo schrieb:
> Hallo Zusammen,
>
> ich möchte diesen Beitrag mal starten um zu erfahren wie man große
> Software/Firmwareprojekte (größer 100.000 Codezeilen) an andere Kollegen
> weitergibt,

Üblicherweise genau dann, wenn es brennt. Und dann mit einem Sprung ins 
kalte Wasser.

> bzw. diese bereits während der Erstellung der Software mit
> einbezieht.

In der idealen Welt arbeiten natürlich mehrere Personen am gleichen 
Projekt. Zwar in anderen Bereichen, aber wenn Not am Mann ist, übernimmt 
das einer von ihnen. Einfach, weil sie in die Sturktur schon 
eingearbeitet sind.

> Hintergrund hier ist einen zweiten Entwickler zu haben, der bei Bedarf
> ohne große schwierigkeiten sofort am Code des anderen weiterarbeiten
> kann.

Das ist eine Wunschvorstellung.

Rational: Der Code ist gut dokumentiert, die Entwickler haben auf 
"findige Tricks zur Optimierung des letzten Quäntchen verzichtet" und 
lesbaren Code erzeugt, es gibt einheitliche Funktionsprototypen, es wird 
nicht in jeder Funktion mit einem anderen Datentyp gearbeitet, es gibt 
funktionale Diagramme, die auf Metaebene den Codeauflauf beschreiben.

Real: Irgendein Entwickler hat mal angefangen, ein Anderer hat es 
übernommen, ist aber in seinem Sabbat-Jahr, ein weiterer hat hier und da 
was hinzugefügt, es gibt eigentlich keinen, der jede Ecke des Programms 
kennt, Dokumentation ist eher so mähbäh und Kommentare fressen unbändig 
viel Speicherplatz auf dem Controller und wurden deshalb gleich ganz 
weggelassen. Die ganze Software tut zwar was sie soll, ist aber so 
behäbig wie die Volkswagen-Behörde und so durchsichtig, wie das 
Steuersparmodell eines Milliardärs.

> - Wie machen das andere Leute / Firmen?

Dokumentation kostet Geld und bringt keinen Profit. Und da 
goldgepresstes Latinum wichtiger ist, als alles andere auf dieser Welt, 
sehen wir uns eher mit Fall 2 konfrontiert. Je größer die Firma, umso 
eher wird Wert auf Wartbarkeit und Dokumentation gelegt und wenn die 
Firma ganz groß ist, dann dokumentiert man mehr, als dass man 
entwickelt. Irgendwo dazwischen liegt der Median.

> - Wöchentliche Meetings bei dem man sich zusammensetzt und den Code
> bespricht?

Da halte ich wenig von. Einfach, weil man vom bloßen Erklärt bekommen 
wenig lernt. Man hat dann vielleicht im Hinterkopf, dass man xyz 
irgendwo irgendwann schonmal gesehen hat, aber das reicht eigentlich 
nicht, um dann auch selbst Veränderungen durchführen zu können.

> - Eine sehr große Dokumentation bei der alles bis ins kleinste Detail
> beschrieben ist?
> - ...?

Es gibt so einen tollen Spruch: Es wird auf dieser Welt nicht zu wenig 
geschrieben, es wird zu wenig gelesen.

Eine überkandidelte Dokumentation ist ein Totschläger. Niemand, der nur 
die Anzahl an Seiten sieht, hat wirklich Lust, sich das anzusehen.

Eine API-Dokumentation mag sinnvoll sein (falls relevant), eine 
Funktionsübersicht mit einem bis zwei Sätzen, die die Funktion erklären. 
Mehr braucht es aber auch nicht, weil man als Entwickler eigentlich 
schnell lernt, seinen Fokus auf's Wesentliche zu richten. Zu viel Bla 
Bla lenkt einfach nur ab. Und, wie oben schon erwähnt, gewisse 
Ablaufdiagramme (z.B. von komplexen Algorithmen).

Ich habe mit vielen Entwicklern zu tun gehabt. Es gibt ganz wenige 
herausragende, die binnen Sekunden den Kern erfassen können. Die 
allermeisten schlürfen behäbig ins Thema, schauen sich den Code an, 
verstehen das Grundprinzip, aber nicht, warum hier z.B. eine 
Betragsfunktion verwendet wird, bevor der Wert weiterverarbeitet wird.

Ich denke bei einem derart komplexen Programm ist die einzige Chance 
eine echte Vertretung zu haben, wenn diese auch aktiv beteiligt ist.

von Lu O. (oszi45)


Lesenswert?

Es nützt eine akademisch tolle Lösung wenig, wenn sie in der Praxis 
versagt. Es gibt gute Programmierer und gute Praktiker. Sie sollten die 
Anforderungen der Anderen kennen, wenn es eine gute Lösung werden soll!

von Michael B. (laberkopp)


Lesenswert?

900ss schrieb:
> Mark B. schrieb:
>> Qualitativ schlechten Code sollte man tatsächlich besser wegwerfen als
>> beibehalten.
>
> Volle Zustimmung

Na ja, qualitativ schlecht nach wessen Massstab, deinem ?

Humbug.

Qualitativ schlecht ist code, wenn er nicht (auch im Fehlerfall) 
funktioniert, wenn er langsam ist oder viele Ressourcen verbraucht.

Das sind Massstäbe, Metriken.

Nicht deine Verblendung 'alle doof ausser ich'.

Daher kommt auch 'never change a running system'.

Übrigens zeigt ein Blick in den Code von CP/M, Windows 1-3.11, GEM, dass 
Software die kommerziell erfolgreich war auch gut geschrieben war. Mit 
Win32 (David Cutler) ging es signifikant bergab.

von 900ss (900ss)


Lesenswert?

Michael B. schrieb:
> Na ja, qualitativ schlecht nach wessen Massstab, deinem ?

Ich habe nur eine Äußerung bestätigt, wo ich meine das sie stimmt. Und 
es ist erstmal ganz allgemein die Qualität gemeint, nach welchen 
Kriterien/Massstäben die festgelegt wird, ist nicht diskutiert worden. 
Ich habe keine genannt. Weshalb dichtest du das jetzt dazu und 
unterstellst mir etwas?

Michael B. schrieb:
> Nicht deine Verblendung 'alle doof ausser ich'.

Ich weiß ja wo es herkommt. Dein Nick ist halt Programm. Und leider auch 
häufiges pöbeln, so wie jetzt auch.
Es ist schade, da es Ausreißer gibt mit Beiträgen von dir, die 
tatsächlich sehr gut sind.

von Michael B. (laberkopp)


Lesenswert?

900ss schrieb:
> da es Ausreißer gibt mit Beiträgen von dir, die tatsächlich sehr gut
> sind.

Deine Bewertung ist einfach: stimmt er mir zu, ist sein Beitrag gut, 
äussert er Kritik, ist sein Beitrag schlecht.

Auf die Art kommst du halt nie zur  Wahrheit.

von Oliver S. (oliverso)


Lesenswert?

Martin S. schrieb:
> Flo schrieb:
>> Hallo Zusammen,
>>
>> ich möchte diesen Beitrag mal starten um zu erfahren wie man große
>> Software/Firmwareprojekte (größer 100.000 Codezeilen) an andere Kollegen
>> weitergibt,
>
> Üblicherweise genau dann, wenn es brennt. Und dann mit einem Sprung ins
> kalte Wasser.

Danke. Wenigstens ein Realist.

Oliver

von 900ss (900ss)


Lesenswert?

Michael B. schrieb:
> stimmt er mir zu, ist sein Beitrag gut, äussert er Kritik, ist sein
> Beitrag schlecht.

Falsch. Wenn die Kritik sachlich und nicht persönlich werdend ist, dann 
ist der Beitrag schon mal lesenswert. Leider ist das bei dir oft nicht 
der Fall. Stänkern und pöbeln liegt einigen Leuten leider eher.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Ich lerne niemandem mehr ein: Zeitverschwendung. Ich habe schon oft 
irgendwelchen Neuzugängen was gezeigt. Entweder die Person ist dann nach 
ein paar Wochen weg oder in einer anderen Abteilung.
Alle guten Leute die da sind, brauchten das nie. Von diesem "Einlernen" 
profitieren am Ende nur die Schwurbler. Die dann Wissen abgreifen und 
damit hausieren gehen. Was habe ICH davon? Nichts. Sollen sich selbst 
kümmern.

: Bearbeitet durch User
von Michael B. (laberkopp)


Lesenswert?

900ss schrieb:
> Wenn die Kritik sachlich und nicht persönlich werdend ist, dann ist der
> Beitrag schon mal lesenswert.

Dann lies mal deine Beiträge mit ihren persönlichen Beleidigungen.

von Bruno V. (bruno_v)


Lesenswert?

Cyblord -. schrieb:
> Von diesem "Einlernen"
> profitieren am Ende nur die Schwurbler. Die dann Wissen abgreifen und
> damit hausieren gehen. Was habe ICH davon? Nichts. Sollen sich selbst
> kümmern.

Sehe ich auch so.

Das einzige, was ich tue und verlange ist ein kompletter 
turnaround-Zyklus: Installieren der Tools, Auschecken, ein Bit ändern, 
Builden, Ablegen, einspielen/nutzen/ablegen.

Meist bleibt ein Haken oder Schritt vergessen.

Wenn das perfekt beschrieben ist, super --> 0 Arbeit für den alten.

Wenn es hakelt, bringt der alte das mit dem neuen zum fliegen, der neue 
aktualisiert ggf. die Doku. Mir reicht es, wenn der neue es danach 
alleine kann.

von Franko S. (frank_s866)


Lesenswert?

Cyblord -. schrieb:
> Ich lerne niemandem mehr ein: Zeitverschwendung. Ich habe schon oft
> irgendwelchen Neuzugängen was gezeigt. Entweder die Person ist dann nach
> ein paar Wochen weg oder in einer anderen Abteilung.
> Alle guten Leute die da sind, brauchten das nie. Von diesem "Einlernen"
> profitieren am Ende nur die Schwurbler. Die dann Wissen abgreifen und
> damit hausieren gehen. Was habe ICH davon? Nichts. Sollen sich selbst
> kümmern.

Vermutlich hauen sie deshalb auch gleich wieder ab bei solchen tollen 
Kollegen, da fühlt man sich gleich sauwohl - aber woanders.

von Steve van de Grens (roehrmond)


Lesenswert?

Xanthippos schrieb:
> Jeder gute Softwareentwickler kann dem Chef sagen "Den alten Schrott
> übernehme ich nicht"

Ich halte mich für einen guten Softwareentwickler, weil ich genau das 
nicht mache.

Neuentwicklungen gibt der Chef mir nicht mehr so gerne, weil ich dabei 
zu schnell bin (sagt er). Er braucht für mich immer drei Leute für 
Code-Review und Test, die dann Monatelang zu nichts anderes mehr kommen 
weil ich sie zu ballere.

Sich in Altlasten rein zu fuchsen dauert länger, die meisten Kollegen 
können das gar nicht. Manchmal fühle ich mich, als hätte ich damit die 
Arschkarte gezogen. Andererseits klappt es ganz gut und ich denke, dass 
man so für die Firma auch wichtiger wird.

: Bearbeitet durch User
von Martin S. (sirnails)


Lesenswert?

Franko S. schrieb:
> Cyblord -. schrieb:
>> Ich lerne niemandem mehr ein: Zeitverschwendung. Ich habe schon oft
>> irgendwelchen Neuzugängen was gezeigt. Entweder die Person ist dann nach
>> ein paar Wochen weg oder in einer anderen Abteilung.
>> Alle guten Leute die da sind, brauchten das nie. Von diesem "Einlernen"
>> profitieren am Ende nur die Schwurbler. Die dann Wissen abgreifen und
>> damit hausieren gehen. Was habe ICH davon? Nichts. Sollen sich selbst
>> kümmern.
>
> Vermutlich hauen sie deshalb auch gleich wieder ab bei solchen tollen
> Kollegen, da fühlt man sich gleich sauwohl - aber woanders.

Das hat mit "tollen" Kollegen nichts zu tun. Das ist einfach die 
Konsequenz aus der Erfahrung, die ich auch gemacht habe.

Wir haben hier in den letzten 6 Jahren inzwischen den 4ten Neuzugang. 
Einer ist noch da. Die anderen sind, oder wurden gegangen. Jedes 
Einlernen frisst mindestesn zwei Wochen Arbeitszeit. Zwei Wochen, in 
denen man selbst kaum produktiv ist, sich aber rechtfertigen muss, warum 
das eigene Zeug nicht fertig wird. Wenn das Einlernen fruchtet: 
Geschenkt. Aber meiner Erfahrung nach ist das Perlen vor die Säue, 
weshalb ich das auch nicht mehr mache, sondern ein Kollege. Irgendwann 
kommt der schon auch noch an den Punkt.

Die Sache mit dem Einlernen ist ja die: Wir sind hier keine Schule. Wir 
erwarten, dass das Rüstzeug vorhanden ist. Sonst könnten wir einen Azubi 
nach der Lehre übernehmen und bei Adam und Eva mit ihm anfangen. Was wir 
beibringen sollen und müssen sind betriebliche Abläufe, Toolchains, 
Organisationsstruktur. Der Rest muss von der Person selbst kommen. Einer 
von den oben genannten 4 Zugängen war sogar so schlecht, dass wir 
mittlerweile alles, was er in der Zeit bei uns gemacht hat (bevor er 
gegangen wurde) nochmal komplett neu gemacht werden musste. Jetzt ist er 
Projektleiter bei einem Unternehmen für Automatisierungstechnik. Naja, 
Aufschwätzen konnte er so richtig gut.

Ich muss korrigieren: Es waren 5 Neuzugänge und einer davon haben wir 
tatsächlich als Geselle innerbetrieblich übernommen. Aber das war auch 
einer der seltenen Fällen von Azubis, die wirklich motiviert und gut in 
dem waren, was sie so als Azubi-Aufgaben bekommen haben.

: Bearbeitet durch User
von 900ss (900ss)


Lesenswert?

Michael B. schrieb:
> Dann lies mal deine Beiträge mit ihren persönlichen Beleidigungen.

Wenn ich welche finde mache ich das gerne :)

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

Lu O. schrieb:
> Es nützt eine akademisch tolle Lösung wenig, wenn sie in der Praxis
> versagt.

Falls du mit "akademisch" das gleiche meinst wie ich: Meistens 
funktionieren diese Lösungen durchaus sehr gut. Es gibt aber zu viele 
Leute im Team, die sie nicht verstehen. Aus Unternehmerischer Sicht 
bleibt man flexibler und fährt billiger, wenn man auf besonders 
komplizierte Sachen so weit wie möglich verzichtet, damit möglichst 
viele Entwickler den Code möglichst rasch erfassen.

Diese Überlegung hat bei Google zur Entwicklung einer eigenen 
Programmiersprache (Namens Go) geführt. Rein technisch ist sie 
vollkommen überflüssig. Sie kann nicht besser, als andere etablierte 
Sprachen. Aber sie kann weniger, vor allem weniger kompliziertes, was 
die "erfahrenen" Programmierer zur Einfachheit zwingt und dem Nachwuchs 
den Zugang erleichtert.

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

Michael B. schrieb:
> Übrigens zeigt ein Blick in den Code von CP/M, Windows 1-3.11, GEM, dass
> Software die kommerziell erfolgreich war auch gut geschrieben war. Mit
> Win32 (David Cutler) ging es signifikant bergab.

Im Linux Quelltext soll es tausende Stellen mit schimpfenden Kommentaren 
gegeben haben. Wir machen das bei und in der Firma auch. So ein "WFT why 
do we not simply use a treemap here?" ist eine Ermunterung an die 
erfahrenen Programmierer, den ganzen Block bei Gelegenheit zu ersetzen, 
falls sie da durch blicken.

: Bearbeitet durch User
von Thomas (db8nr)


Lesenswert?

Flo schrieb:
> ich möchte diesen Beitrag mal starten um zu erfahren wie man große
> Software/Firmwareprojekte (größer 100.000 Codezeilen) an andere Kollegen
> weitergibt, bzw. diese bereits während der Erstellung der Software mit
> einbezieht.


Dafür verwende ich ClearCase:
https://de.wikipedia.org/wiki/Rational_ClearCase
Es gibt aber auch viele andere Versionsverwaltungen.

: Bearbeitet durch User
von Michael B. (laberkopp)


Lesenswert?

Steve van de Grens schrieb:
> Im Linux Quelltext soll es tausende Stellen mit schimpfenden Kommentaren
> gegeben haben

OpenOffice schimpft zwar nicht, enthält (zumindest damals als ich mich 
damit beschäftigen musste) aber extrem viele Kommentare was noch nicht 
implementiert ist oder besser implementiert werden sollte.

Sprich: wird 'verkauft' ist aber noch halbfertig.

von Cyblord -. (cyblord)


Lesenswert?

Martin S. schrieb:
> Wir haben hier in den letzten 6 Jahren inzwischen den 4ten Neuzugang.
> Einer ist noch da. Die anderen sind, oder wurden gegangen. Jedes
> Einlernen frisst mindestesn zwei Wochen Arbeitszeit. Zwei Wochen, in
> denen man selbst kaum produktiv ist, sich aber rechtfertigen muss, warum
> das eigene Zeug nicht fertig wird. Wenn das Einlernen fruchtet:
> Geschenkt. Aber meiner Erfahrung nach ist das Perlen vor die Säue,
> weshalb ich das auch nicht mehr mache, sondern ein Kollege. Irgendwann
> kommt der schon auch noch an den Punkt.

Und dann sind das nicht nur potentielle Kollegen sondern eben auch 
Schwurbler wie Vertriebler usw. denen man mal die Produkte erklären 
soll. Davon hat man selbst Null und gar Nichts. Nicht mal Kollegen die 
einem bei der Arbeit zur Hand gehen können.

von Vanye R. (vanye_rijan)


Lesenswert?

> Einlernen frisst mindestesn zwei Wochen Arbeitszeit. Zwei Wochen, in
> denen man selbst kaum produktiv ist, sich aber rechtfertigen muss, warum
> das eigene Zeug nicht fertig wird.

Also wenn das anlernen eines neuen Kollegen nur zwei Wochen dauert,
dann scheint ihr erstaunlich unkomplexe Dinge zu machen. Und
wenn ich mich gegen irgendjemanden dafuer rechtfertigen muesste das
etwas 2Wochen spaeter fertig wird dann wuerde ich SOFORT
nach einem anderen Job suchen.

Vanye

von Lu O. (oszi45)


Lesenswert?

Cyblord -. schrieb:
> Und dann sind das nicht nur potentielle Kollegen sondern eben auch
> Schwurbler wie Vertriebler usw. denen man mal die Produkte erklären
> soll.

Sei froh, wenn Du wissensdurstige Vertriebler hast, die geben auch mal 
Rückmeldung, was der Kunde braucht. Wenn der Vertrieb nicht 
funktioniert, hast Du bald keine Kunden mehr.

von Steve van de Grens (roehrmond)


Lesenswert?

Vanye R. schrieb:
> Also wenn das anlernen eines neuen Kollegen nur zwei Wochen dauert,
> dann scheint ihr erstaunlich unkomplexe Dinge zu machen.

Das dachte ich auch. Für zwei Wochen ( oder gar zwei Monate) würde ich 
mir nicht ins Hemd machen.

: Bearbeitet durch User
von Manfred P. (pruckelfred)


Lesenswert?

Lu O. schrieb:
> Sei froh, wenn Du wissensdurstige Vertriebler hast, die geben auch mal
> Rückmeldung, was der Kunde braucht. Wenn der Vertrieb nicht
> funktioniert, hast Du bald keine Kunden mehr.

Realitätscheck: Der Vertrieb beklagt sich, die Entwicklung ignoriert ihn 
und der Produktmanger hat keinen Bock, etwas ändern zu lassen.

Der Vertriebler wird umsatzabhängig bezahlt und verkauft den Kram 
trotzdem.

Die Ignoranten behalten Oberhand, weil deren Stümperei ja trotzdem 
Umsatz bringt.

von Bruno V. (bruno_v)


Lesenswert?

Steve van de Grens schrieb:
> Neuentwicklungen gibt der Chef mir nicht mehr so gerne, weil ich dabei
> zu schnell bin (sagt er). Er braucht für mich immer drei Leute für
> Code-Review und Test, die dann Monatelang zu nichts anderes mehr kommen
> weil ich sie zu ballere.

Sorry, aber auf welcher Ebene ergibt das irgendeinen Sinn?

von A. B. (funky)


Lesenswert?

Martin S. schrieb:
>> Wöchentliche Meetings bei dem man sich zusammensetzt und den Code
>> bespricht?
>
> Da halte ich wenig von. Einfach, weil man vom bloßen Erklärt bekommen
> wenig lernt. Man hat dann vielleicht im Hinterkopf, dass man xyz
> irgendwo irgendwann schonmal gesehen hat, aber das reicht eigentlich
> nicht, um dann auch selbst Veränderungen durchführen zu können

Würde ich so unterschreiben. Hab das selbst hinter mir. Über Monate jede 
Woche (war nicht nur eine Software)
Man wird mit viel scheiß beschissen, merken kann man es sich eh nicht 
alles und die Fragen tauchen erst auf wenn man selbst damit arbeitet.
Klar macht es Sinn paar Dinge zu erklären, Grundlagen, ein Konzept 
(falls es sowas überhaupt gibt) oft gibt's das nicht, alles ist 
historisch gewachsen & was Was macht und wieso, weshalb warum weiß eh 
niemand mehr.

mMn muss der neue in so einem Fall anfangen Aufgaben zu bekommen, sich 
mit dem Code vertraut machen und dann gezielt Fragen stellen.

Oftmals sind es dann ja aber keine trivialen Aufgaben mehr, sondern 
Sachen bei denen selbst der alte Hase erstmal nachdenken muss.
Und wenn es doll läuft ist der alte Hase eh schon weg in Rente.

Dann darf der Leiter der Entwicklung dem PM erklären, warum jetzt 
erstmal Stillstand herrscht und sich  nix mehr tut mit neuen Features :)

Viele Firmen sind da so dermaßen schlecht aufgestellt und haben noch nie 
etwas von einem Bus-Faktor gehört.
Wenn dann zusätzlich von dem/den alten Hasen etwas boshaftigkeit 
hinzukommt und sie bestimmten Kram soundurchsichtig geschrieben haben um 
sich ja unersetzbar zu machen... Tjaaa, dann sollte eigentlich derLeiter 
der Software dran sein, dass er sowas zugelassen hat... Aber das bleibt 
eh nurWunschdenken

von A. B. (funky)


Lesenswert?

Steve van de Grens schrieb:
> Sich in Altlasten rein zu fuchsen dauert länger, die meisten Kollegen
> können das gar nicht. Manchmal fühle ich mich, als hätte ich damit die
> Arschkarte gezogen. Andererseits klappt es ganz gut und ich denke, dass
> man so für die Firma auch wichtiger wird.

Das haben sich diejenigen die das verbrochen haben bestimmt auch schon 
gedacht. Verklausulierten kack schreiben den niemand durchblickt um ja 
unersetzbar zu sein.


Kann man den Firmen nur wünschen das sowas auffällt

von Steve van de Grens (roehrmond)


Lesenswert?

Bruno V. schrieb:
> Sorry, aber auf welcher Ebene ergibt das irgendeinen Sinn?

Wenn einer programmiert und die anderem im Team nur noch testen, ist das 
schon schlecht, weil das ganze Produkt von einem einzigen Programmierer 
abhängt. Die Kollegen können sich danach nicht gut gegenseitig 
vertreten. Außerdem will wohl kein Programmierer lange Zeit nur testen.

Man kann natürlich programmierte Änderungen so lange liegen lassen, bis 
alle Programmieraufträge fertig sind, und erst dann testen. Aber das 
diese Strategie nicht mehr Zeitgemäß ist, muss ich wohl niemandem hier 
erklären.

: Bearbeitet durch User
von Max (bit8)


Lesenswert?

Vanye R. schrieb:
>> Einlernen frisst mindestesn zwei Wochen Arbeitszeit. Zwei
> Wochen, in
>> denen man selbst kaum produktiv ist, sich aber rechtfertigen muss, warum
>> das eigene Zeug nicht fertig wird.
>
> Also wenn das anlernen eines neuen Kollegen nur zwei Wochen dauert,
> dann scheint ihr erstaunlich unkomplexe Dinge zu machen. Und
> wenn ich mich gegen irgendjemanden dafuer rechtfertigen muesste das
> etwas 2Wochen spaeter fertig wird dann wuerde ich SOFORT
> nach einem anderen Job suchen.
>
> Vanye

Jetzt mal Hand aufs Herz, wenn man Erfahrungen in der 
Softwareentwicklung hat, sich schon in über ein dutzend Projekten 
eingearbeitet hat, dann sind zwei Wochen machbar.

Nicht jedoch, wenn es total neue Technologien und oder Methoden sind.

Was macht Erfahrungen aus?
Und was macht Wissen aus?
Kennt ihr die Unterschiede?

von Joachim B. (jar)


Lesenswert?

Xanthippos schrieb:
> Immer wieder das selbe. Die Neuen verstanden die Altlasten nicht,
> wollten sie auch nicht verstehen und fingen mit neuen Ideen wieder von
> vorne neu an.

und ich sollte eine bestehende "Luftmessung" erweitern wo schon 100k 
Baugrupen gelaufen sind, ich brauchte 3 Wochen um den Gruppenleiter zu 
überzeugen das das alte Prüfprogramm nichts misst! Dann erst durfte ich 
es neu machen, bei gleichzeitiger Prüftiefe verbessern und noch 30% 
Zeitersparnis. Leider wurden vom Prüfling keine 100k mehr bestellt, es 
waren knapp 1000.

Die alten Kollegen haben schnell das Weite gesucht bevor der Schwindel 
aufflog und alles über Ihnen zusammenbricht.

: Bearbeitet durch User
von Mark B. (markbrandis)


Lesenswert?

Dergute W. schrieb:
> sollte man den qualitativ schlechten Code erst dann wegwerfen, wenn man

Das versteht sich sowieso von selbst. Darum muss man es auch nicht erst 
extra erläutern.

Wenn man aber sowieso das Software-Modul XYZ ändern muss, weil neue 
Anforderungen es so verlangen, dann kann man da auch aufräumen. Hin und 
wieder gelingt das sogar, obwohl dem Management natürlich die 
Code-Qualität vollkommen egal ist und nur auf Termine geschaut wird.

Dass schlechte Qualität an SW-Anforderungen, SW-Architektur, SW-Design 
und SW-Implementierung auch automatisch schlechte Termintreue bedeutet, 
das hat man leider auch nach vielen Jahren immer noch nicht verstanden.

: Bearbeitet durch User
von Bruno V. (bruno_v)


Lesenswert?

Steve van de Grens schrieb:
> Wenn einer programmiert und die anderem im Team nur noch testen, ist das
> schon schlecht, ...


Stefan, ich habe großen Respekt vor Dir und Deinem (öffentlichen) Werk.

Aber das widerspricht vollständig meiner Erfahrung mit guten 
Programmierern:
Deren Code ist viel kleiner und lesbarer für eine Aufgabe, so das alle 
gewinnen. Tests, Code-Reviews etc. werden entweder weniger oder helfen 
den anderen, zu wachsen. Natürlich wachsen nicht alle mit. Aber einige 
schon. Und die anderen werden langfristig halt mit Projekten mit weniger 
Potential betraut.

Gute Leute können es sich sogar leisten, arrogant zu sein (gegenüber 
Wannabies, nie gegenüber weniger befähigten oder Peers), da sie notfalls 
auch mit einem halben Team die volle Leistung bringen können.

Wenn jemand anderes "zu gut für Neues" geschrieben hätte, wäre mein 
Bild:
 * macht viel Code (statt guten*)
 * Eigenbrödler (niemand profitiert davon)
 * Pedant (verlangt Prozesstreue)
 * fachlich wenig geschätzt (Als Hilfe, ja, aber niemand reißt sich 
darum, mit ihm zu arbeiten)

(* Gute Programmiere machen x Zeilen am Tag. Schlechte 2x.

Ein guter Programmierer ist ein Dichter: Er kämpft um jedes Wort, um 
jede Formulierung, um die Ausdruckskraft zu maximieren)

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

Bruno V. schrieb:
> Stefan, ich habe großen Respekt vor Dir und Deinem (öffentlichen) Werk.

Das ist allerdings kein Produkt von Teamwork und auch sonst fachlich 
weit von meinem Job entfernt.

von Lu O. (oszi45)


Lesenswert?

Bruno V. schrieb:
> Ein guter Programmierer ist ein Dichter: Er kämpft um jedes Wort, um
> jede Formulierung, um die Ausdruckskraft zu maximieren)

Ein guter Programmierer arbeitet so, dass die SW in der Praxis gut 
verwendbar ist. Einer ist vor Jahren mit dem Flugzeug abgestürzt und hat 
sein Wissen mit ins Grab genommen. Da es NUR einen gab, war der Bestand 
der Firma in Gefahr!

von Max (bit8)


Lesenswert?

Lu O. schrieb:
> Bruno V. schrieb:
>> Ein guter Programmierer ist ein Dichter: Er kämpft um jedes Wort, um
>> jede Formulierung, um die Ausdruckskraft zu maximieren)
>
> Ein guter Programmierer arbeitet so, dass die SW in der Praxis gut
> verwendbar ist. Einer ist vor Jahren mit dem Flugzeug abgestürzt und hat
> sein Wissen mit ins Grab genommen. Da es NUR einen gab, war der Bestand
> der Firma in Gefahr!

Ich dachte, die einsamen Keller Lötkolben-, Tastentürhelden Zeiten seien 
vorbei.
Heute sollst Du den ganzen Tag in Meetings verbringen und am Ende des 
Tages kommt die KI zum Diktat und setzt die Software um.

Und am Ende des Tages hat man wie  die Sozialwissenschaftler sich das 
Geld durchs Reden verdient.

Das Denken überlassen wir der KI...

Beide Perspektiven haben ihre Berechtigung. Während Präzision und 
Ästhetik wichtige Aspekte der Softwareentwicklung sind, ist es ebenso 
wichtig, dass Software robust, wartbar und von mehreren Personen 
verständlich ist, um die Abhängigkeit von Einzelpersonen zu verringern 
und die Kontinuität der Softwareentwicklung zu gewährleisten.

Es scheint, dass in diesem Beitrag die Merkmale eines "guten" 
Programmierers diskutiert werden, sowie die potenzielle Arroganz, die 
einige talentierte Entwickler gegenüber weniger erfahrenen Kollegen oder 
solchen, die sich als "Wannabies" (Anfänger oder Möchtegern-Entwickler) 
erweisen, zeigen könnten.

Die vorgeschlagenen Merkmale eines "guten" Programmierers könnten sein:

    Effizienz: Die Fähigkeit, mit weniger Aufwand mehr zu erreichen.
    Selbständigkeit: Die Fähigkeit, selbstständig zu arbeiten und auch 
unter Druck oder mit begrenzten Ressourcen gute Ergebnisse zu erzielen.
    Genauigkeit und Präzision: Die Fähigkeit, sich um jedes Detail zu 
kümmern und den Code auf höchstem Niveau zu halten.
    Respektiertes Fachwissen: Die Anerkennung durch Kollegen und 
Fachleute aufgrund ihres Wissens und ihrer Fähigkeiten.
    Kollaborationsfähigkeit: Die Bereitschaft, anderen zu helfen und als 
Teammitglied effektiv zu arbeiten.

Die Erwähnung, dass gute Programmierer "sogar arrogant sein können", 
impliziert, dass sie sich aufgrund ihres Könnens ein gewisses Maß an 
Überlegenheit erlauben könnten, insbesondere gegenüber weniger 
befähigten Kollegen. Dies sollte jedoch nicht mit einer generellen 
Arroganz gegenüber ihren Kollegen oder dem Team verwechselt werden, da 
erfolgreiche Teams oft auf Zusammenarbeit und Respekt basieren.

Die Metapher, dass ein guter Programmierer ein Dichter ist, der um jedes 
Wort und jede Formulierung kämpft, um die Ausdruckskraft zu maximieren, 
betont die Bedeutung von Eleganz, Klarheit und Effektivität im Code. Es 
zeigt auch, dass Programmierung nicht nur eine technische Fähigkeit ist, 
sondern auch eine kreative Kunstform sein kann.

von Bruno V. (bruno_v)


Lesenswert?

Max schrieb:
> Die Erwähnung, dass gute Programmierer "sogar arrogant sein können",
> [...] insbesondere gegenüber weniger befähigten Kollegen.

Ich hatte "gegenüber weniger befähigten Kollegen" explizit rausgenommen. 
Das offenbart einen miesen Charakter. Und gute Leute haben das meist 
nicht nötig.

Ich meine eher die Arroganz, auf starre Prozesse oder Best Practices zu 
pfeifen, wenn sie offensichtlich ungeeignet sind. Beispielsweise ein 
einzelnes Goto zu verwenden, auch wenn der Projektleiter das kategorisch 
ausschließt. Oder Code zu reduzieren, obwohl nach LoC bewertet wird.

von Steve van de Grens (roehrmond)


Lesenswert?

Max schrieb:
> dass Programmierung nicht nur eine technische Fähigkeit ist,
> sondern auch eine kreative Kunstform sein kann.

Das ist es ganz sicher und genau deswegen fürchte ich nicht, von KI 
ersetzt zu werden.

von Oliver S. (oliverso)


Lesenswert?

Und jetzt kommt der Punkt, an dem geklärt werden sollte, was eigentlich 
„Programmieren“ ist, und auf welchem Level die Kunstform anfängt.

Und da sag ich mal, die eigentliche Codeerestellung ist Handwerk, die 
aber ganz sicher aus Indien an die KI verlagert werden wird. Die „Kunst“ 
wird woanders benötigt.

Oliver

von Steve van de Grens (roehrmond)


Lesenswert?

Oliver S. schrieb:
> die eigentliche Code-Erstellung ist Handwerk

Dazu gehört aber auch:
- Anforderungen verstehen
- Unklarheiten klären
- Lücken ergänzen
- Code und Schnittstellen testen
- Dokumentieren

Dafür wenden Programmierer erheblich mehr Zeit auf, als für das 
Schreiben von Quelltext. Kein mir bekannter Programmierer kommt um diese 
Aufgaben herum.

Bei QVC gab es vor einigen Jahren mal den Versuch, nur das reine Coden 
nach Indien auszulagern. Die haben so wenig mit gedacht, dass der 
Aufwand für die verbleibenden Aufgaben regelrecht explodiert ist und 
viele Korrektur-Runden gedreht werden mussten, was die Firma gar nicht 
gewohnt war.

: Bearbeitet durch User
von Michael B. (laberkopp)


Lesenswert?

Steve van de Grens schrieb:
> Bei QVC gab es vor einigen Jahren mal den Versuch, nur das reine Coden
> nach Indien auszulagern. Die haben so wenig mit gedacht, dass der
> Aufwand für die verbleibenden Aufgaben regelrecht explodiert ist

Das ist nicht nur die Erfahrung von QVC, sondern eigentlich jedem, der 
mal was nach Indien ausgelagert hat.

Inder heisst bei uns 'grosse Klappe, nichts dahinter'. Gute Inder sitzen 
längst in den USA oder GB. Ex-UdSSR hingegen sind gute Leute.

von Oliver S. (oliverso)


Lesenswert?

Steve van de Grens schrieb:
> Dafür wenden Programmierer erheblich mehr Zeit auf, als für das
> Schreiben von Quelltext.

Ok, das ist dann doch was anderes als das hier:

Bruno V. schrieb:
> Ein guter Programmierer ist ein Dichter: Er kämpft um jedes Wort, um
> jede Formulierung, um die Ausdruckskraft zu maximieren)

Wer da um jedes Wort kämpfen muß, ist wohl im falschen Job. Der Teil ist 
Handwerk.

Oliver

von Flo (sandiegoo)


Lesenswert?

Danke für die vielen Antworten. Nachdem sich das jetzt mehr in "Wer ist 
ein guter Programmierer" hinzieht wäre es wohl Sinnvoll den Thread zu 
schließen.

von Bruno V. (bruno_v)


Lesenswert?

Flo schrieb:
> Nachdem sich das jetzt mehr in "Wer ist ein guter Programmierer" hinzieht

eigentlich ist das die Quintessens der Frage: Sieh zu, dass der Code 
klar, lesbar, ausdrucksstark ist und Anfoderungen/Schnittstellen 
festgehalten sind. Jemanden ohne konkrete Mitarbeit den Code erklären 
ist so vergeblich wie jemanden "Mal in Word einarbeiten lassen".

von Ein T. (ein_typ)


Lesenswert?

Steve van de Grens schrieb:
> Bei QVC gab es vor einigen Jahren mal den Versuch, nur das reine Coden
> nach Indien auszulagern. Die haben so wenig mit gedacht, dass der
> Aufwand für die verbleibenden Aufgaben regelrecht explodiert ist und
> viele Korrektur-Runden gedreht werden mussten, was die Firma gar nicht
> gewohnt war.

Nach meiner Wahrnehmung ist das aber eher ein kulturelles Thema, man 
darf in diesem Kulturkreis sein Gesicht nicht verlieren. Sein Gesicht 
verliert man, wenn man seine Arbeit nicht richtig beherrscht oder macht, 
also nicht genau das implementiert, was in der Spec steht, oder einen 
Vorgesetzten, oder die Spec kritisiert. Aus diesem Grunde denken viele 
Menschen dort zwar mit, wollen aber nicht negativ auffallen und äußern 
daher weder Kritik, noch Vorschläge. Mit unserer Kultur, Fragen direkt 
zu stellen, Themen offen anzusprechen und erkannte Probleme 
möglicherweise sogar selbst und ohne Rücksprache zu lösen, wird man in 
Indien sehr schnell sehr unangenehm auffallen.

Das sollte man wissen, wenn man Arbeiten nach Indien auslagern möchte. 
Man kann das trotzdem machen, aber dann müssen die Specs absolut 
wasserdicht und vollkommen unmißverständlich ausformuliert sein, und 
zwar auch so, daß die Sprachbarrieren dabei keine Stolpersteine sein 
können. Denn das, was zuvor gesagt wurde, gilt natürlich nicht nur für 
die Coder, sondern auch für die Vorgesetzten: sie fragen im Zweifelsfall 
nicht nach, weil das hieße, daß sie ihren Job nicht können und deswegen 
ihr Gesicht verlieren.

von Manfred P. (pruckelfred)


Lesenswert?

Ein T. schrieb:
> Nach meiner Wahrnehmung ist das aber eher ein kulturelles Thema, man
> darf in diesem Kulturkreis sein Gesicht nicht verlieren.
> [..]
> Das sollte man wissen, wenn man Arbeiten nach Indien auslagern möchte.
> Man kann das trotzdem machen, aber dann müssen die Specs absolut
> wasserdicht und vollkommen unmißverständlich ausformuliert sein, und
> zwar auch so,

Diesem Irrglauben sind schon viele Firmen aufgesessen und haben Lehrgeld 
gelassen.

Ich hatte einen guten Draht zum Leiter Systemtest eines 
Telefonanlagenherstellers. Man hat lokal Mitarbeiter entlassen, "von 
oben verordnet" und Testaufgaben nach Indien gegeben. Das Ergebnis war 
eine Katastrophe.

Unser Partner in England hatte einen Techniker indischer Abstammung. War 
ein lieber Mensch, aber mit seinen Denkstrukturen bekam er Probleme der 
Anlagen nicht in den Griff. Es gibt auch andere Techniker begrenzter 
Kompetenz, aber Ranjit war irgendwie anders.

Für mich hat sich der Eindruck gebildet, dass Europäer und Inder nicht 
harmonieren.

von Joachim B. (jar)


Lesenswert?

Manfred P. schrieb:
> Für mich hat sich der Eindruck gebildet, dass Europäer und Inder nicht
> harmonieren.

die Inder schütteln auch immer den Kopf wenn sie ja meinen aber dann das 
ja nicht gilt.

: Bearbeitet durch User
von Marci W. (marci_w)


Lesenswert?

A. B. schrieb:
> Wenn dann zusätzlich von dem/den alten Hasen etwas boshaftigkeit
> hinzukommt und sie bestimmten Kram soundurchsichtig geschrieben haben

Gibt's solche Arschlöcher wirklich? Also in meinem Umfeld 
(SW-Entwicklung für Steuerungstechnik) gibt es auch Programmcode, bei 
dem man sich fragt, was beim Schreiben im Gehirn des Entwicklers 
vorgegangen sein mag.
Aber das ist in den wenigsten Fällen Absicht, sondern das schiere 
Unvermögen des Entwicklers, verständlichen Code zu schreiben (<grusel>, 
wenn ich dran denke, was ich da schon alles gesehen habe. Echt 
schlimm...)

ciao

Marci

von Marci W. (marci_w)


Lesenswert?

Lu O. schrieb:
> und hat
> sein Wissen mit ins Grab genommen. Da es NUR einen gab, war der Bestand
> der Firma in Gefahr!

Dann war er allerdins ein schlechter Programmierer!

ciao

Marci

von Steve van de Grens (roehrmond)


Lesenswert?

Marci W. schrieb:
> wenn ich dran denke, was ich da schon alles gesehen habe. Echt schlimm

Am schlimmsten finde ich meine eigenen Quelltexte, die ich vor vielen 
Jahren schrieb. Man lernt halt ständig dazu.

von Joachim B. (jar)


Lesenswert?

Steve van de Grens schrieb:
> Am schlimmsten finde ich meine eigenen Quelltexte, die ich vor vielen
> Jahren schrieb. Man lernt halt ständig dazu.

1. lernt man dazu
2. weiss man heute kaum noch warum man es damals so machte.

Ich schaute mir letztens meinen relokatiblen Code vom Sharp PC1500 an.
Es kab keinen Weg an den Programmcounter zu kommen, den brauchte man 
aber um mit branch +- und Return immer wieder zurück zu finden. Durch 
die Stackkorrektur und das ganze Programm blicke ich heute kaum noch 
durch.

von Marci W. (marci_w)


Lesenswert?

Steve van de Grens schrieb:
> Am schlimmsten finde ich meine eigenen Quelltexte, die ich vor vielen
> Jahren schrieb.

Geht mir auch so! Jugendsünden. Vergeben und vergessen ;-)

ciao

Marci

von Thomas W. (dbstw)


Lesenswert?

Steve van de Grens schrieb:
> Marci W. schrieb:
>> wenn ich dran denke, was ich da schon alles gesehen habe. Echt schlimm
>
> Am schlimmsten finde ich meine eigenen Quelltexte, die ich vor vielen
> Jahren schrieb. Man lernt halt ständig dazu.

Beim Corona-Lockdown habe ich mal die Zeit genutzt, aufzuraeumen und 
alte Disketten auszulesen.

Ist schon interessant wie man die Probleme vor 30 - 35 Jahren geloest 
hatte. Natuerlich waren die Probleme einfacher (man wollte einfach nur 
eine Rechnung schreiben), aber die Maschinen (z.b. mit Turbo-Pascal 3.0 
unter DOS) waren natuerlich dumm wie ein Stueck Brot (ach ja, Novell 
Netware war damals top of the line).

Ich finde ich war damals viel kreativer :-)

Was ich nie gemacht habe (jedenfalls willentlich): Selbst 
modifizierender Code.

Gruesse

von Marci W. (marci_w)


Lesenswert?

Thomas W. schrieb:
> Ich finde ich war damals viel kreativer :-)

Nun ja, Kreativität ist in bestimmten Bereichen reines Gift! :-) Oft 
sind die Quelltexte, die für mich schlimm aussehen, durchaus so kreativ, 
dass ich denke: "sowas Kompliziertes könnte ich gar nicht schreiben, da 
ich nicht so komplex denken kann und meine Gehirnleistung dafür nicht 
ausreicht".
Ist ernst gemeint! Mein Code ist dagegen eher primitiv. Aber dafür 
versteht in hoffentlich auch jeder, ohne Knoten im Gehirn zu kriegen.

ciao

Marci

von Rudi R. (rudi_r)


Lesenswert?

Marci W. schrieb:

> Nun ja, Kreativität ist in bestimmten Bereichen reines Gift! :-) Oft
> sind die Quelltexte, die für mich schlimm aussehen, durchaus so kreativ,
> dass ich denke: "sowas Kompliziertes könnte ich gar nicht schreiben, da
> ich nicht so komplex denken kann und meine Gehirnleistung dafür nicht
> ausreicht".
> Ist ernst gemeint! Mein Code ist dagegen eher primitiv. Aber dafür
> versteht in hoffentlich auch jeder, ohne Knoten im Gehirn zu kriegen.
>

Komplex ist ja was anderes als kompliziert. Es gibt Entwickler, die sich 
kompliziert ausdrücken. Oft ist es auch Faulheit. Ich habe mal 'ne 
Klasse mit über 3000 Zeilen eingedampft, dass es nur noch ca. 2000 
waren. Der Programmierer hat immer wieder den gleichen Kram programmiert 
(nur leicht abgeändert von Fall zu Fall), ihm kam aber nicht in den 
Sinn, mal 'ne Funktion zu extrahieren. Mein Refactoring war nicht mal 
besonders tiefgründig. Hätte ich mehr Zeit und Befugnisse in diesem 
Projekt gehabt (ich war da nur drei Wochen drin), hätte ich da noch mehr 
eingedampft. Und zumindest kann ich es über mich sagen: Bei mir entsehen 
solche Klassen gar nicht erst, da ich schon früh überlege, was ist denn 
der Boilerplate-Code hier und wo kann ich noch eine Funktion 
extrahieren.

Dadurch wird der Code überschaubarer, weniger kompliziert und kann damit 
eher für komplexere Sachverhalte ertüchtigt werden.

von Steve van de Grens (roehrmond)


Lesenswert?

Rudi R. schrieb:
> Komplex ist ja was anderes als kompliziert. Es gibt Entwickler, die sich
> kompliziert ausdrücken. Oft ist es auch Faulheit

Das stimmt. Wenn ich Zeit habe, überarbeite ich meinen ersten Entwurf 
nochmal, damit er besser lesbar ist. Manchmal wird er dadurch etwas 
länger, aber das ist egal.

> Dadurch wird der Code überschaubarer, weniger kompliziert und kann
> damit eher für komplexere Sachverhalte ertüchtigt werden.

Den Aspekt finde ich wichtiger, als die Anzahl der Zeilen oder 
raffinierte Tricks. Er ist meistens sogar wichtiger, als die 
Performance.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Rudi R. schrieb:
> Komplex ist ja was anderes als kompliziert.

Auf jeden Fall. Komplexität ergibt sich schlicht aus einer 
Problemstellung. Man kann nur auf bestimmte Art und Weise mit 
Komplexität umgehen und diese beherrschen. Kompliziert ist die Art und 
Weise wie man Dinge tut, das hat man selbst in der Hand. Kein Code muss 
kompliziert sein.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.