Ist "solange es funktioniert" die Norm? [geschlossen]

Siehe meine neuere Frage: Geht das Programmieren als Beruf im Wettlauf nach unten?

Mein letzter Laden hatte keinen Prozess. Agile bedeutete im Wesentlichen, dass sie überhaupt keinen Plan hatten, wie sie ihre Projekte entwickeln oder verwalten sollten. Es bedeutete: "Hey, hier ist eine Menge Arbeit. Mach es in zwei Wochen. Wir sind schnell und agil."

Sie haben Sachen veröffentlicht, von denen sie wussten, dass sie Probleme hatten. Es war ihnen egal, wie die Dinge geschrieben waren. Es gab keine Codeüberprüfungen, obwohl es mehrere Entwickler gab. Sie haben Software veröffentlicht, von der sie wussten, dass sie fehlerhaft ist.

Bei meinem vorherigen Job hatten die Leute die Einstellung, solange es funktioniert, ist es in Ordnung. Als ich nach einer Neufassung eines Codes fragte, den ich geschrieben hatte, als wir uns im Wesentlichen mit der Spezifikation befassten, lehnten sie dies ab. Ich wollte den Code umschreiben, da der Code an mehreren Stellen wiederholt wurde, es keine Kapselung gab und die Leute lange Zeit brauchten, um Änderungen daran vorzunehmen.

Mein Eindruck ist also im Wesentlichen: Die Programmierung läuft auf Folgendes hinaus:

1. Lesen Sie ein Buch über die neuesten Tools / Technologien
2. Zusammenfassen von Code auf dieser Basis, um das Schreiben von individuellem Code zu vermeiden, da das Unternehmen keinen "benutzerdefinierten Code beibehalten" möchte
3. Zeigen Sie es und fahren Sie mit dem nächsten Schritt fort, "solange es funktioniert".

Ich habe mir immer gesagt, dass ich beim nächsten Job einen besseren Laden bekomme. Das passiert nie. Wenn dies der Fall ist, fühle ich mich fest. Die Technologien ändern sich immer; Wenn die einzige berufliche Entwicklung darin besteht, das neueste MS Press-Technologiebuch zu lesen, was haben Sie in 10 Jahren aufgebaut, aber oberflächliches Wissen über verschiedene Technologien? Ich mache mir Sorgen um:

1. Der beste Weg, professionelle Standards zu haben
2. Wie man in dieser Situation aussagekräftiges Wissen und Erfahrung entwickelt

Sie sind indirekt auf das gestoßen, was meiner Meinung nach der Schlüssel zu einem guten Entwickler ist : die Balance zwischen " solange es funktioniert " und ausgereiftem, elegantem Code.

Genau wie in der Politik ist es viel einfacher, Ihre Position an einem Ende des Spektrums abzustecken, als eine differenzierte Position in der Mitte einzunehmen. Die Mehrheit der Entwickler, denen ich begegne, fällt in eine von zwei Kategorien: Codierung von Cowboy-Hacks und Architektur-Astronauten. Ich versuche ein Gleichgewicht zwischen den beiden zu finden. Es ist nicht so einfach, wie es sich anhört.

Um Ihre Frage direkter zu beantworten: Ja, ich denke, "solange es funktioniert" ist oft die Norm. Aber sehen Sie es anders: Sie sind in einer hervorragenden Position, um Ihre Kollegen aufzuklären und einige bessere Praktiken vorzustellen. Aber gehen Sie nicht ins Extreme und denken Sie daran, warum wir das alle tun: um die Probleme unserer Kunden zu lösen.

>> Bei meinem vorherigen Job hatten die Leute die Einstellung, solange es funktioniert, ist es in Ordnung.

Vielleicht bin ich hier eine Minderheit, aber ich bin der festen Überzeugung, dass es klare Beweise dafür geben sollte, warum wir dies brauchen, um etwas umzuschreiben. Und ich meine nicht so etwas wie "uf, ich mag nicht, wie es codiert wurde" - jeder Entwickler hat seine Vorlieben für den Code. Es sollte einige Probleme mit dem Teil geben, den wir umschreiben möchten:

