Zustandsforschung

Ich vermute, wenn ich damals bei der Berufsberatung beim Arbeitsamt gesagt hätte, ich will “irgendwas mit Menschen” machen (statt “ich mag Mathe – was soll ich studieren”), hätte man mir nicht zum Informatikstudium geraten. Auch wer sich heutzutage für ein Studium oder einen Beruf entscheidet und gerne “irgendwas mit Menschen” machen möchte denkt vermutlich nicht gerade an Softwareentwicklung. Aber meine Erfahrung nach mittlerweile fast einem Jahrzehnt als Entwickler ist, dass die Interaktion mit Menschen – neben dem Programmieren – genau das ist, worauf es dabei ankommt.

Dabei meine ich nicht, dass man es auf Stackoverflow oder via Twitter mit anderen Menschen zu tun hat. Ich meine auch nicht das Gespräch an der Kaffeemaschine oder das Meeting mit dem Chef. Sondern tatsächlich Arbeit mit Menschen in Person von Angesicht zu Angesicht – direkte Kommunikation also, mit deren Qualität auch die Qualität des Arbeitsergebnisses steht und fällt.

“Wie kann das sein, wenn Entwickler doch hauptsächlich Code schreiben”, mag sich der ein oder andere jetzt fragen. Aber wer denkt, dass Softwareentwicklung sich nur auf Schreiben von Code beschränkt, hat da etwas grundsätzliches nicht verstanden. Natürlich schreiben Softwareentwickler auch Code – aber gerade im professionellen Umfeld tun sie das nur in den allerseltensten Fällen allein und im Reinraum.

Denn wenn mit Softwareentwicklung Geld verdient werden soll, ist es normalerweise nicht der Entwickler, der sich ausdenkt, was er als nächstes Entwickeln soll, sondern der Auftraggeber – sei es der Fachbereich in der eigenen Firma oder beim Kunden. Klar – ein gewisser Teil (je nachdem ob man eher agil oder eher wasserfallig unterwegs ist) ist in einer Art Spezifikation verschriftlicht. Oft ist es aber so, dass derjenige, der die Spezifikation schreibt, eine andere (domänenspezifische) Sprache spricht als der Entwickler. Das bedeutet, dass Unklarheiten und Missverständnisse normal sind, wenn man nur mit dem Dokument arbeitet. Hier ist es dann extrem wichtig, die Anforderungen direkt mit demjenigen zu diskutieren, der sie gestellt hat. Und genau hier kommt es darauf an, so kommunizieren zu können, dass die beiden Welten “Fachbereich” und “Entwicklung” einander auch verstehen. Scrum versucht diesem Umstand Rechnung zu tragen durch die Rolle des “Product Owner”, der viel unmittelbarer in den Entwicklungsprozess eingebunden ist. Beim Extreme Programming wird der “Onsite Customer” gefordert, um das Projekt zum erfolgreichen Abschluss bringen zu können.

Üblicherweise ist es dann ein Team das die Anforderungen umsetzt, da die Anforderungen meist zu umfangreich sind um von einer Person abgearbeitet werden zu können. Da gibt es dann außer den Entwicklern noch Tester, Projektleiter, Scum Master und Product Owner, manchmal auch Designer und Konzepter. Hier hat man es mit allen Beteiligten mehr oder weniger zu tun. Der Projektleiter muss in der Lage sein zu verstehen, wo das Projekt steht und der Entwickler muss ihm vermitteln können, warum “Kann man schon was sehen?” manchmal eine ziemlich dumme Frage ist. Entwickler und Tester können gemeinsam vor dem gleichen Bildschirm sitzend viel schneller ein komplexe Fehlerreproduktion durchführen als über ein Ticket-System. Der Scrum Master muss das Problem verstehen, das den Entwickler am Weiterarbeiten hindert, bevor er sich an dessen Beseitigung machen kann. Design und Konzept sollten eng mit der Entwicklung zusammenarbeiten, um frühzeitig die Realisierbarkeit der Entwürfe prüfen zu können.

