schnell und einfach vs. gutes Design

Question

Was tun Sie, wenn Ihr Vorgesetzter möchte, dass Sie etwas auf die Schnelle einführen, und Sie wissen, dass es nach hinten losgehen wird?

Mein Vorgesetzter möchte, dass ich eine Webanwendung für einen Kunden entwickle, und zwar so schnell wie möglich. Dies ist die erste Webanwendung, die wir für diesen Kunden entwickeln, und ich denke, es ist wichtig, dass wir es richtig machen, damit wir darauf aufbauen können, wenn er uns zwangsläufig bittet, sie zu verbessern oder eine neue zu erstellen.

Ich würde gerne etwas Zeit damit verbringen, einen Rahmen einzurichten (selbst wenn es nur etwas Einfaches ist wie Streifen ), und die Konfiguration von Tomcat für die Verwendung von DBCP. Ich denke auch, dass wir css-Vorlagen verwenden und uns zumindest ein Minimum an Gedanken über die Präsentation und das Design der Anwendung machen sollten, da meiner Meinung nach nichts so unprofessionell aussieht wie eine schlecht gestaltete Webseite (es sei denn, es handelt sich um eine E-Mail mit wirklich schlechter Grammatik).

Das Problem ist nicht so sehr, dass wir unter Druck stehen, sondern eher, dass mein Vorgesetzter meint, er könne nicht rechtfertigen, dass er zusätzliche Stunden für etwas in Rechnung stellt, das er selbst nicht für notwendig hält. Sein "Mach es einfach so schnell wie möglich"-Ansatz ist schon ein paar Mal nach hinten losgegangen - einmal hat er mir zum Beispiel gesagt, ich solle den Code nicht für eine bestimmte Fehlersituation entwerfen, da es sehr unwahrscheinlich sei, dass sie auftritt, und als sie dann doch auftrat, gab es ein großes Chaos (das ich aufräumen musste).

Was soll ich also tun? Mache ich es wirklich "schnell und schmutzig"? Entscheide ich, dass der schnellste Weg der ist, es richtig zu machen und mich mit den Konsequenzen auseinanderzusetzen, wenn ich länger brauche als erhofft? Ein Teil des Problems besteht darin, dass ich in der Vergangenheit zwar schon Webentwicklungen durchgeführt habe, aber immer innerhalb eines bestehenden Rahmens, so dass die Einrichtung eines neuen Rahmens für mich eine Lernkurve bedeutet.

Answer 1

Bedenken Sie, dass aus seiner Sicht die Abrechnung vieler Stunden den Verkauf für den Kunden unattraktiver macht. Es könnte ein guter Marketing-Ansatz sein (auch wenn es eine schreckliche Design-Entscheidung ist), es jetzt schnell und schmutzig zu schreiben, damit der Kunde es mag, und wenn er Änderungen wünscht, kann er in Zukunft mehr Stunden in Rechnung stellen, weil er den Kunden jetzt "im Netz" hat.

Aber mein Rat ist: Schauen Sie sich um, er hat das Sagen, also machen Sie es auf seine Art, sonst schaffen Sie sich nur selbst Probleme. Wenn Sie die Dinge richtig machen wollen, werden Sie der Chef oder suchen Sie sich ein anderes Unternehmen, das an die richtige Vorgehensweise glaubt. Aber wenn du einfach gegen den Strom schwimmst, wirst du nur gefeuert oder bekommst Ärger mit dem Kerl, so funktioniert das Leben.

Answer 2

Schnell und schmutzig machen. Das ist es, was sie wollen, das ist es, wofür sie bereit sind zu zahlen. Nehmen Sie das Geld und liefern Sie das.

Später, wenn das System nicht mehr handhabbar ist, weil es ein völliges Chaos ist, und der Kunde in der Lage ist, eine robuste, ausgereifte Lösung zu wollen und zu bezahlen, nehmen Sie das Geld und liefern Sie diese.

Sehen Sie, Sie werden doppelt bezahlt!

Darüber hinaus wird eine schlechte Lösung mit einigen manuellen Prozessen einhergehen. Diese können in Rechnung gestellt werden. Sie werden wieder bezahlt!

Kein Wunder, dass Ihr Vorgesetzter diesen Ansatz mag!

Answer 3

Trotz der Risiken biete ich an eine Managementperspektive dazu. :-)

Eine Herausforderung, die ich bei einigen Teammitgliedern festgestellt habe, ist, dass sie manchmal Schwierigkeiten haben, das große Ganze zu sehen. Das ist natürlich eine Aussage, die Entwickler auch über ihre Manager machen können - sicherlich können Manager (insbesondere nicht-technische Manager) nicht erkennen, wie übereilte Entscheidungen jetzt zu späteren Problemen führen. Aber ich möchte wiederholen, dass nicht nur Manager das große Ganze übersehen können. Auch Entwickler können das.

Einmal sollte mein Team eine einfache Demo entwickeln, und ich hatte zwei Leute, die daran arbeiteten. Das war höchstwahrscheinlich eine Wegwerf-Demo. Gab es eine Chance, dass wir sie behalten und weiter ausarbeiten würden? Sicher. Die Chance war sogar anständig - vielleicht (ich denke mir hier einfach eine Zahl aus) 25 %, nur um der Argumentation willen. Nach fast einem Monat gab es keine Ergebnisse, und schließlich habe ich das Ganze abgeblasen. Es stellte sich heraus, dass die Entwickler die Sache "konstruiert" hatten. Sie wollten es modular, anschlussfähig, testbar usw. machen. Ich sagte ihnen, sie sollten aufhören, und schrieb die Demo selbst an einem einzigen Nachmittag. Das "große Ganze" bestand darin, dem Kunden schnell einen Konzeptnachweis zu liefern, und wenn wir uns aus irgendeinem Grund dafür entschieden, dass wir die Demo zu einem echten Stück Produktionssoftware weiterentwickeln wollten - na gut - dann warfen wir im schlimmsten Fall die "harte Arbeit" eines einzigen Nachmittags weg. Und das war der schlimmste Fall. Es war nicht so, dass ich in der Lage war, ein paar hundert Zeilen Code zu schreiben. dass kompliziert.

Zweifellos treffen Manager im Namen der Zweckmäßigkeit manchmal schlechte Entscheidungen, aber nur weil ich mein Team bitte, etwas schnell und unkompliziert zu erledigen, heißt das nicht, dass ich kurzsichtig bin. Meistens bedeutet es, dass es in dieser Situation wichtiger ist, schnell einen Mehrwert zu liefern, als die Technik richtig zu machen. Leider ist dieser Vorschlag für einige Entwickler (eine Minderheit, um genau zu sein) eine Blasphemie.

Answer 4

Fangen Sie an, Ihren Lebenslauf aufzupolieren.

Answer 5

Wenn Sie mit "erster Webanwendung" einen Prototyp meinen, dann sollten Sie ihn wahrscheinlich schnell und schmutzig erstellen. Ihr Kunde möchte wahrscheinlich etwas sehen, bevor er sich zu etwas verpflichtet. Sie KÖNNEN jedoch schnell etwas machen, ohne es schmutzig zu machen. Wenn Sie sorgfältig darauf achten, wie Sie die Webanwendung entwerfen und schreiben, können Sie die Webanwendung wahrscheinlich im Handumdrehen in ein Kunstwerk verwandeln, nachdem Sie die erste Version veröffentlicht haben.