Jeder Softwareentwickler möchte an anspruchsvollen Projekten arbeiten, die ihn fordern und seinen Horizont erweitern. Leider ist das nicht immer die klügste Entscheidung, wie auch die nachfolgende (vielleicht) fiktive Begebenheit verdeutlicht.

Die Geschichte…

Karl, leitender Softwarearchitekt in einem mittelständischenTechnologieunternehmen, sitzt an seinem Schreibtisch und arbeitet sich durch die Spezifikationen für das aktuelle Entwicklungsprojekt. Während er sich gerade einen Überblick verschaffen will, betritt Nachwuchsentwicklerin Jennifer überschwänglich den Raum.

"Hey, ich hab' gehört, in unserem neuen Projekt geht es auch um Verschlüsselung. Diesen Part würde ich echt gerne für das Projekt übernehmen! Ich habe mich auch in den letzten Wochen mit diversen Algorithmen in diesem Bereich beschäftigt", schlägt es Karl voller Tatendrang entgegen. Dieser weiß den Enthusiasmus seiner jungen Kollegin natürlich zu schätzen - hört aber innerlich bereits diverse Sirenen anlaufen.

Nachdem er sich kurz berappelt hat, antwortet er: "Danke Jenny, ich weiß das Angebot zu schätzen, aber ich sag es Dir ganz offen - daraus wird nichts. Und ich sag Dir auch warum: Encryption ist schwer - und gefährlich. In diesem Bereich warten die bösen Jungs nur darauf, dass ein kleiner Fehler passiert. Jede Lücke, jeder Bug - ein Problem jeglicher Art könnte uns massiven Sicherheitsrisiken aussetzen."

Jennifer ist jedoch nicht der Typ, der schnell das Handtuch wirft und versucht weiter ihr Glück. Mit festem Blick antwortet sie: "Aber ich könnte es doch trotzdem versuchen - ich bin dieser Herausforderung auf jeden Fall gewachsen!"

Diesmal zögert Karl schon deutlich kürzer und entgegnet: "Bei allem Respekt, aber das bist du nicht. Um ehrlich zu sein, ich sehe mich nicht einmal annähernd in der Lage, das zu behaupten - das sind wohl die wenigsten Devs. Encryption ist etwas, das in die Hände von Experten gehört. Solche, die schon mehrere kampferprobte Open-Source-Lösungen entwickelt haben. In diesem Bereich muss einfach alles sitzen, ansonsten kommen wir alle in Teufels Küche."

Schließlich merkt Jenny, dass sie auf Granit beißt - und verabschiedet sich lächelnd: "Hmmm. Okay, das macht vermutlich Sinn. Aber Spaß hätte es mir bestimmt trotzdem gemacht."

Inspiriert vom Enthusiasmus seiner Kollegin beschließt Karl, es ihr gleich zu tun und die Dinge in die Hand zu nehmen. Er geht also ins Büro seiner Chefin und wartet darauf, dass sie ihm ihre Aufmerksamkeit schenkt. Als sie ihn nach einer gefühlten Ewigkeit fragend fixiert, legt Karl los: "Also Anja, ich habe ja nicht mehr oft die Gelegenheit, etwas selbst zu programmieren. Deswegen möchte ich das Message-Queueing-System für unser neues Projekt persönlich übernehmen. Ich weiß, 'Build vs. Buy' ist immer eine schwierige Entscheidung, aber ich würde das wirklich gerne tun."

Überzeugt von seiner Idee und ein bisschen stolz auf seine verbale Performance lehnt sich Karl zurück und erwartet, für seinen Enthusiasmus gelobt zu werden. Managerin Anja lächelt kurz und antwortet ihm dann: "Ich weiß Karl, das würde dir gefallen. Aber ich sag es dir ganz offen: Daraus wird nichts."

Die Ironie der Dinge verleitet Karl trotz der Absage zu einem ausgeprägten, innerlichen Lächeln. Anja fährt fort: "Ich weiß, dass Sie gut sind, aber selbst Sie werden zugeben müssen, dass Sie nicht so gut sind. Message-Queueing-Systeme sind komplex - und sie zu optimieren noch viel mehr. Es gibt jede Menge voll funktionsfähiger, vollständiger, funktionierender und bewährter Open-Source-Lösungen dafür. Das geht einfach schneller und ist auch sinnvoller, weil Experten diese Systeme gebaut haben. Du würdest bestimmt etwas zum Laufen bringen, aber es würde mit Sicherheit sehr lange dauern, bis alle Anforderungen abgedeckt wären. Und selbst dann könnten wir uns diesbezüglich nicht ganz sicher sein. Ich weiß, dass du das gerne übernehmen würdest, aber ich kann dir diese Zeit einfach nicht einräumen. Und ich denke, du musst auch selbst zugeben, dass Risiko und Folgekosten einfach zu hoch sind."

Karl kann angesichts der überbordenden Wahrheiten nur noch zustimmend nicken. Seufzend lenkt er nach einigen Sekunden auch verbal ein: "Hmmm. Okay, ich schätze das macht Sinn. Aber Spaß hätte es mir trotzdem gemacht."

…und ihre Moral

Man kann es weder Karl noch Anja verübeln: Jeder möchte an anspruchsvollen Projekten partizipieren, die den Horizont erweitern. Dazu kommen die Verlockungen respektive Irrwege des Ego-Driven Programming: Zu glauben, man ist schlauer und leistet bessere Arbeit als "irgendein" Unternehmen mit einer "generischen" SaaS-Lösung, ist in den meisten Fällen eine fatale Fehleinschätzung.

Selbst ein richtig teures Software-Abonnement kommt langfristig in den allermeisten Fällen günstiger als eine eigene Lösung zu entwickeln (und zu warten) - vorausgesetzt, sie entstammt den Händen von Profis, die über die nötigen Skills im jeweiligen Bereich verfügen. Wenn es also keinen wirklich zwingenden Grund dafür gibt, eine eigene Lösung zu entwickeln, lassen Sie es einfach und stecken Sie die Zeit lieber in Due Diligence. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.