kutombawewe.net

Wie balancieren Sie in Ihrer täglichen Arbeit zwischen "Mach es richtig" und "Mach es so schnell wie möglich"?

Ich denke immer wieder über diese Frage nach. Ich möchte die Dinge richtig machen: sauberen, verständlichen und korrekten Code schreiben, der einfach zu warten ist. Am Ende schreibe ich jedoch Patches über Patches. Nur weil es keine Zeit gibt, Kunden warten, ein Fehler über Nacht behoben werden sollte, das Unternehmen Geld für dieses Problem verliert, ein Manager hart drängt usw. usw.

Ich weiß ganz genau, dass ich langfristig mehr Zeit mit diesen Patches verschwenden werde, aber da diese Zeit Monate der Arbeit umfasst, kümmert es niemanden. Außerdem sagte einer meiner Manager immer: "Wir wissen nicht, ob es eine langfristige Situation geben wird, wenn wir sie jetzt nicht beheben."

Ich bin sicher, dass ich nicht der einzige bin, der in diesen endlosen realen/idealen Auswahlzyklen gefangen ist. Wie gehen Sie, meine Programmierkollegen, damit um?

UPDATE: Vielen Dank für diese interessante Diskussion. Es ist traurig, dass so viele Menschen täglich zwischen einer Quantität und einer Qualität ihres Codes wählen müssen. Trotzdem denken überraschend viele, dass es möglich ist, diesen Kampf zu gewinnen. Vielen Dank für diese Ermutigung.

183
Flot2011

Eigentlich ist dies eine sehr schwierige Frage, da es keine absolut richtige Antwort gibt. In unserer Organisation haben wir bessere Prozesse eingerichtet, um besseren Code zu erstellen. Wir haben unsere Codierungsstandards aktualisiert, um zu reflektieren, wie wir als Gruppe Code schreiben, und wir haben eine sehr starke Test-/Refaktor-/Design-/Codeschleife eingeführt. Wir liefern kontinuierlich oder versuchen es zumindest. Zumindest haben wir den Stakeholdern alle zwei Wochen etwas zu zeigen. Wir fühlen uns als Software-Handwerker und die Moral ist hoch. Trotz all dieser Prüfungen leiden wir unter dem gleichen Problem, das Sie haben.

Letztendlich liefern wir ein Produkt an einen zahlenden Kunden. Dieser Kunde hat Bedürfnisse und Erwartungen, realistisch oder nicht. Oft bringt uns das Verkaufsteam in Schwierigkeiten, nur um eine Provision zu erhalten. Manchmal hat der Kunde Go-Live-Erwartungen, die unrealistisch sind oder Änderungen erfordern, obwohl wir einen Vertrag haben. Zeitleisten passieren. Zapfwelle und verlorene Tage während eines Sprints können passieren. Alle möglichen kleinen Dinge können in einer Situation gipfeln, in der wir in das Rätsel gezwungen werden, "es richtig zu machen" oder "es so schnell wie möglich zu tun". Fast immer sind wir gezwungen, "es so schnell wie möglich zu tun".

Als Software-Handwerker, Entwickler, Programmierer und Leute, die für einen Job programmieren, ist es unsere natürliche Neigung, "es richtig zu machen". "Do it ASAP" ist das, was passiert, wenn wir arbeiten, um zu überleben, wie es die meisten von uns tun. Das Gleichgewicht ist schwer.

Ich beginne immer damit, mich an die Geschäftsleitung zu wenden (ich bin Direktor für Softwareentwicklung und aktiver Entwickler in dieser Gruppe), um den Zeitplan, das Team und die geleistete Arbeit zu verteidigen. Normalerweise wird mir zu diesem Zeitpunkt gesagt, dass der Kunde es jetzt haben muss und es funktionieren muss. Wenn ich weiß, dass es keinen Raum für Verhandlungen oder Geben gibt, gehe ich zurück und arbeite mit dem Team zusammen, um zu sehen, welche Ecken geschnitten werden können. Ich werde nicht auf die Qualität der Funktion verzichten, die das Bedürfnis des Kunden nach einem schnellen Service antreibt, aber es wird etwas gehen und es wird in einen anderen Sprint verschoben. Das ist fast immer in Ordnung.

