Foto: Beach Regulations von Thomas. Lizenz: CC-BY-SA

Menschen hören es nicht gern, dass sie etwas falsch machen.

Oder dass sie etwas ganz anders machen müssen. Einschätzungen wie diese sind immer subjektiv und kommen meist von oben herab rüber.

Ich hatte schonmal über das Schwarz-Weiß-Denken in unserer Zunft geschrieben, wenn es um die Offenheit von Software geht. Dabei ging es um die unter Windows-Nutzern verbreiteten Vorurteile gegenüber Linux.

Militante Verfechter sind genauso schlimm wie militante Gegner

Jetzt hat John Poelstra über die beinahe religiöse Herangehensweise der Verfechter von Open Source geschrieben: You’re doing it wrong.

Dabei beschwert sich John über die Einstellung, es gäbe nur einen wahren Weg für Open Source. Kleinste Abweichungen davon werden nicht geduldet:

Yes, I’m a fan of open source. Yes, I wrote this post on a Mac. Yes, there are more than two colors in the rainbow.

So etwas schreckt ab.

Stell dir vor, du hast durch einen Freund das erste Mal von Open Source gehört und bist bereit zu experimentieren und das mal auszuprobieren.

Wenn dir jetzt jemand sagt, das wäre eine Alles-oder-nichts-Entscheidung und du müsstest deine Gewohnheiten komplett umstellen, weil du es sonst “nicht richtig” machst — bist du dann immer noch bereit zu experimentieren?

Natürlich nicht.

Produktivität und Pragmatismus ist vielen Menschen wichtiger als Politik

Was Leute wollen, ist Dinge schneller erledigen oder mehr Spaß an der Sache haben. Dann ist Pragmatismus gefragt.

Auch für Entwickler ist diese Art der Bequemlichkeit durchaus ein Thema — wer eigene Open-Source-Projekte vorantreiben will, möchte sich nicht erst noch um die Basis seiner Arbeit kümmern. (Ein gutes Beispiel, wie man es nicht machen sollte, zeigt Zed Shaw in seinem zynischen Post Why Does Ruby on Debian Blow? von 2006 auf.)

Für die Politik dahinter interessieren sich die wenigsten. Und das ist auch nicht weiter schlimm. Projekte, die sich nur prinzipientreue Nutzer leisten und pragmatische vor den Kopf stoßen, werden über kurz oder lang nur noch politische, aber keine fachlichen Diskussionen mehr führen.

Andere Projekte werden da schon längst weiter sein.

Anleitung zum Spaßverderben

Wer also Leute von Open Source fernhalten will, wird am besten militanter Verfechter.

Überzeugt Nutzer vom wahren Glauben. Gebt euch nicht mit Kompromissen zufrieden — die sind was für Weicheier. Und weist immer wieder darauf hin, was Leute alles falsch machen.

Das hören sie besonders gern.

Und du?

Hast du auch schlechte Erfahrungen mit militanten Mitgliedern der Community gemacht, die nur Schwarz oder Weiß kennen?

Oder arbeitest du selbst mit Systemen, die so gar nicht frei sind, an eigenen Open-Source-Projekten?

Sag’s uns in den Kommentaren!

Als Arbeitnehmer bin ich ziemlich anspruchsvoll.

Das hat sich in den letzten zwei Jahren so entwickelt. Und kommt natürlich nicht von ungefähr. Ich bin schließlich gut bei dem, was ich tue.

Daher hier also die Punkte, über die Unternehmen aus meiner Sicht ernsthaft nachdenken sollten, wenn sie neue Softwareentwickler (wie mich) suchen.

Schwerpunkt Flexibilität

Versucht eine Firmenkultur zu etablieren, in der Ergebnisse mehr Wert sind als die Zahl der Stunden – und wo sie geleistet werden.

Nicht jedem liegt es, zuhause oder im Café zu arbeiten. Aber das Büro steht eben auch nicht bei jedem ganz oben auf der Liste. Lasst die Leute dort arbeiten, wo sie am produktivsten sind.

Unterstützt Mitarbeiter bei der Suche nach der optimalen Work-Life-Balance, vor allem bei Elternzeit, Wiedereinstieg danach oder Teilzeit.

Vermeidet spontane Meetings, um Mitarbeitern in Homeoffice und Teilzeit nicht vor den Kopf zu stoßen.

Zeit für eigene Ideen

Gebt den Leuten Zeit, eigene Ideen zu umzusetzen. Ihr werdet erstaunt sein, welche kreativen Lösungen dabei entstehen.

