it-swarm.dev

Wie kann ich meinen Chef davon überzeugen, dass Qualität eine gute Sache im Code ist?

Mein Chef kam heute zu mir, um mich zu fragen, ob wir eine bestimmte Funktion in 1,5 Tagen implementieren könnten. Ich habe es mir angesehen und ihm gesagt, dass 2 bis 3 Tage realistischer wären. Dann fragte er mich: "Und wenn wir es schnell und schmutzig machen?" Ich bat ihn zu erklären, was er mit "schnell und schmutzig" meinte.

Es stellt sich heraus, dass er möchte, dass wir Code so schnell wie möglich schreiben, indem wir (zum Beispiel) Teile aus anderen Projekten kopieren und den gesamten Code einfügen Wenn Sie den Code-Behind der WebForms-Seiten hinter sich lassen, kümmern Sie sich nicht mehr um DRY und SOLID) und gehen Sie davon aus, dass der Code und die Funktionen niemals geändert oder modifiziert werden müssen. Was noch schlimmer ist, er möchte nicht, dass wir es nur für diese eine Funktion tun, sondern für alle den Code, den wir schreiben.

Wir können mehr Gewinn machen, wenn wir Dinge schnell und schmutzig machen. Kunden möchten nicht für Sie bezahlen, wenn Sie berücksichtigen, dass sich in Zukunft etwas ändern könnte. Der Gewinn für uns besteht darin, Code so schnell wie möglich zu liefern. Solange die Anwendung das tut, was sie tun muss, spielt die Qualität des Codes keine Rolle. Sie sehen den Code nie.

Ich habe versucht, ihn davon zu überzeugen, dass dies eine schlechte Denkweise als Manager eines Softwareunternehmens ist, aber er wollte einfach nicht auf meine Argumente hören:

  • Entwicklermotivation : Ich erklärte, dass es schwierig ist, Entwickler zu motivieren, wenn sie ständig unter dem Druck unrealistischer Fristen und Budgets stehen, sehr schnell schlampigen Code zu schreiben.
  • Lesbarkeit : Wenn ein Projekt an einen anderen Entwickler weitergegeben wird, ist sauberer und besser strukturierter Code leichter zu lesen und zu verstehen.
  • Wartbarkeit : Es ist einfacher, sicherer und weniger zeitaufwendig, gut geschriebenen Code anzupassen, zu erweitern oder zu ändern.
  • Testbarkeit : Es ist normalerweise einfacher, Fehler in sauberem Code zu testen und zu finden.

Meine Kollegen sind vom Standpunkt meines Chefs genauso verblüfft wie ich, aber wir scheinen ihn nicht zu erreichen. Er sagt immer wieder, dass wir durch schnellere Abwicklung mehr Projekte verkaufen, einen niedrigeren Preis für sie verlangen und gleichzeitig einen größeren Gewinn erzielen können. Und am Ende zahlen diese Projekte die Gehälter des Entwicklers.

Was kann ich noch sagen, damit er sieht, dass er falsch liegt? Ich möchte ihm Kopien von Peopleware und The Mythical Man-Month kaufen, aber ich habe das Gefühl, dass sie seine Meinung auch nicht ändern werden.

Viele von Ihnen werden wahrscheinlich etwas sagen wie "Lauf! Verschwinde jetzt !" oder "Ich würde aufhören!", aber das ist keine Option, da .NET-Webentwicklungsjobs in der Region, in der ich lebe, eher selten sind ...


Aktualisieren

Wow, ich hatte nicht erwartet, so viele Antworten zu bekommen. Vielen Dank für Ihre Beiträge und Ihre Meinung!

Wie einige der Antworten und Kommentare zeigen, spielen die Art des Unternehmens und die Art der Projekte in diesem Thema eine große Rolle. Ich habe hier einige Dinge in Kommentaren zu einigen Antworten erklärt, aber es ist wahrscheinlich besser, sie auch hier hinzuzufügen.

Das Unternehmen, für das ich arbeite, ist eher klein. Wir haben 4 Entwickler, 1 Designer, 1 Chef und 1 Alleskönner (die Frau des Chefs). Die Projekte, die wir durchführen, können in zwei Kategorien unterteilt werden:

  1. Kleinere Websites, die mit unserem eigenen CMS- oder E-Commerce-Framework erstellt wurden (65%)
  2. Mittelgroße Webanwendungen (35%)

