Der Joel-Test stellt zwölf simple Ja/Nein-Fragen, die man am besten alle mit Ja beantworten sollte.

Softwareentwicklung ist eine diffizile Geschichte. Noch immer scheitern viele Projekte oder verzögern sich unendlich, und kein Beteiligter weiß exakt, woran das liegt.

Ein Indikator für die Qualität der Umgebung, in der Software entstehen soll, ist der Joel-Test: Zwölf simple Fragen, die man sich oder den Verantwortlichen stellen sollte, um den Ist-Zustand zu bewerten und den Soll-Zustand kennenzulernen: Zwölf Mal Ja.

Joel Spolsky hat seine Fragen schon vor Jahren in seinem Blog formuliert, und sie sind - zumindest in der informierten englischsprachigen Developer-Gemeinde - legendär geworden. Seine Feststellung ist simpel: Wenn eine Softwarefirma in diesem Test mit weniger als 11 Ja abschneidet, hat sie ein Problem. Trotzdem finden sich immer wieder Firmen, die nur auf zwei oder drei Ja kommen.

Das Problem mit den Originalfragen ist: Sie passen prima auf Szenarien, in denen Entwickler irgendeine Art von Software produzieren, die kompiliert, verpackt und installiert wird und auf mehreren unterschiedlichen Betriebssystemen oder Betriebssystemversionen laufen soll. Dieses Szenario existiert natürlich - für Entwickler, die sich mit Webanwendungen beschäftigen, sind einige Fragestellungen allerdings nicht ganz so exakt beantwortbar. Außerdem bleibt die Welt ja nicht stehen, sondern entwickelt sich weiter. Eine angepaßte und für Webprojekte in meinen Augen sehr brauchbare Version hat unlängst Brandon Savage formuliert. Ich nehme mir die Freiheit, die Testfragen hier in Deutsch zu publizieren - vernünftige Umgebungsbedingungen für erstklassige Softwareentwicklung können nie schaden.

Der Joel-Test für Webentwicklung

Im Schnelldurchlauf:

1. 1. Existiert eine Form von Versionskontrollsystem?
2. 2. Ist es möglich, eine auslieferbare Version der Software in einem Schritt herzustellen?
3. 3. Wird Continuous Integration benutzt?
4. 4. Gibt es eine Bug-Datenbank?
5. 5. Werden Fehler gefixt, bevor neue Features geschrieben werden?
6. 6. Gibt es einen immer aktuell gehaltenen Plan?
7. 7. Gibt es Spezifikationen?
8. 8. Haben die Programmierer eine ruhige Arbeitsumgebung?
9. 9. Werden die besten existierenden Werkzeuge benutzt, die man kriegen kann, und wird auch Geld für die Werkzeuge ausgegeben, die notwendig und teuer sind?
10. 10. Werden Unit-Tests geschrieben?
11. 11. Demonstrieren Job-Bewerber ihr Programmier-Können in einer nachvollziehbaren Art und Weise während des Bewerbungsgesprächs?
12. 12. Gibt es Tester?

Diese zwölf Fragen sollten sich in sehr kurzer Zeit mit Ja oder Nein beantworten lassen, um zu wissen, wo man steht.

Ein paar Detailanmerkungen zu jeder einzelnen Frage:

1. Existiert eine Form von Versionskontrollsystem?

Es gibt hier keine Ausrede für ein Nein. Schon wenn man nur als Einzelperson an einem Projekt arbeitet, hat man Bedarf für die Features von Versionskontrolle: Beliebig ältere Dateiversionen wiederherstellen zu können, oder zumindest nachzusehen, was früher mal drinstand. Und das, ohne dass man in einer Flut von "filename.html.old" ertrinkt.

Erst recht ist Versionskontrolle für die Teamarbeit unverzichtbar, denn erst damit ist es schmerzlos möglich, dass verschiedene Entwickler gleichzeitig an denselben Dateien arbeiten, ohne sich gegenseitig ihre Änderungen zu überschreiben.

Es gibt so viele kostenlose Lösungen: Subversion als der de-facto Standard für zentrale Versionskontrolle (wer noch mit CVS arbeitet, nutzt ein nicht mehr zeitgemäßes Tool und sollte auf Subversion umsteigen - aber das ist immer noch besser, als nichts), oder Git, Mercurial oder Bazaar für die dezentrale Versionskontrolle (alle drei können auch in Kombination mit Subversion eingesetzt werden).

