Wie kann ich ein Teammitglied davon überzeugen, ein Webframework zu verwenden? [geschlossen]


10

Die Frage ist folgende und das Detail folgt: Kann ich als Programmierer etwas sagen / ansprechen, um ihn an meine Seite zu bringen?

Ich würde gerne gültige Argumente für beide Seiten zu diesem Thema hören, aber hauptsächlich Vorschläge, wie man ihn herumredet.


Meine Situation ist folgende: Ich arbeite an einem Teamprojekt in meinem Studiengang und baue eine mittelgroße Website als Prototyp für die Universität. Alle werden in der Gruppe als gleich angesehen und es gibt niemanden, der zum Anführer ernannt wurde. Die Antwort auf dieses Problem kann also nicht "Pull Rank" sein.

Alle sind gleich, es gibt jedoch eine große Wissenslücke zwischen den Mitgliedern. Das betreffende Teammitglied und ich sind beide fähige Entwickler, obwohl er keine Branchenerfahrung besitzt. Die anderen drei Mitglieder sind weniger fähig, und zwei haben sich vollständig aus der Entwicklung zurückgezogen. Alle drei haben sich aufgrund mangelnden Wissens geweigert, zu der Situation Stellung zu nehmen.

Als Gruppe entscheiden wir, welche Technologien für die Implementierung der Website verwendet werden sollen. Insbesondere, ob ein PHP-Framework (Code Igniter) verwendet werden soll oder nicht.

Ich argumentiere dafür und zitiere:

  1. Das Rad nicht neu erfinden
  2. Gut geschriebene und getestete Codebasis zum Arbeiten
  3. Los geht's (die Frist ist näher als wir möchten)
  4. Entwicklungsgeschwindigkeit
  5. Solide und wartbare Designmuster und bewährte Verfahren

Er plädiert dafür, so zu arbeiten, wie er es gewohnt ist:

  • Schreiben von maßgeschneiderten, einmaligen Funktionen in eine "Bibliotheks" -Datei, wenn er sie benötigt
    • Funktionen für den Datenzugriff und das Rendern dieser Daten auf der Seite, das Abrufen / Einstellen zu und von der Sitzung und das Abrufen / Veröffentlichen von Daten usw.
  • 1 Datei pro Seite (was zu keiner Trennung der Bedenken zwischen Kontrolle, Präsentation und Daten führt)

Seine Gründe gegen die Verwendung von Frameworks beruhen hauptsächlich darauf, dass er den Punkt nicht erkennen kann: Er kann all diese Dinge bereits tun. Das Framework ändert daran nichts, es macht es nur schwieriger, weil er das Framework lernen muss. Er möchte keinen Code verwenden, den er nicht persönlich geschrieben hat.

Er hat auch gesagt, dass es "nicht auf die Qualität der Codebasis ankommt, da das Projekt nur ein Prototyp ist und niemals gewartet wird". Für mich ist das keine Entschuldigung , nicht wartbaren Code zu schreiben.

Ich kann sehen, warum er diese Argumente vorbringt, aber ich habe Probleme mit seiner "mangelnden Sorge um die Wartbarkeit" und seiner "Missachtung des guten Designs" oder sogar der Trennung von Bedenken. Ich vermute jedoch, dass er nie Designmuster studiert hat, daher weiß ich nicht, wie effektiv es wäre, zu demonstrieren, warum sich seine Methode als nicht wartbar erweisen könnte.

Ich möchte mit diesem Projekt beginnen, aber ich möchte es nicht ohne Rücksicht auf alles tun, was ich im Laufe der Jahre gelernt habe. Wie ich bereits sagte, gibt es hier keine Möglichkeit, einen Rang zu erreichen, und andere Teammitglieder sind auch nicht bereit, sich einzumischen. Sollte ich einfach zurücktreten und die Dinge auf seine Weise tun? Ist er zu stur und unerfahren, um es besser zu wissen? Oder bin ich hier der Hartnäckige?

TL; DR Unerfahrenes Teammitglied ist stur, wie kann ich ihn für mich gewinnen?


2
Es ist sehr schwierig, die eigentliche Frage in Ihrem Blog-Beitrag zu finden :) Bitte überarbeiten Sie sie so, dass die technischen Argumente, die Sie beide vorbringen, hervorgehoben werden. Obwohl wir Ihnen nicht wirklich sagen können, wie Sie mit einer Person sprechen sollen, die wir nicht kennen, können wir Ihnen helfen, die Situation vom Standpunkt eines Programmierers aus zu betrachten. Es scheint eine gute Frage zum evolutionären Prototyping zu geben, aber ich kann nicht sicher sein ...
Yannis

4
Teile davon wären wahrscheinlich besser geeignet für: area51.stackexchange.com/proposals/30887/professional-matters
Karlson

3
he doesn't want to use code he hasn't personally written.Er sollte sein Betriebssystem, seine IDE, sein Telefon, seine Ampeln usw.
wegwerfen