Viele unserer Projekte sind zwar eher klein, bauen jedoch auf demselben System auf. Dieses System ist ungefähr 4 Jahre alt und die Codebasis ist gelinde gesagt unterdurchschnittlich. Es ist immer eine Angst, neue Funktionen hinzuzufügen oder Standardfunktionen für bestimmte Kunden zu ändern.

Eines der vom Chef gesetzten Ziele ist es, unseren Fokus auf die Produktentwicklung zu richten. Das bedeutet, dass wir größere Anwendungen entwickeln werden, die als Basis für andere Projekte dienen oder SaaS-ähnlich sind.

Ich stimme voll und ganz zu, dass schnelles und schmutziges Handeln die beste Lösung für bestimmte Projekte sein kann. Wenn Sie jedoch ein vorhandenes CMS erweitern, das von allen Sites verwendet wird, die Sie in den nächsten Jahren entwickeln werden, oder ein SaaS -Produkt von Grund auf neu erstellen), gibt es meiner Meinung nach bessere Ansätze.

191
Kristof Claes

Klingt nach meinem alten Job

Das passierte die ganze Zeit bei meinem alten Job. Ich bin damit einverstanden, dass der Verkauf alles antreibt. Der Shop-Manager (Skill-Set: 80% Umsatz 20% Grafik) hat die von den Kunden gewünschten Funktionen ständig unterboten. Ein 20-Stunden-Job würde zu einem 10-Stunden-Preis verkauft, weil der Kunde nicht bereit war, mehr zu zahlen, oder (ich glaube eher) der Verkaufsleiter nicht genug betonte The Value der Kunde war bekommen.

Der Vertriebsleiter zeigt häufig potenzielle Funktionen und Widgets an, die wir für verschiedene Kunden erstellt haben. Und natürlich würde er diese Funktion an den neuen Interessenten unterbieten, weil wir das Ding nicht wirklich neu codieren mussten ... alles, was wir tun mussten, war kopieren und einfügen den Code von einer anderen Website und fügen Sie ihn in diese Website ein. Wir hatten ihn bereits erstellt.

Nach mehreren Hin- und Her-Schreien von "Warum können Sie das nicht schneller erledigen ... Sie haben es bereits für Kunde x getan." und "Es dauerte nur 10 Stunden für den Kunden und wie kommt es, dass es für den Kunden 16 Stunden dauert?".

Wir haben den Verkäufer gefragt, was das Ziel sei. Er sagte, er solle so viele dieser Widgets wie möglich zu einem so günstigen Preis wie möglich verkaufen.

Wir haben ihm gesagt, dass wir ein Qualitätsgeschäft sind und Qualitätsarbeit leisten. Wir sagten ihm, dass er durch die Senkung des Preises tatsächlich den Wert unserer Arbeit verwässerte und dies, wenn der Kunde zu uns zurückkehrt, um neue Funktionen zu erhalten, die zuvor nicht entwickelt wurden (was bedeutet, dass die Option zum Kopieren und Einfügen von Site x nicht vorhanden war) 't there) sie würden die Preisgestaltung zurückschieben und der Verkaufsleiter würde unter dem Druck nachgeben.

Wir haben uns entschlossen, unsere Widgets so wie sie sind zu einem Premium-Preis zu bewerten. Änderungen wären extra. Wir haben das Management davon überzeugt, dass wir, wenn wir die Zeit haben, diese Widgets zu entwickeln, damit wir sie von unserer "Code Library" anstatt von anderen Websites abrufen können, sie allgemeiner erstellen können, damit wir sie buchstäblich plumpsen können Sie werden in 2 Stunden auf eine vorhandene Site übertragen und für 10 Stunden bezahlt.

Er fing an, sie "wie sie sind" mit Prämiengebühren für Änderungen zu verkaufen, und wir konnten sie in zwei Stunden einbauen und zum Laufen bringen. Wir haben auch damit begonnen, diese Widgets zu "nsere Website" hinzuzufügen, und haben die Verwendung der Websites anderer Kunden als Verkaufstools eingestellt. Wir würden nur die Websites anderer Kunden verwenden, um zu zeigen, wie das Widget " gegen eine geringe Gebühr " angepasst werden kann, um so zu handeln oder das.

Um unser Konzept zu beweisen, blieben wir (die Entwickler) einige Nächte nach der Arbeit, um ein generisches Widget zu erstellen, das in unsere Codebibliothek aufgenommen wurde. Das Leben wurde besser. Die Diskussionen haben sich geändert, von warum es so lange dauert bis ... " Hey, können Sie dieses Widget, das Kunde x möchte, weiterverkaufen? Wenn ja, welche Funktionen sollen wir hinzufügen? zum Grundmodell, um Ihnen beim Verkauf zu helfen. "