Neue Dinge auszuprobieren macht jedem Spaß und dafür noch bezahlt zu werden, motiviert zusätzlich. Das zeigt Mitarbeitern außerdem, dass sie vom Unternehmen nicht als Humankapital gesehen werden.

Fragt also am besten nicht nach, was das gewünschte Thema jetzt genau mit eurem Produkt oder Service zu tun hat. Vielleicht nichts. Aber darum geht es gar nicht.

Selbstorganisation und agile Prozesse

Gebt keine technischen Lösungen oder Werkzeuge vor. Teams werden in vernünftigen Prozessen mit den für sie optimalen Werkzeugen die beste Lösung finden.

Das gilt nicht nur für das Ergebnis, sondern auch für den Weg dorthin. Fördert Selbstorganisation.

Fordert keine Stundennachweise, sondern Ergebnisse.

Software-Tests

Testet eure Software automatisiert. (Nein, manuelle Tests zählen nicht!) Es wird nicht mehr lange dauern, bis kein Entwickler (m/w) mehr bereit ist, ungetestete Software an Kunden zu liefern — ich zähle mich bereits zu dieser Gruppe.

Wenn euch test-getriebene Entwicklung ein Fremdwort ist, stellt jemanden ein, der euch damit weiterhelfen kann. Tests sind teuer, aber deswegen heute auf sie und morgen auf die besseren Entwickler zu verzichten, könnt ihr euch nicht leisten.

Fehlt etwas?

Viele dieser Punkte setzt mein jetziger Arbeitgeber bereits ansatzweise um. Dadurch weiß ich, wie wichtig sie mir geworden sind oder wo noch nachgebessert werden kann. Und dass ich sie anderswo nicht missen möchte.

Allgemeingültig ist die Liste deshalb aber längst nicht. Und auch nicht vollständig.

Was steht auf deiner? Sag’s uns in den Kommentaren!

[Foto: Magnet von John V. Keogh, Lizenz: CC-BY-NC]

Es gibt zwei Umstände, die bei der Softwareentwicklung nicht gerade helfen, das Produkt in einem nutzerfreundlichen Zustand auszuliefern:

• Anforderungen werden meist technisch und ohne ihren Nutzen für den Anwender formuliert. Das lässt zu wenig Spielraum für Alternativen, falls sie notwendig sein sollten. Außerdem wird es erschwert, die Anforderung zu hinterfragen.
• Oft vergeht zwischen der Formulierung einer Anforderung und ihrer Umsetzung zu viel Zeit. Damit ist dann auch die Information über den Nutzen im besten Fall nicht mehr gegenwärtig, im schlimmsten Fall sogar ganz verloren.

Abhilfe können User Stories schaffen, die häufig in agilen Prozessen wie Scrum benutzt werden.

Beschreibung von Features nach Schema F

User Stories formulieren die Anforderung und den zugehörigen Kundennutzen in Alltagssprache:

Als [Nutzer]
kann ich [Dinge tun],
um [daraus einen bestimmten Nutzen zu ziehen].

Das macht es vor der Umsetzung einfacher, über das Feature zu reden, ohne den Kunden mit technischen Details in die Flucht zu schlagen. (Oder sich als Entwickler die Umsetzung vorweg nehmen zu lassen.) Das ist eine der Hauptaufgaben: Konversationen anzustoßen.

Aber auch während der Umsetzung ist das eine Erleichterung, weil die Story die Hintergründe einer Anforderung deutlich macht. Wenn technische Einschränkungen die Anforderung erschweren oder unmöglich machen, lässt die Story Spielraum für Alternativen.

User Stories können also zur Produktivität, Selbstorganisation und Kundenzufriedenheit beitragen.

Woran man eine schlechte User Story erkennt

User Stories werden meist auf Karteikarten, sogenannte Story Cards, geschrieben — um sie “klein zu halten”.

Wie genau man sich an die Formulierungsvorgabe hält, ist jedem selbst überlassen. Die Story soll schließlich einen Zweck erfüllen — daher ist es legitim, das nach eigenem Ermessen anzupassen.

Eine gute Story lebt davon, dass sie wirklich in Alltagssprache formuliert wird. Dabei ist der dritte Teil, also der Kundennutzen, unbedingt zu beachten.

Als Nutzer
kann ich “OK” drücken,
um den Dialog zu schließen.

ist eine denkbar schlechte User Story. Warum?

1. Die Rolle “Nutzer” ist zu schwammig formuliert, das passt immer.
2. Die Aktion “[OK] drücken” ist zu technisch formuliert.
3. Der Nutzen “um den Dialog zu schließen” ist gar keiner, sondern lediglich eine weitere Aktion.

