Die Planung am Anfang von einem IT-Projekt ist immer relevant – bei großen wie bei kleinen Projekten. Der Umfang hängt von den Bedingungen ab, die gegeben sind. Ein Lastenheft, in dem akribisch festgehalten wird, was im Detail geplant ist, verschafft Firmen Rechtssicherheit und spart Geld. Bei einem kleineren Ein-Mann-Projekt kann man sich unter Umständen mehr von seiner Kreativität inspirieren lassen und spontan sein.

Auf eine Frage stoße ich dennoch immer wieder, und zwar in beiden Umfeldern: Wähle ich eine andere Programmiersprache, ein geeigneteres Architekturmodel, ein neues Framework? Oder bleibe ich bei meinem bisherigen Standard und spare damit viel Zeit?

Diese Frage zu beantworten, fällt mir nicht immer leicht. Der bekannte als auch der neue Weg bietet Chancen und Nachteile, die ich in diesem Post mal beleuchten möchte.

Die Einen wollen so, die Anderen so

Fangen wir mal mit den Unternehmen an. Es ist eine neue Android-App geplant, alles soll von Grund auf neugestaltet und programmiert werden. Zur Auswahl stehen zwei Programmiersprachen. Die Wahl wird den Verlauf des IT-Projekts, vielleicht sogar das Schicksal der Firma, beeinflussen.

Im Grunde ist man sich einig: Es war schon immer Java, wir beherrschen es, also verwenden wir es auch. Soweit die Perspektive der EntwicklerInnen, die auch absolut nachvollziehbar ist. Warum sollte ich mich mit etwas Neuem beschäftigen, wenn mich das Bisherige viel schneller an mein Ziel bringt?

Könnte man so stehen lassen, wären da nicht der Zahn der Zeit und betriebswirtschaftliche Interessen. Diese geben nicht nur den Zeitrahmen, sondern auch die Qualität des fertigen Produktes vor. Wir wollen nicht genauso gut wie die anderen sein, wir wollen besser als die anderen sein. Besser bedeutet in der IT-Branche in der Regel performanter und moderner. Und auch persönlich wollen wir ja als EntwicklerInnen unser Know-How erweitern – Fortschrittlichkeit spielt eine große Rolle in der Informationstechnik.

Manchmal ist es wertvoll, einen größeren Zeitaufwand am Anfang in Kauf zu nehmen. Es zahlt sich im Verlauf der Arbeit aus, wenn auf dem neuen Weg Zeit gespart wird. Außerdem erweitern die EntwicklerInnen ihr Know-How, was für Unternehmen immer einen Mehrwert bietet.

Neue Wege stellen sicher, dass ein fertiges IT-Projekt nicht aus der Zeit fällt und nach dem ersten Release schon auf dem Weg in die Versenkung ist. Immerhin vergehen von der Planung bis zum ersten Release oft Monate oder Jahre.

Sind wir morgen noch modern?

Eine weiterer Punkt ist die Frage, wie aktuell der Weg in zwei bis fünf Jahren noch sein wird. Wenn ich im Jahr 2020 eine WPF-Anwendung entwickle, muss ich mich mit der Frage beschäftigen, ob WPF in den nächsten fünf bis zehn Jahren noch unterstützt wird. Und ob es sich wirtschaftlich überhaupt noch lohnt (oder ich von der Konkurrenz längst mit einer browserbasierten Lösung abgehängt wurde).

WPF war nur ein Beispiel. Es gibt an dieser Stelle zahllose Beispiele, bei denen abgewägt werden muss. Auch bei den browserbasierten Lösungen.

Es ist denkbar, dass dann doch eher die moderne Lösung das Mittel der Wahl wird. Niemand profitiert davon, wenn eine Anwendung entwickelt wird, deren Basis in wenigen Jahren sowieso eingestampft wird. Außer vielleicht die EntwicklerInnen, die ein Unternehmen infolgedessen unter Zeitdruck einstellen muss.

Es braucht EntwicklerInnen

Neben der Modernität des Weges spielt auch die Personalfrage eine Rolle. Der gewählte Weg sollte eine gute Zukunftsperspektive bieten – aber was ist mit den EntwicklerInnen? Die nächsten Generationen werden in ihren Ausbildungen und Studiengängen vermehrt mit browserbasierten Lösungen konfrontiert werden. Solche sind eben modern und liegen heute mehr im Trend als je zuvor. Die EntwicklerInnen, die noch Assembler beherrschen und Pascal programmieren können, werden weniger.