Wenn Sie nicht liefern können, weil es so viele Fehler gibt, die Codequalität schlecht ist und sich verschlechtert und die Zeitpläne kürzer werden, befinden Sie sich in einer anderen Situation als von mir beschrieben. In diesem Fall können aktuelle oder vergangene Misswirtschaft, schlechte Entwicklungspraktiken, die zu einer schlechten Codequalität führten, oder andere Faktoren Sie auf einen Todesmarsch führen.

Meine Meinung hier ist, Ihr Bestes zu geben, um guten Code und Best Practices zu verteidigen, um Ihr Unternehmen aus den Gräben zu ziehen. Wenn es keinen einzigen Kollegen gibt, der bereit ist, zuzuhören oder gegen das Management für die Gruppe zu kämpfen, ist es möglicherweise an der Zeit, sich nach einem neuen Job umzusehen.

Am Ende übertrumpft das wirkliche Leben alle. Wenn Sie für ein Unternehmen arbeiten, das verkaufen muss, was Sie entwickeln, werden Sie täglich auf diesen Kompromiss stoßen. Nur durch das Streben nach guten Entwicklungsprinzipien konnte ich der Codequalitätskurve immer einen Schritt voraus sein.

Das Push and Pull zwischen Entwicklern und Verkäufern erinnert mich an einen Witz. "Was ist der Unterschied zwischen einem Gebrauchtwagenhändler und einem Softwareverkäufer? Zumindest weiß der Gebrauchtwagenhändler, dass er lügt." Halten Sie Ihr Kinn hoch und versuchen Sie, "das Richtige zu tun", während Sie gehen.

106
Akira71

Eine Sache, die ich in meiner Karriere erkannt habe, ist, dass es immer Zeit gibt, es richtig zu machen. Ja, Ihr Manager könnte Druck machen. Der Kunde könnte sauer sein. Aber sie wissen nicht, wie lange es dauert. Wenn Sie (Ihr Entwicklerteam) es nicht tun, wird es nicht erledigt. Sie halten die gesamte Hebelwirkung.

Weil Sie wissen, was wirklich dazu führt, dass Ihr Manager Sie oder Ihren Kunden verärgert? schlechte Qualität.

62
Telastyn

Dies läuft auf das hinaus, was ich mir als "Der ewige Konflikt" (zwischen Wirtschaft und Technik) vorgestellt habe. Ich habe keine Lösung, da es sich um ein Problem handelt, das nie verschwindet, aber Sie können Maßnahmen ergreifen, um Abhilfe zu schaffen.

  • Wert kommunizieren

Was die Leute oft nicht merken, ist, dass wir als Ingenieure nur davon ausgehen, dass das Problem des "erfolgreichen Geschäfts" immer eine Selbstverständlichkeit ist. Wir möchten, dass unser Code schön und ordentlich und wartbar ist, damit wir schnell und mit einem Minimum an Kunden, die die Qualitätssicherung für uns durchführen, neue Funktionen hinzufügen und vorhandene optimieren können, indem wir bizarre Randfälle entdecken, die durch besseren Code vereitelt worden wären. Kunden zu halten und einen Wettbewerbsvorteil mit Funktionen und Finesse zu erzielen, die niemand sonst schnell genug produzieren kann, sind beides Geschäftsgewinne, zu denen guter Code direkt beiträgt und die viel darüber informieren, warum wir überhaupt besseren Code wollen.

Also buchstabieren Sie es. "Wir möchten X in unserer Codebasis ausführen, denn wenn wir dies nicht tun, wirkt sich dies aufgrund von Y negativ auf das Geschäft aus" oder "... weil dies unsere Wettbewerbsfähigkeit verbessert, indem wir unsere Fähigkeit verbessern, neue Verbesserungen und Funktionen schneller umzusetzen . "