• Leistungsprobleme
• Es wurden mehr Fehler gefunden als in anderen Teilen des Systems
• Entwickler verbringen mehr Zeit damit, an diesem Teil zu arbeiten
• etc.

Agile ist nicht dafür verantwortlich, dass ein Mensch sich entscheidet, fehlerhafte Software zu veröffentlichen. Menschen sind.

Das heißt, Sie legen großen Wert auf Qualität, und es ist gut. Ich bin mir sicher, dass Sie ein Perfektionist sind und sich Sorgen um Ihren eigenen Wert machen, wenn Sie nicht mit den neuesten Technologien Schritt halten.

Das Problem ist, dass Perfektionismus zu Aufschub und Aufschub zu Mittelmäßigkeit führt .

Aus diesem Grund wird das Geschäft Prioritäten in Sachen Time-to-Market setzen und Agile einsetzen , um Werte schnell und in vorhersehbarem Tempo zu liefern.

Da Sie die Geschäftsstrategie Ihres Unternehmens nicht beschrieben haben, sollten Sie zunächst Ihren Managern Fragen dazu stellen.

Indem Sie sich an ihren Zielen und Plänen ausrichten (sie haben Sie beauftragt, ihnen beim Erreichen dieser Ziele zu helfen), können Sie besser verstehen, wie Sie dazu beitragen können, anstatt sich auf Ihre eigenen und persönlichen Ziele zu konzentrieren.

Ich bin sicher, wenn Sie versuchen, understandihren Wert zu nutzen, können Sie Ihren Wert teilen, und das ist der Beginn einer fruchtbaren Zusammenarbeit.

Und wenn Sie feststellen, dass sie nicht wissen, was sie tun, können Sie nur aufhören .

Es hängt alles davon ab, was Sie bauen. Wenn Sie eine Microsite erstellen, die nur für einen Monat online ist, und Sie neun Tage Zeit haben, um sie zu erstellen: Ja, solange es funktioniert, reicht es aus.

Wenn Sie die Fly-by-Wire-Algorithmen für das FA-18-System schreiben, ist es besser, sie so perfekt wie möglich zu erstellen.

So wie es bei den meisten technologischen Antworten der Fall ist ... kommt darauf an.

Es kommt auf das Unternehmen an. Viele Unternehmen haben jedoch ernsthaften Wettbewerbs- und Zeitdruck. Das ist ein typischer Grund. Eine andere wäre eine große Arbeitsbelastung, möglicherweise ohne genügend Personal. (Es gibt einige sehr gute Gründe, unterbesetzt zu sein, die nicht unbedingt die Schuld des Unternehmens sind.) Allerdings konnten einige Unternehmen den Weg aus einer nassen Papiertüte nicht finden.

Ich denke die 80/20 Regel gilt hier. Grundsätzlich müssen Sie sich mit den beschissenen 80% abfinden und sich in die 20% hineinarbeiten. Beachten Sie jedoch, dass auch sie Kompromisse eingehen müssen. In der Wirtschaft spielt es normalerweise keine Rolle, dass Sie es absolut richtig haben. Es ist wichtig, dass Sie es jetzt haben.

Wenn die einzige berufliche Entwicklung darin besteht, das neueste MS Press-Technologiebuch zu lesen, was haben Sie in 10 Jahren aufgebaut, aber oberflächliches Wissen über verschiedene Technologien?

