Neuester Stand der Technik versus praxiserprobte Technologie. Wie werden Sie ein Gleichgewicht finden

Question

Ich denke schon seit einiger Zeit über diese Frage nach. Wie wählt man eine Technologie aus (ich spreche nicht von Java vs. .Net vs. PHP), wenn man ein neues Projekt plant oder ein bestehendes Projekt in einer Organisation pflegt.

Argumente für den Einsatz der neuesten Technologie

1. Sie könnte einige der Einschränkungen der bestehenden Technologie überwinden (man denke nur an die Skalierbarkeit von No SQL gegenüber RDBMS). Manchmal ist die neueste Technologie abwärtskompatibel und man kann nur die neuen Funktionen nutzen, ohne die alte Funktionalität zu zerstören.
2. Es wird eine bessere Benutzererfahrung bieten (vielleicht HTML 5 für Videos, nur ein Gedanke)
3. Reduziert die Entwicklungszeit und -kosten und macht die Pflege der Codebasis relativ einfach

Argumente für die Wahl einer praxiserprobten Technologie/gegen die Wahl einer bahnbrechenden Technologie

1. Sie hat sich nicht bewährt. Es kann zu unvorhergesehenen Problemen kommen. Umständliche Lösungen können zu weiteren Problemen während der Wartungsphase führen und die Anwendung kann zu einem weißer Elefant
2. Möglicherweise gibt es noch keine Normen. Die Normen könnten sich ändern und es könnten erhebliche Nacharbeiten erforderlich sein, um das Projekt an die Normen anzupassen.
3. Die neue Technologie wird möglicherweise nicht von der Organisation unterstützt. Die Unterstützung einer neuen (oder auch einer anderen Technologie) würde zusätzliche Ressourcen erfordern
4. Es könnte schwierig sein, qualifizierte Ressourcen mit Spitzentechnologie zu finden

Aus der Sicht eines Entwicklers sehe ich keinen Grund, sich nicht (in seiner Freizeit) die Hände mit einer neuen Technologie schmutzig zu machen, aber er/sie könnte auf Open Source/Free Ware/Entwickler-Editionen beschränkt sein.

Aus Sicht der Organisation ist das ein zweischneidiges Schwert. Bleibt man zu lange bei einer "praxiserprobten" Technologie, könnten gute Leute abwandern (ganz zu schweigen davon, dass es immer Leute geben wird, die vertraute Technologien bevorzugen und sich weigern, ihr Wissen zu aktualisieren). Versucht man einen unkonventionellen Ansatz, läuft man Gefahr, das Budget/die Zeit zu überschreiten, ganz zu schweigen von den unvorhergesehenen Risiken.

TL;DR

Unterm Strich. Wann halten Sie eine Technologie für so ausgereift, dass sie von einer Organisation übernommen werden kann?

Answer 1

Höchstwahrscheinlich arbeiten Sie mit einem Team von Mitarbeitern zusammen, und das sollte ebenfalls berücksichtigt werden. Einige Möglichkeiten zur Prüfung/Bewertung der technologischen Reife:

1. Sind Ihr Team und Ihr Management überhaupt bereit, neue Technologien einzusetzen? Dies könnte Ihr größtes Hindernis sein. Wenn Sie das Gefühl haben, dass sie nicht aufgeschlossen sind, können Sie versuchen, sie mit großen formellen Präsentationen zu überzeugen... oder probieren Sie es einfach aus (siehe unten).

2. Googeln Sie doch mal nach Problemen, die andere damit haben. Wenn Sie nicht viel finden, dann werden Sie bei Problemen auf Folgendes stoßen

3. Finden Sie ein neues kleines Projekt mit sehr geringem Risiko (z. B. etwas, das nur Sie oder ein paar Leute benutzen würden), wenden Sie die neue Technologie in Skunkworks-Manier an, um zu sehen, wie es sich entwickelt.

4. Versuchen Sie, den reifsten der Unreifen zu finden. Wenn Sie zum Beispiel über einen NoSQL-Datenspeicher nachdenken. Alle NoSQL-Produkte sind im Vergleich zu RDBMS wie Oracle, die es seit Jahrzehnten gibt, noch unausgereift. Suchen Sie also nach der ausgereiftesten Lösung, für die es Support-Organisationen gibt, entweder professionell oder über Support-Gruppen.

5. Am einfachsten ist es, ein bestehendes Projekt zu beginnen, indem man eine bestehende Software umschreibt. Sie haben bereits Ihre Anforderungen: Machen Sie es genau wie que . Wählen Sie einfach einen kleinen Teil der Software aus, den Sie mit der neuen Technologie neu schreiben, vorzugsweise etwas, das Sie mit Unit-/Load-Tests testen können, um zu sehen, wie es sich bewährt. Ich plädiere nicht dafür, eine ganze Anwendung neu zu schreiben, um sie zu testen, sondern nur einen kleinen, messbaren Ausschnitt.