Da entsteht die Vermutung, Unternehmen, die heute auf weniger moderne Ansätze setzen, könnten in den kommenden Jahrzehnten ernste Probleme bekommen. Eine lange supportete Technologie braucht selbstverständlich auch EntwicklerInnen, die damit arbeiten wollen.

Im Vordergrund sollte natürlich immer stehen, wie das Produkt vom gewählten Weg profitierten würde. Aber die Frage des Personals, das das Produkt in Zukunft betreuen soll, sollte bewusst in diesen Entscheidungsprozess mit einbezogen werden.

Ein Mann, ein Wort

Bei Ein-Mann-Projekten wird es weniger kompliziert – zu denen ich offen gesagt auch viel mehr sagen kann, als Hobbyentwickler und als Freiberufler, da die meisten meiner Projekte solo ablaufen.

Ich probiere zwar gerne neue Konzepte aus (gehe neue Wege), aber die Verlockung, alten Mustern zu folgen, ist trotzdem groß. So hat sich das PHP-Framework Laravel zum Beispiel in den letzten zwei Jahre bei mir bewährt. Viele Kundenaufträge sollen in relativ kurzer Zeit fertiggestellt werden, da macht es Sinn, etwas Vertrautes zu nutzen.

Anders sieht das bei Projekten aus, die sich von den bisherigen deutlich abheben. Es bietet sich an, dann Neues auszuprobieren, und es beeinflusst oft die Performance positiv. Bei umfangreicheren Projekten sind die Kunden gleichzeitig viel geduldiger und bereiter, eine Weile auf erste Resultate zu warten.

Für das persönliche Know-How ist es unverzichtbar, gelegentlich Neues auszuprobieren. Sonst hängt man irgendwann hinterher und ist nicht mehr gefragt. Wenn es beruflich keinen Platz findet, muss es in der Freizeit nachgeholt werden.

So viel zum „What“. Und was ist mit dem „So What“?

Im ersten Teil ging es um das What, um die Ausgangslage und wie sich diese in unterschiedlichen Situationen bewerten lässt. Aber welche Erkenntnisse ergeben sich daraus und wie kann man sie in die eigene Arbeitsweise integrieren (das So What)?

  1. Die Lage bewerten
    Es bietet sich auf jeden Fall in allen (semi)professionellen Umfeldern an, sich die Frage nach dem geeigneten Weg zu stellen. Einfach drauf losarbeiten führt immer zu Fallstricken. Es sind Lektionen, die jede/r EntwicklerIn am Anfang der Karriere lernt, im unternehmerischen Umfeld kann das aber richtig teuer werden oder den ersten Release-Termin blockieren. Optimal ist es, die Lage erst einmal grob zu bewerten:
    Wo will ich mit meinem Projekt hin?
    Gibt es eine Deadline oder einen Release-Termin?
    Hängt vom Produkt mein Erfolg als Freelancer ab?
  2. Zukunftstauglichkeit checken
    Wie angesprochen, nützt es nichts, ein Produkt zu entwickeln, das zehn Jahre auf dem Markt Bestand haben soll, dessen Grundlage aber vielleicht schon nach wenigen Jahren wegbricht. Dann heißt es neuentwickeln und eventuell provoziert man sogar, dass das Produkt bei Kunden ausfällt. Da ist anfangs richtig gründliche Recherche gefragt, im Zweifel sollte man andere Fachkundige nach ihrer Meinung fragen.
  3. Die Personalfrage
    Bevorzugt sollten Wege in Frage kommen, für die auch noch in Zukunft Mitarbeiter gefunden werden können. Es nützt – ähnlich wie im vorherigen Absatz beschrieben – nichts, auf eine Technologie zu setzen, die in zwei bis fünf Jahren ausstirbt. Das trifft natürlich eher auf das unternehmerische Umfeld zu. Der Aufwand bei einem Ein-Mann-Projekt ist wahrscheinlich eher überschaubar.
  4. Die Entscheidung
    Sollte dann auch konsequent umgesetzt werden. Ich habe keine guten Erfahrungen damit gemacht, Mitten im Projekt eine Mischung aus zwei Wegen einzubringen. Nachteile bietet jeder Weg, immer. Aber mit der gezielten IT-Projektplanung federt man auch die Nachteile gekonnt ab. Das ist doch letzten Endes das Beeindruckende in der Softwareentwicklung – Vorteile ausspielen und Nachteile bzw. Probleme gekonnt umschiffen.