Von diesem Pseudo-Nutzen zum tatsächlichen kommt man mit der Frage “Wozu?” — “Um zu drucken.” Aha, da ist der wirkliche Nutzen! (Die Frage muss unter Umständen wiederholt werden. Um solchen Dingen auf die Schliche zu kommen, bietet sich der “forehead-slap”-Test an.)

Dieses Fragen ist übrigens auch ein guter Test, um scheinbar aus der Luft gegriffenen Anfragen von Kunden auf den Grund zu gehen (aber das ist ein anderes Thema).

Was eine gute Story ausmacht

Ein viel besseres Beispiel ist:

Als Autor
muss ich das Löschen meines Dokuments bestätigen,
um ein versehentliches Löschen zu verhindern.

Der Nutzen “versehentliches Löschen verhindern” ist konkret und lässt gleichzeitig Spielraum, den gewünschten Effekt auch anders umzusetzen (z.B. eine Rückgängig-Funktion, nach dem das Dokument ohne Rückfrage gelöscht wurde.)

Dem Nutzer hilft, wenn man permanent an ihn denkt

Der explizit formulierte Nutzen führt dazu, dass man als Entwickler nicht nur die technische Herangehensweise sieht, und sich auch in den Nutzer hineinversetzt.

Gute User Stories zu schreiben ist nicht so einfach. Zumindest aber helfen sie, bessere Software zu schreiben und sie näher am Nutzer zu orientieren.

Wie siehst du das als Nutzer, Entwickler oder Auftraggeber? Hast du schon Erfahrungen mit User Stories gemacht, die du beitragen möchtest? Werden User Stories vielleicht auch für andere Produkte eingesetzt?

Sag’s uns in den Kommentaren!

[Foto: WikiData User Stories von Paul Downey, CC-Lizenz]

Mittlerweile bin ich überzeugt, dass im Lehrbetrieb auch Sadisten arbeiten.

Zumindest kommt es mir so vor, wenn ich von Programmierkursen in C++ oder Java höre, die in nicht-technischen Studienfächern zum Curriculum gehören.

Manchmal sogar als Pflichtkurse.

Da kann man nur mit dem Kopf schütteln. Menschen, die nie etwas mit Computerprogrammierung zu tun gehabt haben, muss man behutsam an die Sache heranführen.

Verbrannte Erde

Bring Einsteigern public static void main bei, oder den Unterschied zwischen einfachen und komplexen Datentypen, oder dass sie sich selbst um Speicherverwaltung zu kümmern haben, und du wirst verbrannte Erde hinterlassen.

Du wirst sie in dem Glauben bestärken, dass Computer diese unbeherrschbaren Maschinen sind. Die nur was für diese Freaks sind, von denen sich jeder gern distanziert (auch ich). Du wirst ihnen die letzte Hoffnung nehmen, die Arbeitsweise von Computern auch nur ansatzweise zu verstehen. Im besten Fall rennen sie einfach nur schreiend weg und reden nicht mehr mit dir.

Programmieren soll Spaß machen. Gerade für Einsteiger sollten daher Sprachen gewählt werden, mit denen schnell Ergebnisse erzielt werden können und die den Fokus nicht auf sich ziehen, sondern bei dem zu lösenden Problem belassen.

Daher hier meine Favoriten, die ich jedem ans Herz legen möchte.

Ruby: Leichter Einstieg und doch mächtig

Wie schon erwähnt: Wer gerade erst in die Programmierung einsteigt, will schnell Erfolge sehen, ist ungeduldig. Diese Ungeduld können viele Sprachen, die Anfängern im Studium beigebracht werden, nicht stillen.

Ruby hingegen stellt mit der Interactive Ruby Shell (IRB) das ideale Werkzeug zum Ausprobieren von kurzen Programmen bereit — selbst für Erfahrene.

Mit try ruby! kann man das sogar online ausprobieren — in 15 Minuten. Und gewinnt dabei einen kurzen Überblick in die Möglichkeiten der Sprache.

Dabei wird dann klar, dass Programmierung nicht nur was für Ariane-Raketen ist, sondern auch für den Hausgebrauch.