Und geben Sie Ihr Bestes, um konkrete Beweise dafür zu erhalten, dass Verbesserungen funktionieren. Wenn die Verbesserung einer Teilmenge einer App zu einer schnelleren Funktion/Verbesserung führte, überprüfen Sie das von Ihnen verwendete Backlog-Tool auf Beweise dafür und weisen Sie bei geeigneten Besprechungen darauf hin.

  • Bring das Team auf die gleiche verdammte Seite

Egos sind oft ein Problem. Eine Sache, die Ingenieurteams sehr dringend brauchen, ist es, den Wert eines vereinbarten konsistenten Ansatzes zur Lösung bestimmter Arten von Problemen zu ermitteln, wenn jeder seine eigene Tasse Kool Aid d'jour trinkt, weil er es besser weiß. Es ist in Ordnung zu glauben, dass die Präferenz des anderen schlechter ist als Ihre, aber Wertschöpfung gegenüber mehr Recht, wenn sein Ansatz praktikabel ist und es ein Argument ist, das Sie nicht gewinnen können. Kompromisse aus Gründen der Konsistenz sind der Schlüssel. Wenn die Dinge konsistent sind, ist es schwieriger, sie falsch zu machen, da der konsistent etablierte Weg normalerweise auch der schnellste ist.

  • Wählen Sie die richtigen Werkzeuge

Es gibt zwei Schulen von Frameworks/Toolsets/Bibliotheken/was auch immer. "Stellen Sie 99% davon für mich ein, damit ich sehr wenig wissen/tun muss" vs. "Bleiben Sie mir aus dem Weg, wenn ich Sie nicht dort haben will, aber helfen Sie mir, sehr schnell und konsequent mit Dingen zu basteln, die ich eigentlich will eher auf der Karotte als auf dem Peitschenprinzip zu verwenden. " Bevorzugen Sie den zweiten. Flexibilität und granulare Kontrolle sollten niemals am Altar einer schnellen Abwicklung geopfert werden, da für Unternehmen "wir können dies nicht tun, weil unsere eigenen Tools uns nicht zulassen" niemals eine akzeptable Antwort ist und die Frage immer für Nicht-Unternehmen gestellt wird. Trivial-/Einweg-Produktentwicklung. Nach meiner Erfahrung werden unflexible Werkzeuge fast immer weit geöffnet oder unelegant herumgearbeitet und verursachen ein großes, riesiges, nicht zu wartendes Durcheinander. Meistens sind die flexiblen/einfacher zu modifizierenden Lösungen kurzfristig genauso oder fast genauso schnell, unabhängig davon. Mit den richtigen Werkzeugen sind schnell, flexibel und wartbar.

  • FFS, wenn Ingenieure sich nicht entscheiden, erhalten Sie zumindest Ingenieur-Input bei der Auswahl der Werkzeuge

Ich habe das Gefühl, dass dies eine Frage aus Entwicklersicht ist, aber ich war in viel zu vielen Situationen, in denen Technologieentscheidungen ohne Eingaben von Ingenieuren getroffen wurden. Was zum Teufel ist das? Ja, letztendlich muss jemand den letzten Anruf tätigen, aber wenn Sie kein technischer Manager sind, müssen Sie einige qualifizierte Meinungen einholen, nicht das, was ein Verkäufer oder eine Demo-Site über seine eigenen Produkte sagt. Alles, was verspricht, Ihnen Geld zu sparen, weil die Leute nicht so schlau sein müssen oder weil es Entwickler vor sich selbst schützt, ist eine schmutzige, schmutzige Lüge. Stellen Sie Talente ein, denen Sie vertrauen können. Erklären Sie ihnen, was Sie von einem Stack oder einer anderen technischen Lösung erwarten, und nehmen Sie ihre Beiträge ernst, bevor Sie entscheiden, auf welchen technischen Zug Sie springen möchten.

  • Fokus auf Design über Implementierung