Das alles geht natürlich umso effizienter, je kürzer die Kommunikationswege sind und natürlich auch je besser die Beteiligten in der Lage sind, miteinander zu kommunizieren. Und natürlich müssen sich auch die Entwickler untereinander austauschen – zum KnowHow-Aufbau, wie Anforderungen umgesetzt werden sollen, wo es sowas ähnliches im System schon gibt oder beim Pair Programming.

Ich kenne fast kein Projekt, in dem nicht Pair Programming zumindest punktuell nutzbringend eingesetzt werden konnte. Pair Programming bedeutet, dass tatsächlich zwei Entwickler gemeinsam am gleichen Bildschirm eine Anforderung umsetzen oder ein Problem lösen. Das heißt bei dieser Art der Zusammenarbeit hat man es nicht nur ab und zu zur Abstimmung mit einem anderen Menschen zu tun, sondern man sitzt im Zweifelsfalle den ganzen Tag gemeinsam vor dem Rechner und diskutiert Lösungen, Vorgehensweisen und Probleme. Vorzugsweise nicht immer mit der gleichen Person sondern möglichst oft mit unterschiedlichen Paaren. Für meine Begriffe ist das die Königsdisziplin in Sachen “irgendwas mit Menschen”.

Das sind zwar noch längst nicht alle Aspekte, wo man bei der Softwareentwicklung “irgendwas mit Menschen” macht, aber das soll mal genügen, um hier anhand von ein paar Beispielen verdeutlichen, dass das Klischee vom “Kellerentwickler”, der alleine vor sich hinprogrammiert einen völlig falschen Hinweis darauf gibt, welcher Typ Mensch als Entwickler geeignet sein könnte – und dass der Umgang mit Menschen ein zentraler und extrem wichtiger Bestandteil der professionellen Softwareentwicklung ist.

Vor ein paar Monaten habe ich bei einem Kollegen ‘gitshots‘ im Einsatz gesehen. Das macht immer dann einen Schreenshot, wenn man ein git commit ausführt. Allerdings ist die Anleitung wie das geht eher so für die Mac-Welt gedacht. Das nutzt mir mit meinem Windows-Notebook natürlich nicht so viel.

Aber weil das so dermaßen cool ist, habe ich mich auf die Suche nach einer Alternative gemacht, und das Tool “CommandCam” gefunden. Das tut nix anderes als beim Aufruf mit der Webcam ein Foto machen und das als Datei ablegen. Damit und einem Git Post-Commit-Hook ließ sich das dann relativ einfach umsetzen:

Zunächst “CommandCam” herunterladen und in ein Verzeichnis legen – dort kommen später auch die Bilder hin (ist bei mir I:\Tools\CommandCam).