Ich habe gesehen, wie Unternehmen dies taten. Sie enden mit verärgerten Kunden. Kunden haben die Angewohnheit, wieder zu kommen und nach neuen Funktionen zu fragen, sobald die App Geld für sie verdient oder in ihren Geschäftsablauf integriert ist. Sie müssen diesen Kunden bald mitteilen, dass Sie dem von Ihnen erstellten Durcheinander keine neuen Funktionen hinzufügen können, da Sie die Codebasis nicht mehr verwalten können. Oder Sie brauchen viel mehr Zeit.

Kunden (auch in einer Wettbewerbssituation) neigen dazu zu reden. Entweder direkt, durch Mitarbeiter, die das Unternehmen wechseln, oder durch zufällige Besprechungen bei für ihre Branche typischen Veranstaltungen (Konferenzen, Ausstellungen). Sie werden sehr bald Schwierigkeiten haben, neue Kunden zu gewinnen, wenn Ihr Unternehmen einen schlechten Ruf hat.

Außerdem: Codierung von geringer Qualität funktioniert (wenn überhaupt) nur, wenn Sie Ihr Unternehmen auf sehr kleine Projekte beschränken. Alles, was größer oder komplexer ist, verliert sofort Zeit (und das für Geld), selbst innerhalb des ersten Live-Zyklus des Projekts, indem einfach mehr Zeit für das Debuggen aufgewendet wird als geschätzt.

54

Bringen Sie ihm technische Schulden bei

Was Sie tun müssen, ist, ihn die Konsequenzen der Entscheidungen, die er trifft, erkennen zu lassen. Schnell und schmutzig kann manchmal in Ordnung sein, weil Sie Dinge schneller erledigen können, aber es hat langfristige Konsequenzen.

Wenn zum Beispiel das Projekt niemals eine große Codebasis haben sollte, könnte schnell und schmutzig die vollkommen richtige Art sein, mit diesem Projekt umzugehen.

Ward Cunningham entwickelte die brillante Metapher "Technical Debt". So wie Sie vielleicht einen Kredit bei der Bank aufnehmen, um etwas schneller zu bekommen (anstatt zu sparen), müssen Sie langfristig mehr bezahlen, weil Sie Zinsen zahlen müssen. Dies kann eine gute Sache sein, wenn der Wert, Ihr "Ding" schneller zu bekommen, die Kosten des Interesses überwiegt.

Schnelle und schmutzige Lösungen sind wie Kredite in der Bank. Und wieder, wenn der Wert, eine Funktion früher zu erhalten, die Kosten für die anschließende Bereinigung überwiegt, könnte die Aufnahme des Kredits der richtige Ansatz sein.

Wenn Sie jedoch immer mehr Kredite bei der Bank aufnehmen, zahlen Sie am Ende Ihr gesamtes Zinseinkommen. Genauso wie bei technischen Schulden. Wenn Sie zu viele schnelle und schmutzige Lösungen gefunden haben, ist Ihre technische Verschuldung so hoch, dass Ihr Fortschritt zum Erliegen kommt.

Ich habe das gesehen. In einem Projekt, an dem ich gearbeitet habe, war die technische Verschuldung so hoch, dass wir 3 Monate lang keine ernsthaften Fortschritte hatten. Wir haben nur versucht, Fehler zu beheben, die neue Fehler usw. einführten.

Wenn Sie ihn dazu bringen können, das Konzept der technischen Verschuldung gründlich zu verstehen, sollte er in der Lage sein, die richtigen Entscheidungen zu treffen (viel Glück, es ist ein Knaller). Beachten Sie, dass die richtige Lösung gelegentlich auch schnell und schmutzig bedeutet.

Eine letzte Sache, auf die Sie hinweisen könnten, ist, dass Entwickler produktiver sind, wenn sie hoch motiviert sind;)

34
Pete

Die Kosten für Wartung sind oft viel höher und machen oft den größten Teil der Kosten für eine Software aus.

Wenn Sie schnell und schmutzig programmieren, wird die Wartung um eine Größenordnung schwieriger, und die Kosten sind ebenfalls hoch.