Tools sind für die Implementierung vorgesehen und können Ihnen als solche helfen. Die Architektur muss jedoch oberste Priorität haben, unabhängig davon, welche Spielzeuge Sie zum Erstellen dieser Architektur haben. Am Ende des Tages KISS und DRY und alle hervorragenden Philosophien, die sich von dieser Angelegenheit mehr erstrecken als ob es sich um .NET oder Java oder vielleicht etwas, das sowohl kostenlos als auch nicht saugt.

  • Protokollieren Sie Ihre Bedenken

Wenn die Unternehmensseite darauf besteht, dass Sie es schlecht machen, speichern Sie diese E-Mail, insbesondere den Teil, in dem Sie angegeben haben, warum es Sie kosten würde. Wenn alle Ihre Vorhersagen wahr werden und ernsthafte geschäftsschädigende Probleme auftreten, haben Sie eine Menge Argumente, um die Bedenken der Ingenieure ernst zu nehmen. Aber Zeit Dinge sorgfältig. Mitten im lodernden Inferno ist eine schlechte Zeit für ein "Ich habe es dir gesagt", wenn man den Feuercode befolgt. Löschen Sie das Feuer und bringen Sie Ihre Liste der zuvor ignorierten Bedenken zu einem nachträglichen Meeting/Gespräch. Versuchen Sie, den Fokus auf technische Bedenken zu legen, die zum Ausdruck gebracht und ignoriert werden, und auf die Gründe, die Sie verstanden haben, warum sie ignoriert wurden, und nicht auf die Namen der tatsächlichen Personen die Entscheidung treffen, zu ignorieren. Du bist Ingenieur. Bleib bei den Problemen, nicht bei den Menschen. "Wir äußerten uns besorgt über X, weil wir befürchteten, dass dies zu Y-Problemen führen würde. Uns wurde Z gesagt, wir sollten den Umgang damit aufschieben."

21
Erik Reppen

Es gibt nur eine Lösung. Reservieren Sie ca. 10-20% der Projekt-/Arbeitszeit für das Refactoring. Wenn es schwierig ist, das Management davon zu überzeugen, dass es eine vertretbare Aufgabe ist, geben Sie ihm das einzig wahre Argument: Ohne Umgestaltung werden die Kosten für die Codewartung im Laufe der Zeit exponentiell steigen. Es ist gut, ein paar Metriken/Artikel/Forschungsergebnisse zu haben, um diese These während des Treffens mit dem Manager zu untermauern :)

Bearbeiten: In diesem Whitepaper werden einige gute Ressourcen zum Thema "Refactoring vs. steigende Wartungskosten" erwähnt: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

19
Andrzej Bobak

Wann immer Sie Zeit haben, etwas richtig zu machen, verwenden Sie es - schreiben Sie den bestmöglichen Code und verbessern Sie ihn stetig. Machen Sie Ihre Arbeit nicht schwieriger, indem Sie schlampig werden und technische Schulden einführen, wenn dies nicht erforderlich ist.

Notrufe zur Behebung eines schwerwiegenden Fehlers können Sie nicht selbst kontrollieren. Wenn sie auftreten, müssen Sie so schnell wie möglich reagieren, das ist das Leben. Wenn Sie den Eindruck haben, dass Ihr ganzer Job aus Notrufen besteht und Sie nie genug Zeit haben, um die Dinge richtig zu machen, sind Sie natürlich auf dem Weg zum Burn-out und sollten mit Ihrem Chef sprechen.

Wenn das nicht hilft, gibt es immer noch "Scottys Strategie", um genügend Zeit zu haben, um die Dinge richtig zu machen: Multiplizieren Sie alle Ihre Schätzungen mit dem Faktor 4:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

14
Doc Brown

