Sollten Sie eine gute Dokumentation und sauberen Code schreiben, um den „Bus-Faktor“ zu erhöhen?

Eines der Hauptziele von Softwareentwicklungsunternehmen ist die Erhöhung des Busfaktors. Dies wird auch in einem von Google organisierten Vortrag befürwortet .

Das bedeutet, dass Sie alles so codieren und dokumentieren sollten, dass das Projekt fortgesetzt werden kann, wenn Sie morgen mit dem Bus überfahren werden. Mit anderen Worten, Sie sollten sich leicht durch einen anderen Programmierer ersetzen lassen, der ähnliche Fähigkeiten wie Sie besitzt.

Austauschbar zu sein, widerspricht das nicht dem Interesse eines Entwicklers? In dem Buch heißt es in 48 Machtgesetzen in Regel 11, dass Sie versuchen sollten, die Menschen von Ihnen abhängig zu machen, um Macht zu erlangen, was sich dann in monetären Belohnungen niederschlägt.

Abgesehen von dem Szenario, in dem Sie einige Unterlagen für sich selbst benötigen, um ein Projekt nach 6 Monaten Pause fortzusetzen, scheint hier ein klarer Interessenkonflikt zwischen dem Entwickler und dem Softwareunternehmen zu bestehen.

Als Programmierer sollten Sie also wirklich hervorragende Dokumentationen und leicht lesbaren Code für alle schreiben. oder sollten Sie Code und Dokumentation so schreiben, dass sie die Aufgabe erfüllen und Sie sie selbst verstehen können, aber eine andere Person hat möglicherweise Probleme, sie zu verstehen?

Sie sollten versuchen, unersetzlich zu werden, indem Sie nicht Code schreiben, den niemand versteht, sondern indem Sie mehr Erfahrung und Wissen sammeln als andere. Der erste Weg macht Sie zu einem Entwickler, mit dem jeder nicht zusammenarbeiten möchte, da er befürchtet und es ablehnt, den von Ihnen geschriebenen Code zu pflegen. Auf diese Weise werden Sie zu einem gesuchten Teammitglied, das Manager in ihrem Team haben möchten.

Nach meiner Erfahrung hat sich das Schreiben von sauberem, gut dokumentiertem (und vorzugsweise selbstdokumentierendem) Code immer ausgezahlt. Tatsächlich nutzte ich fast jede Gelegenheit, um anderen zu helfen und sie zu unterrichten (und von ihnen zu lernen, wenn sie etwas besseres wussten), und ich fühlte mich kaum jemals in Gefahr, von jemandem ersetzt zu werden, der weniger fähig war als ich. Tatsächlich half dies normalerweise dem gesamten Team, besser zu arbeiten und Probleme schneller zu lösen, was der Traum eines jeden Managers ist - und ein vernünftiger Manager möchte nicht die Mitglieder eines guten Teams ersetzen.

Wenn Sie Organisationen oder Menschen so transparent manipulieren, sind sie besser dumm oder stecken in einem Stau, der ihnen keine andere Wahl lässt. Ein gut geführter Softwareentwicklungs-Shop würde sich Ihren undurchsichtigen Code und die fehlende Dokumentation ansehen und Sie einfach entlassen, bevor Sie viel Schaden anrichten könnten. Wenn sie schlecht laufen oder andere Entwickler nicht dazu bringen können, für sie zu arbeiten, warum möchten Sie dann eine Sinecure mit ihnen haben?

PS Weder Herr Greene noch Machiavelli haben tatsächlich viel erreicht, außer Bücher zu schreiben, die versuchten, möglichen "harten Männern" der Zeit zu schmeicheln. Nehmen Sie ihren Rat mit einem Körnchen Salz.

Wenn Sie unersetzlich sind, können Sie nicht befördert werden.

