Dieser Artikel ist eine Übersetzung aus dem Englischen ins Deutsche. Thema ist der von Joel Spolsky am 09. August 2000 verfasste Artikel “The Joel Test: 12 Steps to Better Code”. Der Test selbst besteht aus 12 Fragen, deren Antwort im Idealfall immer Ja sein sollte. Ziel dieser Fragestellung ist es, den Ist-Zustand eines IT-Projekts fest zu stellen. Hat man alle Fragen positiv beantwortet, läuft das Projekt wie es soll. 11 Fragen mit Ja sind noch akzeptabel. Projekte, die darunter liegen, gelten als verbesserungswürdig.
Beginn der Übersetzung ins Deutsche
Der Joel Test
- Verwenden Sie ein Versionskontrollsystem?
- Können Sie eine auslieferbare Version (Build) in einem Schritt herstellen?
- Liefern Sie tägliche Softwarepakete?
- Haben Sie eine Fehler-Datenbank?
- Fixen Sie Fehler, bevor Sie neuen Code schreiben?
- Haben Sie eine aktuellen Zeitplan?
- Haben Sie Projektspezifikationen?
- Stehen den Entwicklern ruhige Arbeitsbedingungen zur Verfügung?
- Verwenden Sie die besten Werkzeuge, die erhältlich sind?
- Werden Softwaretester eingesetzt?
- Lassen Sie neue Team-Mitglieder während des Interviews nachweisen, dass Sie entwickeln können?
- Lassen Sie die Usability testen?
Das Tolle am Joel Test ist, dass es einfach ist zu jeder Frage ein schnelles Ja oder Nein zu erhalten. Sie müssen nicht erst die täglichen Codezeilen oder durchschnittlichen Bugs identifizieren. Geben Sie Ihrem Team einen Punkt für jede JA Antwort. Einziger Nachteil des Joel Tests wäre, dass Sie ihn nicht dafür einsetzen sollten um sicher zu stellen, ob ihre Kernkraftwerksoftware auch sicher läuft.
Ein Ergebnis von 12 ist perfekt, 11 sind noch akzeptabel, aber weniger als 10 zeigen auf, dass es schwerwiegende Probleme gibt. Die traurige Wahrheit ist jedoch, dass die meisten Softwarefirmen einen Wert von 2 oder 3 aufweisen und unbedingt Hilfe benötigen, weil Unternehmen wie Microsoft rund um die Uhr einen Wert von 12 aufweisen.
Natürlich sind das nicht die einzigen Faktoren, welche über Erfolg und Scheitern entscheiden: Insbesondere bedeutet das, falls Sie ein großartiges Software-Team haben, welches an einem Produkt arbeitet, was niemand will, wird dass dann auch niemand kaufen wollen. Und es ist durchaus möglich sich vorzustellen, dass ein Team von sogenannten “Revolverhelden” es schafft, tolle Software zu produzieren, die die Welt verändert. Dennoch - wenn Sie die folgenden 12 Punkte richtig machen, besitzen Sie ein diszipliniertes Team, welches zuverlässig liefern kann.
1. Verwenden Sie ein Versionskontrollsystem?
Ich habe sowohl kommerzielle Versionsverwaltungssysteme als auch CVS verwendet, welches kostenlos ist und ich kann Ihnen bestätigen, dass CVS in Ordnung ist. Falls Sie keine Versionskontrolle verwenden, wird Sie der Versuch nerven die Entwickler dazu zu bringen zusammen zu arbeiten. Programmierer haben keine andere Möglichkeit festzustellen, was jemand anderes bereits erledigt hat. Fehler lassen sich nicht einfach rückgängig machen. Zudem ist es eine saubere Sache, dass mittels eines Versionskontrollsystems der Quellcode automatisch auf die Festplatte jedes Entwicklers ausgecheckt (kopiert) wird - ich habe noch von keinem Projekt gehört, bei dem Code verloren ging, wenn es eine Versionskontrolle verwendet.
2. Können Sie eine auslieferbare Version (Build) in einem Schritt herstellen?
Damit meine ich folgendes: wie viele Schritte sind notwendig, damit Sie eine auslieferbare Version des letzten Codestands herstellen können? In einem guten Team gibt es hierfür ein einziges Skript, welches Sie verwenden, um einen vollständigen Checkout von Grund auf zu erzeugen. Welches alle Codezeilen umbaut, EXE-Dateien erstellt - in allen Varianten, Sprachen und #ifdef-Kombinationen. Ein Installationspaket erzeugt und ein Endmedium kreiert - sei es ein CDROM, ein Download-Archiv oder was auch immer.
Falls dieser ganze Prozess mehr als einen Schritt benötigt ist er fehleranfällig. Und sobald Sie sich dem Liefertermin nähern, bevorzugen Sie einen sehr schnellen Zyklus um den letzten Fehler zu korrigieren, die finale EXE-Datei zu erzeugen usw. Falls Sie für diesen Prozess mehr als 20 Schritte benötigen um den Code zu kompilieren, die Installationsdatei zu erstellen usw, läuft alles schnell aus dem Ruder und es schleichen sich vermeidbare Fehler ein.
Aus diesem Grund wurde in der letzten Firmen, für die ich gearbeitet habe von WISE auf InstallShield umgestellt: unsere Anforderung war, dass der Installationsprozess automatisch von einem Skript über Nacht unter der Verwendung einer NT-Steuerung lief. WISE konnte die Steuerung über Nacht nicht liefern, also wurde es verworfen. (Die netten Leute von WISE versicherten mir, dass in ihrer neusten Version die nächtlichen Builds (1) nun unterstützt werden.)
3. Liefern Sie tägliche Softwarepakete?
Sobald Sie eine Versionsverwaltung verwenden kann es vorkommen, dass ein Entwickler aus Versehen etwas eincheckt, was den Build unterbricht. Es kann zum Beispiel vorkommen, dass jemand eine neue Quelldatei hinzugefügt hat. Alles kompiliert wie es soll auf deren PC, allerdings wurde vergessen die Quelldatei auch in das Repository (2) hinzuzufügen. Die Person macht den PC aus und geht nach Hause - glücklich und unbeschwert. Allerdings kann niemand sonst mehr weiter arbeiten und muss ebenfalls heim gehen, weniger glücklich.
Den Build zu unterbrechen ist ein schlechtes (und leider häufiges) Vorkommnis und es hilft, wenn man jeden Tag einen Build durchführt um sicher zu gehen, dass keine Unterbrechungen unbemerkt bleiben. Bei großen Teams hat es sich bewährt jeden Tag am Nachmittag einen Build zu starten, zur Essenszeit, so dass Unterbrechungen gleich gefixt werden. Jedes Team-Mitglied macht so viele Checkins wie möglich vor dem Essen. Wenn sie zurück kommen ist der Buildprozess beendet. Hat alles funktioniert ist das großartig! Jeder checkt die neuste Version des Codes aus and fängt an damit zu arbeiten. Hat der Build nicht funktioniert muss er gefixt werden, aber zwischenzeitlich kann jeder mit der vorherigen Buildversion ohne Unterbrechung weiter arbeiten.
Im Excel-Team gab es eine Regel dass jeder, der für die Unterbrechung des Builds sorgte als “Strafe” für die weitere Durchführung eines Builds verantwortlich war. Solange bis ein anderer aus dem Team für eine unvorhergesehene Unterbrechung sorgte. Das war ein guter Anreiz dafür zu sorgen, den Build nicht zu unterbrechen und eine gute Möglichkeit einmal den Build-Prozess jeden durchführen zu lassen. Damit jeder lernte, wie das ganze funktioniert.
Mehr zu diesem Thema in meinem Artikel “Daily Builds are Your Friend”.
4. Haben Sie eine Fehler-Datenbank?
Mir ist es egal was Sie sagen. Falls Sie Code entwickeln, selbst bei einem Ein-Mann-Team, ohne auf eine organisierte Datenbank, welche alle bekannten Codefehler auflistet, sind Sie auf dem besten Weg schlechte Qualität zu liefern. Viele Entwickler bilden sich ein, dass Sie die Fehlerliste im Kopf haben. Unsinn, ich kann mich nicht an mehr als zwei oder drei Bugs gleichzeitig erinnern. Und am nächsten Morgen oder während der stressigen Auslieferungsphase wurden sie wieder vergessen. Es ist unbedingt notwendig, dass Sie an den formellen Fehlern dran bleiben.
Fehlerdatenbanken können kompliziert oder einfach sein. Eine Fehlerdatenbank sollte mindestens die folgenden Daten für jeden Fehler bereit halten:
- die vollständigen Schritte um den Fehler zu reproduzieren
- das zu erwartende Verhalten
- das beobachtete (fehlerhaftes) Verhalten
- wer sich darum kümmern soll
- ob er behoben wurde oder nicht
Sollte Sie bisher nur die Komplexität der Fehlerverfolgung vor dem Verfolgen von Fehlern abgehalten haben, erstellen Sie einfach eine 5-spaltige Tabelle mit den entscheidenden Feldern und fangen Sie an diese zu verwenden. Mehr zu diesem Thema lesen Sie in: “Painless Bug Tracking”.
5. Fixen Sie Fehler, bevor Sie neuen Code schreiben?
Die allererste Version des Microsoft Word für Windows wurde für ein Todesmarsch Projekt gehalten. Es dauerte ewig. Es geriet außer Kontrolle. Das gesamte Team hat unheimlich viele Stunden gearbeitet. Das Projektziel wurde immer wieder verschoben und der Stress war einfach unglaublich groß. Als das elende Teil endlich veröffentlicht wurde - Jahre später - hat Microsoft sein ganzes Team erst einmal für einen Urlaub nach Cancun geschickt. Und setzte sich dann hin um sich ernsthafte Gedanken über den Projektverlauf zu machen.
Was sie heraus gefunden haben war, dass die Projektmanager so sehr auf die Einhaltung des Zeitplan drängten, dass die Entwickler einfach nur durch den Entwicklungsprozess geeilt sind. Sie schrieben extrem schlechten Code, weil die Phase der Fehlerbehebung kein Teil des Planes war. Es gab keine Versuche die Fehlerquote unten zu halten. Ganz im Gegenteil. Es ging die Geschichte herum, dass einer der Entwickler, welcher an der Entwicklung einer Funktion zur Berechnung der Höhe einer Textzeile beteiligt war, einfach ein “return 12;” schrieb. Und dann einfach auf den Fehlerbericht zu seiner nicht arbeitenden Funktion wartete. Der Zeitplan bestand überwiegend aus einer Art Checkliste mit Features, die darauf warteten in Fehler umgewandelt zu werden. Im Nachhinein wurde dies als Endlose Fehler Methode bezeichnet.
Zur Problembehebung eignete sich Microsoft etwas namens Null Fehler Methode an. Viele der Entwickler amüsierten sich darüber, da es so klang als ob das Management dachte mit dieser Anordnung Fehler reduzieren zu können. Tatsächlich bedeutete Null Fehler dass zu jeder Zeit die Fehlerbehebung einen höheren Stellenwert hat als das Schreiben von Code. Hier der Grund, warum das so ist.
Generell gilt, je länger Sie mit der Fehlerbehebung warten, desto kostspieliger (in Zeit und Geld) wird es den Fehler zu beheben. Ein Beispiel: wenn Sie einen Schreib- oder Syntaxfehler machen, den der Compiler erkennt, ist die Fehlerbehebung eigentlich trivial. Sollten Sie einen Fehler haben, den sie gleich beim ersten Mal bemerken, haben Sie den auch schnell behoben, weil der verwendete Code noch relativ gut im Gehirn verankert ist. Findet man aber einen Fehler in einem Codeabschnitt, der schon ein paar Tage alt ist, wird es eine Weile dauern diesen zu beheben, weil man erst mal wieder jede Codezeile lesen und analysieren muss, was man da genau gemacht hat.
Aber wenn Sie einen Fehler finden, der schon ein paar Monate alt ist, haben Sie wahrscheinlich schon die meisten Dinge hinsichtlich des Codes vergessen. Und es wird um einiges schwieriger diesen Fehler zu beheben. Zu diesem Zeitpunkt sind Sie wahrscheinlich sogar schon dabei den Fehler von jemand anderen zu verbessern, jemand, der vielleicht gerade in Aruba Urlaub macht und nichts mehr zu seinem Codeabschnitt sagen kann. In dem Fall ist Fehlerbehebung eine Wissenschaft: langsam, methodisch und akribisch und man kann nicht genau sagen, wie lange es dauert, bis alles wieder funktioniert.
Und sollten Sie einen Fehler finden, der bereits ausgeliefert wurde, wird sich die Fehlerbehebung zu einem unglaublich teurer Aufwand entwickeln.
Das ist nur einer der Gründe, warum man einen Fehler gleich beheben soll: weil es einfach weniger Zeit in Anspruch nimmt. Ein weiterer Grund ist der, dass es einfacher wird vorherzusagen, wie lange es dauert neuen Code zu schreiben als bestehenden zu verbessern. Ein Beispiel: Falls ich Sie frage, wie lange es dauern wird den Code zum sortieren einer Liste zu schreiben, erhalte ich mit Sicherheit eine ziemlich genaue Zeitschätzung von Ihnen. Will ich jedoch von Ihnen wissen, wie lange es dauern wird den Fehler zu beheben, der auftritt, weil der Internet Explorer 5.5 installiert ist, bekommen Sie mit Sicherheit Probleme die Schätzung abzugeben, weil Sie nicht genau wissen was den Fehler verursacht. Es kann drei Tage oder auch nur zwei Minuten dauern.
Konkret bedeutet dass, wenn Sie einen Zeitplan haben und es müssen noch sehr viele Fehler gefixt werden, dann ist der Zeitplan unrealistisch. Haben Sie aber bereits alle bekannten Fehler behoben und es ist nur noch neuer Code übrig, dann wird der Zeitplan auch relativ genauer sein.
Ein weiterer Vorteil des Null Fehler Plan ist, dass die Antwortzeiten im Wettbewerbsumfeld einfach schneller sind. Viele Entwickler wissen bereits, dass sie dadurch ein Produkt einfach schnell ausliefern könnten. Denn wenn ihr Mitbewerber mit einer neuen Hammerfunktion daher kommt, dass Ihnen die Kunden nimmt, könnten Sie so eine neue Funktion ebenfalls einfach schneller implementieren und ausliefern - ohne erst die angesammelte Anzahl an Fehlern beheben zu müssen.
6. Haben Sie eine aktuellen Zeitplan?
Obiges bringt uns auch schon zur Zeitplanung. Wenn der Code für ihr Geschäft schon so wichtig ist, dann gibt es viele Gründe, warum es ebenfalls wichtig für ihr Geschäft ist zu wissen, wann der Code fertig sein wird. Entwickler sind bekanntermaßen recht mürrisch wenn es um die Zeitplanung geht. “Es wird fertig sein, wenn es fertig ist.” hört man sie oft schreien.
Unglücklicherweise trifft es diese Aussage nicht. Es gibt zu viele zu berücksichtigende Entscheidungen in der Planung, die im Voraus getroffen werden müssen hinsichtlich: Demos, Vorführungen, Werbung usw. Und die einzige Möglichkeit hierfür besteht darin einen Zeitplan zu erstellen und diesen stets aktuell zu halten.
Ein weiterer wichtiger Punkt, der für einen Zeitplan spricht ist der, dass Sie gezwungen werden festzuhalten, an welchen Features gearbeitet wird. Und das zwingt Sie dazu die weniger wichtigen Funktionalitäten zu identifizieren und raus zu nehmen anstelle in die Featuritis abzugleiten (a.k.a. scope creep).
Eine Zeitplanung muss nicht schwer sein. Lesen Sie meinen Artikel Painless Software Schedules, welcher einen einfachen Weg für einen großartigen Zeitplan beschreibt.
7. Haben Sie Projektspezifikationen?
Konzepte schreiben ist wie Zahnseide: jeder ist der Meinung, dass es eine gute Sache ist, aber keiner verwendet es.
Ich bin mir nicht sicher warum das so ist, aber wahrscheinlich liegt es daran, dass Entwickler das Schreiben von Dokumenten hassen. Aufgrund dessen bevorzugen Teams, die hauptsächlich aus Entwicklern bestehen, ihre Lösungen anhand von Code auszudrücken, anstelle von Dokumenten. Sie würden lieber tiefer eintauchen und Code schreiben, als erst die Spezifikation zu erzeugen.
In der Entstehungsphase, wenn man Probleme entdeckt, ist es einfacher diese zu fixen, indem man ein paar Zeilen Text anpasst. Ist der Code erst einmal geschrieben, sind die Kosten ein Problem zu beheben drastisch höher. Sowohl emotional (Leute hassen es Code wegschmeißen zu müssen) als auch zeitlich. So gibt es immer Widerstand wenn ein Problem tatsächlich behoben wird. Software, die nicht aufgrund von Konzepten erstellt wurde endet gewöhnlich mit einem schlechten Design und der Zeitplan gerät außer Kontrolle. Das scheint auch das Problem bei Netscape gewesen zu sein, als die ersten vier Versionen in so einem Durcheinander endeten, dass das Management dummerweise entschied den Code raus zu schmeißen und neu zu beginnen. Und dann machten Sie genau den selben Fehler mit Mozilla. Sie erschufen ein Monster, dass außer Kontrolle geriet und mehrere Jahre brauchte, um den Alpha Zustand zu bekommen.
Meine Lieblings-Theorie ist die, dass dieses Problem behoben wird, indem die Entwickler gelehrt werden weniger zurückhaltende Autoren zu sein und zu einem Intensivkurs im Schreiben geschickt zu werden. Eine weitere Lösung ist, dass intelligente Programm Manager angeheuert werden, welche die schriftlichen Konzepte erstellen. In jedem Fall sollten Sie die einfache Regel “Kein Code ohne Spezifikationen” durchsetzen.
Erfahren Sie alles über das Schreiben von Spezifikationen durch das Lesen meiner 4-teiligen Serie.
8. Stehen den Entwicklern ruhige Arbeitsbedingungen zur Verfügung?
Es gibt ausführlich dokumentierte Produktivitätssteigerungen, welche dem denkenden Arbeiter Raum, Ruhe und Privaspähre liefern. Das klassische Software Management Buch dokumentiert diese Produktivitätsvorteile umfassend.
Das Problem daran. Wir alle wissen, dass Kopfarbeiter am besten funktionieren, wenn Sie im Flow sind, auch bekannt als sich “In der Zone” befinden. Wo sie sich völlig auf die Arbeit konzentrieren können und ihre Umwelt ausblenden. Sie verlieren die Zeit aus den Augen und produzieren tolle Ergebnisse durch absolute Konzentration. Das ist die Phase, wenn sie alle produktive Arbeit erledigen. Autoren, Entwickler, Wissenschaftler und sogar Basketballspieler können Dir von diesem “In der Zone” sein erzählen.
Das Problem ist, dass es nicht leicht ist “In die Zone” zu kommen. Wenn man versucht es zu messen, sieht es so aus, als ob es im Durchschnitt 15 Minuten dauert, bis man anfängt maximal produktiv zu arbeiten. Manchmal, wenn man müde ist oder schon viel kreative Arbeit an dem Tag geleistet hat, kommt man einfach nicht in die Zone und man verbringt den Rest des Tages damit herum zu spielen, im Web zu lesen oder Tetris zu spielen.
Das andere Problem ist, dass es einfach ist aus der Zone zu fliegen. Lärm, Telefonanrufe, Essen gehen, 5-Minuten-Fahrten zum Starbucks und Unterbrechungen durch Kollegen - insbesondere Unterbrechungen durch Kollegen - alle schaffen es dich aus der Bahn zu werfen. Falls Dich ein Kollege etwas fragt, was eine Unterbrechung von 1 Minute verursacht, bringt dich das schon so aus der Zone, dass es eine halbe Stunde dauern würde wieder iin den Produktivmodus zu gelangen. Die Gesamtproduktivität hat dadurch ein ernsthaftes Problem.
Befinden Sie sich in einer lauten Umgebung wie sie bei koffeingetriebenen Dotcom Unternehmen gerne erzeugt werden, mit schreienden Marketing Leuten am Telefon neben Entwicklern, wird die Produktivität leiden und Geistesarbeiter werden immer wieder unterbrochen und gelangen nie in die gewünschte Zone.
Bei Entwicklern ist es besonders schwer. Die Produktivität hängt davon ab ob sie fähig sind eine Menge Details gleichzeitig im Kurzzeitgedächtnis zu behalten. Jede Art von Unterbrechung sorgt dafür, dass Details verloren gehen. Wollen sie mit der Arbeit fort fahren, können Sie sich nicht mehr an alle Details erinnern (wie lokale Variablen, die sie verwenden oder wo sie gerade den Suchalgorythmus integrieren wollten). Man muss diese Dinge immer wieder nachschauen was zu Verzögerungen führt bis man wieder beim gewohnten Tempo ist.
Hier ist eine einfache Rechenaufgabe. Nehmen wir an (was wir bereits vermutet haben), dass wenn wir einen Entwickler unterbrechen - sei es nur für eine Minute - wie in Wirklichkeit 15 Minuten Produktivität in den Wind schießen. Als Anschauungsbeispiel nehmen wir zwei Entwickler, Jeff und Mutt, die in offenen Büro nebeneinander arbeiten. Mutt kann sich einfach nicht an den Namen der Unicode Version der strcpy Funktion erinnern. Er könnte nachsehen, was ihm 30 Sekunden kosten würde, oder er fragt Jeff danach, was 15 Sekunden dauern würde. Da er direkt neben Jeff sitzt, fragt er ihn. Jeff wird abgelengt und verliert 15 Minuten seiner produktiven Phase (was Mutt gerade einmal 15 Sekunden Zeit erspart).
Nun setzen wir beide in unabhängige Büros mit eigener Tür. Falls sich Mutt jetzt nicht an diese Funktion erinnern kann, könnte er sie nachschlagen. Was ihn immer noch 30 Sekunden Zeit kostet, oder er könnte Jeff danach fragen, was ihn jetzt allerdings 45 Sekunden Zeit kostet und mit Aufstehen verbunden ist (keine leichte Aufgabe, sieht man mal von der durchschnittlichen körperlichen Fitness eines Entwicklers ab). Also schaut er sie nach. So verliert Mutt 30 Sekunden seiner produktiven Zeit, aber er erspart Jeff 15 Minuten. So einfach ist das!
9. Verwenden Sie die besten Werkzeuge, die erhältlich sind?
Schreiben von Code in einer kompilierten Sprache ist eines der letzten Dinge, die noch immer nicht sofort auf jedem x-beliebigen Heim PC erledigt werden können. Sollte ihr Kompilierungsprozess mehr als ein paar Sekunden dauern, kann Ihnen der neuste und best ausgestatteste Computer sehr viel Zeit sparen. Selbst wenn die Kompilierung gerade einmal 15 Sekunden dauert langweilt das schon viele Entwickler. Während der Kompiler läuft wechseln sie häufig zu The Onion, was sie in Beschlag nimmt und Stunden von Produktivität auslöscht.
GUI Code mit nur einem Monitor-System zu debuggen ist schmerzhaft, wenn nicht gar unmöglich. Falls Sie GUI Code schreiben sind zwei Monitore viel besser.
Die meisten Entwickler müssen Bitmaps für Icons oder Toolbars manipulieren und die meisten Programmierer haben keine guten Bitmap Editoren. Der Versuch Microsoft Paint zum Manipulieren von Bitmaps zu verwenden ist Lachhaft aber traurige Wahrheit.
Bei meinem letzten Job schickte mir der Systemadministrator ständig automatisierte Spammails mit der Beschwerde, dass ich mehr als … verwendete als … 220 MB Speicherplatz auf der Festplatte des Servers verfügbar war. Ich habe darauf hingewiesen, dass anlässlich des aktuellen Festplattenpreises die Kosten für Speicherplatz deutlich günstiger sind als die Kosten für von mir verwendetes WC Papier. Selbst bereits 10 Minuten Aufräumarbeiten in meinem Verzeichnis wären eine unglaubliche Verschwendung meiner Produktivität.
Erstklassige Entwicklerteams foltern ihre Entwickler nicht. Selbst kleinere Enttäuschungen, erzeugt durch die Anwendung unterentwickelter Werkzeuge, machen Programmierer mürrisch und nicht glücklich. Und ein mürrischer Entwickler ist ein unproduktiver Entwickler.
Um dem ganzen noch eines aufzusetzen … Entwickler sind leicht zu bestechen indem man ihnen coole und neue Sachen gibt. Das ist der bei weitem günstigste Weg sie zum Arbeiten zu bewegen als ihnen konkurrenzlose Gehälter zu zahlen.
10. Werden Softwaretester eingesetzt?
Falls ihr Team keine Tester einsetzt, mindestens einen pro zwei oder drei Entwickler, dann liefern sie entweder fehlerbehaftete Produkte oder sie vergeuden Geld, indem Sie einen Programmierer für 100 Dollar pro Stunde für Arbeiten einsetzen, welche ein Tester für 30 Dollar pro Stunde erledigt. An Testpersonen zu sparen ist ökonomisch so falsch, dass ich mich einfach nur noch wundere warum Leute das nicht erkennen.
Lesen Sie Top Five (Wrong) Reasons You Don’t Have Testers, einen Aufsatz, den ich zu dem Thema geschrieben habe.
11. Lassen Sie neue Team-Mitglieder während des Interviews nachweisen, dass Sie entwickeln können?
Würden Sie einen Zauberer anheuern, ohne eine Kostprobe seiner Kunst zu verlangen? Sicherlich nicht.
Würden Sie einen Partyservice mit Ihrem Hochzeitsessen beauftragen, ohne vorher zu probieren? (Es sei denn es ist Tante Marge - hier würden sie eine Ausnahme machen, aber sie würde kein Wort mehr mit Ihnen reden, dürfte sie nicht ihren allseits beliebten Hackbraten kochen.)
Dennoch werden jeden Tag Programmierer angeheuert. Lediglich auf Basis eines eindrucksvollen Resumees oder weil der Interviewer einfach gerne mit ihnen redet. Oder ihnen werden triviale Fragen gestellt (Was ist der Unterschied zwischen CreateDialog() und DialogBox()?) was einfach dadurch beantwortet wird indem man in der Dokumentation nachschlägt. Es ist Ihnen egal ob sie tausend triviale Entwicklungsthemen wissen. Sie interessieren sich dafür, ob sie auch fähig sind Code zu produzieren. Oder - viel schlimmer noch - ihnen werden einfache AHA Fragen gestellt: die Art von Fragen die einfach erscheinen wenn man die Antwort kennt, aber weiß man die Antwort nicht, sind sie unmöglich.
Bitte, hören Sie damit auf. Machen Sie was auch immer während des Interviews aber lassen Sie den Kandidaten auf jeden Fall etwas Code schreiben. Für weitere Ratschläge lesen Sie in meinen Guerrilla Guide to Interviewing.
12. Lassen Sie die Usability testen?
Für einen Hallway Usability Test (= Flurtest) schnappt man sich die nächste Person, die gerade auf dem Flur vorüber geht und nötigt sie den Code, den sie eben schrieben, zu testen. Wenn Sie das mit fünf Personen tun lernen Sie 95% von dem was man über Usability Problemen im Code lernen kann.
Gutes Oberflächen Design ist gar nicht schwer aber es ist entscheidend, ob Kunden sie lieben und ihr Produkt kaufen wollen. Lesen Sie in Jakob Nielsens Artikel warum das so ist. Selbst wenn Ihnen Oberflächendesign-Wissen fehlt, solange Sie es schaffen diese Flurtests durchzuführen, welche absolut nichts kosten, wird Ihre Benutzeroberfläche viel viel besser werden.
Ende der Übersetzung. Übersetzt aus dem Englischen von Claudia Meindl
Persönliches Fazit
Wer die 12 Punkte durchliest und selbst schon in großen als auch weniger großen IT-Projekten gearbeitet hat, wird schnell erkennen, dass die hier aufgeführten Probleme nicht weit her geholt sind. Obwohl der Artikel selbst von Joel Spolsky bereits ein paar Jahre auf dem Buckel hat fand ich es erschreckend feststellen zu müssen, dass die beschriebenen Projektsituationen noch immer aktuelle Problemherde sind. Was der Autor schon damals in seiner Projekttätigkeit bei der Durchführung erfolgreicher Projekte als Probleme identifiziert hat, ist auch heute leider immer noch so. Große Unternehmen haben diese Problematik bereits erkannt und setzen ihre Projekte entsprechend um. Die weniger großen Softwareschmieden und IT-Agenturen sind offenbar noch nicht soweit und kümmern sich auch heut zu Tage noch herzlich wenig um eine Qualitätssicherung ihrer Projekte wie in dem von Spolsky beschriebenen Abschnitten.
Anhang
1) Was ist ein Build?
Bei einem Build handelt es sich um eine unvollständige, jedoch ausführbare Entwicklerversion innerhalb einer Entwicklungsumgebung oder Testumgebung.
2) Was ist ein Repository?
Bei einem Repository handelt es sich um einen Speicherort, an den die Daten gespeichert werden und von dem aus die Daten von anderen abgerufen werden.
3) Originaltext
Der Originaltext von Joel Spolsky ist zu finden unter: http://www.joelonsoftware.com/articles/fog0000000043.html
