Quick and Dirty
Inhaltsüberblick
Leseprobe 1
Leseprobe 2
Inhaltsverzeichnis
Buch bestellen
Presse
Impressum




Wie entwickelt man eine gute Softwarearchitektur?

Ein mittelständischer Software-Unternehmer rief mich an, er bräuchte jetzt Unterstützung von einem Externen, da seine Entwickler alle für 2 Jahre beschäftigt seien: Sie bauten an einem ganz tollen zukunftstauglichen System mit der ultimativen Softwarearchitektur. Leider aber könnten seine Kunden nicht so lange warten und deshalb brauche er jetzt zusätzliche Kapazität, um die Kundenanforderungen zu erfüllen.

Das ist eine weit verbreitete Situation, denn ich erlebte sie auch bei einem großen Telekommunikationskonzern als die gesamte Entwicklung von annähernd 200 Softwareentwicklern sage und schreibe 5 Jahre mit der Entwicklung eines Systems mit einer solchen zukunftstauglichen Softwarearchitektur beschäftigt war. Schließlich gerieten auch hier die Kundenwünsche so ins Hintertreffen, dass eine ernsthafte Krise eintrat.

Hinter dieser Art von Vorgehen steht die Idee, dass die Entwicklung einer guten Softwarearchitektur extra Anstrengungen und Aufwand erfordern würde. Das heißt, in eine gute Softwarearchitektur müsse man Zeit und Entwicklungskapazität investieren und das nicht zu knapp.

Das scheint so selbstverständlich und richtig, dass es so gut wie niemals hinterfragt wird.

Ich möchte deshalb hier als Kontrast das genau gegenteilige Vorgehen gegenüberstellen:

Ein bestimmtes Ziel oder auch ein bestimmter Nutzen wird auf ganz direktem Wege ganz unmittelbar angestrebt. Das heißt, das zu entwickelnde System wird auf dem schnellst-möglichen Weg entwickelt. Das ist das, was auch als Quick and Dirty bezeichnet wird.

Bei dieser Art des Vorgehens, wird über Softwarearchitektur gar nicht groß nachgedacht. Es entsteht natürlich trotzdem eine Struktur, die man als Softwarearchitektur ansehen kann. Sie entsteht irgendwie von selbst.

Um beide Vorgehensweisen ein bisschen besser in Beziehung setzen zu können, möchte ich ein paar Begrifflichkeiten einführen und klären:

Es gibt in der Softwareentwicklung ein WIE und ein WAS: Das WAS ist das Ziel, was erreicht werden soll, der Zweck des zu entwickelnden Systems. Das WIE sind die konkreten Lösungen, wie es umgesetzt wird. Dazu gehört auch die Softwarearchitektur. Die Leistungsmerkmale und der Hauptzweck eines Systems gehören zum WAS und die Softwarearchitektur zum WIE.

Hinter jenem eingangs geschilderten Vorgehen, mit großem Aufwand eine zukunftstaugliche Softwarearchitektur zu entwickeln, steht also folgende Annahme:

Es ist in Softwareentwicklung nötig oder sinnvoll, für ein gutes WIE, einen (teilweise ganz erheblichen) Mehraufwand zu investieren.

Dem möchte ich jetzt eine ganz andere Annahme entgegensetzen:

Die schnellste und direkteste Lösung, bringt automatisch die besten Ansätze zur Softwarearchitektur hervor - ohne dass groß darüber nachgedacht wird.

Schauen wir uns das Ganze noch ein bisschen genauer an:

Hinter der großen zeitraubenden Anstrengung, eine zukunftstaugliche Softwarearchitektur hervorzubringen, steht die Angst, eine Softwarearchitektur könne sich als ungeeignet herausstellen und dann muss man alles noch mal machen.

Und diese Angst ist im Grunde auch berechtigt. Denn Softwarearchitekturen gelangen regelmäßig an ihre Grenzen und dann steht man vor der Alternative, entweder eine schlechte Softwarearchitektur mit sich herumzuschleppen oder das System neuzuentwickeln.

Deshalb scheint es so richtig und vernünftig, ganz viel Anstrengung und Aufwand im Vorhinein in eine zukunftstaugliche Softwarearchitektur hineinzustecken.

Der Witz ist nur, dass es nicht möglich ist, diese Dinge vorauszudenken. Die wirklich relevanten Informationen für gute Softwarearchitektur liefert immer nur die Praxis.

Wenn man immer den schnellsten, direktesten Weg geht, dann muss man von Zeit zu Zeit das System neu aufsetzen. Das ist aber kein Problem, weil das System extrem klein und schlank ist. Auf diese Weise erhält man mit der Zeit die richtig guten wirklich tragfähigen Softwarearchitekturen.

Während bei dem anderen Vorgehen große unflexible Monstersysteme herauskommen, die neuzuentwickeln gar nicht so einfach möglich ist. Man bindet sich damit dauerhaft an Strukturen, die ganz schnell nicht mehr optimal geeignet sind und von denen man aber dann nicht mehr loskommt.
 

die kreative Lücke Entwicklungsmethoden Informatik Kreativität Softwarearchitektur
 
 
Impressum © 2007-2016 Alle Rechte vorbehalten