Sie wollen nicht unersetzlich sein. Sie möchten nicht, dass sich die Menschen von Ihnen abhängig fühlen, Sie möchten, dass sie Sie schätzen. Im Allgemeinen möchten Sie sich von Menschen fernhalten, die der Meinung sind, dass auch die Hälfte der Gesetze der Macht auf (berufliche oder persönliche) Beziehungen angewendet werden sollte.
Diese Regeln enthalten Anweisungen, wie eine Win-Lose-Situation erfolgreich hergestellt werden kann. Was Sie wollen, ist eine Win-Win- Situation.
Sobald die Leute anfangen zu fühlen, dass Sie versuchen, sie auf die Seite der Niederlage einer Win-Lose-Situation zu drängen, werden sie sich wehren. Versuche, Gewinn- und Verlustsituationen zu etablieren, führen häufig zu Verlusten, da Sie Ressourcen verschwenden, um Ihren Partner in eine Verlustposition zu bringen, anstatt ihn in den Gesamterfolg Ihrer Partnerschaft zu investieren.

Wenn Sie dies mit Ihren Arbeitgebern tun, werden diese versuchen, Ihnen Maßnahmen aufzuzwingen, um Ihr Wissensmonopol zu verringern. Meist handelt es sich dabei um lächerliche Richtlinien, wie Sie Ihre Arbeit verrichten müssen und damit Ihr Arbeitsleben in eine lebendige Hölle verwandeln. Außerdem rufen sie dich um 3 Uhr nachts an, wenn etwas kaputt geht, weil du die einzige Person bist, die es reparieren kann. Wenn Sie versuchen, Situationen wie Hebeleffekte auszunutzen, kann dies zu Fehlschlägen und Problemen führen.

Die Friedhöfe sind voller unverzichtbarer Männer.
- Gaulle, Charles De

Also schneiden Sie den Mist und machen Sie Ihre Arbeit richtig. Wenn nicht für irgendetwas anderes, dann für Sie, weil Sie wahrscheinlich die arme Seele sind, die in 2 Jahren einige Änderungen am Code vornehmen muss.

Die negativen Reaktionen sind angesichts der überdurchschnittlichen Anzahl von Programmierern, die diese Site anzieht, nicht allzu überraschend. Talentierte Menschen müssen im Allgemeinen nicht auf diese Art von Taktiken zur Absicherung durch Verschleierung zurückgreifen. Aber ich arbeitete bei einem Fortune 500-Automobilzulieferer mit einigen weniger talentierten Entwicklern, die sich kleine Lehen ausgedacht hatten, die sie eifrig bewahrten, indem sie umfangreiche Dokumentationen für die horrenden Schnittstellen erstellten, die sie entworfen hatten.

Die ganze Aufgabe eines Mannes bestand darin, den Code für ein Modul zu verwalten, das zwei völlig getrennte Subsysteme überbrückt und es den Modulen auf jedem System ermöglicht, über einen UART zu kommunizieren. Im Grunde war es die serielle Programmierung 101. Anstatt nur eine allgemeine Schnittstelle zu erstellen, die ungefähr so ​​aussah:

  int sendData (int targetModule, void * data, size_t byteCount);
  int recvData (int sourceModule, void * data, size_t maxBytes);

Er erstellte separate Opcodes für jede einzelne Nachricht , die zwei miteinander kommunizierende Module aneinander senden möchten. Das bedeutete, dass sein Modul über jede Nachricht Bescheid wissen musste und jedes Mal aktualisiert werden musste, wenn eine Nachricht hinzugefügt oder geändert wurde. Sprechen Sie über unangemessene Intimität!

Die Sache ist, dass dieser Typ ein Word-Dokument geführt hat, das alle Opcodes / Nachrichten ordentlich auflistet und es nach Bedarf sorgfältig aktualisiert. Es wurde sein ganzer Job . Einige Male in der Woche sandte er eine neue Revision an alle Menschen, die das Pech hatten, ihn auf ihrem kritischen Pfad zu haben. Und dies wurde als "professionell" angesehen, da das Management es liebte , Dokumentation zu sehen. Ein bisschen bringt mich dazu, für die Automobilindustrie zu weinen.

Ich denke, mein Punkt ist: Manchmal kann das Schreiben von Dokumentation mittelmäßige Programmierer schützen . Manager können oft nicht zwischen einem guten und einem schlechten Design unterscheiden, und viele sind gezwungen, technische Entscheidungen mit begrenzten Informationen zu treffen. Es ist unglaublich stressig für sie. Es kann sehr beruhigend sein, ein Word-Dokument mit Dutzenden ordentlich formatierten Tabellen zu sehen - auch wenn das, was darin beschrieben wird, eine grundsätzlich schlechte Idee ist.