Das wäre ziemlich bescheuert, aber in diesem Jahrzehnt gab es möglicherweise einige spektakuläre Misserfolge. Ich habe viele Orte gesehen, an denen ich mich an bestimmte Dinge erinnern kann, die ich an meiner Arbeit dort mochte oder die mir nicht gefielen, und die ich daher in Frage stellen würde, wenn ich sie wieder an meinem neuen Arbeitsplatz hätte. Manchmal gibt es die neue Vorgehensweise, die man ausprobieren sollte, wenn ein Unternehmen versucht, Scrum zu implementieren oder einen Test-Driven Development-Ansatz zu verwenden. Dies sind möglicherweise Gelegenheiten, die jedoch nicht unbedingt als berufliche Entwicklung angesehen werden, da dies nicht in einem formellen Klassenzimmer stattfindet.

Ich kenne verschiedene Orte, an denen das "solange es funktioniert" gemeinsam mit verschiedenen Cowboy-Codierungsstrategien üblich ist. In ein paar Start-ups habe ich diese Art von Mentalität gesehen, die sinnvoll sein kann, wenn das Unternehmen so jung ist, dass es immer noch versucht, die Idee herauszuspülen, was es wirklich zu tun versucht. In anderen Unternehmen, in denen ich gearbeitet habe, gab es mehr Prozesse und eine Reife, die recht gut sein kann, aber nicht unbedingt leicht zu finden ist, fürchte ich. Einige Orte hatten Prozesse, die ich sehen und gehen musste: "Ich mag das. Ich werde das für spätere Arbeitssituationen in Erinnerung behalten", und andere, wo ich hingehen würde: "Ich mag das wirklich nicht. Ich werde es bemerken um dies in Zukunft zu vermeiden. "

Ich arbeitete eine Weile in einem Geschäft wie diesem, gerade an dem Punkt, an dem es sie einholte. Es gab zwei oder drei Jahre alte Anwendungen mit bekannten Fehlern, die buchstäblich nicht behoben werden konnten. Stellen Sie sich eine 4.000 Zeilen lange Schleife mit einer laufenden Berechnung für Layoutbreiten und -höhen vor. Das Reparieren eines Codeteils zur Behebung eines Problems in einer Instanz würde zu zwanzig Problemen an anderer Stelle führen, da frühere Entwickler ähnliche Probleme durch willkürliche Anpassung der Berechnungsergebnisse mit magischen Zahlen behoben hatten. Der Code konnte nicht als etwas anderes als giftig beschrieben werden.

Endlich wurde mir ein neues Projekt übergeben, von dem mein Chef sagte, ich könne diesen vorhandenen Code verwenden, um mit Layouts umzugehen. Irgendwie überzeugte ich ihn, dass ich es "ändern" sollte, damit er mir etwas mehr Zeit gab. Ich nutzte die Zeit, um stattdessen eine gut gestaltete Bibliothek zu schreiben, die das Layout unterstützt. Die Lösung von Fehlern in diesem neuen Projekt hat buchstäblich 10 Sekunden gedauert. Ich konnte Probleme identifizieren, bevor ich mir den Code ansah, um festzustellen, was schief gelaufen ist.

Ich dachte, dies würde einen Wendepunkt für meinen Manager bedeuten, aber alles, was ich bekam, war ein Klopfen auf den Rücken.

Seitdem arbeite ich für einen anderen Laden und hier ist es besser. Der Punkt ist, Sie können ihre Meinung nicht ändern. Geh einfach woanders arbeiten.

Ich habe immer noch die Hoffnung, dass es in der Wirtschaft eine Art Evolutionsprozess gibt, der solche Unternehmen früher oder später aus dem Geschäft wirft. Aber vielleicht bringt das hohe Tempo des technologischen Fortschritts zu viele neue Nischen hervor, sodass selbst schwache Konkurrenten immer noch genug "Lebensmittel" finden können.

Wenn Sie Ihre Chancen erhöhen möchten, an einem guten Ort zu arbeiten, suchen Sie nach einem Unternehmen, dessen Produkte an viele Kunden verkauft werden, anstatt alle paar Wochen etwas Neues zu schreiben. Es sollte mehr Interesse geben, eine gute Codebasis zu haben und neue Funktionen hinzuzufügen, ohne den vorhandenen Code ständig zu beschädigen.