4
@AndyBursh I want to know exactly how everything worksist ein gültiges Argument beim Lernen, wenn die Neuerfindung des Rades tatsächlich akzeptabel ist. Vielleicht, nur vielleicht, könnte man das als Hilferuf und nicht als Sturheit lesen.
Yannis

4
since the project is only a prototype and will never be maintained Letzte letzte Worte :) Ich wünschte, ich hätte jedes Mal einen Dollar, wenn ich diese Annahme gemacht hätte und herausgefunden hätte, dass die Ungeduld und die kurzfristige Gier der höheren Schichten entschieden haben, dass der Prototyp jetzt das Produkt ist.
maple_shaft

Antworten:


20

Du wirst ihn nicht dazu überreden können. Es heißt Dunning-Kruger-Effekt . Er ist zu unwissend, um zu wissen, was er nicht weiß, und zu ängstlich, um zu verlieren, was er als Vorteil bezeichnet.

Wenn Sie keinen Konsens erzielen können, müssen Sie stattdessen einen Kompromiss erzielen. Vielleicht können Sie die Arbeit so aufteilen, dass er nur wenig lernen muss, um das Framework zu lernen. Vielleicht haben Sie eine Art "Design-Off", bei dem Sie es jeweils ein paar Wochen lang auf Ihre Weise tun, und dann stimmt das Team ab, welches das beste ist. Vielleicht können Sie Ihren Sponsoring-Professor oder den Kunden in die Lösung des Problems einbeziehen.


3
+1 da dies gelegentlich in der realen Welt passiert. Ich war in Jobs, in denen ich einem anderen Entwickler nicht zustimmen konnte, was der beste Ansatz war. Also haben wir beide einen POC herausgebracht und dann die Vor- und Nachteile jedes einzelnen untersucht. 9 von 10 Fällen haben wir eine Lösung gewählt, die ein Mashup der beiden POCs war, und jeder hat etwas aus dem Prozess gelernt.
Timothy Baldridge

1
+1 für das Unterrichten über Dunning-Kruger! Jeder muss es wissen ..
Stephen Gross

Bah. Es ist zu einfach, Dunning-Kruger zu zitieren, wenn man mit jemandem nicht einverstanden ist - zu einfach, ihn als dumm zu bezeichnen. Vielleicht glaubt der Teamkollege, dass Frameworks den Geist der Aufgabe verletzen, vielleicht möchte er die Probleme, die ein Framework löst, aus erster Hand lösen, vielleicht möchte er die Debatte über CodeIgniter, Cake, Symfony vermeiden ... Meine erste Annahme war das nicht Er war ein Idiot.
Corbin

1
@Corbin, Dunning-Kruger handelt nicht von mangelnder Intelligenz, sondern von Unerfahrenheit. Zwei sehr unterschiedliche Dinge. Ich bin damit einverstanden, dass Ihre Gründe gültig sein könnten, aber das OP sagte, dass dies nicht die Argumente waren, die er vorbrachte. Stattdessen "sieht er keinen Sinn", Frameworks zu verwenden, weil er in kürzerer Zeit selbst etwas genauso Gutes von Grund auf neu schreiben kann. Eine unerfahrene Person, die ihre eigene Kompetenz im Vergleich zu einer Lösung überschätzt, von der er zugegebenermaßen fast nichts weiß, ist ein Lehrbuchbeispiel für Dunning-Kruger. Solche Leute können nicht zu etwas "überredet" werden, sie müssen gezeigt werden.
Karl Bielefeldt

7

Ein Argument für Sie ist die Wiederverwendbarkeit von Wissen. Alle Teammitglieder, die ein bekanntes und weit verbreitetes Framework (wie CodeIgniter) erlernen, können ihr Wissen für das nächste Projekt wiederverwenden. Während die Kenntnis einer zufälligen "proprietären" Bibliothek "nicht wiederverwendbar ist. Dies kann bei den anderen Teammitgliedern gut ankommen, da sie es wahrscheinlich vorziehen, nützliches, wiederverwendbares Wissen über dieses Projekt zu erlangen.

Ein weiteres Argument könnte eine konkrete Messung der Entwicklungs- / Wartungskosten sein. Ich stelle mir vor, dass sich ein mit CodeIgniter versierter Entwickler schneller entwickeln kann als Ihr Kollege, der all diese proprietären Funktionen selbst schreibt. Dies könnte demonstriert werden, indem Sie und er eine identische Webseite erstellen - Sie mit CodeIgniter, er auf seinem eigenen Weg - und die Zeiten bis zur Fertigstellung messen. Nehmen Sie dann eine Reihe von Änderungen / Erweiterungen an den Seiten vor und messen Sie erneut die Zeit bis zur Fertigstellung. Natürlich sollte die Spezifikation von jemandem erstellt werden, der von Ihnen beiden unabhängig ist, um auf neutralem Boden zu kämpfen.

