Neuste Werkzeuge und Probleme

Kürzlich hatten wir in unserem Entwicklungsteam Schwierigkeiten nachdem einige Teammitglieder von ReSharper 9 auf ReSharper 10 aktualisiert haben. Es hat sich am Ende herausgestellt, dass die Werkzeuge gar nicht schuld waren. Dennoch hat dieser Zwischenfall eine Diskussion über die Team-interne Verwendung von Werkzeugen ausgelöst. Dabei wurde den Aktualisierten vorgeschlagen von der neuen Version wieder auf die alte zurückzugehen. Plötzlich stand das Installieren der neusten Versionen zur Debatte und es wurde von “der Team-Version” gesprochen. Das Thema haben wir auch in unserer Retrospektive diskutiert und hier wurde dann sogar von Installations-Veto und Installations-Verbot von den Softwarearchitekten gesprochen. Hiermit möchte ich meinen Standpunkt nocheinmal schriftlich klarstellen.

Es handelt sich bei diesem Thema eigentlich um zwei Themen. Das erste betrifft Probleme, die bei der Verwendung von Werkzeugen auftreten. Das zweite betrifft den Umgang mit neuen Versionen an sich. Wenn wir beides vermischen kommen wir zu vermeintlichen Lösungen die gar keine sind.

1. Thema: Tool-Probleme

Was sollten wir tun, wenn wir Probleme mit einem Werkzeug haben? Für mich ist die Antwort eindeutig: Beheben und zwar so schnell wie möglich! Ein Versions-Downgrade kann meiner Meinung nach nur das letzte Mittel sein. Wer ist dafür verantwortlich? Meiner Meinung nach die, die das problematische Werkzeug einsetzen. Und wenn das unbedingt eine bestimmte Person sein muss, dann bitte der CTO. In unserer Abteilung sehen sich die Architekten verantwortlich für den Einsatz von Entwicklungstools. Meiner Meinung nach ist das Schwachsinn. Entwicklungstools haben mit Softwarearchitektur nichts zu tun. Ich befürchte sogar, dass wir unsere Architekten mit Problemen, Fragen und Diskussionen rund um die Tools von den tatsächlichen und wichtigeren Aufgaben bezüglich der Softwarearchitektur abhalten und ablenken. Laut Wikipedia geht es bei Softwarearchitektur um

eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen

oder ähnlich

Strukturen eines Softwaresystems: Softwareteile, die Beziehungen zwischen diesen und die Eigenschaften der Softwareteile und ihrer Beziehungen.

Architekten kümmern sich nicht um die Werkzeuge der Bauarbeiter, das machen die Bauarbeiter selber.

2. Thema: Neue Versionen

Ich glaube unsere Architekten beschäftigen sich nur deswegen so viel mit Werkzeugen, weil es sonst keiner macht und sie es gerne kontrollieren wollen. Aber allein die Idee, vorzugeben welche Werkzeuge zu verwenden sind und welche nicht, finde ich höchst fragwürdig. Meiner Meinung nach widerspricht das der Selbstorganisation, dem elften Prinzip des agilen Manifests:

The best architectures, requirements, and designs emerge from self-organizing teams.

Ich meine damit nicht, welches Versionsverwaltungssystem das Team einsetzt oder welche Framework-Version der Buildserver nutzt. Diese Punkte sehe ich tatsächlich im Entscheidungsbereich der Team-übergreifenden Einheiten und den Kundenanforderungen. Aber die Version von Visual Studio und ReSharper sehe ich im Entscheidungsbereich der Teammitglieder. Schließlich kennen die ihre Werkzeuge und Konsequenzen am Besten. Das Argument für eine homogene Versionslandschaft ist Code-Kompatibilität und Pair-Programming-Vereinfachung. Beides kann ich gut verstehen und beides ist in der Realität auch mit heterogener Versionslandschaft kein Problem. Zusätzlich haben wir ja mit Versionskontrolle und CI ausreichende Sicherheitsmechanismen um selbst theoretischste Probleme auf diesem Gebiet zu verhindern.

Aber ist es sinnvoll das ein Teammitglied Visual Studio 2012 und ein anderes Visual Studio 2015 nutzt? Nein. Wo ist das Problem? Das Problem sehe ich in der alten Version. Meiner Meinung nach hat das Team ein doppeltes Ziel. Zum Einen sollten alle im Team die gleiche Version einsetzen und zum Anderen sollten alle die neuste Version einsetzen. Zu jeder Zeit? Nein, statt immediate consistency lieber eventual consistency. Es stellt sich also die Frage nach dem Zeitpunkt der Umstellung. Ich würde sagen, early adopters sofort um die neue Version im praktischen Einsatz zu evaluieren. Wenn es Probleme gibt sollten diese behoben werden (siehe Thema 1) und zwar von den early adopters. Dann sollte das restliche Team maximal zwei Sprints später ebenfalls umsteigen. Um das zu ermöglichen sollte die Verfügbarkeit einer neuen Version von den early adopters angesprochen und das Team damit über den Begin einer Evaluierungsphase informiert werden.