Wenn Sie Ihre gesamte Software schnell und schmutzig erstellen, wird sie beschissen und fehlerhaft sein und Ihre Kunden werden es bemerken. Wenn Ihre Produkte weiterhin beschissen und fehlerhaft sind, verlieren Sie sie auf lange Sicht. Kunden möchten Ihren Konkurrenten ein wenig mehr für ein Produkt von guter Qualität bezahlen, als unter Ihren Fehlern zu leiden.

Versteht Ihr Chef das nicht?

18
Jesper

In allen bis auf die seltensten Fälle können Sie jemanden nicht überzeugen (- === -), der wahnsinnig kurzsichtig ist, dass länger in unserem Beruf fast immer besser ist. Entschuldigung, aber das ist die Wahrheit; Kurzsichtige Menschen werden später alles opfern, um die Vorteile zu nutzen, und am Ende fast immer leiden.

Manchmal besteht die richtige Lösung darin, die Position an einen Ort zu ändern, an dem die Menschen klug genug sind, die Vorteile der Qualität zu verstehen und nicht kurzsichtig sind.

13
Wayne Molina

Hinweis: Für diese Antwort wird eine Geschäftskommunikationsstrategie verwendet, bei der versucht wird, mithilfe der Vernunft sicherzustellen, dass jeder das bekommt, was er will. Wenn das Problem einfach darin besteht, dass minderwertige Technik Ihren Lebenswillen beeinträchtigt oder Ihr Chef ein Sklavenfahrer ist und kein Ende in Sicht zu sein scheint, kann es tatsächlich Zeit für einen Szenenwechsel sein.

Sie sprechen nicht die Sprache Ihres Chefs. Ein Teil Ihrer Aufgabe besteht darin, Ihrem Chef Informationen zu geben, damit er Entscheidungen treffen kann, und Sie müssen Ihre Strategie zur Informationsvermittlung ändern. Sie sprechen in technischer Sprache, und was er hören muss, ist Risiko, Kosten, Investition und Rendite. Sie müssen auch ein bisschen defensiv sein und stellen Sie sicher, dass es eine gute Aufzeichnung darüber gibt, worüber Sie ihn informieren.

Das besteht aus zwei Teilen:

Das erste ist die Mitteilung Ihrer Schätzung und der Idee, dass es sich nicht um ein Ziel oder einen Plan handelt. Ich könnte hier Bände schreiben, aber es wäre im Grunde eine Kopie von allem in McConnells " Software Estimation: Demystifying the Black Art ", einem Buch, für das Sie zu Ihrem Buchladen laufen und nicht gehen sollten. Achten Sie darauf, zwischen Schätzungen, Zielen und Verpflichtungen zu unterscheiden, und stellen Sie sicher, dass Sie eine echte Schätzung vornehmen, bevor Sie sich zu etwas verpflichten!

Die zweite ist die Kommunikation der tatsächlichen Risiken, an denen Ihr Chef interessiert wäre. Einfach ausgedrückt bedeutet dies, dass Sie Ihrem Chef mitteilen müssen, dass die Implementierung, die in 1,5 Tagen abgeschlossen sein könnte, die grundlegenden Anforderungen erfüllt, aber das Risiko erheblich erhöhen, dass zukünftige Änderungen und Funktionen erheblich mehr Zeit benötigen, als es scheint. Wenn er nach dem Grund fragt, verwenden Sie die Hausbau-Analogie: Wenn Ihre Software ein Haus ist, ist jede Änderung ein neues Möbelstück, und jede Funktion ist ein neuer Boden. Wenn Sie nicht über ein starkes Fundament verfügen und jedes Mal, wenn Sie etwas tun, ein wenig umgestalten/renovieren, befinden Sie sich schließlich in einer Situation, in der ein umfassender Umbau erforderlich ist, um das Gewicht und die Größe einer neuen Fensterbehandlung zu unterstützen. und das ganze Haus muss wieder aufgebaut werden, wenn sie vier neue Stockwerke und ein Deck tragen wollen.

Dies bringt den Ball zurück in das Spielfeld Ihres Chefs - Sie haben ihm Informationen gegeben, und er muss sich entscheiden. Er muss darüber nachdenken, ob es in Zukunft Änderungen geben wird oder nicht und ob er die Möglichkeit ignorieren möchte oder nicht. Wenn von dort aus entschieden wird, dass schnell und von geringer Qualität der richtige Weg ist, stellen Sie sicher, dass Sie (taktvoll) Erinnerungen an diese Entscheidung in praktisch jede Art von Kommunikation und Dokumentation einfließen lassen, die Sie können. Senden Sie eine Folge-E-Mail, in der die Entscheidung und die von Ihnen mitgeteilten Risiken bestätigt und schriftlich festgehalten werden. Notieren Sie sich die Engineering-Strategie und die Risiken in Ihrer Spezifikation.