Ich sehe meine Aufgabe darin, die bestmögliche Software bereitzustellen, die innerhalb der für das Projekt zulässigen Zeit möglich ist. Wenn ich befürchte, dass das Qualitätsniveau niedrig sein wird, werde ich den Projektbesitzer engagieren. Ich beschreibe meine Bedenken und diskutiere die potenziellen Risiken der Bereitstellung der Software in diesem Zustand. Eines von drei Dingen wird an dieser Stelle passieren:

  1. Der Projektbesitzer möchte die Risiken nicht akzeptieren und verschiebt den Zeitplan zurück, damit wir mehr Zeit für die Softwarequalität verwenden können.

  2. Der Projektbesitzer möchte die Risiken nicht akzeptieren, kann den Zeitplan jedoch nicht zurück verschieben. In diesem Fall müssen wir verhandeln, welche Features/Funktionen aus dem Projektumfang entfernt werden sollen, um mehr Zeit für die Softwarequalität der Hauptteile der Anwendung zu verwenden.

  3. Der Projektbesitzer wird die Risiken akzeptieren und die Software von geringer Qualität wird planmäßig ausgehen. Manchmal ist das Geschäftsrisiko, nichts bereitzustellen (oder zu spät bereitzustellen), viel größer als das Geschäftsrisiko, Software von geringer Qualität bereitzustellen, und nur der Projektbesitzer kann diese Entscheidung treffen.

Das Schreiben von Software ähnelt dem Malen eines Porträts. Es ist unmöglich zu sagen, dass ein Porträt "richtig" oder "perfekt" gemacht wird. Perfekt ist der Feind von erledigt. Sie könnten buchstäblich 1 Monat damit verbringen, an einer einzelnen Methode zu arbeiten, und sie wird von manchen immer noch nicht als "perfekt" angesehen. Meine Aufgabe ist es, ein Porträt zu malen, mit dem der Kunde zufrieden ist.

11
Shane

Das optimale Gleichgewicht könnte darin bestehen, so viel zusätzliche Zeit damit zu verbringen, es richtig zu machen, wie Sie damit verschwenden würden, die Fehler zu beheben, die Sie beseitigen, indem Sie es richtig machen. Vermeiden Sie eine Vergoldung der Lösung. In den meisten Fällen ist die richtig gemachte Volkswagen Lösung genauso gut wie die Cadillac-Lösung. Sie können normalerweise später ein Upgrade durchführen, wenn nachgewiesen ist, dass Sie den Cadillac benötigen.

Das Beheben von Code, der nicht den Best Practices entspricht, dauert häufig viel länger. Der Versuch, herauszufinden, woher die Null kommt, wenn der Aufruf wie a.b.c.d.e () aussieht, kann lange dauern.

Das Anwenden von DRY und das Wiederverwenden von vorhandenem Code ist normalerweise viel schneller als das Codieren und Testen einer weiteren Lösung. Es erleichtert auch das Anwenden von Änderungen, wenn sie auftreten. Sie müssen nur einen Satz ändern und testen Code, nicht zwei, drei oder zwanzig.

Streben Sie nach soliden Basiscodes. Es kann viel Zeit verschwendet werden, um es perfekt zu machen. Es gibt Best Practices, die zu schnellem, aber nicht unbedingt schnellstem Code führen. Darüber hinaus kann es Zeitverschwendung sein, Engpässe zu antizipieren und den Code während der Erstellung zu optimieren. Schlimmer noch, die Optimierung kann den Code verlangsamen.

Stellen Sie nach Möglichkeit die minimale Arbeitslösung bereit. Ich habe Wochen verschwendete Vergoldungslösungen gesehen. Seien Sie äußerst vorsichtig mit dem Umfang.

Ich habe einige Zeit an einem Projekt gearbeitet, das sechs Monate hätte dauern sollen. Als ich dazu kam, war es seit anderthalb Jahren im Gange. Der Projektleiter hatte dem Projektmanager zu Beginn eine Frage gestellt: "Soll ich es richtig machen oder reagieren?" In einer Woche wurde eine Funktion am Montag, Mittwoch und Freitag implementiert. Dienstag und Donnerstag wurde die Funktion entfernt.

BEARBEITEN: Wenn der Code zufriedenstellend ist, lassen Sie ihn. Gehen Sie nicht zurück, um das Problem zu beheben, wenn Sie einen besseren Weg finden, dies zu tun. Wenn Sie sich eine Notiz machen müssen. Wenn Änderungen erforderlich sind, überprüfen Sie Ihre Idee und setzen Sie sie um, wenn dies noch sinnvoll ist.