Austauschbar zu sein, widerspricht das nicht dem Interesse eines Entwicklers?

Ich hasse es, es dir zu brechen, aber jeder ist austauschbar. Sicher, manchmal kann es eine leichte Herausforderung sein, Sie zu ersetzen (wenn Sie erfahren und klug genug sind), aber es ist Lichtjahre von unmöglich.

Der Weg, wirklich ein wertvolles Gut für Ihren Arbeitgeber zu sein (nicht nur der aktuelle Arbeitgeber, sondern jeder Arbeitgeber), besteht darin, die Fähigkeit zu demonstrieren, Code so einfach zu schreiben, dass jeder, der den Code liest, ihn lesen und dokumentieren kann (kurze Einarbeitungszeit) den Code (jeder kann sich einen Überblick über Ihre Systeme verschaffen, ohne sich mit Code befassen zu müssen).

Tatsächlich ist es heutzutage eine schwierige Aufgabe, eine gute Codedokumentation zu haben, sodass Sie sich von anderen abheben können.

Sauberer und gut dokumentierter Code ist es auch wert, in einen Lebenslauf aufgenommen zu werden (zumindest greifbare Ergebnisse davon, dh "wir konnten nneue Entwickler mit minimalem Ramp-Up und Unterstützung aufgrund meiner Dokumentation gewinnen"), bei dem es um Hinterlist geht selbst "unersetzlich" ist nicht.

Austauschbar zu sein, widerspricht das nicht dem Interesse eines Entwicklers?

Kommt darauf an, was die Interessen dieses Entwicklers sind. Wenn Sie eine Person sind, die es in einem einzigen Job für Ihre gesamte Karriere aushalten möchte, sind Sie für ein Unternehmen, das Inkompetenz belohnt und gutes Geld verdient, absolut unverzichtbar.

Aber was passiert, wenn die Firma zusammenbricht, wahrscheinlich weil sie zu viele solche Leute eingestellt hat? Wohin gehst du als nächstes? Was ist, wenn sie dich fragen, warum du 15 Jahre im selben Job geblieben bist? Und so weiter.

Betrachten Sie es jetzt anders: Wie viele Entwickler haben ihre Arbeit verloren, weil sie Code geschrieben haben, den jeder lesen kann?

Die einzige Wahrscheinlichkeit dafür besteht darin, dass das Unternehmen in Schwierigkeiten gerät und Mitarbeiter entlassen werden. In diesem Fall sollten Sie besser aussteigen und auf die bevorstehenden Interviews gut vorbereitet sein. Außerdem ist Ihr Gewissen völlig frei - Sie hinterlassen keinen unerklärlichen Code, den Sie zu Ihrem eigenen Vorteil geschrieben haben.

Ich weiß nicht, welche Art von Person Sie sind, aber das dient meinen Interessen besser.

Persönlich denke ich, dass eine meiner größten Stärken darin besteht, meinen eigenen Job zu automatisieren. Was glaubst du, neigt ein Unternehmen dazu, zu denken, wenn ich meine eigenen Anforderungen übererfüllt habe? Denken sie "ok, wir werden ihn jetzt los" oder denken sie "warum versetzen wir ihn nicht in eine andere Rolle und lassen ihn es wieder tun"?

Austauschbar zu sein, widerspricht das nicht dem Interesse eines Entwicklers?

Sie haben recht, aber ich denke, Sie haben die Bedeutung von austauschbar falsch verstanden. Ich konnte 1000 Entwickler finden, die hektischen Code schreiben, undokumentiert, der sich schnell in ein nicht zu wartendes Chaos verwandeln kann.

Ein Entwickler, der nicht nur stabile Programme, sondern auch sauberen Code erstellt, eine informative Dokumentation erstellt und die Kontinuität des Projekts sicherstellt, das ist nicht nur unersetzlich, sondern auch von unschätzbarem Wert .

Ich werde diese Frage aus einer anderen Perspektive angehen, da es bereits mehrere ausgezeichnete Antworten gibt.