Wenn der Tag kommt, an dem der Kunde einen Pool in der 50. Etage haben möchte und Sie sehen, dass die letzten 20 Etagen mit Stöcken und Sand gebaut wurden, stellen Sie sicher, dass die große Fettschätzung, die Sie dafür produzieren, technisch vertretbar ist, und machen Sie sich bereit Rollen Sie die Papierspur von Niedrigbieterrechnungen aus, um zu veranschaulichen, warum dies so viel kosten wird.

10
nlawalker

Wenn Sie wirklich alle diese Argumente vorgebracht haben und er sie immer noch wegwischt, dann ist es Ihre Pflicht als Fachmann, dieses Anliegen auf eine höhere Instanz zu heben. Ja, das heißt über den Kopf gehen. Der Grund dafür ist einfach, dass Ihr Chef eine Gefahr für das Unternehmen darstellt.

Meine Erfahrung mit diesen Jungs ist, dass sie Ihre Organisation irgendwann zum Scheitern oder zumindest zur Mittelmäßigkeit führen werden. Ihr Produkt wird saugen und Ihre Kunden werden Sie verlassen.

Für die Aufzeichnung: Ich gehe davon aus, dass das Kerngeschäft des Unternehmens die Softwareentwicklung ist und das Produkt wichtig ist und nicht weggeworfen wird.

7
Martin Wickman

W. Edwards Deming ist am bekanntesten für seine Arbeit beim Wiederaufbau der japanischen Fertigung nach dem Zweiten Weltkrieg. Oft übersehen wird die Tatsache, dass es bei seiner Arbeit eigentlich mehr um Management als um Fertigung geht. Tatsächlich geht es in einem wichtigen Abschnitt seines Buches Out of the Crisis um die Verbesserung der Qualität in Serviceorganisationen. Zu seinen Beispielen für Dienstleistungsorganisationen gehören Software, Banken, Versicherungen und Kirchen.

Deming argumentiert - mit vielen realen Beweisen, die dies belegen -, dass eine Steigerung der Qualität den Gewinn steigert.

Sie können die Softwareentwicklung als Geschäftsprozess analysieren. Wie bei der Herstellung werden absichtliche, unbeabsichtigte, direkte und indirekte Produkte hergestellt.

Zu den beabsichtigten direkten Produkten der Herstellung und Programmierung gehören Wasserhähne und Quellcode. Zu den beabsichtigten indirekten Produkten gehören Schulden und Erträge.

Zu den unbeabsichtigten Produkten von Herstellungsprozessen gehören Wasserhähne mit Herstellungsfehlern, versehentlichen Bränden, Verletzungen, hoher Fluktuation und Mitarbeiterdiebstahl. Zu den unbeabsichtigten Produkten von Programmierprozessen gehören Fehler, Wartungsprobleme, Skalierbarkeitsprobleme, Sicherheitsprobleme, hohe Fluktuation und Mitarbeiterdiebstahl.

Jedes dieser "Produkte" unterliegt Variationen, statistischen Analysen und Prozessverbesserungen.

In Ihrem Fall müssen Sie wahrscheinlich die unbeabsichtigten Produkte Ihrer Softwareentwicklungs- und Projektmanagementprozesse aufzählen und quantifizieren.

Deming ist einer der Hauptgründe, warum Japan eine Weltmacht in der Fertigung ist. Der Deming-Preis ist nach ihm benannt.

Ja, das können wir heute gemeinsam hacken.

Wenn wir das so machen, wird es mehr Fehler als der Durchschnitt geben und die zukünftige Entwicklung ernsthaft beeinträchtigen. Das zusammen zu hacken ist wirklich etwas, was wir ein- oder zweimal tun können. Stellen Sie sich das als Wolkenkratzer vor, vielleicht haben wir bereits ein schönes Fundament, und wir haben 10 Stockwerke, die auch wirklich schön sind. Wenn Sie möchten, können wir schnell einige Zelte und Kisten in den 11. Stock zusammenschlagen und vielleicht sogar ein bauen 12. Stock aus Zelten und Kisten, aber Sie sind geschraubt, weil Sie darüber hinausgehen. Wir müssen alle aus diesen beiden Stockwerken herausholen, sie einrichten, alles neu trainieren und alles neu bauen, nur um den 13. Stock zu erreichen.