Wenn es Stellen gibt, an denen Sie Erweiterungen für kommende Funktionen implementieren würden, implementieren Sie die Erweiterungen nicht. Sie können einen Markierungskommentar hinterlassen, um Sie daran zu erinnern, wo Sie die Änderungen vornehmen müssen.

7
BillThor

Dies wird nicht in jedem Fall funktionieren, aber ich hatte etwas Glück mit dieser Strategie, wenn das Problem ein defektes Produktionsproblem ist, das dringend behoben werden muss. Schätzen Sie die Zeit für eine schnelle Korrektur, um die Produktion zum Laufen zu bringen, und die Zeit, um die Qualitätskorrektur für die Zukunft durchzuführen. Präsentieren Sie die Schätzungen Ihrem Chef/Kunden und lassen Sie die Zeit für beide genehmigen. Dann machen Sie die schnelle Lösung, um die Produktion zum Laufen zu bringen, und sofort danach eine langfristige Lösung, wenn der dringende Zeitdruck nachlässt. Ich stelle fest, dass meine Kunden diesen Ansatz zu mögen scheinen, wenn ich ihn so präsentiere, wie ich diese Zeit brauche, um die Arbeit richtig zu erledigen, aber ich kann einen temporären Fix einrichten, bis ich das kann. Es wird wieder zum Laufen gebracht und es wird der langfristige Bedarf gedeckt.

7
HLGEM

Lass es funktionieren, dann mach es perfekt

Ich mag etwas nachlassen - aber wenn Zeit von entscheidender Bedeutung ist, sollte Ihre Hauptpriorität darin bestehen, sie zum Laufen zu bringen, so einfach ist das. Kommentieren Sie ausführlich die Mängel in Ihrem Code und notieren Sie sich, was Sie in einer von Ihnen verwendeten Projekt-/Zeitmanagementsoftware getan haben.

Hoffentlich haben Sie dadurch mehr Zeit, um auf diese Themen zurückzukommen und sie zu perfektionieren.

Natürlich gibt es keine absolut richtige Antwort darauf, aber ich versuche, mich an diese Antwort zu halten. Möglicherweise finden Sie es jedoch nicht für Ihren aktuellen Arbeitsstil geeignet. Was mich zur Alternative führt ...

Finden Sie einfach eine Methode, die für Sie funktioniert; und dann bleib dabei. Jeder hat seine eigene Art, mit Projekten umzugehen, und es gibt keinen einheitlichen Ansatz. Finden Sie einen Ansatz und machen Sie ihn zu Ihrem.

6

"Richtig machen" bedeutet, die richtigen Kompromisse für eine bestimmte Situation einzugehen. Einige von ihnen sind:

  1. Entwicklungszeit und -kosten
  2. Einfaches Lesen, Debuggen und späteres Aktualisieren des Codes (von Variablennamen bis hin zur Architektur)
  3. Gründlichkeit der Lösung (Randfälle)
  4. Ausführungsgeschwindigkeit

Wenn ein Teil des Codes einmal verwendet und weggeworfen wird, kann # 2 natürlich für jeden der anderen geopfert werden. (Aber Vorsicht: Sie können denken Sie werden es wegwerfen und dann feststellen, dass Sie es weiterhin verwenden und warten müssen. An diesem Punkt wird es schwieriger sein, die Leute davon zu überzeugen, Ihnen Zeit für Verbesserungen zu geben etwas, das "funktioniert".)

Wenn Sie und/oder Ihr Team weiterhin Code verwenden und aktualisieren, bedeutet das Verwenden von Verknüpfungen nur, dass Sie sich später verlangsamen.

