„Moment … der Joel-Test? Der ist doch uralt!“ mögen sich die Älteren unter uns nun denken. Ja, ist er. 24 Jahre, um genau zu sein.
Ich bin zufällig wieder über diesen Test gestolpert und habe aus Spaß über eine ganze Reihe vergangener Projekte nachgedacht. Und mein persönliches Ergebnis war ernüchternd.
Im Jahr 2024 sind einige der Fragen doch sicherlich leicht verdiente Punkte, dachte ich mir. Und ja, einige sind tatsächlich überholt und andere wiederum nur vermeintlich veraltet.
Doch lass uns einfach direkt einsteigen.
Ich lade Dich ein, Dein Team oder vergangene Projekte ebenfalls schnell zu bewerten. Es sind 12 mit „Ja“ oder „Nein“ zu beantwortende Fragen. Das dauert nur 1–2 Minuten.
Laut Joel Spolsky wäre eine Punktzahl von 11 noch akzeptabel. 10 oder weniger bedeutet, dass man ernsthafte Probleme hat.
Zu welchem Ergebnis kommst Du?
Im Folgenden gehe ich die Fragen etwas detaillierter durch und ergänze sie aus meiner persönlichen Erfahrung und Beobachtung. Das sind keine fertigen Lösungen. Die musst Du in Deinem Kontext selbst finden. Ich stelle nur Fragen und möchte Dinge besser verstehen.
Okay, das ist nun wirklich ein leicht verdienter Punkt, oder? Selbst wenn Du die einzige Entwicklerin bist, hat eine Versionskontrolle Sinn. Wiederherstellung alter Entwicklungsstände, immens vereinfachte Zusammenarbeit, Transparenz und somit die Vermeidung von kognitiver Last, wo sie wirklich nicht gebraucht wird, sind nur einige wenige Vorteile.
Wenn es hier schon scheitert, sind Deine Probleme größer als gedacht.
Hier wird es schon knackiger. In der originalen Beschreibung des Joel-Tests tauchen natürlich Technologien und Artefakte auf, die heute kaum noch Bedeutung für die Masse der Softwareentwicklung haben.
Doch wie steht es um Deine aktuellen Build-Systeme? Sind sie komplett automatisiert? Laufen sie stabil? Kann und darf jeder Entwickler im Team einen Build anstoßen? Laufen eure Build unabhängig oder sind sie von Artefakten anderer Teams abhängig?
Das ist eigentlich eine veraltete Frage. Viel besser wäre: erstellt ihr Builds bei jedem Commit?
Eine ernst zu nehmende Continuous Integration habt ihr erst, wenn alle dieser Punkte zutreffen:
Alles andere sind lediglich erste Schritte zu diesem Zielzustand.
Ich erweitere die Frage: Habt ihr einen strukturierten und transparenten Prozess, um mit Fehlermeldungen umzugehen? Und mit „strukturiert“ meine ich nicht Zuruf über den Flur, spontane Anrufe, Chat-Nachrichten oder E-Mails.
Gibt es eine Vorqualifikation der Meldungen, z. B. durch einen 1st- und 2nd-Level-Support, bevor sie beim Entwicklungsteam aufschlagen? Sind die Fehlermeldungen „brauchbar“ in Hinsicht auf Zeitpunkt, Reproduzierbarkeit, erwartetem und beobachtetem Verhalten?
Und dann stellt sich natürlich direkt die Frage, wie ihr mit gefundenen Fehlern umgeht. Hordet ihr eure Bugs oder …
Wird die Anzahl eurer Bug-Items in einem geeigneten Ticketsystem immer größer? Wieso eigentlich und woher kommen die vielen Meldungen? Testet ihr am Ende nicht genug und v.a. nicht automatisiert auf verschiedenen Ebenen? Stimmt etwas nicht bei der Erfassung und Besprechung der Erwartungen und Anforderungen?
Und was ist euer Bewertungssystem, ob und wann ein Bug behoben wird? Denn im Grunde genügt eine binäre Betrachtung: Kann eine Nutzerin damit leben oder ist es wirklich ein Fehlverhalten?
Im ersten Fall ist es entweder irrelevant oder eine mögliche Verbesserung und kann entsprechend priorisiert und eingeplant werden.
Im zweiten Fall wird das Problem sofort gelöst oder gar nicht. Seid im Team so ehrlich mit euch und schiebt die Entscheidung nicht auf die lange Bank.
Denn die Rechnung ist nicht nur in Hinsicht auf die Zufriedenheit und Belastung für Dich als Entwickler simpel.
Auch wirtschaftlich betrachtet ist eine sofortige Behandlung vorzuziehen. Je länger auf einen Fix gewartet wird, umso teurer in Hinsicht auf Zeit und damit Geld wird die Behebung.
Gibt es, je nach Umgebung, einen Projektplan oder eine geeignete Form von Roadmap? Ist das Dokument aktuell und realistisch? Sind die Inhalte allen Beteiligten auf allen Ebenen des Vorhabens bekannt?
Und bevor ein bekanntes Argument kommt: Meilensteine sind nicht per se schlecht, auch wenn jeder von uns den unnötigen Druck durch eine willkürliche Festlegung kennt. Doch es gibt unverrückbare Tatsachen, die sich nicht wegdiskutieren lassen. Gibt der Gesetzgeber z. B. neue Rahmenbedingungen mit Datum vor, dann sind diese zu erfüllen. Auch wichtige Messetermine lassen sich nicht verschieben.
Je nach Vorhaben kann dies eine Detailspezifikation sein, die abgearbeitet wird. Oder ein klares Ziel, auf das ein Team iterativ und anpassungsfähig hinarbeitet. In beiden Fällen stellt sich die Frage, ob alle Beteiligten das gleiche Verständnis haben, wann eine Anforderung erfüllt ist und welche Qualitätskriterien gelten.
Die Spezifikationsfrage lässt sich ebenso auf das richtige Maß an architektonischer Vorarbeit erweitern – es gibt viele Grautöne auf der Skala von „Big Design Up Front“ bis „saubere Anforderungen auf kurze Sicht“.
Oder das beliebte Thema Dokumentation. Wie stark z. B. ist unter den Entwicklerinnen und Entwicklern die Fraktion „der Code ist die Doku“? Und welche Probleme verursacht dies bei der Wissensverteilung im Team, der Einarbeitung neuer Teammitglieder oder der Transparenz für Stakeholder?
Wissensarbeit und „Deep Work“ brauchen Ruhe. Punkt.
Bietet euer Arbeitsraum diese Ruhe? Das kann den tatsächlichen physischen Raum betreffen, Kommunikationsregeln, Meeting-Last und mehr.
Und mit geeigneten Metriken lässt sich dies auch messen.
Kurz gefasst: spart nicht am falschen Ende. Schwache Rechner, billige und kleine Monitore oder die falsche Software sind nur wenige Beispiele, die zu Unzufriedenheit und niedrigerer Produktivität führen.
Zudem sind nicht alle Teams gleich, weshalb es eine schlechte Idee sein kann, allen Entwicklern die gleichen Werkzeuge aufs Auge zu drücken. Lasst die Experten selbst entscheiden, was sie brauchen, um ihre Arbeit bestmöglich zu erledigen!
Und ein Wort der Vorsicht, wenn ihr Tools selbst zusammenschustern wollt. Ja, das Ergebnis kann einen Tick besser zu euren Anforderungen passen. Doch unterschätzt nicht die Kosten für die Erstimplementierung und v.a. nicht den Aufwand für die kontinuierliche Pflege. Die übliche Abwägung zwischen „build, buy, or customize“ eben.
Ich wäre sogar schon zufrieden, wenn sie in einer anderen Abteilung wären. Das ist zumindest ein Anfang. Gar keine zu haben, ist dagegen ein Problem.
Auf der anderen Seite sind explizite Testerinnen und Tester kein Argument, das Thema Qualität anderen zu überlassen. Qualität ist ein Thema des gesamten Entwicklungsteams! Und manuelle Tests sind kein Ersatz für eine ausreichende Abdeckung mit automatisierten Tests.
Ein dedizierter QA-Mensch im Team muss auch nicht alles selbst testen. Klar, eine eigene Kraft für explorative Tests hat Vorteile. Doch wie sieht es mit der Wissensverteilung aus, z. B. rund um das Schreiben guter Tests und den Umgang mit Test-Tools?
Ja, Recruiting ist ein schwieriges Thema.
Hat das Team ein Mitsprachrecht, wer neu aufgenommen wird? Wer nimmt den fachlichen Test einer Kandidatin oder eines Kandidaten vor? Hat der testende Mensch das nötige Wissen und Erfahrung, um die Antworten bewerten zu können und ggf. die „Testrichtung“ zu ändern? Wenn praktische Problemstellungen gelöst werden sollen, sind diese an echte Aufgaben aus der täglichen Arbeit angelehnt oder theoretischer Natur?
Sind die Anwenderinnen eures Produkts im eigenen Haus, zieht ihr diese zu Tests und Reviews hinzu? Was hält euch auf?
Sind die Anwender oder Kunden außerhalb, zieht ihr diese zu Tests und Review hinzu? Was hält euch auf?
Wann kommt eine Nutzerin generell zum ersten Mal in Kontakt mit dem System? Und Du ahnst es schon: Was hält euch auf?
Du bist erfahrener Entwickler und denkst Dir jetzt: „Also bitte, das ist doch alles glasklar. Es kann doch nicht sein …?“ Doch, kann es und ist es „dort draußen“.
Die Software- und Beratungsindustrie ist gut darin, ununterbrochen Neues zu erzeugen. Seien es Werkzeuge, Methoden oder Prozesse.
Was diese Flut an Neuigkeiten überdecken kann, ist die Tatsache, dass selbst die einfachsten und ältesten Mindestanforderungen an eine zeitgemäße Entwicklung nicht erfüllt werden.
Der Joel-Test zeigt ein Vierteljahrhundert später, wo es in der Softwareentwicklung noch immer recht traurig aussieht.
Das ist nicht zwangsweise die Schuld der Devs (was sie nicht aus der Verantwortung lässt.) „Warum verstehen Manager noch immer nicht Dinge wie Komplexität, Unschätzbarkeit, diverse Gesetzmäßigkeiten etc.?“ ist ein zu einfaches Gegenargument. Wieso hat es ihnen denn niemand in einer für sie verständlichen Sprache erklärt?
Und natürlich sind die in diesem Beitrag behandelten Faktoren nicht die einzigen Indikatoren für den Erfolg eines Teams. Sie sind ein Baustein unter vielen.
Geht nicht? Doch, geht. Seit Jahrzehnten. Wenn es bei Dir nicht geht, ist es eher ein „geht nicht, weil …“. Und mit dem darauffolgenden Nebensatz beginnt die Verbesserung.
Schnapp Dir die 7 Fragen für hochproduktive Entwicklungsteams und buche Deine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Dich am wirkungsvollsten unterstützen kann.