Wenn wir versuchen, aus Kisten und Zelten einen 13. Stock zu bauen, könnten wir zu jeder zufälligen Zeit drei Stockwerke einstürzen, und es könnte Monate dauern, bis wir die Jenga-Blöcke und das supergeklebte Duplo an den richtigen Stellen haben.

Ist das für dich akzeptabel?

4
Incognito

Ihr Chef könnte Recht haben. Ich kann mir Szenarien vorstellen, in denen diese Art der Codierung ausreichend ist. Angenommen, Sie schreiben Wegwerfskripte für eine Art Datenanalyse oder dinky Websites, auf denen Sie sich ein paar Seiten ansehen und sich ein Bild davon machen können, was los ist. Diese Art von Dingen muss nicht überarbeitet werden, da es unwahrscheinlich ist, dass sie beibehalten werden. Wenn wir das wollen, was die Kunden wollen, dann bekommen die Kunden das auch.

Jetzt könnte es auch sehr gut sein, dass Ihr Chef sich irrt und die Kunden schlecht funktionierende Produkte nicht schätzen. Dies ist meistens der Fall.

Es könnte auch eine Option sein, sich ein fröhliches Medium auszudenken. Die Hauptsache ist, wenn etwas nicht funktioniert, muss es sich ändern. Offensichtlich ist Ihr Chef nicht zufrieden damit, wie sich der Entwicklungsprozess auf das Geschäft auswirkt. Die Markteinführungszeit ist genauso wichtig wie die Produktqualität. Was Sie tun müssen, ist sicherzustellen, dass Ihr Team ein Qualitätsprodukt in einem Zeitraum produzieren kann, der die Marktfähigkeit des Produkts nicht zerstört. Wenn die Konstruktionsprinzipien korrekt angewendet werden, sollte dies die Produktivität eines Teams nicht beeinträchtigen. Wenn überhaupt, sollte die Verwendung solider Praktiken den Entwicklungsprozess beschleunigen UND die Qualität steigern.

4

Ich denke nicht, dass es möglich ist. Unterschiedliche Unternehmen haben unterschiedliche Kulturen, und wenn die Kultur Ihres aktuellen Unternehmens (schnell und schmutzig) nicht zu Ihnen passt, sollten Sie meiner Meinung nach weitermachen. Einige andere Unternehmen sind anderer Meinung und dort arbeiten Sie mit Menschen zusammen, die genauso denken wie Sie.

Ich möchte nicht wirklich in die Diskussion einsteigen, welche Art von Kultur besser ist (siehe die anderen Beiträge, wenn Sie interessiert sind). Ich sage nur, dass es für Ihre geistige Gesundheit von Vorteil ist, wenn Sie in einem Unternehmen mit derselben arbeiten Ansatz.

3
Grzenio

Ich habe alle Fragen durchgearbeitet und festgestellt, dass niemand in die Perspektive der Sicherheit gegangen ist ...

Ja, andere haben die Debug-Zeit erwähnt, aber das Debuggen erfolgt in diesem Fall nur bis zur Stufe "Hey, es funktioniert endlich".

In meinen Projekten (klein und/oder groß) lege ich großen Wert auf Exploits und mögliche Sicherheitslücken.

Diese zu berücksichtigen und zu testen, nimmt eine beträchtliche Zeit in Anspruch, aber zumindest auf diese Weise werden sie mich nicht beschuldigen, nicht das Beste zu tun, was ich konnte wenn etwas Schlimmes passiert.

Ich wette, wenn Sie schnell und schmutzig werden, vergessen Sie, einige Variablen zu bereinigen, einige Funktionen zu überprüfen und damit Ihr Projekt zu einem guten Ausgangspunkt für Hacker zu machen.

Wenn mein Chef fragt, warum ich so lange gebraucht habe, zeige ich ihm alle Sicherheits- und Funktionsprüfungen, die ich eingebaut habe, um Dinge wie Injektion, Inklusion, Endlosschleifen und sogar die Sicherheitsmaßnahmen zu verhindern, wenn etwas gehackt wird, verursacht es nur minimalen Schaden

3
HTDutchy

Dies mag offensichtlich erscheinen, aber ich denke, Sie müssen einen Mittelweg finden. Diskontieren Sie nicht die Haltung Ihres Chefs. Ihre Sicht darauf ist ihm wahrscheinlich genauso fremd wie seine für Sie.

Jedes Extrem ist offensichtlich für niemanden gut, also versuchen Sie, einen Mittelweg zu finden.