Wenn Sie derzeit fehlerhaften Code liefern (schwach bei # 4) und lange dafür brauchen (schwach bei # 1), und weil Sie versuchen, Code zu aktualisieren, der bei # 2 schwach war, haben Sie Ich habe ein solides, pragmatisches Argument für die Änderung Ihrer Praktiken.

5
Nathan Long

Wenn es ein Fehler ist, tun Sie es so schnell wie möglich. Wenn es sich um eine neue Funktion handelt, nehmen Sie sich Zeit.

Und wenn Sie für ein Unternehmen arbeiten, das die Entwicklerarbeit nicht respektiert, haben Sie möglicherweise keine andere Wahl, als es schnell zu tun und auf Qualität zu verzichten.

Ich habe für eine Reihe von Unternehmen gearbeitet, die einfach von Projekt zu Projekt gingen und alles schnell erledigten. Letztendlich hatten sie in jedem Projekt wenig Erfolg, da die Implementierung (nicht nur die Programmierung) beschleunigt wurde.

Die besten Unternehmen wissen, dass gute Software Zeit und Handwerkskunst erfordert.

4
Dimitry

Hier ist ein guter Plan:

  1. Stellen Sie sicher, dass Ihr Do-it-Right-Plan genauso lange dauert wie Do-it-asap so schnell wie möglich.
  2. Optimieren Sie Ihre Zeit dafür, bis Ihre Umgebung zufrieden ist. Behalten Sie die Qualität
  3. ???
  4. Erfolg
3
tp1

Erstellen Sie im Notfall die Patch-Lösung. Erstellen Sie einen neuen Fehler in der Fehlerverfolgung, indem Sie dies erwähnen. Machen Sie es richtig, wann immer Sie Zeit haben.

3
Manoj R

Ich denke, ich mache das, was jeder tut, der in dieser Branche festsitzt. Ich erledige es so schnell ich kann und wenn ich einige der schönen Dinge weglassen muss, die helfen würden, Probleme in der Zukunft zu verhindern oder das Lösen von Problemen in der Zukunft zu erleichtern, tue ich das. Es ist keine optimale Situation, aber wenn Sie Fristen einhalten, die auf Schätzungen basieren, die auf Schätzungen basieren, die auf vielen unbekannten Variablen basieren, ist dies so ziemlich das Beste, was Sie tun können.

3
Matt

Software ist seltsames Zeug und der Softwareentwicklungsprozess ist seltsamer.

Im Gegensatz zu den meisten Dingen im wirklichen Leben, aber wie die meisten Dinge, die mit Computern zu tun haben

Schneller ist zuverlässiger

Dies widerspricht jeder Intuition, die Ihnen Ihr bisheriges Leben beigebracht hat, stark abgestimmte Autos fallen häufiger aus als Standardautos, schnell gebaute Häuser fallen schneller auseinander, Hausaufgaben im hinteren Teil des Schulbusses erhalten keine guten Noten.

Langsame methodische Verfahren führen jedoch nicht zu besserer Software. Leute, die Wochen damit verbringen, Anforderungsdokumente und Tage mit Klassendiagrammen zu erstellen, bevor sie Code schreiben, produzieren keine bessere Software. Der Typ, der die Grundvoraussetzung erfüllt, einige Probleme klärt, ein Klassendiagramm auf das Whiteboard kritzelt und seine Teamcodierung erhält, wird fast immer zuverlässigere und bessere Software produzieren, und zwar in Tagen statt in Monaten.

1
James Anderson

Ich mache die meisten Dinge routinemäßig, den ersten Weg, der mir in den Sinn kommt. Das geht schnell und ich denke gerne, dass ich ein anständiger Programmierer bin und die meisten Dinge beim ersten Versuch einigermaßen in Ordnung mache.

Hin und wieder (ich würde gerne zweimal pro Tag sagen, aber zweimal pro Woche ist realistischer), besonders wenn ich etwas extrem Langweiliges finde, denke ich "was wäre ein FANTASTISCHES." Weg, dies zu tun? " und ich verbringe die zusätzliche Zeit damit, einen besseren Weg zu finden oder zu erfinden.

Wenn ich das oft genug mache, wird sich meine Routinecodierung weiter verbessern, denke ich.

1
RemcoGerlich