Probleme beim Einloggen
Ralf Westphal Zielerfassung aus der Ruhe - Alignment als Grundlage für Veränderungen
Innehalten im Tagesgeschäft und der Frage nach der inneren Qualität der Software überhaupt ersteinmal Raum geben, das steht am Anfang des CCD-Weges.
Wohin soll dann aber dieser Weg führen? Was ist das Ziel? Oder gibt es mehrere? Ganz allgemein könnten die mit Bezug zu den CCD-Werten doch so lauten:
* Software, die heute umfassend korrekt ist, weil sie die Anforderungen des Kunden erfüllt (Außensicht)
* Software, die sich mit angemessenem Aufwand über lange Zeit neuen Kundenanforderungen anpassen lässt (Innensicht: Evolvierbarkeit, Produktionseffizienz)
* Ein Team, das zum Nutzen heutiger und zukünftiger Kunden mit ihren wachsenden Wünsche softwaretechnisch auf dem Laufenden ist (Innensicht: Reflexion)
Klingt einfach, oder? Liegt für Sie als Mitglied dieser XING-Gruppe auf der Hand, oder?
Doch wie ist´s mit anderen Mitgliedern Ihres Teams? Was würde Ihr Chef dazu sagen? Was würde dessen Chef dazu sagen usw.?
So, wie ich Softwareabteilungen und -unternehmen durch Kontakt mit ihnen in Beratungen, Trainings und auf Konferenzen erlebe, bin ich im Zweifel, ob eine solche Zieldefinition im weiteren Umkreis um Sie herum verstanden und auch akzeptiert würde. Wer mit Softwareentwicklung zu tun hat, ist oft so verstrickt ins Tagesgeschäft und gefangen in überkommenen wie auch unausgesprochenen Vorstellungen, dass er/sie sich keine Gedanken über Ziele jenseits "Die Arbeit auf dem Tisch wegschaffen" Gedanken macht.
Und wenn doch... wie groß ist dann die Schnittmenge mit dem oben formulierten Zielen?
Bevor Sie Hand anlegen an Ihren Code oder seinen Produktionsprozess, sollten Sie daher als erstes laut eine Frage stellen. Sie sollten Ihre Kollegen wie auch die zumindest unmittelbare Hierarchie über Ihnen nach den gemeinsamen Zielen fragen. "Was wollen wir mit unserer Softwareentwicklung erreichen?" oder "Warum entwickeln wir Software?" und "Warum entwickeln wir Software so, wie wir es tun?" sind geeignete Fragen, um die Diskussion zu beginnen.
Erwarten Sie allerdings nicht sofort knackige Antworten. Solche Grundsätzlichen Fragen wirken oft verstörend. Sie rühren womöglich an Verdrängtem, an Unsicherheiten, an Unklarheiten. Bleiben Sie dann aber dran! Lassen Sie sich nicht mit Offensichtlichem abspeisen. Eine oft gehörte Antwort wie "Wir wollen mit unserer Software Geld verdienen" ist nämlich keine wirkliche Erklärung, warum denn Software das Mittel zum Geldverdienen ist. Andere Tätigkeiten sind vielleicht lukrativer. Auch ist es keine Erklärung, warum die Softwareentwicklung so aussieht, wie sie bisher aussieht. Denn Software lässt sich bestimmt anders entwickeln - zum Beispiel auf der Basis von CCD-Bausteinen.
Hoffen Sie also zunächst nur, einen Diskussionsprozess in Gang zu bringen. Der kann ein paar Tage, Wochen oder sogar Monate dauern. Jenachdem, wieviel Energie hineinfließt. Wichtig ist nur, dass am Ende klare Vorstellungen herrschen, ob und in welchem Boot alle zusammen sitzen und in welche Richtung sie rudern.
Denn darum geht es: Nur mit einer expliziten, von allen geteilten Vorstellung vom Warum und Wie der Softwareentwicklung kann ein Veränderungsprozess überhaupt in Gang kommen. Denn ob Veränderungen etwas bewirken, ob sie in die richtige Richtung gehen, das kann nur beurteilen, wer überhaupt die Richtung kennt. Und davon kann es nur eine geben.
Woimmer Entscheidungen zu treffen sind, kann die am geeignetste Option nur erarbeiten oder wählen, wer das eine große Ganze kennt, zu dessen Erreichung sie beitragen sollen.
Auf die Praxis übertragen: Wenn Sie CCD-beseelt einem Kollegen oder Chef z.B. vorschlagen, "Wir sollten die Produktion unserer Software automatisieren." und der abwinkt, dann ist es Zeit innezuhalten. Innehalten statt evangelisieren. Enttäuschung im Zaum halten, zurücktreten und die ultimative Frage stellen: "Schauen wir beide eigentlich in dieselbe Richtung? Wollen wir dasselbe? Haben wir eine gemeinsame Vorstellung davon, warum und wie Software grundsätzlich hergestellt werden sollte? Teilen wir ein Wertverständnis zur Softwareentwicklung?"
Solange nicht offen auf dem Tisch liegt, welche Vorstellungen, Werte, Interessen, Bedürfnisse hinter Skepsis und Ablehnung von CCD-Bausteinen stehen, solange führt jeder geäußerte Veränderungswunsch quasi notwendig in unerquicklichen Konflikt. Und der dient der CCD-Sache nicht.
Deshalb: Regen Sie aus dem Innehalten für die Reflexion über innere Qualität zunächst eine ganz allgemeine Diskussion über Werte und Ziele in Ihrem Umkreis an. Ihre CCD-Interessen können davon nur profitieren.
-Ralf Westphal
Ralf Westphal Beginnen mit Innehalten - CCD beginnt mit Zeit für Reflexion
Wer Clean Code Developer werden will, der macht sich auf zu einem Weg durch viele Veränderungen. CCD bricht einfach mit z.T. tief eingegrabenen Gewohnheiten und Glaubenssätzen. Das macht es unabhängig von konkreten technischen Belangen womöglich schwieriger, als z.B. von ADO.NET auf einen O/R Mapper oder von WinForms auf WPF zu wechseln.
Vielleicht sollten wir wie die Zeitschrift Brigitte mal Vorher-Nachher-Bilder von Entwicklern machen? :-) "Das ist Klaus, solange er noch manuell getestet hat; das ist Klaus nach seinem Umstieg auf konsequentes Unit Testing." Oder: "Das ist Susanne, wie sie die 500. Zeile Code zu einem Button-Click-Eventhandler hinzufügt; und das ist Susanne nachdem CCD ihr Verständnis für die Prinzipien SRP und SoC geweckt hat."
Ja, so ist das mit CCD. Es geht um recht grundlegende Veränderung der eigenen Haltung der Softwareentwicklung gegenüber. Sowas braucht dann natürlich Zeit. Umso mehr, je weniger CCD-affin die Projektumwelt ist.
Deshalb lautet der erste Rat für den Aufbruch auf den CCD-Weg: Nicht zuviel vornehmen! Lieber dauerhaft kleine Schritte, als in einem Schwung alles umkrempeln wollen.
Und der erste Schritt besteht darin, jeden Tag mindestens einmal innezuhalten. Innehalten und einfach die Frage für einen Moment im Kopf bewegen: Was habe ich heute für die "innere Qualität" meines Projektes getan?
Nein, es geht nicht darum, wieviele Bugs gefixt oder wieviele Features eingebaut wurden. Es geht darum, inwiefern der Code verständlicher oder flexibler oder weniger komplex oder einfacher ausrollbar gemacht wurde.
Nicht mehr ist am Anfang nötig - und sollte dann nie wieder aufhören. Nur ein Innehalten und fragen: Inwiefern habe ich heute einen Beitrag dazu geleistet, dass meine Software ein längeres leben hat?
Technische Gimmicks und hehre Prinzipien sind erstmal unwichtig. 5 oder 10 Minuten anhalten im Tagesgeschäft und reflektieren über die "innere Qualität" der Software ist alles.
Probiert das mal aus.
-Ralf
Carsten Posingies Imagination?
So, jetzt imaginiere ich mich auch mal... Carsten, kurz vorm Kehren (39,x Jahre), Atari 2600 (3 Monate, dann langweilig), ZX81 (6 Monate, dann zu klein), Apple II+ (bis zum Auseinanderfallen wegen exzessiver Hardware-Bastelei), selbstgebauter 19''-Z80-Computer (CPU-Platine handgefädelt, auf 6 (!) MHz (!) overclocked, ja, da bin ich stolz drauf) mit CP/M 2.2 und Turbo Pascal, No-Name-i286, No-Name-i386SX-Laptop, abwechselnd mit Win 3.11 (von 7 Disketten) und Slackware-Linux (von 22 Disketten), Microsoft C Compiler, VB 1.0, VC++ 1.0... Vista, 2008, VS TS 2008 DE, C# und F#. UML-ignorant. Stets auf der Suche nach besseren Wegen zu besserer Software. Star-Trek- und William-Gibson-Fanatic. Hobby-Koch. Fühlt euch eingeladen.
Stell Dir vor, Du kommst in ein Projekt, und alle reden eine Sprache.
Stell Dir vor, Du kommst in ein Projekt, und Du kannst sofort anfangen mit Deinen Aufgaben.
Stell Dir vor, Du kommst in ein Projekt, und Du bist gleich produktiv.
Stell Dir vor, Du bist in einem Projekt, und der Abgabetermin droht Dir nicht, sondern lächelt Dir freundlich zu.
Stell Dir vor, Du lächelst genauso freundlich und zufrieden zurück.
Stell Dir vor, Du hast Zeit für eine richtig gute Dokumentation.
Stell Dir vor, Du hast eine Wochenarbeitszeit, und die erlaubt es Dir, Dich weiterzubilden.
Stell Dir vor, Du hast einen Projektleiter, und der freut sich, wenn Du Dich weiterbildest.
Stell Dir vor, Du hast einen Arbeitgeber, der Dich dazu ermuntert, Dich weiterzubilden.
Stell Dir vor, Du hast einen Arbeitsplatz, an dem Du sogar spielen darfst.
Stell Dir vor, Spielen bringt das Projekt weiter.
Imagine there's no pressure
It's easy if you try
No code hell below us
Above us only the sky
Imagine all the people
Working full of joy
Ralf Westphal
Carsten,
das ist eine sehr schöne Imagination, finde ich. Sie beschreibt einen wahrhaft humanen Arbeitsplatz in der Softwareentwicklung. Insofern sollte sie wesentlicher Bestandteil der "Zieldefinition" eines Softwareteams oder gar dessen Unternehmens sein. Daran lassen sich Entscheidungen messen: Dienen sie diesem Ziel?
Der Controller (als personifizierter Spaßverderber für uns Softwareentwickler) wird aber natürlich schnell einwänden, dass da etwas wesentliches fehlt: nämlich der Blick auf Umsatz und Kosten. Und Recht hat er. Solch weltliche Kleinigkeiten wollen auch in einer Zieldefinition berücksichtigt werden. Doch eben nicht auf Kosten deiner Vision! Beides muss zusammenkommen.
Ich bin da auch sehr zuversichtlich: das geht. Wenn man sich die Zeit nimmt als Team/Unternehmen, dann findet man eine Zieldefinition, die alle Bedürfnisse berücksichtigt. Als Ausgangspunkt für die zukünftige Arbeit stellt sie dann sozusagen den letzten Konsens dar. Danach geht es dann weiter - oder sollte es zumindest aus meiner Sicht - im Konsent. Denn dann gibt es eine klare Richtung, gegenüber der jeder Abweichungen feststellen und durch einen schwerwiegenden Einwand in weiteren Entscheidungsprozessen aufzeigen kann.
Aber was ist, wenn kein anfänglicher minimaler Zielkonsens erreicht werden kann? Dann ist es Zeit, entweder sich klein zu machen und zu erdulden, oder sich groß zu machen und gehen. Beides ist ein Abschied: entweder ein Abschied nach innen oder ein Abschied nach außen. Tertium non datur? Kann man sich nach innen halb verabschieden und weiter für Verbesserungen "kämpfen"? Vielleicht eine Zeit lang. Bewegt sich dann aber nichts, verändert sich das Ziel nicht in Richtung auf die eigenen Bedürfnisse, dann steht man wieder vor der Entscheidung, welchen Abschied man wählt.
Ich wünsche dir, dass du in einem Unternehmen bzw. einem Team arbeitest, wo ein Ziel vereinbart ist oder wird, in dem auch deine Vision enthalten ist.
Ralf
Nur für XING Mitglieder sichtbar ein Qualitöter auf Abwegen
Hallo allerseits,
mein Name ist Matthias Schmotz, ich bin 40 Jahre alt. Schon in jungen Jahren habe ich eine Leidenschaft für Computer entwickelt, angefangen hat damals alles mit dem C64. Nach dem Abitur habe ich deswegen eine Lehre zum Datenverarbeitungskaufmann absolviert und bin, nach einem kurzen Abstecher ins Personalwesen, sogleich in einer QS-Abteilung gelandet. Seit 2000 bin ich Freiberufler, mein Tätigkeitsschwerpunkt liegt aber immer noch im Bereich des "externen" Testens und der QS. In meiner Lehre durfte ich mich in der Hauptsache mit Basic und Cobol beschäftigen, inzwischen bin ich bei VB.NET gelandet und versuche mich seit geraumer Zeit an einer umfassenden Softwarelösung für das Black-Box-Testing. Und da ich mit meinen bisherigen Ergebnissen nicht wirklich zufrieden bin, dachte ich mir, horchst Du mal hier herein.
Gruß Matthias

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 5.001
  • Sichtbarkeit: offen
  • Beiträge: 482
  • Kommentare: 2.983