Episode 6: Grenzen des Refactorings ::: Softwareprojekte

« Wörter und Zeichen eines Beitrags zählen : TinyMCE in Wordpress anpassen Barcamp Bodensee - Web-Konferenz im Mai 2008 in Friedrichshafen »

Episode 6: Grenzen des Refactorings ::: Softwareprojekte

22. April 2008 roland

Zu Episode 1 wurde ein Kommentar geschrieben der mir zeigte das auch noch andere Mitstreiter das Problem des Refactorings aktiv angehen. Die Aussage „Andererseits weiß ich, dass wenn ich die Firma verlasse, dann werden die Projekte andere nach mir übernehmen und wieder alles reverseengeneeren müssen. …wenn ich das Unternehmen verlasse, muss von vorne begonnen werden“ fand ich sehr passend.
Mit Refactoring kann man nicht die Welt retten. Ein Softwaresystem ist für mich wie ein lebender Organismus. Unsere Haut wird beispielsweise alle sieben Jahre erneuert. Bei Software verhält sich das im Prinzip genauso.

Orlando war mal wieder auf einer Schulung

Ok, da war er schon in Episode 3 und das hat auch seinen Grund. Orlando ist Single und liebt es in Hotelzimmern herumzuhängen. Da das Familienunternehmen zur Zeit noch nicht in mehreren Ländern vertreten ist, ist es für ihn die einzige Möglichkeit das Jet-Set-Gefühl zu erleben.
Bei der Schulung wurde der Model Driven Architecture-Ansatz besprochen. Wieder kam er freudestrahlend zurück und wollte das Erlernte sofort ausprobieren. Das ist auch eine typische Orlando Eigenschaft. Er nimmt gerne Neues an und versucht so viel wie möglich gleich zu implementieren.

Da es sich bei dem, von Hans, Karl und Orlando, betreuten System um ein hochriskantes, produktives System handelt, ist diese Freude an Neuem für Hans und Karl nicht unbedingt nachvollziehbar. Zuweilen sind Orlandos Kollegen sonderbar altmodisch und wollen vor allem ein überlebensfähiges, stabiles System haben.
Vielleicht liegt das an den Betonschuhen die am Ausgang von den schweren Jungs abgestellt wurden…
Wie dem auch sei. Hin- und wieder werden Hans und Karl von Orlando überredet etwas Neues zu implementieren. Die Drei wollten erreichen, dass die Entwicklung auf Dauer gesehen immer stabiler und sicherer wird. Deshalb schauten sie sich ihr System genauer an und überlegten ob Model Driven Architecture eventuell eingeführt werden kann.

Keine Architektur?

Karl schaute sich die bisherigen Architekturkonzepte an.
„Also im Moment sind wir mit einem Mischmasch zwischen prozeduraler Programmierung und objektorientierter Programmierung konfrontiert. Wenn wir das ändern wollen, müssen wir das ganze System am Besten wegwerfen und neu bauen.“
Die drei waren sich hier sehr einig. Ein Neubau würde jedoch einem langanhaltenden Tauchgang im Familienteich nahe kommen.
„Vielleicht können wir uns wenigstens eine Architektur überlegen wie es aussehen sollte und das als unsere Strategie definieren. Dann könnten wir beim Review darauf achten in die Richtung der Strategie zu arbeiten“, bemerkte der geschulte Orlando.
Hans nickte zustimmend.
„Das klingt schon eher machbar. Wir werden also mit dem Refactoring keine endgültige Lösung finden. Wir werden die, zur Zeit erkannten Fehler und Missstände, aufdecken und korrigieren können. Das System wird also nie fertig werden.“
Orlando überlegte:
„Ich glaube, dass ist eine normale Eigenschaft in komplexen Systemen. Jede neue Idee führt zu einer Änderung und diese Änderung erfordert neue Vorgehensweisen. Ich glaube das Geheimrezept liegt im Changemanagement und in der Umsetzung der Strategievorgaben. Lasst uns zuerst einmal eine Strategie für die nächsten drei- bis fünf Jahre definieren. Wir sollten dringend mit Giuseppe reden um zu erfahren was er alles vor hat. Dann können wir unsere IT-Bemühungen entsprechend auslegen.“

Vielleicht habt ihr euch schon hin- und wieder gefragt warum Firmen viel Geld für Enterprise Architektur ausgeben. Ich habe im Moment das Vergnügen mit den Architekten eng in einer Gruppe zusammen arbeiten zu können. Die Kollegen produzieren im Prinzip (außer Papier und endlosen Telefongesprächen ) nichts. Doch der Gewinn für die Firma ist, dass sie sich über die weiteren Jahre Gedanken machen. Es ist wichtig die IT-Landschaft, wie jede andere Prozesslandschaft, über die Jahre hin proaktiv zu bewirtschaften.
Unsere drei Freunde haben aus Angst vor Betonschuhen bisher nur reagiert. Mit dem Handwerkzeug Reverse Engineering, haben sie erreicht sich über Wasser zu halten und nicht zusammen mit ihrem alten System zu sterben. Doch um wirklich eine gute Zukunft zu haben, kommen sie um eine Strategie und eine sinnvolle Planung nicht herum. Es wird Zeit das wir eine Koordination in die Geschichte bringen!
Um ehrlich zu sein, ich bin gespannt wo dieses Blog noch hinführt…

miradlo bloggt