Dann folgenden Post-Commit-Hook in C:\Program Files (x86)\Git\share\git-core\templates\hooks\post-commit (bzw. im jeweiligen Repository in .git/hooks/post-commit eintragen (Pfade selbstverständlich entsprechend ersetzen):

cd I:/Tools/CommandCam
number=$[ ( $RANDOM % 4000 )  + 1000 ]
CommandCam.exe //filename gitcc`date +%s`.bmp //quiet //delay $number

Das war’s dann schon – ab jetzt macht eure Webcam bei jedem Commit ein hübsches Foto von euch (mit zufällig zwischen 1 und 5 Sekunden Verzögerung).

Auch 2012 habe ich wieder notiert, welche Bücher ich gelesen habe und was ich so darüber denke:

• Miss Marple Omnibus I, II und II von Agatha Christie:
  Ich habe auf Empfehlung meiner Frau alle 12 “Miss Marple”-Romane gelesen. Spannend sind sie alle – und ich bin nur bei zweien vor dem Ende darauf gekommen, wer der Mörder ist. Was ich außerdem großartig finde ist die Atmosphäre Englands in der beginnenden zweiten Hälfte des 20. Jahrhunderts, die dort aufgebaut wird.
• Spring in Action, 3rd Edition von Craig Walls:
  Praxisnahe Einführung in das Spring Framework. Allerdings ist es hier wie bei allen Fachbüchern: Wenn man’s nicht sofort anwendet, hat man’s auch gleich wieder vergessen.
• Eating Animals von Jonathan Safran Foer:
  Foer hat über den Zeitraum von 3 Jahren recherchiert, wie die Tiere, die – hauptsächlich in den USA – gegessen werden denn so auf den Teller kommen. Ich befürchte, dass dieses Buch wohl wieder mal die falschen lesen werden, denn die meisten die gerne Fleisch essen, wissen vermutlich sehr gut, dass sie besser nicht zu genau darüber informiert sind.
• Stumbling on Happiness von Daniel Gilbert:
  Ein Buch darüber, warum es so schwierig ist, die eigenen Emotionen vorherzusagen und warum man dadurch auch eher schlecht darin ist zu wissen, was glücklich macht. Gilbert schreibt im Vorwort: “If your future self is not satisfied when it arrives at the last page, it will at least understand why you mistakenly thought it would be.“
• Clean Code von Robert C. Martin:
  Ein Standardwerk, was ich jedem Softwareentwickler unbedingt weiterempfehlen würde. “Uncle Bob” erklärt wie sauberer, lesbarer Code aussieht und wie man nicht ganz so sauberen Code mit einigen einfachen Heuristiken deutlich verbessern kann.
• Scrum – Agiles Projektmanagement erfolgreich einsetzen von Roman Pichler:
  Da wir im aktuellen Projekt bereits Scrum einsetzen, dachte ich es kann nicht schaden auch mal was drüber zu lesen (und zu sehen, ob wir das auch alles so richtig machen). Das Buch von Roman Pichler ist dafür wirklich auch gut geeignet: Auf weniger als 200 Seiten wird hier in alle wichtigen Aspekte der Entwicklung mit Scrum eingeführt.
• Frankenstein von Mary Shelley:
  Ist einem irgendwie im Bewusstsein als Horror-Roman – tatsächlich ist es aber eher eine traurige Science-Fiction-Story, bei der man nicht so richtig weiß, ob einem Frankenstein oder seine Kreatur mehr Leid tun soll.
• Ender’s Game von Orson Scott Card:
  Immer dann, wenn ich aufpassen muss, dass ich beim Lesen in der Straßenbahn meine Haltestelle nicht verpasse, ist ein Buch richtig gut. “Ender’s Game” ist so ein Buch. Science-Fiction vom feinsten.
• Speaker for the Dead von Orson Scott Card:
  Die Fortsetzung von Ender’s Game – mindestens genau so genial, allerdings vom Thema her deutlich anders – teilweise sogar mit religiösen Untertönen. Passt aber ganz gut, wenn man bedenkt, dass Ender… Egal. Ich will nicht zu viel verraten – wer Sci-Fi mag, der muss die beiden Bücher lesen.
• Der Alchimist von Paul Coelho:
  Offenbar bin ich nicht wirklich die Zielgruppe – mehr als “nettes Märchen” fällt mir zu dem Buch leider nicht ein.
• Titus Groan von Mervyn Peake:
  Mal abgesehen davon, dass das Buch eine ganz schöne Herausforderung an meine Englischkenntnisse war, finde ich die Story über das Leben in und um die riesige, verfallende Burg Gormenghast mit sehr viel Atmosphäre umgesetzt.
• eXtreme Programming: Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis von Henning Wolf, Stefan Roock und Martin Lippert:
  Wieder mal ein Fachbuch. Nachdem ich ja dieses Jahr in einem Scrum-Projekt gearbeitet habe und vor kurzem auch ein Buch dazu gelesen hatte, wollte ich mich dann auch mal über eine andere agile Methode informieren. Dieses Buch halte ich für eine geeignete Einführung in XP.
• Kafka am Strand von Haruki Murakami:
  Extrem abgefahrene Story mit surrealistischen Elementen, die sich kaum beschreiben lässt. Wenn man sich darauf einlässt, ist der Roman allerdings bis zur letzten Seite spannend.

Im Moment bin ich grade dran, den Rest der Gormenghast-Trilogie zu lesen – das notiere ich dann aber in der Leseliste 2013

Eigentlich ist alles ganz einfach: Man schreibt erst einen Test, der fehlschlägt. Dann schreibt man ein bisschen Source-Code, der den Test gerade so erfüllt, dass er durchläuft. Jetzt kommt das Refactoring, das den Code wieder “schön” macht. Soweit in Kürze die Theorie zum Test-Driven Development. Aber weil sich das in der Praxis dann doch als schwieriger erweist als sich das da oben liest, war vor kurzem bei meinem Arbeitgeber “Aufschlauen in Sachen TDD” angesagt.

Auf einer internen Schulung wurden 10 Entwickler – darunter auch ich selbst – in die Basis des TDD eingeführt. Mit Fahd Al-Fatish von der andrena objects ag hatten wir einen Coach, der uns mit viel Enthusiasmus für die Sache beigebracht hat, dass Unit-Tests mit TDD keine lästige Zusatzaufgabe ist, sondern dass es im Gegenteil sehr viel Spaß macht, mit dem “Red-Green-Refactor”-Paradigma einen Algorithmus zu entwickeln. Jetzt stand natürlich die Umsetzung in die Praxis an – es bot sich an, das erlernte gleich auch im aktuell beginnenden Projekt einzusetzen.

Dabei habe ich bisher einige Erkenntnisse gesammelt, die ich hier mit euch teilen möchte:

Testgetrieben Entwickeln erfordert Umdenken

Wenn man nach dem Red-Green-Refactor-Paradigma entwickelt, muss man sich anfangs ganz schön umstellen. Denn die Art, wie man üblicherweise bisher Source-Code geschrieben hat, unterscheidet sich ziemlich heftig von der Art, wie man bei TDD Source-Code schreibt. Das fühlt sich zunächst mal ziemlich ungewohnt an und manchmal fühlt man sich auch eher hilflos dabei. Aber das geht vorbei, wenn man eine zeitlang auf diese Art entwickelt hat.

Tests für bestehenden Code schreiben fast unmöglich

Ich war lange einer von denjenigen, die der Meinung waren es wäre egal, ob man den Code zuerst schreibt oder den Test. Das lag aber wohl daran, dass ich nicht viele Tests geschrieben habe – denn wenn man sich näher damit auseinandersetzt, merkt man oft, dass Code der nicht testgetrieben entwickelt wurde, oft so gebaut ist, dass man ohne umfangreiches Refactoring oder irrsinnig große Mock- oder Stub-Konstrukte einfach keinen Test dafür schreiben kann.

Besseres Gefühl beim Arbeiten mit gut getestetem Code

Oder vielleicht eher umgekehrt ein ziemlich ungutes Gefühl beim Arbeiten mit ungetestetem Code: Wenn man normalerweise mit gut getestetem Code arbeitet und dann mal wieder Code ändern muss, von dem man weiß, dass er keine gute Testabdeckung hat, hat man irgendwie ein schlechtes Gefühl dabei. Das geht so ein bisschen in die Richtung, dass wenn man mal angefangen hat, testgetrieben zu entwickeln, man eigentlich anders gar nicht mehr möchte.

Code, der mit TDD entwickelt wurde ist sauberer

Natürlich kann man auch mit TDD hässlichen Code schreiben. Aber das ist damit deutlich schwieriger. TDD zwingt einen ein bisschen dazu, den Code deutlich modularer aufzubauen, als man das möglicherweise sonst getan hätte – einfach weil sich anders der Test kaum schreiben lässt.

TDD in der “echten Welt” ist ganz schön schwer

Jetzt kommen wir zu dem Thema aus dem Titel des Artikels: Beim Einsatz im Projekt gibt es immer mal wieder Punkte, an denen es extrem schwierig ist, mit dem TDD-Paradigma zu entwickeln. Das passiert meist dann, wenn man externe Libraries verwendet (oder durch das Umfeld in dem man entwickelt dazu gezwungen ist). Dazu ein paar Beispiele:

• In einer der Bibliotheken, die wir verwenden, gibt es einige Klassen, die nur statische Methoden anbieten. Wie geht man damit nun am besten um (siehe auch How to deal with static utility classes when designing for testability)?
• Sollte man ein Mock-Framework verwenden? Wenn ja – welches? Und baut man damit nur Stubs oder testet man auch das Verhalten auf den Mocks (siehe auch Mocks Aren’t Stubs)?

Übrigens hat man manchmal wenn man nach Antworten auf solche oder ähnliche Fragen sucht ein bisschen das Gefühl als sei man der erste Mensch, der auf dieses Problem stößt – scheinbar ist TDD im professionellen Umfeld doch noch nicht so verbreitet…

Laut Wikipedia dient Werbung “sowohl der gezielten und bewussten als auch der indirekten und unbewussten Beeinflussung des Menschen zu meist kommerziellen Zwecken. Teils durch emotionale (Suggestion), teils durch informierende Werbebotschaften spricht Werbung bewusste und unbewusste Bedürfnisse an oder erzeugt neue.”

Im Umkehrschluss könnte man also – vielleicht ein wenig überspitzt formuliert – sagen, dass Werbung versucht uns unzufrieden zu machen mit dem was wir bereits besitzen, so dass wir glauben, wenn wir das Smartphone/Bier/Parfüm/Tütensüppchen kaufen, was uns da angeboten wird, wäre die Welt wieder in Ordnung (spannendes Detail am Rande: Werbung kann sogar Erinnerungen fälschen).

Da viele glauben, sich nicht durch Werbung beeinflussen zu lassen, möchte ich folgendes zu bedenken geben: Die deutschen Unternehmen geben nicht 25 Milliarden Euro im Jahr für Werbung aus, weil sie hoffen, mal den ein oder anderen zu einem Kauf bewegen zu können, sondern weil sie genau wissen, dass das bei den meisten funktioniert. Und es funktioniert sogar so gut, dass man glaubt, man wäre gar nicht beeinflusst worden, sondern es wäre die eigene Entscheidung gewesen.

Die Organisation “Adbusters” geht sogar so weit, von mentaler Verschmutzung (mental pollution) durch Werbung zu reden und schreibt, dass “Fernsehwerbung und Autobahnwerbeflächen näher verwandt sind mit giftigem Klärschlamm als mit Sprache”

Weil ich mich nicht so gern beeinflussen lassen möchte, keinen unnötigen Kram brauche und Werbung eigentlich (von wenigen Ausnahmen mal abgesehen) nur nervig finde, versuche ich mich so weit es eben geht dem zu entziehen. Und das funktioniert bei mir folgendermaßen:

Internet

Ich habe in jedem Browser, den ich regelmäßig benutze, ein Plugin zum Ausblenden von Werbung installiert (gibt’s als Adblock Plus für Firefox und Adblock für Chrome – für IE lässt sich vermutlich was ähnliches finden).

Wer sich nicht so vorstellen kann, wie das dann am Ende aussieht, der möge einfach mal die beiden folgenden Screenshots miteinander vergleichen:

Fernsehen

Seit ich mir meinen MythTV HTPC gebaut habe, schaue ich so gut wie keine Sendung mehr dann wenn sie im Fernsehen läuft, sondern nehme alles erstmal auf. Dadurch kann ich dann ganz einfach die Werbepausen überspringen und muss keine dämliche Fernsehwerbung mehr über mich ergehen lassen. Außerdem bezahle ich noch Geld für einige PayTV-(Serien)-Sender, die sowieso keine Werbeunterbrechungen haben.

Natürlich braucht man dazu nicht unbedingt MythTV, sondern gerne auch jeden beliebigen anderen Festplattenrecorder – oder man schaut einfach kein Fernsehen mehr

Post

So trivial es klingen mag, aber hier hat ein ganz einfacher “Keine Werbung!”-Aufkleber (sogar ohne “bitte”) bereits gereicht, um den Großteil an Werbemüll, der so in meinem Briefkasten gelandet ist, auszufiltern.

Radio

Meine Lösung für Radiowerbung ist möglicherweise nicht für jeden was: Ich bin umgestiegen auf den Kultursender hr2, weil die keine Werbung senden und höre jetzt tatsächlich beim Frühstück klassische Musik. Alternativen könnten zukünftig aber auch die bezahlten und damit werbefreien Versionen von Simfy oder Spotify sein.

Sonst so

Natürlich kann man sich nicht hundertprozentig gegen Werbung abschotten. Kaum entkommen kann man beispielsweise der guten alten Plakatwerbung oder wie’s jetzt neuerdings an Bahnhöfen beliebt wird, den Massen solcher nerviger Bildschirme, die dort aufgestellt werden.

Aber man kann zumindest einiges dafür tun, die Anzahl und damit auch die Wirkung der täglich auf uns niederprasselnden Werbebotschaften deutlich zu reduzieren.