(Wer mit solche spielerischen Tutorials nichts anfangen kann und stattdessen lieber Zeichnungen eines — sagen wir, exzentrischen — Freaks betrachtet, um seine gängigen Vorurteile aufzufrischen, kann auch gern mal Why’s Poignant Guide to Ruby durchblättern.

Smalltalk: Entworfen für Kinder — aber muss das Erwachsene abhalten?

Smalltalk und dessen Umsetzung Squeak ist von jeher für die Kleinsten konzipiert. Es ist ein in sich geschlossenes System zum Programmieren.

Das ist schon deshalb vorteilhaft, weil man von der Datei als Metapher wegkommt — mancher meint ja sogar, das Konzept von Dateien liegt im Sterben. Und hat damit nicht ganz Unrecht.

(Nebenbei bemerkt überrascht mich immer wieder, mit welcher Vehemenz sich Otto Normalnutzer die Verzeichnishierarchie zu Nutze machen, um Fotos zu katalogisieren — wo es doch Programme gibt, die diesen Zweck viel eleganter lösen als jeder Dateimanager dazu im Stande wäre. Aber ich schweife ab…)

Alles, was man in Smalltalk sieht, kann man untersuchen und verändern. Das lädt zum Ausprobieren ein, zumal sämtliche Änderungen automatisch protokolliert werden.

Und weil man das nicht in einer Viertelstunde online probieren kann, sei an dieser Stelle das kostenfreie Buch Squeak by Example als eine wunderbare Einführung in Squeak Smalltalk empfohlen.

Überzeugt?

Hast du während deiner Ausbildung schlechte Erfahrungen mit Programmierkursen gemacht? Bist du ein gebranntes Kind? Mit welcher Sprache wurdest du gequält?

Oder hast du noch einen Tipp, welche Sprache für Anfänger geeignet sein könnte? Hast du mit Ruby oder Smalltalk vielleicht schon Erfahrungen gesammelt?

Sag es uns in den Kommentaren!

[Foto von iboy, CC-Lizenz]

Wer eine Website betreibt und zuverlässig erfahren möchte, in welchen Bereichen sich eine Optimierung lohnt, um bestimmte Ziele zu erreichen, kommt um Web-Analytics nicht herum.

Dabei gibt es auch Alternativen zum Platzhirsch Google Analytics.

Auf WendtsWelt nutzen wir die freie Software Piwik (nähere Infos zur Speicherung von Benutzerdaten stehen im Impressum). Wer wissen will, was Piwik so alles über Besucher herausfindet, kann sich auf der Demo-Seite umsehen.

Der Nachteil von Piwik: Die Software nutzt Flash für die grafische Darstellung der Daten. Und Flash gibt’s nicht auf dem iPhone. Piwik bietet aber eine API an, um an die Rohdaten zu kommen und damit eigene Anwendungen zu schreiben.

Also haben Sebastian und ich uns hingesetzt und eine eigene Web-App geschrieben:

Piwik für’s iPhone (und das sieht auch nur dort wirklich gut aus)

Der Vorteil: Es muss nichts weiter installiert werden, weder auf dem iPhone noch auf dem Server.

Fertig ist das Ganze noch lange nicht, aber funktionieren tut es allemal.

Auf den Schultern von Giganten

Möglich ist das nur dank folgender Projekte:

• Piwik
• jQuery als Fundament
• jQTouch für das iPhone Look-and-Feel
• das jQuery-Plugin visualize für die Grafiken

Wer mitmachen möchte, kann das gern tun: Der Quellcode ist frei verfügbar unter MIT-Lizenz.

Über jegliches Feedback, Anregungen, Kritik und Mitarbeit in Form von Patches, Doku oder schlichtes Weitersagen freuen wir uns!

[Screenshot aufgepeppt mit Fabian Kreisers iPhone Screentaker]

Wäre es nicht toll, sich nicht erst nach Projektende Gedanken zu machen, was alles schief gelaufen ist? Sich mit den anderen darüber auszutauschen und Dinge sozusagen “unterwegs” zu verbessern? Und Erkenntnisse aus einer guten Phase zu nutzen, um das Projekt doch noch zum Erfolg zu führen? Mit Retrospektiven geht das.

Retrospektiven sind regelmäßige Meetings. Das Projektteam analysiert darin einen vergangenen Projektzeitraum und formuliert dann Maßnahmen, um die Situation zu verbessern.

Man kann sich leicht vorstellen, dass diese Regelmäßigkeit mehr bringt als sich nach dem Projekt unter dem Titel “Lessons Learned” (oder noch beser: Post mortem) zusammenzufinden. Wohin das führt, illustriert der erste Teil der Artikelserie Scary Team Retrospectives: Symbolisches Schulterklopfen, die Ergebnisse verschwinden in einer Schublade, und das Team ist demoralisiert.

Retrospektiven verfolgen dagegen eine andere Strategie:

The trick is to make small improvements regularly.

– Peter Stevens, Start with Trust, Start with a Retrospective

Veränderungen werden quasi “zwischendurch” angestrebt. Ihre Auswirkungen haben direkten Einfluss auf den weiteren Projektverlauf, ihr Erfolg wird dadurch messbar.

Was ist beim Ablauf zu beachten?

Damit Retrospektiven funktionieren und ihren Zweck erfüllen (nämlich dauerhafte Veränderungen bzw. Verbesserungen herbeizuführen), ist es hilfreich, sind an folgenden Dingen zu orientieren:

• Zeitplan. Ewige Diskussionen sind nicht zielführend. Sie kürzt man am besten ab, wenn man sich ein festes Ende setzt und den gesamten Ablauf daran ausrichtet. Für unser Team reicht meist eine gute Stunde aus.

• Aktivitäten. Das sind sozusagen soziale Lockerungsübungen. Das Team spricht über Emotionen, um ein gemeinsames Verständnis von Ereignissen zu erlangen und daraus Maßnahmen abzuleiten:

  Typischerweise wissen die Teilnehmer eigentlich alles, was sie für Verbesserungen bräuchten. Man muss sie “nur” dazu bringen, das zu erkennen und zu artikulieren, in der Gruppe die besten Lösungen zu erarbeiten und die Lösungen so weit zu konkretisieren, dass sie umsetzbar sind.

  – Catalyst, Retrospektiven

  Das kann so aussehen, dass jeder Teilnehmer Ereignisse des zu untersuchenden Zeitraums auf Zettel schreibt und dann an eine Pinnwand heftet. Die ersten Aha-Effekte kommen mit den Zetteln der anderen. Wenn man die Ereignisse dann noch positiv/negativ beurteilt, kommt man ganz automatisch ins Gespräch. Und bekommt eine ungefähre Vorstellung, was besser zu machen ist.

  Ohne Aktivitäten wird es darauf hinauslaufen, dass man letztlich immer dieselben Fragen stellt — das langweilt selbst die hartgesottenen Teammitglieder und führt nach spätestens zwei oder drei Retrospektiven nicht weiter.

  Einen guten Überblick über mögliche Aktivitäten liefert das entsprechende Kapitel aus Agile Retrospectives: Making Good Teams Great.

• Moderation. Das ist empfehlenswert, um die Zeit im Auge zu behalten und die Aktivitäten zu koordinieren.

Die Rahmenbedingungen müssen stimmen

Damit Retrospektiven tatsächlich funktionieren, müssen einige Voraussetzungen erfüllt sein.

Einerseits muss das Team über Arbeitsprozesse selbst entscheiden dürfen. Die besten Maßnahmen sind nichts wert, wenn sie — als Vorschläge aufgefasst — noch irgendeinen Dienstweg gehen müssen.

Andererseits muss das Projekt in kurzen Iterationen durchgeführt werden. Agile Methoden wie Scrum helfen hier: Zwischen Sprints kann man etwa alle zwei bis vier Wochen eine Retrospektive durchführen.

Blick über den Tellerrand

Kent Beck beschreibt im Vorwort zu Agile Retrospectives: Making Good Teams Great, wie er Retrospektiven für sich nutzt und seinen Geburtstag zum Anlass nimmt, das vergangene Jahr Revue passieren zu lassen und Dinge in seinem Leben zu ändern.

Was für Erfahrungen habt ihr gemacht? Gibt es einen anderen, ähnlich effektiven Ansatz? Könnt ihr euch vorstellen, Retrospektiven bei euch zu nutzen, um schon im laufenden Projekt etwas zu verbessern?

[Foto von valentin.d, CC-Lizenz]

Seien wir ehrlich: Softwareentwicklung ist harte Arbeit. Es geht nicht nur darum, einer Maschine beizubringen etwas zu tun — das wäre ja einfach! Nein, es geht vor allem darum dafür zu sorgen, dass ich und andere in Zukunft daran weiterarbeiten können. Automatisierte Tests helfen dabei.

Wie muss man sich solche Tests vorstellen? Automatisierte Tests sind wie Checklisten, die ich schreibe und der Computer überprüft.

Eine solche Liste formuliert Anforderungen an die Software. Spezielle Programme arbeiten diese Listen Punkt für Punkt ab und zeigen, wo die Software sich anders verhält als gewollt.

Jeder, der sich einmal bei einer E-Mail-Adresse vertippt hat, weiß, wie pingelig Computer sein können, wenn etwas nicht genau ihren Erwartungen entspricht. Die Dinger sind ganz schön stur, gell?

Genau das macht man sich in Tests zunutze.

Dokumentation und Sicherheitsnetz in einem

Was bringen automatisierte Tests? Zunächst einmal eine rudimentäre Dokumentation, was die Software alles kann (vorausgesetzt, alle Tests laufen ohne Fehler durch und sind selbst nicht fehlerhaft programmiert).

Außerdem wird die Wartbarkeit der Software mit Tests erhöht. Jede noch so kleine Änderung kann Auswirkungen auf das Verhalten des gesamten Systems haben, wie auch XING weiß:

Jede neue Codezeile in einem Programm kann die exisitierenden Funktionalitäten beeinträchtigen.

Irgendwie beängstigend, oder? Ohne Tests ist man da als Entwickler weniger motiviert, Änderungen vorzunehmen. Mit Tests sieht die Sache anders aus.

Brillante Idee für ein neues Feature? Schreibe einen Test und entwickle dann die Funktion.

Unleserlicher Programmcode, der zwar tut was er soll, aber trotzdem verbessert werden muss? Kein Problem: Tests geben einem das gute Gewissen, dass sich am Verhalten der Software nichts geändert hat.

Bug gefunden? Der lässt sich mit einem Test nachstellen und dann beheben. So ist man davor geschützt, denselben Fehler nochmal zu machen.

Think big

Für große Projekte ist ein Argument für Tests unschlagbar: Wirtschaftlichkeit. Tests machen Änderungen an großen Systemen überhaupt erst möglich. Software zu warten, die über Jahrzehnte gewachsen ist und deren erste Autoren die Firma längst verlassen haben, ist ohne Tests ein Albtraum. Häufig ist eine Neuentwicklung unumgänglich — und das kostet!

Für Kunden heißt das übersetzt: Tests sichern die Weiterentwicklung. Und das kann nur gut sein.

Die Kehrseite der Medaille

Natürlich können Tests genauso fehlerhaft sein wie andere Programme auch. Dagegen hilft meist nur Erfahrung, um Probleme zu erkennen und zu vermeiden.

Auch die Investition, die für die Entwicklung von Tests notwendig ist, ist nicht zu vernachlässigen: Nicht selten sind Tests länger als die eigentlichen Programme — sogar in einem Mini-Projekt wie Headhunter ist der Test mehr als doppelt so lang wie das Programm selbst.

Ausblick

Dieser Aufwand ist es scheinbar auch, was manchen Manager davon abhält, in Tests zu investieren. Schade. Solche Firmen werden es in Zukunft schwer haben, Nachwuchs-Entwickler zu finden.

Man kann nur hoffen, dass sich Tests auch bei Kleinst-Projekten durchsetzen. Gerade für Hobbyprojekte kann es durchaus hilfreich sein, das vollständig getestete Programm an jemanden abzugeben, wenn man selbst keine Zeit mehr hat.

[Foto von Jen Rabulan-Bertram, CC-Lizenz]

Irgendwann vor ein paar Tagen hat jemand zwei Straßenecken weiter einen Einkaufskorb mit Kabelbinder an einem Schild befestigt. Mittlerweile wird der Korb als Müllbehälter benutzt, und kaputte Stühle wurden auch daneben abgestellt (“für Bastler”), die wieder weg sind. Das ganze ist eine wunderbar anschauliche Variante der Broken-Windows-Theorie.

Diese Theorie besagt, dass z. B. eine zerbrochene Fensterscheibe ausreicht, um weitere Zerstörung und Verwahrlosung zu fördern und beschleunigen. Das kaputte Fenster sollte schleunigst repariert werden, um Schlimmeres zu verhindern.

Umgeben von Hässlichem

Das Phänomen ist auch bei der Softwareentwicklung zu beobachten. Aufgabe jedes Entwicklers muss sein, lesbaren und wartbaren Programmcode zu hinterlassen. Code kann aber mit der Zeit verwahrlosen — vor allem, wenn er immer wieder unregelmäßig, unter hohem Zeitdruck und ohne die nötige Sorgfalt geändert wird (womöglich noch von unterschiedlichen Personen). Dazu genügt es, kleine Stellen im Programm unsauber zu hinterlassen.

Der entsprechende Artikel im C2-Wiki fasst das so zusammen:

When you’re surrounded by ugly things, your attitude and outlook change. You become pessimistic, and your expectations are lowered. Soon you start accepting that “that’s just how things are.” You start producing ugly things yourself.

Verhindern kann das, wer Software sorgfältig entwickelt, und dabei problematische Stellen gleich verbessert oder wenigstens als solche markiert.

Menschen respektieren gut gepflegte Dinge

Häufig hilft es dabei, das zu lösende Problem nicht isoliert zu sehen, sondern im Kontext: Passt die jetzige Lösung in die Umgebung oder muss ich noch mehr anpassen? Macht meine Lösung etwas anderes überflüssig? Kann jemand, der von dem Problem noch nichts weiß, ohne Erklärung erkennen, was mein Code tut? (Das Thema Refactoring, also Strukturverbesserungen von Programmcode, das hier angeschnitten wird, ist durchaus einen gesonderten Artikel wert.)

Wenn beim Blick auf den Programmcode grobe Schnitzer auffallen, gebe ich mir weniger Mühe. Wenn der Programmcode dagegen einen gut durchdachten und sorgfältig gepflegten Eindruck macht, werde ich das bei meinen Änderungen berücksichtigen und mir mehr Mühe geben.

Das ist insbesondere dann wichtig, wenn man als Entwickler auf Unterstützung aus ist.

Also: Repariere zerbrochene Fenster schnell.

Elizabeth Naramore hat ein paar interessante Antworten auf die Frage, warum Entwickler nicht zu Open-Source-Projekten beitragen. Diese Frage hat mich auch schon beschäftigt.

Was Elizabeth klären wollte, fasst sie wie folgt zusammen:

There are so many great opportunities in open source projects. Are people taking advantage of them? Do they even know about them? Do people even care?

Die drei am häufigsten genannten Gründe, sich als Entwickler nicht zu beteiligen, sind laut ihrer Umfrage:

• Zeitmangel
• Unsicherheit, was zu tun ist
• zu wenig Vertrauen in die eigenen Fähigkeiten

Als mögliche Gegenmittel dazu sind unter anderem aufgeführt:

• Aufteilung der ausstehenden Arbeit in kleine Häppchen
• genauere zeitliche Bezifferung für Mitwirkung
• Klärung der Erwartungen an Mitstreiter
• auch einfache Aufgaben für Anfänger übriglassen
• Bedarf nach Dokumentation, Design oder Support kommunizieren

Nur ein Teil des Puzzle

Diese Vorschläge gehören auf jeden Fall umgesetzt, viele davon sind allerdings zu kurz gegriffen oder wenig praktikabel. Entwickler sind von Natur aus eher am Entwickeln interessiert als daran, sich mit klar formulierten Anleitungen auf die Suche nach Mitwirkenden zu machen. Das kostet Zeit, die auch in die Programmierung neuer Features investiert werden könnte. Hier muss erst ein Bewusstsein entstehen, dass man sich das Leben mit ein paar einfachen Dingen leichter machen kann.

Und Schätzungen, wie lange bestimmte Aufgaben dauern, sind ohnehin ein Problemkind unserer Branche. (Das ist mit ein Grund, warum agile Methoden so populär sind.)

Die richtige Frage den falschen Leuten gestellt

Das größte Problem mit der Umfrage von Elizabeth sehe ich aber in ihrer Zielgruppe: Ich denke, dass es für Open-Source-Projekte kaum Mangel an Entwicklern gibt. Das Problem scheint mir einfach konstruiert.

Zunächst müsste man ermitteln, wer alles einen Beitrag leisten kann (Entwickler, Designer, Texter, …) und dann herausfinden, welcher dieser Gruppen das überhaupt bewusst ist. Die Frage “Warum nicht?” muss allen gestellt werden, nicht nur den Entwicklern. Entwickler, die (aus welchen Gründen auch immer) nichts zu Open-Source-Projekten beitragen, sind meiner Ansicht nach nur ein kleiner Teil. In der Mobilisierung der anderen Gruppen liegt das Potenzial.

Ich kenne Designer, die Open Source zehn Meilen gegen den Wind an Äußerlichkeiten zu erkennen glauben, aber selbst noch keinem Projekt zu einer anständigen Homepage verholfen haben.

Anderes Beispiel: Die offizielle Website vom Versionskontrollsystem Git, dessen Doku versucht, auch Nicht-Entwickler für das Projekt zu interessieren, wurde von einem Entwickler gestaltet.

Das sind Widersprüche, die untersucht werden müssen. Es scheint, als wären sich beispielsweise Designer zu fein, zu solchen Projekten beizutragen. Die Frage ist: Stimmt das? Und wie könnte man das ändern?

[Bild: Ausschnitt des Uncle Sam Recruiting Poster, gemeinfrei, unterliegt also nicht dem Urheberrecht]

Irgendwann kursierte bei uns im Freundeskreis mal die Bemerkung, man wisse nicht so genau, “was ich eigentlich den ganzen Tag mache”. Das habe ich zum Anlass genommen, meine Tätigkeit mal von einem nicht-technischen Standpunkt aus zu betrachten. Ein für mich wesentlicher Bestandteil: Agile Softwareentwicklung mit Scrum.

Gerade größere Softwareprojekte leiden unter dem Ruf, weder innerhalb des Zeitplans noch innerhalb des Budgets abgeschlossen zu werden — und wenn überhaupt, dann meist mit der schmerzhaften Einschränkung, dass dringend benötigte Funktionen nur teilweise umgesetzt wurden. Um dem entgegenzutreten, finden in der Branche immer häufiger agile Methoden Anwendung. (Manche gehen sogar so weit, agile Softwareentwicklung als Mainstream zu bezeichnen.)

Agile Softwareentwicklung versucht, typische Probleme bei der Entwicklung von Software zu vermeiden, indem Bürokratie vermieden und der Fokus auf die zu erreichenden Ziele gelegt wird.

Scrum (“Gedränge”) ist nur eine von vielen Möglichkeiten, Software agil zu entwickeln. Auf andere Methoden gehe ich hier nicht ein, weil sich mein Wissen über agile Methoden auf Scrum beschränkt. (Leider sind für mich agile Methoden im Allgemeinen und Scrum im Speziellen nicht immer klar voneinander abgegrenzt, eben weil ich bisher nur mit Scrum gearbeitet habe.) Scrum project management eliminates time spent going in the wrong direction sollte aber genauso für andere Ansätze gelten.

Scrum: In Sprints zu vorzeigbaren Ergebnissen

Nach der Scrum-Methode wird Software in sehr kleinen Schritten (“Sprints”, in der Regel zwei bis drei Wochen) entwickelt, ohne das gesamte Projekt von hinten bis vorne durchzuplanen. Ziel dieser iterativen Entwicklung ist es, möglichst schnell lauffähige Software zu erhalten.

Das ist weniger der Unlust am Planen geschuldet als vielmehr der Einsicht, dass die detaillierte Planung für einen größeren Zeitraum sowieso beliebig nutzlos sein wird. Im Alltag würde niemand auf die Idee kommen, sämtliche Mahlzeiten für das nächste halbe Jahr durchzuplanen, nur um sich möglichst ausgewogen und abwechslungsreich zu ernähren. So wie kaum jemand die Einzelheiten der Erziehung seines Kindes bis zur Volljährigkeit festlegen dürfte.

Man fängt also klein an und entwickelt einen Bruchteil der Software — der für sich genommen einen Nutzen darstellt. Ist der fertig, kann man darauf aufbauend eine gut informierte Entscheidung treffen, was als Nächstes zu tun ist.

Schneller sehen, wohin die Reise geht

Die Vorteile für den Auftraggeber dieses Rennens zur laufenden Software liegen auf der Hand: Er erhält schnelles Feedback und sieht, in welche Richtung sich das Produkt entwickelt — und ob das mit seinen Erwartungen übereinstimmt. Damit kann er während der Entwicklung Einfluss nehmen und z.B. einige Details noch weiter ausarbeiten und dafür weniger wichtige Dinge zurückzustellen oder ganz fallen zu lassen. Im schlechtesten Fall kann ein Projekt ganz eingestampft werden, bevor ein ganzes Jahr (oder zwei) vergangen und das Budget vollständig aufgebraucht ist.

Für das Team bietet Scrum schnelle Erfolgserlebnisse (auch durch die kurzen Feedback-Schleifen mit dem Auftraggeber), eigenständiges und selbstorganisiertes Arbeiten und vor allem die Möglichkeit, den eigenen Prozess und damit das Produkt zu verbessern. Wenn Fehler frühzeitig erkannt werden, die Richtung der Entwicklung noch geändert werden kann und in Retrospektiven regelmäßig über den vergangenen Sprint nachgedacht wird, erhöht das die Produktivität und verbessert das Endprodukt.

Natürlich ist auch Scrum kein Allheilmittel: Gerade die oben angesprochene hohe Verbreitung von agilen Methoden erhöht die Gefahr, Prozesse zu verwässern und “agil” als Marketing-Etikett zu missbrauchen. Scrum erfordert von allen Beteiligten viel Disziplin und den Mut, die eigene Arbeitsweise zu hinterfragen — und zwar nicht einmalig, sondern während des gesamten Projektes. Wer dazu bereit ist, wird Software nicht mehr anders als agil entwickeln wollen.

[Foto von royskeane, CC-Lizenz]