Kaufen oder selber machen?

Entwicklungsteams stehen regelmäßig vor der Frage, ob ein Stück Software eingekauft oder selbst gemacht werden sollte. Diese Frage stellt sich sogar nicht nur Softwareentwicklern sondern jedem Menschen. Mache ich etwas selbst oder lasse ich es einen Experten machen? Bin ich der Experte oder ist der andere der Experte? Investiere ich Zeit und spare Geld oder investiere ich Geld und spare Zeit? Soziologie und die eigene Weltanschauung spielen bei der Beantwortung dieser Fragen und bei Entscheidungen eine große Rolle.

Um in der Welt der Softwareentwicklung zu bleiben, ist hier ein kleines Beispiel. Es geht um ein Web-Template. Es kann entweder ein fertiges Template gekauft werden oder man kann das Template selber bauen. Zunächst können einmal die Vor- und Nachteile beider Alternativen gegenübergestellt werden.

Kaufen

Vorteile

  • Das Template ist bereits fertig und kann sofort verwendet werden. Bei Bedarf kann es noch ein wenig angepasst werden, aber es ist bereits vollständig und umfangreich.
  • Das Template ist professionell gestaltet. Design, Layout und Look & Feel sind konsequent und kongruent.

Nachteile

  • Manche Komponenten sind nicht gut genug. Es gibt bessere Lösungen für Inputs, Tabellen und Charts.
  • Das Template ist schwergewichtig. Es enthält viele Komponenten und Funktionen, die gar nicht gebraucht werden.

Selber bauen

Vorteile

  • Ein eigenes Template ist maximal flexibel. Es können beliebige Komponenten verwendet werden.
  • Ein eigenes Template ist leichtgewichtig. Es enthält nur genau die Funktionen und Komponenten, die benötigt werden.

Nachteile

  • Ein eigenes Template muss erstmal entwickelt werden. Es entsteht Basisaufwand, der leicht unterschätzt wird.
  • Ein eigenes Template ist lange unvollständig. Vor allem wenn die Lösung in Design, Layout, Responsiveness und Look & Feel vergleichbar sein soll.

In dieser Gegenüberstellung kann der Begriff “Template” durch “Lösung” ersetzen werden. Das Schema bleibt gleich.

Eigene Meinung

Um maximal produktiv zu sein, würde ich jederzeit Geld in Zeit eintauschen. Um Zeit zu sparen bin ich bereit Geld zu investieren. Natürlich muss der Preis verhältnismäßig sein, aber darum geht es hier nicht. Die Nachteile einer gekauften Lösung sind schnell kompensiert. Unzulängliche Komponenten können durch bessere ersetzt werden. Nicht verwendete Funktionen können entfernt und das Template somit leichtgewichtiger gemacht werden. Diese Anpassungen sind unkompliziert und schnell. Es war schon immer leichter Dinge wegzulassen, als sie neu zu schreiben. Dadurch werden die Vorteile der Eigenentwicklung relativiert.

Wir sollten anfangen, an unseren USPs zu arbeiten statt uns an 0815-Basisentwicklung aufzuhalten. Wir neigen schnell dazu alles selber machen zu wollen. Manche Dinge müssen leider aus technischen, fachlichen und rechtlichen Gründen selbst gemacht werden. Da können dann keine fertigen Lösungen verwendet werden. Aber es gibt auch viele andere Dinge, bei denen von fertigen Lösungen profitiert werden könnte. Oft wird dort dann allerdings auch gerne auf den Produktivitäts-Boost verzichtet und die Lösung ebenfalls selbst gebaut.
Das ist das klassische Not Invented Here Syndrome. Man glaubt, dass die Eigenentwicklung besser, kontrollierter und schneller erfolgt als die bestehende. Verhaltensforscher führen viele Gründe für die Abneigung gegenüber Bestehendem an. Die prominentesten Gründe sind Mangel an Verständnis der bestehende Lösung und die Unwilligkeit, die Arbeit anderer anzuerkennen oder zu schätzen. Leslie Hannah führt dieses soziale Phänomen sogar auf eine Form des Tribalismus zurück.

Entscheidung

Am Ende des Tages steht eine Entscheidung. Entscheidungen müssen uns in die Lage versetzen, schnell und gut handeln zu können. Natürlich können wir alles mögliche entscheiden, aber wenn wir das Entschiedene nicht umsetzen können, ist die Entscheidung hinderlich und lähmend. Die Entscheidung “Kaufen” oder “Selber bauen” kann also nicht sinnvoll von oben entschieden werden. Deswegen müssen diejenigen, die viel mit dem Ergebnis arbeiten werden, auch aktiv mitentscheiden. Diejenigen, die wenig oder gar nicht mit dem Ergebnis arbeiten, dürfen auch nur wenig mitentscheiden. Was aber sehr wohl vorgegeben werden kann, sind Anforderungen und Budget. In diesem Kontext ist es dann die Verantwortung der Entwickler, die Ressourcen nicht zu verschwenden und die beste technische Lösung zu finden.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s