Dies ist die Heimat der Java User Group Nürnberg.


Sonntag, 13. Januar 2008

Hex and the City: Versionsaktualisierung

Hier meine erste Kolumne im dem kostenlosen Magazin KaffeeKlatsch. Wer die Zeitung noch nicht abboniert hat, kann hier lesen:

Hex and the City: Versionsaktualisierung

Zum Start möchte ich uns die Antwort auf alle Fragen, die in Zusammenhang mit dieser Kolumne auftreten, geben. 42. Diese Antwort ist natürlich nicht von mir. Aber ich denke (und hoffe), ich muss nicht erklären woher sie stammt.1 Nachdem wir uns jetzt auf den Umgang mit Fragen geeinigt haben, können wir beginnen. Immerhin ist der Fortschritt der Zeit zu konstant um Pausen einzulegen. Was gerade wir in unserer täglichen Arbeit stets beobachten. Kaum beenden wir ein Projekt – erfolgreich versteht sich2 - um in Produktion zu gehen mit der API ABC in Version 1.2.3 und dem Framework XYZ in Version 4.5.6, müssen wir feststellen (meist in einem kaffeebegleitenden Gespräch oder in einem Artikel), dass es ABC jetzt in Version 1.3.7 und XYZ in Version 5.0.b8 gibt. Außerdem heißt XYZ jetzt Xyzoon. Oder so ähnlich. Und alles andere zu benutzen gilt als nostalgisch. Nun gut, in manchen Bereichen bezeichne ich mich gern als klassisch, also nein, dass abgeschlossene Projekt wird nicht mehr geändert. Oder doch? Wie sollen wir mit Neuerungen umgehen? Entwicklung3 ist die große Herausforderung, der wir uns jeden Tag stellen müssen. Wir könnten vorpreschen und immer das Neueste benutzen oder immer vorsichtig sein und eine Version erst dann einsetzen, wenn andere sie jahrelang in Benutzung haben. Die Erfahrung zeigt, dass Extreme selten die besten Lösungen bieten. Welche Aspekte sind wichtig, wenn wir über die Einführung von Neuerungen nachdenken?

Mitarbeitermotivation: Hoffentlich kein Fremdwort. Wenn man Mitarbeitern stets verbietet mit neuen Technologien zu arbeiten, bleibt nicht nur die Technologie auf einem Stand stehen, sondern auch unser wertvollstes Gut. Stürzen wir sie hingehen ständig in neue Welten, kann sich ebenso Frustration breit machen. Ziel sollte eine ausgewogene und koordinierte Einführung neuer Technologien in jedem Projekt sein. Daher zu Beginn eines jeden Projektes die verfügbaren und in Frage kommenden Technologien kurz evaluieren und die Risiken bewerten. Mindestens eine Neuerung sollte in ein Projekt einfließen, Arbeit am Fließband macht immerhin niemand gern.4 Aber ein bestehendes Projekt? Wir sind auch froh, wenn wir einmal etwas abschließen können. Also ein Projekt nicht künstlich offen halten, dass motiviert sicher nicht.

Beseitigung von Fehlern/Stabilität: Ich würde Technologien in einem laufenden Projekt nur anpassen, wenn die neuen Versionen Fehler beheben, auf die wir stoßen oder für das weitere Projekt benötigte Features liefern, die uns das Leben erleichtern. Allerdings muss hier unbedingt das Risiko abgewogen werden, zum Beispiel was Kreuzanforderungen an andere Technologien betrifft. Muss man vielleicht deutlich mehr auf neueren Stand bringen, wenn man „nur" eine API austauscht? Fast immer ist die Antwort darauf ja (oder 42, wie wir ja gelernt haben), daher beim Aktualisieren niemals leichtfertig handeln. Und die Entwicklungsdauer ist hier ebenso entscheidend. Ein Projekt, das bald in Produktion geht, tut sich schwerer mit Änderungen, als ein Projekt, dass noch ein Jahr laufen wird. Ganz entscheidend sind hier die Tests: wir müssen anhand von ausreichenden Tests unbedingt verifizieren, dass sich an der Funktionalität und Lauffähigkeit unseres Projektes nichts verändert hat. Lediglich wer eine umfangreiche Testsuite besitzt, kann meines Erachtens Versionsupdates überhaupt in Betracht ziehen. Und mit umfangreich ist wirklich umfangreich gemeint. Das schließt also Blackbox- wie Whitebox-Unittest ein, Integrationstest und viel wichtiger als Basis für alle diese Tests ausgeklügelte Testszenarien.

Neue Projekte: Was bei neuen Projekten? Alles rein was es an Neuem gibt? Bereits unter dem Punkt Mitarbeitermotivation erwähnte ich die Risikobewertung. Selbst bei einem neuen Projekt können wir uns nicht immer leisten, auf Bewährtes zu verzichten. Neue Technologien bedeuten neue Fehlerquellen, nicht intensiv eingearbeitete Teammitglieder, kaum Erfahrungen in der weiten Welt des Internets. Wir sollten gut prüfen, welche Features wir brauchen, ob die enthaltenen Bugfixes vonnöten sein werden, und wie viele Risiken wir auf uns nehmen wollen. Bloß nicht jeden Hype mitmachen. Und wenn, dann Technologien nur in der Umgebung einsetzen, für die sie gedacht sind. Neues ist gut und wichtig, aber wir dürfen nicht die Kontrolle über ein Projekt verlieren. Daher die Bereiche identifizieren, in denen wir uns Neuerungen erlauben können und eventuell Berater ins Team holen, die uns mit Rat und Tat zur Seite stehen und ihr Wissen an das Team weitergeben.

