Technologien - Die soziale Seite

Softwareentwicklung findet im Team statt und hat daher einen sozialen Aspekt. Aber wie viel Rücksicht sollte man darauf nehmen?

In Pocket speichern vorlesen Druckansicht 8 Kommentare lesen
Lesezeit: 2 Min.
Von
  • Eberhard Wolff

Softwareentwicklung findet im Team statt und hat daher einen sozialen Aspekt. Aber wie viel Rücksicht sollte man darauf nehmen?

Für Technologieentscheidungen gibt es viele Einflussfaktoren. Ob es darum geht, serverseitig HTML zu erzeugen oder eine Single-Page App (SPA) zu entwickeln, eine NoSQL-Datenbank oder eine relationale Datenbank einzusetzen, Containerisierung oder Bare Metal zu nutzen: Neben der technischen Eignung beeinflussen auch soziale Aspekte solche Entscheidungen. Wenn alle anderen Faktoren gleich sind, ist die Technologie risikoärmer, mit der das Team bereits gearbeitet hat. Neben Erfahrung spielt auch Motivation eine Rolle: Technologien, die das Team gerne nutzen will, können eine bessere Wahl sein.

Interessant wird es, wenn der soziale Aspekt im Widerspruch zu anderen Aspekten steht. Schließlich haben die Technologien immer bestimmte Stärken und Schwächen. In einigen Situationen sind SPAs die bessere Wahl, in anderen serverseitiges HTML. Relationale Datenbanken und NoSQL-Datenbank sind in unterschiedlichen Situationen unterschiedlich sinnvoll.

Im Extremfall nutzt das Projekt eine unpassende Technologie und Architektur, weil die Team-Mitglieder die Technologie oder Architektur präferieren oder schon Erfahrungen damit haben. So werden die eigentlich passende Technologie und Architektur nicht umgesetzt. Sollte man auch in solchen Situationen so einen starken Fokus auf die soziale Seite der Entscheidung legen?

Hinzu kommt: Ein Pragmatic Prgrammer sollte pro Jahr mindestens eine neue Programmiersprache lernen. Gilt das nicht noch viel mehr für Technologien oder gar Architekturkonzepte? Warum also solche Situationen nicht nutzen, um neue technische Skills zu erlernen?

Technologie- und Architekturentscheidungen haben soziale Aspekte. Diese spielen manchmal aber eine zu große Rolle. Ergebnis: Schlechte Technologiewahl, schlechte Architektur und eine vergebene Gelegenheit, Neues zu lernen.

Danke an meine Kollegen Frederik Dohr, Christoph Iserlohn, Tammo van Lessen, Till Schulte-Coerne, Michael Simons, Christian Stettler und Stefan Tilkov für das Feedback zu einer früheren Version des Blog-Beitrags. ()