3
Gratzy

Wirf Mathe auf ihn. Leider habe ich nicht die Bücher zur Verfügung, um Zitate zu liefern (hoffentlich kann mir jemand helfen), aber einer oder beide von The Pragmatic Programmer und Code Complete 2 haben einen Abschnitt, der auf Studien verweist, die die Kostenauswirkungen einer schnellen Ausführung zeigen 'n' Dirty Way, anstatt sich Zeit zu nehmen, um es später zu beheben. Andere Poster haben viele Argumente geliefert, aber je nach Verhalten Ihres Chefs reagiert er möglicherweise viel besser auf die Unterstützung bestehender Studien. Er könnte denken, dass Sie nur toben, um Ihre Zeit zu puffern und Ihre eigene Arbeitsbelastung zu erleichtern. Ihm zu zeigen, dass es eine branchenübliche Tatsache ist, im Gegensatz zu nur Ihrer Meinung, könnte das Ticket sein.

2
asfallows

Ich bin irgendwie in einer ähnlichen Situation wie du. Ich arbeite für ein Dienstleistungsunternehmen und schreibe daher eine benutzerdefinierte Anwendung für verschiedene Kunden. Personen, die für die Bereitstellung der Anwendung verantwortlich sind (wie Projektmanager, Projektmanager usw.), kümmern sich wirklich nicht um die Codequalität (obwohl sie dies sagen). Sie kümmern sich nur darum, die Inhalte pünktlich bereitzustellen, damit sie die Leistung maximieren können profitieren. Ich werde ständig gebeten, innerhalb kurzer Zeit Features zu schreiben.

Eine Technik, mit der ich die Codequalität während der Einhaltung der Frist beibehalten habe, ist das kontinuierliche Refactoring. Wenn ich gebeten werde, Feature A in einem Tag zu schreiben, was tatsächlich 3 bis 5 Tage dauert, um mit hoher Qualität zu schreiben, mache ich einfach den schnellen und schmutzigen Weg und liefere. Aber während ich den schnellen und schmutzigen Weg mache, mache ich mir Notizen über den Bereich, der verbessert werden kann/sollte. Später im Entwicklungszyklus werde ich hier und da nur Teile von Zeitfragmenten finden, um meinen Code in Feature A umzugestalten.

Am Anfang war es eine schmerzhafte Erfahrung, meinen schnellen und schmutzigen Code umzugestalten. Ich erinnere mich an einige Fälle, in denen ich ein Feature während des Refactorings fast vollständig neu geschrieben habe. Aber als ich mehr und mehr umgestaltete, wurde mein schneller und schmutziger Code nicht mehr so ​​schmutzig. Ich fing an, ein besseres natürliches Gefühl für modulares Design zu entwickeln, so dass Codes, die ich schreibe, immer modularer werden, selbst wenn ich mich im schnellen und schmutzigen Modus befinde.

Es ist nicht falsch zu glauben, dass die Codequalität keine Rolle spielt, weil es für viele Menschen tatsächlich keine Rolle spielt. Wie interessiert Sie wirklich die Designqualität der Schaltung in Ihrem SONY-Fernseher, solange dieser ein schönes HD-Bild anzeigt und 5 bis 10 Jahre lang einwandfrei funktioniert?

Als Entwickler sollten Sie sich jedoch wirklich um die Codequalität kümmern, da Sie den Nutzen davon kennen. Es ist unwahrscheinlich, dass Ihr Chef seine Meinung zur Codequalität ändert, es sei denn, er erlebt einige Probleme, bei denen die Codequalität seinen Tag rettet oder wenn er persönlich den Zusammenhang zwischen Gewinn und Codequalität sieht.

Nur weil Ihr Chef keine Kenntnisse über die Codequalität hat, bedeutet dies nicht, dass Sie die Codequalität beeinträchtigen sollten (es ist jedoch immer noch eine gute Idee, den Kommunikationskanal mit Ihrem Chef über die Codequalität offen zu halten). Bemühen Sie sich, den Gleichgewichtspunkt zwischen Codequalität und Entwicklungsplan zu finden. Sie können keinen guten Qualitätscode für den aktuellen Zeitplan schreiben. Das bedeutet nicht, dass Sie die Qualität in den zukünftigen Zeitplänen nicht verbessern können, oder?

2
Alvin