Überlegen Sie, was passiert, wenn Sie kleine Spiele spielen, indem Sie versuchen, sich selbst "unersetzbar" zu machen, ohne dass andere Leute lernen, wie Ihr Code funktioniert. Sie bleiben im selben Job und pflegen Ihre eigenen Probleme, solange das Unternehmen Sie toleriert. Und das ist das beste Szenario, das schlechteste Szenario ist, dass andere, talentiertere und ethisch korrektere Ingenieure und Manager in Ihrem Unternehmen die Hindernisse sehen, die Ihre schlechten Praktiken dem Unternehmen auferlegen, und sie beschließen, etwas dagegen zu unternehmen: Sie zu entlassen und neu zu schreiben alles von Grund auf neu. Es wurde getan. In der Tat ist es eine ziemlich häufige Sache.

Überlegen Sie nun, was passiert, wenn Sie guten Code und gute Dokumentation schreiben. Sie erstellen eine Komponente oder ein System, das gut funktioniert, das nach einer Weile im Betrieb reibungslos funktioniert und kaum überprüft werden muss. Die Wartung ist mit geringem Aufwand verbunden. Sie können dann zu größeren und besseren Projekten übergehen und einen soliden Sieg verbuchen. Die Leute werden Sie für gute Arbeit anerkennen und Ihre Meinung respektieren. Sie haben die Möglichkeit, in der Nahrungskette aufzusteigen und aussagekräftigere Entscheidungen zu treffen, wichtigere und effektivere Arbeiten auszuführen oder Projekte auf einer höheren Ebene zu verwalten. Ihre Karriere wird sich verbessern, Sie werden befördert, Sie werden mehr Geld verdienen, Sie werden von Ihren Kollegen anerkannt und anerkannt, Sie werden mehr und mehr Erfolge von immer wichtigeren Projekten zu Ihrer Erfolgsbilanz hinzufügen.

Welche Route würdest du bevorzugen?

Wenn Sie die einzige Fehlerquelle sind, wird Ihr Kunde (oder Arbeitgeber) wahrscheinlich versuchen, Sie zu ersetzen. Es gibt immer einen Punkt, an dem es weniger kostspielig ist, Software zu ersetzen als zu warten, egal wie wichtig es scheint. Es gibt einen Grund, warum IT zu den auslagerungsfähigsten Berufen zählt.

Auf der anderen Seite bietet Ihnen der Austausch mehrere unschätzbare Vorteile:

• Urlaub machen können
• nicht auf Abruf sein
• Freiheit zu gehen und an einem neuen und spannenden Projekt zu arbeiten

Wenn Sie nicht 5 Minuten damit verbringen, eine kurze Dokumentation zu schreiben, müssen Sie eine Stunde lang nachlesen und den Leuten erklären, wann sie Ihren Code verwenden müssen.

Noch schlimmer könnte es sein, Tage auf der Suche nach einem neuen Job zu verbringen, da Ihr Chef herausgefunden hat, dass Sie keinen wartbaren Code schreiben.

Ausgezeichnete Dokumentation wird mit Refactoring / Evolutions irgendwann überholt sein, und es ist wirklich zeitaufwändig, sie auf dem neuesten Stand zu halten.

Clean Code + Unit Test> hervorragende Dokumentation

Die Antwort auf Ihre Frage lautet "Ja". Ja, Sie sollten eine gute Dokumentation und sauberen Code schreiben. Wenn man absichtlich etwas anderes tut, zeigt sich ein Mangel an Integrität, der, obwohl er in der Geschäftswelt zunehmend vorherrscht, nicht plötzlich eine "gute" Sache ist.

Niemand ist unersetzlich. Menschen, die eine Situation herstellen, in der sie glauben, sie seien geneigt, den schwierigen Weg herauszufinden, den sie nicht gehen. Das Herstellen einer Co-Abhängigkeit für sich selbst ist kontraproduktiv, da es Sie und nicht nur Ihren Arbeitgeber einschränkt.

Eines der Hauptziele von Softwareentwicklungsunternehmen ist die Steigerung ihres Busfaktors