Warum stellen wir überhaupt um? Es geht dabei um Verbesserung und Innovation. Unter dem Strich ist die neue Version besser. Ansonst hätte es sie ja nicht geben müssen. Die neuen Versionen haben weniger Fehler und neue Features. Wenn man sich nicht mit den neusten Tools beschäftigt, kann man auch nicht wissen, wie diese das Arbeiten erleichtern und sogar beschleunigen. Zum Beispiel bietet Visual Studio 2015 mit dem Visual Live Tree und Delegates im Debug-Window zwei Funktionen auf die ich nicht mehr verzichten möchte. Und ReSharper 10 enthält Postfix Templates out of the box. Außerdem, wenn man immer am Ball bleibt ist es auch einfacher auf eine noch neuere Version umzusteigen, die besonders außergewöhnliche Features bietet. Das ist wie beim Mergen von Branches. Je länger man wartet, desto weiter laufen die Pfade auseinander und desto schwieriger ist es, diese wieder zu vereinen.

Es ist wichtig, dass wir hier alle am selben Strang ziehen und zwar nach vorne.

Advertisements

5 thoughts on “Neuste Werkzeuge und Probleme

  1. Hallo Manuel,

    Wir haben sicherlich auch unsere Protion von Problemen, aber solche hatten wir noch nie! Ich glaube, diese Probleme haben nichts mit Tools und Versionen zu tun. Mir drängen sich 2 Ideen in den Vordergrund:
    1. Conways Law – wie unabhängig sind die Teams?
    2. Ich hoffe, du hast nicht gerade die Entwickler “Bauarbeiter” genannt und die Architekten auf ein Podest gestellt?!

    Gruß,
    Krisztina

  2. Hallo Manuel,

    Ich befürchte tatsächlich, in eurem Team muss die Rolle des Softwarearchitekten einmal klar definiert werden. Irgendwie scheint sich das Bild eines Vorarbeiters eingeschlichen zu haben. Wenn ihr einen braucht, der den Entwicklern vorschreibt, wie sie entwickeln sollen, stellt einen “Lead developer” ein. Ansonsten schaut, dass sich euer Architekt um Architektur kümmert. So daneben ist deine Wikipedia-Definition nicht :-)

    Viele Grüße

  3. Hallo Manuel,
    glaubst Du nicht, dass es auch mal Gruende geben kann nicht auf die neueste Version zu wechseln? Ich bin z.B. froh, dass wir nie VS2013 eingesetzt haben, aber finde es super jetzt VS2015 zu verwenden.
    Natuerlich ist es, meiner Meinung nach, wichtig am selben Strang und in die selbe Richtung zu ziehen, aber manchmal muss es nicht immer sofort und gleich wenn es moeglich ist sein. Vielleicht sind Kollegen noch nicht so weit oder es gibt andere gute Gruende zu warten.
    Ein gutes Entwicklungsteam und da zaehle ich die NichtEntwickelndenArchitekten nicht dazu, sollte das immer in einem gemeinsamen Entscheidungsprozess oder in einer gemeinsamen Entscheidung tun.
    Es stellt sich naemlich die Frage, wenn es Entwicklerkollegen gibt, die immer vorauseilen und denen die Gruende, warum anderen nicht oder noch nicht wecjseln wollen egal sind, ob diese Entwicklerkollegen so gute Teamworker sind, ihre Qualitaet als sehr gute Softwareentwickler ausser Frage gestellt.

    Teamwork sollte aus meiner Sicht das Zauberwort sein. Gemeinsam im Projekt bis zum Projektziel, dann hat auch jeder Freude, woraus Kreativitaet und Innovation entstehen und weiterentwickelt werden kann.

  4. “In unserer Abteilung sehen sich die Architekten verantwortlich für den Einsatz von Entwicklungstools. Meiner Meinung nach ist das Schwachsinn. Entwicklungstools haben mit Softwarearchitektur nichts zu tun.” das hört sich für mich danach an, als wären die early adopters jetzt diejenigen, die statt den Architekten entscheiden. Generell sollte es doch eine Team Decision sein. Oder war das so gemeint, dass ohnehin immer umgestellt wird und die nur kurz diejenigen, die das noch nicht mitgekriegt haben, informieren?

    “Warum stellen wir überhaupt um? Dabei geht es um Verbesserung und Innovation. Unter dem Strich ist die neue Version besser. Ansonst hätte es sie ja nicht geben müssen.” => Ich sage nur Windows 8…

    “Die neuen Versionen haben weniger Fehler und neue Features.” => weniger Fehler? Also eine 1 Jahr lang nur mit bugfixes versorgte Version ist wohl stabiler als eine neue große Major-Version. Sowohl bei dir, als auch bei mir sind das aber lediglich Meinungen/Aussagen ohne Belege. Neben logischerweise neuen Features können ggf. aber auch alte rausgenommen worden sein! Hier mal ein richtig nerviger Bug im neuen ReSharper 10: https://youtrack.jetbrains.com/issue/RSRP-450980

    “Wenn man sich nicht mit den neusten Tools beschäftigt, kann man auch nicht wissen wie diese das Arbeiten erleichtern und sogar beschleunigen.” => Dafür muss man nicht unbedingt gleich migrieren. Das kann man auch erst einmal in Coding Dojos angehen.

    “Das ist wie beim Mergen von Branches. Je länger man wartet, desto weiter laufen die Pfade auseinander und desto schwieriger ist es, diese wieder zu vereinen.” => Vielleicht ein ungünstiges Beispiel, weil es hierfür sinnvolle Lösungen gibt. Stichwort rerere (https://git-scm.com/blog/2010/03/08/rerere.html)

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s