Eine andere - wie Sie bereits erwähnt haben - ist die Codequalität. Sobald die Webseiten fertig sind, führen Sie jeweils die gleichen Abnahmetests durch und vergleichen Sie die Fehlerdichte.

Wenn Sie unter Zeitdruck stehen, gibt es natürlich möglicherweise keine Möglichkeit, solche Messungen anzuhalten und durchzuführen. Sie möchten also wahrscheinlich eine schnelle Lösung für dieses Dilemma. Versuchen Sie, die anderen Teammitglieder zu überzeugen (z. B. indem Sie sie die bevorstehenden Antworten auf Ihren Beitrag hier lesen lassen :-), um einen gewissen Gruppendruck auf ihn auszuüben. Wenn er wirklich nicht überzeugt werden kann, können Sie das Projekt mit CodeIgniter in zwei Teile teilen, einen für ihn und - idealerweise - einen für den Rest des Teams. Konzentrieren Sie sich darauf, Ihren eigenen Beitrag nach besten Kräften zu leisten, und lassen Sie ihn tun, was er will. Die Ergebnisse werden wahrscheinlich für sich selbst sprechen.


Ich mag die Idee eines Geschwindigkeitstests, um das zu demonstrieren. Welche Art von Abnahmetests könnten wir durchführen? Ich werde dies sicherlich vorschlagen, aber ich bin nicht sicher, ob es gut zu ihm (oder der Gruppe) passt, da wir alle andere Fristen zu verwalten haben, und ich bezweifle, dass jemand besonders daran interessiert ist, die Spezifikation oder "Zeitverschwendung" (as) zu schreiben Ich bin sicher, es würde darauf gesetzt werden.
Andy Hunt

1
Wissenschaft, es funktioniert: xkcd.com/54
StuperUser

5

Ich denke, Sie müssen die anderen 3 Teamkollegen engagieren. Sie müssen beide Ihre Argumente präsentieren und ihnen die Dinge erklären, damit sie verstehen. Am Ende des Tages müssen sie auch mit dieser Codebasis arbeiten. Und wenn alle gleich sind, sollten sie mitbestimmen, womit sie arbeiten möchten.

Ich denke, ein guter Ansatz wäre für jeden von Ihnen, die Vorteile Ihrer jeweiligen Lösungen zu skizzieren und den anderen Teammitgliedern zu zeigen, warum Sie der Meinung sind, dass dies der beste Weg ist. Dann lassen Sie sie entscheiden. Es gibt 3 von ihnen, also wird es der Krawattenbrecher sein.

Eine Sache, auf die Sie hinweisen möchten, ist, dass wenn dies Ihr Sr.-Projekt ist und die anderen Teammitglieder keine andere Erfahrung haben, dieses Projekt die Arbeit widerspiegeln muss, die sie potenziellen Arbeitgebern leisten können. Wenn Sie es richtig machen, kann es ein guter Gesprächsthema in einem Interview sein. Ich weiß, dass ich neue Absolventen auffordere, ihr Senior-Projekt zu skizzieren und wie es entworfen und entwickelt wurde.

Wenn sie dem Ansatz des anderen entsprechen, müssen Sie ihn aufsaugen. Aber gib die Hoffnung nicht auf. Überlegen Sie sich ein gutes Design, damit das Chaos, das er schreibt, nicht alles beeinflusst. Wenn Sie Zeit haben, bereinigen Sie den Code, überarbeiten Sie einige seiner Inhalte und zeigen Sie ihm, dass er das Rad nicht jedes Mal neu erfinden muss.


Ich hatte ehrlich gesagt nicht darüber nachgedacht, wie sich dies auf die anderen in der Gruppe auswirkt. Ich werde sicher darauf hinweisen.
Andy Hunt

1

Ich glaube, das College ist wie ein Sandkasten. Die meisten Dinge, die Sie dort tun, werden bei der Bereitstellung nicht verwendet. So haben Sie viel mehr Freiheit zu experimentieren und Ihre Komfortzone zu verlassen. Entdecken Sie neue Dinge, denn ein Fehlschlag hat keine allzu großen Auswirkungen. Auch in Ihrer Situation haben Ihre Teammitglieder den zusätzlichen Vorteil, dass ihnen jemand mit Vorkenntnissen hilft.

Das andere erfahrene Teammitglied hätte nicht aufs College kommen müssen, wenn er nichts Neues lernen wollte. Dies ist eine gute Gelegenheit, etwas Neues zu lernen und es seiner Toolbox hinzuzufügen.

Und für die unerfahrenen Teammitglieder erhöhen sich ihre Chancen, angestellt / besser angestellt zu werden, mit einem Rahmen wie CodeIgniter in ihrem Lebenslauf (tatsächlich das Wissen, um dies in ihrem Lebenslauf zu rechtfertigen).

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.