2. Ist es möglich, eine auslieferbare Version der Software in einem Schritt herzustellen?

Das berührt die Frage: Wie kommt der geschriebene Code denn eigentlich auf den Server? Antwort: Indem jemand die geänderten Dateien hochspielt und irgendwie parallel auch die Veränderungen in der Datenbank vornimmt? Böse Falle! Der Prozess ist fehleranfällig und aufwendig. In Wirklichkeit will man einfach irgendwo einen Knopf drücken oder ein Programm starten, und alles notwendige passiert automatisch.

Aber eine neue Version wird ja nicht einfach so blind auf den Server geworfen: Vorher müssen Tests laufen, die neue Version wird vermutlich erstmal durch die Qualitätskontrolle geschleust (auf einem separaten Server nur für die QA-Leute). Insgesamt hat es einen deutlich beschleunigenden und fehlerreduzierenden Effekt, wenn der Aufwand, die Software auf den Server zu tun, möglichst gering ist. Man denke nur an den nötigen Aufwand, einen komplett neuen Server erstmalig in Betrieb nehmen zu müssen.

3. Wird Continuous Integration benutzt?

Continuous Integration ist der Prozess, dass sämtliche Arbeit der Entwickler fortwährend in das Gesamtprojekt einfließen, und dass sofort geprüft wird, ob eine Änderung irgendetwas kaputt macht. Für diese regelmäßige Aufgabe existieren Tools wie phpUnderControl oder Xinc, die sämtliche Code-Änderungen im Versionskontrollsystem einer eingehenden Prüfung unterziehen: Unit-Tests ablaufen lassen, die Einhaltung von Coding-Standards prüfen, quantitative Qualitätsmerkmale ermitteln, automatische Dokumentation generieren etc. - und sofort Alarm zu geben, wenn irgendeiner dieser Schritte scheitert. Denn es ist am einfachsten, sofort zu reagieren, wenn die Erinnerung der Entwickler noch frisch ist, wenn eine Änderung irgendetwas kaputt macht.

4. Gibt es eine Bug-Datenbank?

Keine Frage: Ein Entwickler sollte seine geistige Kapazität ausschließlich für das Coden bereithalten, nicht zum Erinnern an irgendwelche Bugmeldungen. Und er sollte diese Bugmeldungen auch nicht in einem unübersichtlichen Mailarchiv hervorsuchen müssen.

Bug-Datenbanken, oder auch Issue-Tracker genannt, sind der ideale zentrale Ort, in dem sich alle Meldungen über Merkwürdigkeiten, Bugs, neue Features etc. befinden. Es gibt viele kostenlose Systeme wie Trac (das integriert gleich noch ein Wiki und einen Browser für den in der Versionskontrolle gehaltenen Code), Mantis oder Bugzilla. Diese sind als Minimal-Erfüllung der Frage vollkommen in Ordnung. Aber es gibt auch etliche deutlich mächtigere Systeme, die für Geld zu lizensieren sind, und die Verwaltung und das Management des Projekts deutlich leichter machen. Egal, was installiert würde: Die Abwesenheit einer Bug-Datenbank ist unentschuldbar.

5. Werden Fehler gefixt, bevor neue Features geschrieben werden?

Je mehr Zeit vergeht, bevor ein gefundener Fehler behoben wird, desto aufwendiger wird es. Angenommen, ein Entwickler baut einen Tippfehler ein. Wenn ihm der Compiler oder Interpreter sofort eine Fehlermeldung auswirft, dauert es keine fünf Sekunden, und der Fehler ist weg. Wenn der Tippfehler subtiler ist, und erst nach dem Commit das Continuous Integration-System das Scheitern eines Unit-Tests meldet, dauert das Beheben schon länger - der Code muss erst wieder gefunden und gelesen werden. Wenn eine Woche vergeht, bevor der Entwickler die Bugmeldung bearbeitet, ist die Erinnerung an seine Absichten in dem Code schon verblasst. Er muss sich erst wieder reindenken, was er erreichen wollte.

Und die Situation wird natürlich nicht einfacher, wenn zwischendurch der fehlerhafte schon durch neue Features verändert wurde. Im Gegenteil: Mit Pech verlässt sich irgendein anderer Codeteil mittlerweile auf das falsche Verhalten. Oder es wurden viele Entwicklerstunden verbraten, weil der Fehler zu unerklärlichem Verhalten führte. Egal, was es ist: Fehlerhaftem Code kann man nicht trauen - spätestens wenn der Fehler an Kunden ausgeliefert wird, und der ihn entdeckt, sinkt das Vertrauen in die Qualität des Produkts.