Erinnert mich an meinen Hauptkollegen vom College. Er besuchte eine VLSI-Designklasse und fand für seine ersten Hausaufgaben ein Bauteil, das in der Größenordnung von Mikrometern Breite und einer Meile Länge lag. Die Simulationen verliefen einwandfrei.

Seine Antwort an seine Kritiker lautete: "Ich weiß nur, dass meine Scheiße funktioniert."

Eine recht gute Norm ist das Pareto-Prinzip

Ich habe Erfahrung aus einem Projekt mit 80-20 Regel und es hat sehr gut funktioniert. Ich denke, Antworten auf diese Frage "Wo ziehen Sie die Grenze für Ihren Perfektionismus?" Können ebenfalls hilfreich sein.

Der Begriff "Pareto-Prinzip" kann sich auch auf die Pareto-Effizienz beziehen. Das Pareto-Prinzip (auch als 80-20-Regel bekannt, das Gesetz der Lebensnotwendigen und das Prinzip der Faktor-Sparsity) besagt, dass bei vielen Ereignissen etwa 80% der Auswirkungen auf 20% der Ursachen zurückzuführen sind. Der Denker der Unternehmensführung, Joseph M. Juran, schlug das Prinzip vor und benannte es nach dem italienischen Ökonomen Vilfredo Pareto, der 1906 feststellte, dass 80% des Landes in Italien im Besitz von 20% der Bevölkerung waren. Er entwickelte das Prinzip, indem er beobachtete, dass 20% der Erbsenschoten in seinem Garten 80% der Erbsen enthielten. Im Geschäftsleben ist dies eine gängige Faustregel. zB "80% Ihres Umsatzes kommen von 20% Ihrer Kunden". Mathematisch gesehen muss, wenn etwas unter einer ausreichend großen Gruppe von Teilnehmern geteilt wird, eine Zahl k zwischen 50 und 100 vorliegen, so dass "k% von (100 - k)% der Teilnehmer genommen wird". Die Anzahl k kann von 50 (bei gleicher Verteilung, dh 100% der Bevölkerung haben gleiche Anteile) bis fast 100 (wenn eine kleine Anzahl von Teilnehmern fast die gesamte Ressource ausmacht) variieren.Die Zahl 80% ist mathematisch nichts Besonderes, aber viele reale Systeme haben irgendwo in dieser Region ein mittleres Ungleichgewicht in der Verteilung. Das Pareto-Prinzip ist nur tangential mit der Pareto-Effizienz verbunden, die ebenfalls von demselben Ökonomen eingeführt wurde. Pareto entwickelte beide Konzepte im Kontext der Einkommens- und Vermögensverteilung in der Bevölkerung.

Link zur Quelle

Als ich nach einer Neufassung eines Codes fragte, den ich geschrieben hatte, als wir uns im Wesentlichen mit der Spezifikation befassten, lehnten sie dies ab. Ich wollte den Code umschreiben, da der Code an mehreren Stellen wiederholt wurde, es keine Kapselung gab und die Leute lange Zeit brauchten, um Änderungen daran vorzunehmen.

Nichts für ungut, aber als Manager habe ich diese Aussage irgendwo gelesen:

"Als ich darum bat, zweimal bezahlt zu werden, um einen Code umzuschreiben, den ich bereits geschrieben habe, wollte meine Firma nicht bezahlen. Ich wollte das zusätzliche Geld, um das Durcheinander zu beseitigen, das ich beim ersten Schreiben gemacht habe, und mein Kollegen waren sauer auf mich, weil sie ihr Leben schwer gemacht haben. "

Wenn es sich um Ihren eigenen Code handelt, über den Sie sich beschweren, haben Sie nicht viel zu tun.

AKTUALISIEREN

Ich verstehe, dass dieser POV unbeliebt ist. Aber ich glaube auch nicht, dass dies in Widerspruch zu den Verantwortlichkeiten und Einstellungen eines professionellen Entwicklers steht.