Schnelle und schmutzige Dinge können Sie schon vor dem Mittagessen verlangsamen. Sehr oft tut es weh, noch bevor Sie über eine vollständige Funktion verfügen, um zu versuchen, sie von einem Kunden akzeptiert zu bekommen.

Vielleicht können Sie die Metapher der technischen Schulden ausprobieren, die Belastung durch Zinszahlungen wird nach einem bestimmten Zeitpunkt größer sein als das Einkommen.

Die Steuerung in Richtung eines Umschreibens ist auch eine Gelegenheit für Ihre Kunden, eine andere Entwicklungsfirma auszuprobieren (wenn wir von vorne anfangen sollen, könnten sie dies auch tun).

Wenn Sie keine alternativen Arbeitgeber in Ihrer Nähe haben, gibt es möglicherweise mehr als viele Kunden, die sich ebenfalls abnutzen müssen. Im Grunde kann Ihr Chef also weitermachen, was er tut, keine Konkurrenz, die es besser macht. Vielleicht ein eigenes Unternehmen gründen? ;-);

Alternativ könnten Sie ihm einfach sagen, dass Sie Dinge immer "schnell und schmutzig" machen und einfach Ihr eigenes Ding machen.

2
Joppe

Die bestmögliche Antwort wäre ein agiler Ansatz:

früh freigeben, häufig freigeben

Frühzeitig freigeben ist gut für Ihr Unternehmen, da Sie frühzeitig bezahlt werden. Der erste Release-Punkt ist, wenn Ihr Produkt über genügend Funktionen verfügt, sodass es zumindest in einigen Aspekten verwendet werden kann. Dies erhöht den Wert des Kundenunternehmens. Deshalb ist es klug, Modul für Modul zu entwickeln.

häufig veröffentlichen ist gut für Ihren Kunden, weil er früher bekommt, was er braucht. Ich habe absichtlich nicht schreiben wollen, weil das Endergebnis häufig von der Idee am Anfang abweicht.

Wenn nichts anderes, wird dies Ihre Kunden mehr zufriedenstellen, da sie sich stärker involviert fühlen und Sie Ihr Produkt Schritt für Schritt durchlaufen.

1
Robert Koritnik

Ich habe das starke Gefühl, dass Sie in diesem Fall nichts sagen können. Aber ein paar Punkte, die ich ansprechen möchte:

Das Beheben von Problemen dauert länger

Wenn Sie den gesamten Code kopieren und einfügen, dauert das Beheben eines Fehlers in diesem Code länger und das Testen länger. Daher verschwenden Sie zusätzliche Stunden in der Support-Phase (da ich vermute, dass Sie keine integrierte Testphase mit der Mentalität "Get it out the Door" haben) .

Das Hinzufügen einer neuen Funktion dauert länger

Das Hinzufügen einer neuen Funktion zum Spaghetti-Code dauert viel länger. Und weil es ein Durcheinander beim Kopieren und Einfügen ist, müssen Sie den Code an vielen Stellen optimieren. Dies wiederum führt an verschiedenen Stellen zu Fehlern oder unerwarteten Funktionen. Daher müssen Sie in der Support-Phase zusätzliche Stunden verschwenden.

Skinning UI-Elemente und Terminologie für neue Clients dauert länger

Firma, bei der ich gerade arbeite, ihr Web-Client war zunächst ein Durcheinander von Spaghetti-Code. Bevor ich anfing, dauerte es 2 Wochen, um den Web-Client für einen neuen Kunden zu häuten.

Nach mehr als ein paar langen Abenden dauert es jetzt einen Nachmittag. Ich arbeite immer noch daran, es so zu optimieren, dass es weniger Zeit braucht.


Wenn Ihr Chef ein Produkt, das einfach zu verkaufen ist, für verschiedene Kunden herstellen möchte, muss er die Zeit investieren, um sicherzustellen, dass Sie keine Zeit damit verschwenden, Ihr Produkt zu häuten, wenn Sie ihnen neue Funktionen verkaufen könnten.

Es wird schwierig, aber Sie müssen Ihrem Chef klar machen, dass Sie in Zukunft viel mehr Stunden mit Fehlern verschwenden werden, wenn Sie nicht einige Zeit damit verbringen, sicherzustellen, dass alles richtig gemacht wird, und dass Sie tatsächlich länger brauchen, um das Produkt zu erhalten bereit für einen neuen Kunden in der Zukunft.

Alles, was ihn interessiert, ist das Endergebnis. Sie müssen ihm also klar machen, dass das Codieren auf diese Weise nicht hilft und es nur behindert.

1
Tyanna