6. Gibt es einen immer aktuell gehaltenen Plan?

Der Plan sollte die Frage beantworten: Was passiert als nächstes? Und zwar für das gesamte Team sichtbar. Entwickler mögen keine Überraschungen, vor allem keine unangenehmen. Wenn unerwartet in drei Tagen die Fertigstellung wichtiger Features auf den Plan kommt, wirft das die gesamte interne Planung jedes einzelnen Entwicklers über den Haufen.

Zwar kann der Plan nicht in Stein gemeißelt werden, er muss flexibel sein und sich sowohl an den Projektfortschritt als auch die wandelnden Erfordernisse und Kundenwünsche anpassen. Aber in gewissen Punkten muss er verlässlich sein: "In den kommenden zwei Wochen realisieren wir die Features A, B und C" wäre eine einfache Ansage und klärt gleichzeitig, dass sich nicht mit Features D und E beschäftigt wird.

7. Gibt es Spezifikationen?

Mit Spezifikationen sind nicht die 500-Seiten-Dokumente gemeint, die sowieso keiner liest. Aber eine irgendwie fixierte Feststellung, was eigentlich genau gewünscht ist und hergestellt werden soll. Eine Skizze eines Seitenlayouts, eine stichpunktartige Liste von Methoden, eine kurze Beschreibung einer zu realisierenden Schnittstelle.

Soezifikationen klären, was genau zu tun ist - bevor man es tut. Durch Spezifikationen können Entwickler den Umfang der Aufgabe abschätzen. Außerdem verhindern sie, dass sich im Laufe der Erledigung die Aufgabe ständig um neue Features erweitert (feature creep) oder der Kunde in letzter Minute noch "wichtige Änderungen" haben will. Wenn eine Spezifikation vor dem Start abgesegnet ist, ist klar, dass die Aufgabe erledigt ist, wenn alle Punkte wie spezifiziert realisiert wurden. Das bedeutet nicht, dass z.B. der Kunde nichts ändern kann - nur nicht einfach so während der Aufgabenerledigung mit der Erwartung, dass dann trotzdem alles zum gleichen Zeitpunkt fertig wird.

8. Haben die Programmierer eine ruhige Arbeitsumgebung?

Programmieren ist eine extrem anstrengende Tätigkeit, die hohe Konzentration verlangt. Höchstleistungen erbringen Programmierer immer erst, nachdem sie sich eine gewisse Zeit, vielleicht zehn Minuten oder eine Viertelstunde, auf das Problem konzentriert haben und idealerweise in den "Flow" kommen. Jede äußere Störung, sei es durch Telefon, schwatzende Kollegen, hereinkommende Mails etc., unterbricht den Arbeitsfluß, stört den Flow, und senkt die Qualität und Produktivität.

Auch wenn Programmieren im Prinzip Teamarbeit ist: Die Möglichkeit, sich ungestört in ein Büro zurückzuziehen, ist unbezahlbar.

9. Werden die besten existierenden Werkzeuge benutzt, die man kriegen kann, und wird auch Geld für die Werkzeuge ausgegeben, die notwendig und teuer sind?

Entwickler sind verhältnismäßig teuer von den Betriebskosten her. Deshalb gibt es keine Entschuldigung, ihre Produktivität zu senken, indem unzulängliche Werkzeuge benutzt werden müssen.

Ein vernünftiger Rechner, der in der Lage ist viele Programme gleichzeitig geöffnet zu haben, nicht hakelt oder endlos mit der Festplatte rödelt? Zwingende Voraussetzung. Zwei angeschlossene Monitore? Das ist kein Luxus, das hebt die Produktivität um 20 bis 30%. Funktionierende Peripherie wie Tastaturen und Mäuse, eine vernünftige Softwareentwicklungsumgebung (IDE), ... all das sind elementare Grundbedürfnisse zur Erfüllung der Arbeit.

Im Prinzip muss das Arsenal von Werkzeugen in der Lage sein, dem Entwickler zu keiner Zeit störend im Weg zu stehen - denn auch das stört den Flow. Im Gegenteil drückt die Investition in hochwertige Werkzeuge die Wertschätzung aus, die den Entwicklern entgegengebracht wird (natürlich auch im negativen Sinn).