Falsche Prämisse. Die Hauptziele eines Softwareentwicklungsunternehmens (jedenfalls jedes, bei dem ich gearbeitet habe) sind es, die bestmögliche Software zu entwickeln und Geld zu verdienen, nicht unbedingt in dieser Reihenfolge. Die Reduzierung des "Busfaktors" ist nur eine Möglichkeit, um Geldverluste zu vermeiden.

Gesetz 11 Lerne, Menschen von dir abhängig zu machen.

Was bedeutet das für dich?

Möchten Sie, dass sich die Menschen auf Sie verlassen, weil Sie sie so untergraben haben, dass sie nur mit Ihrer Hilfe vorankommen können? Oder möchten Sie, dass sich die Menschen auf Sie verlassen, weil Sie intelligent und aufschlussreich, zuverlässig, vertrauenswürdig und in der Lage sind, anderen zu helfen, ihre Arbeit auch besser zu machen? Möchten Sie, dass Ihre Kollegen ohne Ihre Hilfe schlecht aussehen, oder möchten Sie, dass sie Sie dafür schätzen, dass sie gut aussehen?

Es ist dein Anruf.

(unter der Annahme von Produktionscode)

Ich neige dazu, ein bisschen weiter zu gehen. Ich habe darüber geschrieben, Programme "idiotensicher" zu machen, aber ich qualifiziere das nicht immer: Ich schreibe viel Code, den andere Leute nicht sehen oder mit dem sie nicht arbeiten werden (zumindest ist dies die Erwartung, wenn es geschrieben wird). ichIch bin der Idiot, vor dem ich mich in diesem Fall zu verteidigen versuche. Es ist eine gute Sache, wenn Ihr Programm Probleme für Sie erkennt und das Problem so stark vereinfacht wurde, dass es offensichtlich ist, dass ein Fehler vorliegt und dessen Ursache. Die Wahrheit ist, dass Implementierungsdetails offensichtlich sind, wenn Sie ein Programm schreiben (es sei denn, Sie implementieren es vorzeitig), aber sie sollten für Clients abstrahiert und fehlerresistent sein (selbst wenn eine Modullokalität vorhanden ist). Der Grund dafür ist, dass Programme sehr komplex werden. Manchmal kann man Probleme trennen, aber nicht die ganze Zeit. Wenn Sie Ihre Komponenten sehr streng, einfach, gut gekapselt und idiotensicher halten, sind sie in der Regel gut skalierbar und die meisten Fehler werden vor dem Versand erkannt. Es ist einfacher, die Programme wiederzuverwenden, und Sie haben mehr Vertrauen und eine einfachere Zeit, die Programme wiederzuverwenden. Diese komplexen Programme, die Sie schreiben, werden erst nach einiger Zeit komplexer (auch für Sie). Wenn Sie es in 6 Monaten lesen, kann das Verstehen und Debuggen im Vergleich zur idiotensicheren Version absurd lange dauern. Wenn eine Komponente eine Unterbrechungsänderung einführt, kann sie ansonsten für eine lange Zeit unentdeckt bleiben. Programme sind komplex; Sie können dieser Realität nicht entkommen, aber Sie können sie idiotensicher machen, was Ihr Leben viel einfacher macht, wenn etwas schief geht oder wenn es wiederverwendet oder verändert werden muss. Daher bedeutet der idiotensichere Ansatz, dass Ihre Software auch von Ihren Junioren oder neueren Mitarbeitern im Team verstanden, wiederverwendet oder gewartet werden kann (nicht nur von jemandem, der so gut / erfahren ist wie Sie). Ersatz ist ein besonderes Anliegen: Wenn die Leute gerne mit Ihren Programmen arbeiten, leisten Sie gute Arbeit. Sorgen Sie sich nicht um Ersatz. Sicher, ich könnte mir Szenarien einfallen lassen, in denen unverständliche Programme Ihren Job retten könnten, aber das Schreiben eines guten Programms, das andere verwenden und warten können, ist eindeutig das geringere Übel (siehe die Resopns der anderen). Wenn ich mich dabei ertappe, etwas zu schreiben, das nicht idiotensicher ist, versuche ich, das zu beheben.

Abgesehen von dem Szenario, in dem Sie einige Unterlagen für sich selbst benötigen, um ein Projekt nach 6 Monaten Pause fortzusetzen, scheint hier ein klarer Interessenkonflikt zwischen dem Entwickler und dem Softwareunternehmen zu bestehen.