Wenn Sie zunächst sauberen Code schreiben (und es gibt eine Vielzahl von Gründen dafür - unabhängig davon, ob Sie glauben, dass Ihr Code in der Produktion verwendet wird oder nicht), tritt dieses Problem viel seltener auf.

Wenn Sie sauberen Code und Refactoring-Zeit in Ihre Schätzungen einbeziehen, haben Sie auch den Zeitplan, um die Codebasis sauber zu halten. Wenn Sie aufgrund des Termindrucks nicht die erforderliche Zeit haben, sollten Ihre künftigen Schätzungen aufgrund des Umgangs mit den entstandenen technischen Schulden steigen.

Ihre zukünftigen Schätzungen (oder Ungewissheiten in Bezug auf Ihre Schätzungen) geben Ihnen die Möglichkeit, sich für ein Umschreiben einzusetzen (wenn Ihr Manager Sie bittet, den Prozess zu beschleunigen). Wenn nicht, akzeptieren Sie, dass das Unternehmen Ihren Kostenvoranschlag akzeptiert hat und lieber die laufenden Kosten als einen Ersatz übernimmt. Das ist eine rein geschäftliche Entscheidung - keine technische.

Denken Sie daran, die Zeit zum Aushandeln von Zeitplänen liegt vor dem Schreiben des Codes - nicht danach. Nachdem der Code geschrieben wurde (und "funktioniert"), möchten Kunden, Manager und Führungskräfte keine weitere Rechnung für "Wartung" sehen, die sich den ursprünglichen Kosten nähert oder diese übersteigt. Wenn Ihnen das Geschäft so am Herzen liegt, wie Sie es für richtig halten, können Sie es jederzeit umschreiben - genau darum bitten Sie das Geschäft.

Aus der Sicht Ihres Managers bringt Sie der Zeitplan für das Umschreiben dazu, seinen Arsch aufs Spiel zu setzen. Wenn Sie nicht liefern oder die Produktivität um so viel steigern, wie Sie sagen, dann ist er derjenige, der die Tasche in der Hand hält. Im Vergleich zu der relativ geringen Unannehmlichkeit, Ihnen zuzuhören, raten Sie, welche er bevorzugen wird.

Wenn Sie einen solchen Job bekommen, konzentrieren Sie sich einfach darauf, jedes Mal besseren Code zu schreiben, anstatt zurückzugehen und alten Code neu zu schreiben. Es gibt noch einen Qualitätsbereich, in den Sie beim Zusammenkleben von Paketen von Drittanbietern einsteigen können.

Wenn Sie Zeit haben und den Code einer vorhandenen, von Ihnen verwalteten Komponente verbessern möchten, können Sie dies nicht einfach tun, ohne um Erlaubnis zu bitten, solange das funktioniert, was Sie tun? Berücksichtigen Sie die Zeit in Ihren Schätzungen für das nächste Projekt, in dem die Komponente verwendet wird.

Wenn Sie bei der Programmierung auf niedrigerer Ebene keine Lernzufriedenheit mit Ihrer Arbeit erzielen können, ist es vielleicht an der Zeit, sich ein Open-Source-Projekt anzusehen?

q303, Ich fand Ihre Frage interessant und fand, dass Sie diese Frage des Programmierers vielleicht lesenswert finden, wie Sie Manager davon überzeugen können, dass Entwickler technische Probleme angehen .

Ich denke allgemein, ja, das ist die Norm. Verstehen Sie, dass funktionierende, aber nicht optimale Software viel besser ist als nicht funktionierende Software. Es gibt auch das Argument, dass die Definition von "Arbeiten" auf der Grundlage der Wahrnehmung und der Vorurteile jedes Einzelnen variieren könnte. Wenn Sie ein neues System implementieren, gibt es immer jemanden, der sagt, das alte System sei besser. Und wenn Sie mit einem Entwickler sprechen, wird er oder sie wahrscheinlich nur ungern zugeben, an beschissener Software gearbeitet zu haben.