Answer 2

Ein paar Faustregeln.

Verwenden Sie immer nur eine "neue" Technologie auf einmal. Je mehr neue Dinge Sie verwenden, desto größer ist die Wahrscheinlichkeit, dass ein ernsthaftes Problem auftritt.

Vergewissern Sie sich, dass es einen Vorteil bringt, es zu benutzen. Wenn diese coole, neue Technologie Ihnen keinen Vorteil bringt, warum verwenden Sie sie dann?

Planen Sie die Lernkurve ein. Es wird Aspekte der neuen Technologie geben, mit denen Sie nicht vertraut sind. Sie und Ihr Team werden mehr Zeit damit verbringen müssen, sich mit ihnen vertraut zu machen, als Sie denken.

Wenn möglich, sollten Sie die neue Technologie zunächst an einem kleinen, weniger wichtigen Projekt ausprobieren. Das Buchhaltungssystem Ihres Unternehmens ist nicht der beste Ort für Experimente.

Haben Sie einen Plan für den Notfall. Neue Technologien erweisen sich nicht immer als lohnend. Erkennen Sie, wann Sie sich in einer "Sarg-Ecke" befinden und es an der Zeit ist, auszusteigen.

Answer 3

Es gibt einen Unterschied zwischen "praxiserprobt" und "veraltet". Entwickler (mich eingeschlossen) bevorzugen im Allgemeinen die neuesten Entwicklungen. Bis zu einem gewissen Grad müssen Sie Ihr Entwicklungspersonal bei Laune halten und dafür sorgen, dass es sich für seine Arbeit interessiert.

Aber ich habe noch nie einen Kunden gehabt, der mit einer in der Praxis erprobten Technologie unzufrieden war. Im Allgemeinen wissen sie nichts von der Technologie, die bei der Herstellung eines Produkts zum Einsatz kommt, oder es ist ihnen gleichgültig. Ihre oberste Priorität ist, wie es im täglichen Umgang mit dem Produkt funktioniert.

Wenn ich ein neues Projekt beginne, stelle ich mir zwei Fragen, wenn ich überlege, ob ich zu einer neuen Plattform wechseln sollte:

1) Welche Vorteile bringt mir der Wechsel zur neuen Plattform? Wenn sie mir eine drastische Verkürzung der Entwicklungszeit oder erhebliche Leistungssteigerungen für die Nutzer bietet, werde ich eine halbwegs fortschrittliche Technologie in Betracht ziehen.

2) Welche Risiken sind mit der neuen Plattform verbunden? Ist es wahrscheinlich, dass ich auf einige Szenarien stoße, die in der neuen Plattform nicht ganz ausgereift sind? Ist es wahrscheinlich, dass die Unterstützung für diese neue Plattform ausläuft und ich auf der Unterstützung einer veralteten Umgebung sitzen bleibe? Gibt es Supportkanäle, die ich nutzen kann, wenn ich an einem kritischen Punkt meines Projekts feststecke?

Wie alles ist es eine Kosten-Nutzen-Analyse. Im Allgemeinen lerne und trainiere ich zwar immer neue Technologien, aber ich werde nichts für einen Kunden entwickeln, das eine Technologie (Umgebung, Bibliothek, Serverplattform usw.) verwendet, die nicht seit mindestens 6-12 Monaten von einer großen Anzahl von Entwicklern angenommen wurde.

Answer 4

Das hängt vom jeweiligen Kontext ab. Jede Organisation muss ihre eigenen Entscheidungen treffen. Die klassische Literatur zu diesem Thema ist Die Überwindung der Kluft von Geoffrey A. Moore.

Answer 5

Wenn das Unternehmen/die Gemeinschaft, das/die das Produkt entwickelt, für gute Produkte bekannt ist, dann setze ich sehr gerne auf ihre neuen Produkte.

Ich würde zum Beispiel sehr gerne auf Rails 3 oder Ruby 1.9 entwickeln, da ich mir sicher bin, dass sie gut sein werden, wenn sie fertig sind.

Allerdings würde ich nicht viel Code in superNewLang schreiben, bis ich davon überzeugt bin, dass sie ein großartiges, gut unterstütztes Produkt haben, oder dass sie eine Funktion haben, ohne die ich nicht leben kann.

Ich neige dazu, das vertrauenswürdigste Produkt zu kaufen, das alle meine Bedürfnisse erfüllt.