Sie haben wirklich keine Ahnung, was Sie manchmal gedacht haben, als Sie inaktive Implementierungen erneut durchgesehen haben. Wenn Sie wirklich erfahren sind, ist das Problem einfacher, weil Sie sich mehr auf etablierte Methoden oder Ansätze verlassen können, die Sie verwenden. Dies setzt jedoch voraus, dass diese Methoden unveränderlich sind. Auch wenn die Dokumentation nachlässt, müssen Sie in Ihren Implementierungen immer noch defensiv sein (z. B. wissen Sie besser, als in diesem Szenario NULL zu übergeben - testen Sie diese Bedingung).

Als Programmierer sollten Sie also wirklich hervorragende Dokumentationen und leicht lesbaren Code für alle schreiben. oder sollten Sie Code und Dokumentation so schreiben, dass sie die Aufgabe erfüllen und Sie sie selbst verstehen können, aber eine andere Person hat möglicherweise Probleme, sie zu verstehen?

Ich empfehle den idiotensicheren Ansatz, der noch klarer und fehlerresistenter ist als der Busfaktor-Ansatz. Schreiben Sie Ihre Programme und Dokumentationen so, dass sie von jemandem außerhalb des Projekts leicht verstanden werden - es ist auch gut für Sie. Dadurch erhöhen Sie Ihren Wert für Ihr Unternehmen und Ihr Team, sie möchten Sie nicht ersetzen.

Sie haben das Spiel grundlegend falsch verstanden. Das Spiel besteht nicht darin, weiterhin die alten Dinge zu tun, die Sie zuvor getan haben, sondern für den gesamten Code verantwortlich zu sein, den Sie geschrieben haben, weil ihn sonst niemand bekommt. Das Spiel besteht darin, ein Projekt abzuschließen und mit dem nächsten fortzufahren. Dabei bleibt Code übrig, den andere in Ihrer Abwesenheit leicht verstehen und bearbeiten können, sodass Sie neue Dinge tun und mehr und andere Aufgaben übernehmen können. Ihre Prämisse funktioniert nur, wenn Sie glücklich sind, immer wieder das Gleiche zu tun, ohne die Chance zu haben, etwas zu lernen oder sich zu verbessern.

Ich werde auch darauf hinweisen, dass Sie, wenn Sie nicht die Gelegenheit haben, sich diesen Code sehr oft anzuschauen, in sechs Monaten Probleme haben werden, ihn herauszufinden, wenn Sie ihn absichtlich verschleiern.

Ich dokumentiere den kleinen Code, den ich schreibe, nicht damit andere ihn lesen können, sondern damit ich ihn in 3 Monaten lesen kann! Es geht darum, die Wartung zu vereinfachen. Wenn Sie für den Code verantwortlich sind, den Sie geschrieben haben, und Sie keine Fehler beheben können, die später auftauchen, möchten Sie, dass er gut dokumentiert ist ... Es spielt keine Rolle, wie ersetzbar Sie sind, wenn Sie nicht in der Lage sind um deinen Job zu machen!

Jeder "unersetzliche" Computerfachmann, mit dem ich das Pech hatte, zu interagieren, wurde ersetzt, zum großen Teil, weil sie versuchten, die Ressourcen ihrer Arbeitgeber als Geiseln zu nehmen. Wenn mir Leute berichten, dass ihre Zeit zu wertvoll ist, um Dokumente zu "verschwenden", ersetze ich sie so schnell wie möglich.

Es scheint, dass wenn ein angehender Mitarbeiter die 48 Gesetze der Macht als ethisch oder moralisch akzeptabel ansieht, es Ihnen ohne sie besser geht.

Wenn Sie WIRKLICH unersetzlich sein möchten (was Sie vielleicht nach dem Lesen aller Antworten noch einmal überdenken möchten ...) - warum sollten Sie aufhören, den Code nicht zu dokumentieren?

Es gibt eine wirklich hervorragende Anleitung zum Schreiben von nicht wartbarem Code, die Sie unbedingt lesen sollten: http://thc.org/root/phun/unmaintain.html

Genießen! (Ich habe ganz sicher ...)