Freigabe von Software: In einigen Unternehmen existieren Bollwerke, welche die Einfuhr neuer Software erschweren. Hier muss man Freigaben erhalten, um etwas produktiv nutzen zu können. Gerade unter solchen Bedingungen müssen wir darauf achten, dass es den Sinn des Schutzes einer konsistenten Softwarelandschaft nicht verliert und zu einer reinen Blockade wird, die uns zu langsam fortschreiten lässt. Wer hier Aktualisierungen durchführt, sollte die Freigaben rechtzeitig prüfen, bzw. beantragen. Der Sinn eines solchen Bollwerkes soll an dieser Stelle natürlich nicht in Frage gestellt werden. Es ist eine weitere Instanz zur Kontrolle von Neuerungen, die projektübergreifend handelt. Gemeinsames planen zu Beginn des Projektes, bzw. der Releasephasen kann spätere Probleme minimieren und ein gemeinsames Verständnis für die Zukunft in der Softwarelandschaft und in der Entwicklung fördern.

Neue Wege statt neuer Software: Manchmal sind es keine Softwareaktualisierungen oder neue Tools, die Mitarbeiter vorschlagen und gern einsetzen würden. Oft geht es lediglich um neue Arten mit Problemen bei der täglichen Programmierung umzugehen. Wir stoßen auf Fragen wie : „Warum benutzen wir hier keine Factory-Klassen", oder Bemerkungen derart „Es wäre viel schöner, wenn wir da Aspektorientierte Programmierung einsetzen" und ebenfalls „Das kann man auch gut in einer Zeile schreiben". Teilweise legitime Vorschläge, wobei mir gerade bei letzterem einige Szenarios einfallen, bei dem man dem Entwickler getrost sagen kann, dass es bezüglich Wartung, Lesbarkeit und Verständnis eine nicht ganz ausgereifte5 Idee ist. Wenn es sich nicht gerade um ein Konstrukt wie

if (result != true) {

return false;

} else {

return true;

}

handelt (ist schon traurig, aber tritt immer wieder auf). Aber zu dem generellem Umgang mit solchen Vorschlägen. Ich denke sie sollten jeweils durchaus auf den Prüfstand gestellt und im Einzelfall darüber entschieden werden. Und in keiner Form sollte jemals eine Antwort wie „Nein, dass haben wir noch nie so gemacht", oder „Das machen wir aber immer so" geäußert werden. Leider muss ich selbst manchmal solche Antworten weiterreichen, wenn ich lediglich Zwischenstation in der Entscheidung bin. Mir liegt dann immer direkt eine Entschuldigung an den Vorschlagseinreicher auf den Lippen, denn solche Willkür ohne echte Begründung lässt mich auch bloß den Kopf schütteln. Anders, wenn der Vorschlag selbst nicht ausreichend begründet ist: „Aber in einem Projekt hat das damals prima geklappt". Hier können wir gern sagen: „Das Risiko ist uns zu groß. Nur weil es einmal geklappt hat, muss es bei uns nicht funktionieren". Es ist wie in der großen kulinarischen Welt. Es gibt einen Grund, warum lokale Spezialitäten die regionalen Grenzen nicht überschritten haben.

Die Neue Welt: Und ein letzter Punkt, den man meines Erachtens auch nicht aus den Augen verlieren darf: der Zahn der Zeit nagt an allem, wir dürfen den Anschluss nicht verpassen. Wer sich jahrelang auf das bestehende verlässt und den Fortschritt um sich ignoriert, den wird irgendwann dieses Versäumnis einholen. Dann besitzt man nur noch Mitarbeiter, die sich mit dem Neuen nicht auskennen, und wenn der Tag kommt, an dem man tatsächlich umrüsten muss, sieht man sich mit großen Problemen konfrontiert. Wissensbeschaffung ist eines davon. Und jahrelanges Wissen und Erfahrung kann sich selbst der beste Mitarbeiter nicht kurzfristig aneignen. Dazu kommt, welche Mitarbeiter unter solchen Voraussetzungen überhaupt die letzten Jahre treu geblieben sind – vielleicht nicht unbedingt die, welche sich in Neues gern einarbeiten.



Nicht zu viel und nicht zu wenig. Nicht jedes Gewürz beim Kochen ausprobieren, sondern Ausgewogenheit schaffen. Nichts ist so konstant wie die Lageänderung6. Daher müssen wir flexibel mit ihr umgehen.

1Falls doch sei dem Leser nahe gelegt, diese Kolumne in Zukunft erst recht aufmerksam zu verfolgen.*

* Und sie nicht zu ernst zu nehmen.**

** Sowie vielleicht einmal den "Hitchhiker's Guide to the Galaxy" von Douglas Adams zu lesen. Und wer bereitwillig diese Fußnoten liest, dem seien die Scheibenwelt Romane von Terry Pratchett ans Herz gelegt. Ehre wem Ehre gebührt.

2Man merkt, mit welcher Erwartungshaltung der Autor den Leser betrachtet

3Hier Fortschritt, nicht das stumpfsinnige Schreiben von (teils) logischen Befehlen in kryptischen Sprachen

4Oder mag hier jemand die Hand heben?

5Um nicht zu sagen dumme

6Vermutlich ein Zitat, wie ich dumpf im Hinterkopf habe - vielleicht sogar von mir. Leider kann ich die Quelle nicht auftreiben.

Keine Kommentare: