Eine falsch ausgerichtete Ansicht: Priorisierung von Peers gegenüber Benutzern
Wie oft haben Sie sich den Code von jemandem angesehen und gesagt:
Ich benutze das nicht, weil es nicht gut geschrieben aussieht.
Und in diesem Fall könnte „gut geschrieben aussehen” entweder ein Ersatz sein für:
- „so aussehen, wie ich es schreiben würde”,
- „erscheinen mir sinnvoll”
Sicher – es gibt Zeiten, in denen die Verwendung von Open-Source-Code riskant ist. Wir kennen dies von den verschiedenen Software und Diensten, die Schwachstellen aufweisen. Aber behandeln Sie diese zumindest für diesen Beitrag als Ausnahme – nicht als Regel.
Dies bedeutet, dass wir uns etwas ansehen müssen, das wir verwenden können, uns aber gegen die Verwendung entscheiden, weil es nicht so geschrieben zu sein scheint, wie wir denken, dass es geschrieben werden sollte.
Priorisierung von Peers gegenüber Benutzern
Die Entwicklung ist schwierig, weil wir – oder andere Entwickler – mehrere Kompromisse eingehen müssen, wenn sie etwas bauen.
Von innen nach außen schauen
Wir müssen bedenken:
- Zeit- und Budgetbeschränkungen,
- Welches Paradigma wird uns helfen, einen Solid innerhalb dieser Einschränkungen zu liefern,
- löst die endgültige Lösung wirklich das Kernproblem,
- Entstehen Wartungskosten im Zusammenhang mit der Art und Weise, wie wir etwas zusammengestellt haben?
Und die Liste ließe sich fortsetzen.
Sich mit den verschiedenen Aspekten der Entwicklung auseinanderzusetzen und Philosophien zu diskutieren, wie etwas gebaut werden soll, ist in unserer Branche keine Seltenheit
Aber es ist auch zeitaufwändig, und es kann sich als eine Übung herausstellen, die ein Nettoergebnis von Null ergibt, weil nichts dabei herauskommt. (Ja, es kann oft eine Lernerfahrung sein, aber nicht immer.)
Foto von José Alejandro Cuffia auf Unsplash
Blick von außen nach innen
Praktisch aber:
- Wirkt sich das zum Erstellen der Lösung verwendete Paradigma auf Ihre Nutzung der Software aus?
- Löst die betreffende Software das Problem?
- Wenn Sie nicht sehen könnten, wie das Projekt zusammengestellt wurde, welches Fazit würden Sie über die Software ziehen?
Und der letzte Punkt ist möglicherweise der kritischste, wenn es um Open-Source-Software geht.
Ich habe lange genug in der Branche gearbeitet, um zu wissen, dass Menschen oft eine funktionale Lösung suchen, die ihr Problem löst, und sie davon ausgehen, dass sie sicher gebaut ist.
Entwickler hingegen prüfen den Code mehr als die Lösung, die er bietet, und das Problem, das er löst.
Wenn Sie ein Entwickler sind, gibt es absolut eine Zeit und einen Ort für beides. Aber wenn Sie sich von letzterem daran hindern lassen, ersteres zu versenden, bekommen Sie möglicherweise nie etwas heraus, das andere verwenden können, weil Sie sich zu viele Gedanken darüber machen, was Ihre Kollegen denken könnten.
Und wenn Sie ein Problem für andere Menschen lösen, sollten sie derjenige sein, der mehr zählt als Ihre Kollegen.