10. Werden Unit-Tests geschrieben?

Continuous Integration funktioniert nur, wenn Probleme und Fehler innerhalb von kürzestmöglicher Zeit durch automatisierte Verfahren entdeckt werden. Und zentraler Bestandteil solcher automatisierten Verfahren sind Unit-Tests.

Viele Projekte funktionieren ohne Unit-Tests. Meist deshalb, weil manuelle, menschliche Tester checken, ob die Software irgendwo kaputt ist. Oder die Entwickler werfen ein Auge drauf und bemerken auftretende Probleme. Dummerweise ist manuelles Testen nie so gründlich, weil es eine sehr langweilige Aufgabe ist, dieselben Prüfungen immer und immer wieder vorzunehmen. Deshalb sind automatisierte Tests ein sehr wichtiger Faktor zum Heben der Qualität. Je weniger Fehler unentdeckt bleiben, desto stabiler wird die Software, und desto mehr Zeit steht den Entwicklern für die Herstellung neuer Features zur Verfügung.

11. Demonstrieren Job-Bewerber ihr Programmier-Können in einer nachvollziehbaren Art und Weise während des Bewerbungsgesprächs?

Joels Originalfrage war: Schreiben Bewerber während des Bewerbungsgesprächs Code? Das ist eventuell etwas zu konkret und speziell. Ohne Frage ist es für den Arbeitgeber notwendig, die Fähigkeiten des Bewerbers einschätzen zu können - konkret das Schreiben von Code liefert aber nicht zwingend ausreichende Hinweise.

Stattdessen sollte das Gespräch flexibler und am Bewerber orientiert sein: Einem Berufsanfänger stellt man andere Aufgaben, vielleicht tatsächlich konkret die Programmierung einer einfachen Funktion, als einem auf dem Papier mit langjähriger Erfahrung ausgestatteten Entwickler. Mit dem diskutiert man vielleicht lieber die grundsätzliche Umsetzung kniffliger Probleme. Insgesamt sollte aus dem Gespräch die Erkenntnis gewonnen werden, wie der Bewerber denkt, wie er Probleme löst, und wie er kommuniziert.

12. Gibt es Tester?

Zweifellos wird Software immer noch von Menschen benutzt, und deshalb sind menschliche Tester unverzichtbar für einen guten Softwareentwicklungsprozess. Testern kommt dabei eine sehr wichtige Rolle zu: Sie müssen einerseits in die Rolle des Endusers schlüpfen und die Verständlichkeit der Benutzerführung etc. prüfen, andererseits aber auch fachliches Wissen der Programmierer haben, um zu erkennen, mit welchen potentiell problematischen Testszenarien sie Fehler im Programm provozieren können. Und sie müssen am Ende ihre Resultate auch noch in verständlichen und das Problem ausreichend beschreibenden Meldungen dokumentieren.

Die Entwickler sind hingegen ganz schlechte Tester. Einerseits wissen sie, was sie programmiert haben, und damit voreingenommen. Andererseits ist ihre Aufgabe, zu programmieren, und nicht zu testen. Vor allem wenn der Zeitplan eng ist, ist die Versuchung groß, das Testen einfach zu kürzen oder ganz wegfallen zu lassen.

Eigenständige Tester, die in der Lage sind, den Finger auf wunde Stellen zu legen, und denen die Kompetenz zugesprochen wird, ihr Veto zu einer geplanten Veröffentlichung einzulegen, wenn die Software nicht ordentlich funktioniert oder die Spezifikationen nicht erfüllt, sind ein sehr wichtiger Team-Bestandteil.

Unter dem Strich

Diese Anforderungen (mindestens mit dem Fokus auf weborientierte Software), die eine gute Arbeitsumgebung für Softwareentwicklung auszeichnen, sollten im Prinzip überall realisiert werden, wo Software geschrieben wird. Wie erwähnt: Microsoft und ähnliche Top-Kaliber haben 12 von 12 Ja - die ganze Zeit. Sehr gute Firmen laufen mit 11/12. Ab 10/12 wird es laut Joel kritisch.

Die Fragen sind einfach genug, dass man sie sich in fünf Minuten selbst beantworten kann. Und alle Punkte mit "Nein" sollten so bald wie möglich geändert werden, dass ein "Ja" dabei rauskommt.

Kommentare nehme ich natürlich sehr gerne entgegen.