 |
|||
|
|
|
|
 |
|||
Jemals gehört von SEMA ? Diese ziemlich exotische Methode misst, wie gut ein Softwareteam ist. Nein, halt! Folgen Sie nicht dem Link! Sie werden allein sechs Jahre brauchen, um dieses Zeug nur zu verstehen! Ich habe deshalb einen eigenen, schlampigen und hochgradig verantwortungslosen Test entwickelt, um ein Softwareteam beurteilen zu können. Das Beste daran ist, das er gerade mal 3 Minuten dauert. In der gesparten Zeit können Sie beispielsweise Medizin studieren.
|
|||
|
|
|
|
|
|
|||
Das Pfiffige an diesem Test ist, dass man mühelos ein schnelles Ja oder Nein für jede Frage erhält. Kein mühsames Zählen von Kodezeilen, keine Was-weiß-ich-wie-komplizierte-Berechnungen. Einziger Nachteil: Der Joel-Test eignet sich nun wirklich nicht dazu, die Sicherheit von Software für Atomkraftwerke zu verifizieren.
Ein Ergebnis von 12 ist tadellos, 11 ist tolerierbar, aber 10 oder weniger bedeutet, dass Sie ernste Probleme haben. Die bittere Wahrheit ist: Die meisten Software-Unternehmen arbeiten zwischen 2 und 3 und brauchen dringend Hilfe, weil Firmen wie Microsoft rund um die Uhr bei 12 laufen.
Aber natürlich sind das nicht die einzigen Faktoren, die über Erfolg oder Pleite entscheiden. Wenn Sie beispielsweise mit einem Spitzen-Softwareteam an einem Produkt arbeiten, das niemand will, ... dann wird es wohl auch niemand kaufen wollen. Andererseits ist es denkbar, dass ein Team von lässigen "Revolverschwingern" in der Lage ist, sagenhafte Software zu produzieren und damit die Welt zu verändern, auch ohne sich um die genannten Punkte zu kümmern. Nichtsdestotrotz - wenn Sie die 12 Punkte auf die Reihe kriegen, haben Sie ein diszipliniertes Team, das zuverlässig liefern kann.
Ich habe kommerzielle Quellenverwaltungen und ich habe das kostenlose CVS benutzt. Lassen sie mich das sagen: CVS ist ok Wenn Sie aber keine Quellenverwaltung benutzen, werden Sie zwangläufig Stress verbreiten müssen bei dem Versuch, Ihre Programmierer zum Zusammenarbeiten zu bewegen. Programmierer wissen erstmal nicht, was die anderen gemacht haben. Und Fehler sind schwer rückgängig zu machen. Ein weiterer Pluspunkt der Quellenverwaltung ist, dass der Quellkode auf die Festplatte des Programmierers kopiert wird -- ich habe noch von keinem Projekt mit Quellenverwaltung gehört, bei dem Kode verloren ging.
Damit meine ich: Wie viele Arbeitschritte brauchen Sie, um vom letzten Quelltextstand ein auslieferbares Paket zu schnüren? Gute Teams haben ein einziges Skript, das von Null anfängt, alles ausbucht, alle Kodezeilen umwandelt, alle EXE-Dateien in allen Varianten, Sprachen und #ifdef-Kombinationen erzeugt, ein Installationspaket erstellt und das endgültige Medium bereitstellt, sei es als CD-ROM-Layout, als Download-Archiv oder sonst etwas.
Wenn dieser Prozess aus mehr als einem Arbeitsschritt besteht, so neigt er zu Fehlern. Wenn Sie sich dem Auslieferungstermin nähern, möchten Sie in einem sehr schnellen Zyklus den "letzten" Fehler beseitigen oder die endgültigen EXEs erzeugen können, ... und Sie werden ins Rotieren kommen, wenn sie stattdessen 20 Arbeitsschritte brauchen, um den Kode umzuwandeln, um die Installation zu erzeugen, und und und...
Aus genau diesem Grund wechselte die letzte Firma, für die ich gearbeitet habe, von WISE zu InstallShield: Wir forderten einen Installationprozess, der automatisch von einem Skript heraus zu starten war, in der Nacht, mithilfe der NT-Ablaufsteuerung. WISE konnte das nicht, also haben wir's rausgeworfen. (Die netten Leute von WISE versichern mir heute, das ihre neueste Version nächtliche Builds unterstütze.)
Wenn man eine Quellenverwaltung benutzt, kommt es vor, dass ein Programmierer aus Versehen etwas einbucht, das den ganzen Prozess unterbricht. So jemand hat zum Beispiel eine neue Quelldatei eingebunden und erfolgreich auf der eigenen Maschine umgewandelt, aber vergessen, die neue Datei der Quellenverwaltung bekannt zu machen. Nichtsahnend und glücklich sperrt er seine Maschine ab und macht Feierabend. Auch die anderen können jetzt nicht mehr weiterarbeiten und machen Feierabend. Diese allerdings weniger glücklich.
Den Bau des Pakets zu unterbrechen ist übel aber, leider, üblich. Dagegen hilft, täglich zu bauen. So bleibt keine Unterbrechung verborgen. Für ein großes Team ist zum Beispiel praktisch, jeden Tag, sagen wir in der Mittagspause, das Paket zu bauen. Damit wird sichergestellt, dass Unterbrechungen im Prozess sofort behoben werden können. Nach Mittag ist der Prozess durch. Wenn's geklappt hat: prima! Jeder holt sich die neueste Quellversion und kann damit weiterarbeiten. Wenn's Probleme gab, wird die Ursache behoben, aber alle können trotzdem mit der funktionierenden Quellversion vom Vormittag weitermachen.
Im Excel-Team gab es die Regel, wer immer eine Unterbrechung verschuldete, war "zur Strafe" fortan zuständig fürs Überwachen des Paketbaus, bis jemand anderes die nächste Unterbrechung verursachte. Das war ein guter Anreiz, Unterbrechungen zu vermeiden, und eine gute Methode dafür, einmal jeden mit dem Prozess des Bauens zu befassen. Alle lernten, wie das funktionierte.
Mehr zu diesem Thema in meinem Aufsatz Daily Builds are Your Friend .
Mir egal, was Sie jetzt sagen wollen. Wenn Sie Kode entwickeln, selbst wenn das Team aus nur einer Person besteht: Ohne eine organisierte Datenbank, die alle bekannten Probleme im Kode auflistet, werden Sie schlechte Qualität abliefern. Viele Programmierer glauben, sie hätten die Fehlerliste im Kopf. Unsinn. Ich kann mich an nicht mehr als zwei oder drei Fehler gleichzeitig erinnern. Am nächsten Tag oder in der Eile für die nächste Auslieferung sind die schon wieder vergessen. Man braucht einen Formalismus, um an den Fehlern dranzubleiben.
Fehlerdatenbanken können kompliziert oder einfach sein. Eine Datenbank, die nützlich sein soll, enthält mindestens folgende Daten:
Wenn nur die Komplexität von Fehlerverfolgungssystemen Sie bisher davon abgeschreckt hat, Fehler zu verfolgen, machen Sie sich eine Tabelle mit 5 Spalten für die entscheidenden Punkte, und benutzen Sie sie!
Mehr zu diesem Thema lesen Sie in: Painless Bug Tracking .
Die allererste Version von Micosoft Word for Windows wurde als eine Art "Todesmarsch"-Projekt angesehen. Es dauerte ewig. Es geriet außer Kontrolle. Das Team hatte aberwitzige Arbeitszeiten, der Termin wurde wieder und wieder verschoben, und der Stress war unglaublich. Als das Mistding endlich, Jahre später, ausgeliefert werden konnte, schickte Microsoft das ganze Team nach Cancún in Urlaub, und unterzog sich anschließend einer ernsthaften Gewissensprüfung.
Sie fanden heraus, dass die Projektmanager so hartnäckig auf Einhaltung des Zeitplans bestanden hatten, dass die Programmierer durch die Kodierphase nur so durchgerauscht waren und extrem schlechten Kode abgeliefert hatten, einfach deshalb, weil die Fehlerbehebungsphase nicht formaler Teil des Zeitplans gewesen war. Es gab keinen Versuch, die Fehlerzahl gering zu halten. Eher das Gegenteil. Man erzählt sich die Geschichte von dem Programmierer, der eine Funktion zur Berechnung der Höhe einer Textzeile zu schreiben hatte und deshalb einfach "return 12;" schrieb, um dann auf den Fehlerbericht zu seiner nicht immer korrekt arbeitenden Funktion zu warten. Der Zeitplan war nichts anderes als eine Liste von Funktionen, die darauf warteten, zu Fehlermeldungen zu werden. Bei der Autopsie wurde das die "Endlose-Fehler-Methode" (engl.: infinite defects methodology) genannt.
Um das Problem zu beheben, machte sich Microsoft eine Methode zueigen, die "Null-Fehler-Methode" (engl.: zero defects methodology) genannt wurde. Viele Programmierer grinsten, weil das so klang, als ob das Management jetzt Fehler verbieten wolle. Tatsächlich aber bedeutete "null Fehler", dass zu jedem Zeitpunkt vorrangig Fehler behoben werden sollen, bevor neuer Kode geschrieben wird. Und das hat folgenden Grund:
Allgemein gilt: Je länger man zögert, einen Fehler zu korrigieren, umso teurer (in Zeit und Geld) wird es.
Einen Schreib- oder Syntaxfehler zu beheben, den der Compiler bereits erkennt, ist trivial.
Einen Kodierfehler, den Sie beim ersten Ausprobieren bemerken, werden Sie fast ohne Zeitverlust beheben können, weil Sie den Kode noch frisch im Gedächnis haben.
Wenn Sie auf einen Fehler aufmerksam werden in einem Kodestück, das Sie vor einigen Tagen bereits geschrieben haben, wird die Jagd auf die Ursache etwas länger dauern. Sobald Sie aber den Kode nochmal gelesen haben, werden Sie sich erinnern und den Fehler innerhalb vernüftiger Zeit beheben können.
Befindet sich der Fehler in einem Kodestück, das Sie vor Monaten geschrieben haben, ist sicher das meiste schon vergessen und entsprechend schwer zu korrigieren. Vergleichbar damit ist, wenn Sie anderer Leute Kode korrigieren, die gerade Urlaub auf Aruba machen. Das ist dann wie wissenschaftliches Arbeiten - Sie müssen bedächtig, methodisch und aüßerst sorgfältig vorgehen, und sie können nicht wissen, wie lange die Suche nach dem Gegengift dauern wird.
Und wenn ein Fehler in bereits ausgelieferten Kode auftritt, werden Sie den nur mit unglaublichem Aufwand beseitigen können.
Das ist der eine Grund, Fehler ohne Zögern zu beseitigen: weil man nämlich weniger Zeit braucht. Es gibt aber noch einen Grund: es ist nämlich einfacher vorherzusagen, wie viel Zeit man für neuen Kode benötigen als wie lange man durch einen Fehler aufhalten werden wird. Wenn ich Sie beispielsweise fragte, wie lange Sie für den Kode zum Sortieren einer Tabelle brauchen, so könnten Sie das ganz gut abschätzen. Wenn ich aber dasgleiche wissen wollte in Bezug auf einen Fehler, bei dem Ihr Kode nicht funktioniert nur dann, wenn gleichzeitig der Internet Explorer 5.5 installiert ist, so können Sie das nicht einmal erraten, weil Sie nämlich nicht wissen (können), was den Fehler verursacht. Die Suche kann 3 Tage dauern - oder 2 Minuten.
Die Folgerung daraus ist, dass ein Zeitplan zusammen mit einem Haufen unbearbeiteter Fehler unzuverlässig ist. Wenn aber alle bekannten Fehler sofort behoben wurden, das heißt, nur noch neuer Kode zu schreiben ist, ist der Zeitplan erstaunlich zutreffend.
Noch ein Vorteil, den Fehlerzähler bei Null zu halten: Sie können viel schneller auf die Konkurrenz reagieren. Für manchen heißt das sogar, das Produkt jederzeit auslieferungsbereit zu haben. Wenn der Konkurrent jetzt versucht, mit einer Superneuheit Ihre Kunden wegzustehlen, können sie jetzt sofort diese Superneuheit auch implementieren und ausliefern, ohne zuerst die vielen aufgelaufenen Fehler abarbeiten zu müssen.
Was uns zum Thema Zeitplanung bringt. Wenn Ihr Kode wichtig ist für's Geschäft, gibt es für's Geschäft Gründe genug zu wissen, bis wann der Kode fertig sein wird. Programmierer sind bekanntermaßen dünnhäutig, wenn's um Zeitpläne geht. "Es ist fertig, wenn's fertig ist!" blaffen sie in Richtung Vertriebsleute.
Dummerweise funktioniert das so nicht. Der Vertrieb muss zu viele wichtige Planungsentscheidungen weit vor der Kodeauslieferung treffen: für Demoversionen, Messeauftritte, Werbung usw. Und das geht nur, wenn man einen Zeitplan hat, der immer aktuell ist.
Der andere entscheidende Aspekt ist, dass ein Zeitplan dazu zwingt, zu entscheiden, welche Funktionen realisiert werden sollen. Und damit zwingt er, die unwichtigsten Funktionen zu identifizieren und rauszuwerfen anstatt in "Featuritis" abzugleiten.
Zeitpläne einhalten muss nicht schwer sein. Lesen Sie dazu meinen Artikel Painless Software Schedules , der eine simple Methode für großartige Zeitplanung beschreibt.
Konzept schreiben ist wie Mülltrennen: Alle halten es für richtig, aber keiner tut es.
Ich bin mir nicht sicher, aber vielleicht liegt's daran, dass die meisten Programmierer eine Abneigung gegen das Schreiben haben. Folglich neigt ein Team, dass nur aus Programmierern besteht, dazu, die Lösung eines Problems in Form von Kode, nicht von Text, niederzuschreiben. Die würden sich eher noch in das Problem reinknieen, Kode zu schreiben, der ein Konzept erzeugt.
Wenn Sie in der Entwurfsphase Probleme entdecken, können Sie die beheben, indem Sie ein paar Zeilen Text bearbeiten. Ist der Kode erst einmal geschrieben, liegen die Kosten für die Fehlerbehebung dramatisch höher; sowohl emotional (man hasst es, Kode zu verwerfen) als auch in Zeiteinheiten gerechnet. Also gibt es Widerstände, das Problem überhaupt anzugehen. Software, die ohne Konzept entwickelt wurde, stellt sich üblicherweise als schecht konzipiert heraus und ihr Zeitplan gerät meist außer Kontrolle. Das scheint auch das Problem bei Netscape gewesen zu sein, wo die ersten vier Versionen in solchem Chaos endeten, so dass das Management die dumme Entscheidung traf, den Kode zu entsorgen und ganz von vorne anzufangen. Den gleichen Fehler machten sie dann bei Mozilla noch einmal, das zu einem Monster außer Kontrolle geriet; es dauerte mehrere Jahre bis zur Alpha-Version.
Meine Lieblingstheorie dazu ist, dass man das Problem in den Griff bekommt, indem man die Programmierer lehrt, bessere Autoren zu werden und sie dazu auf einem Intensiv-Schreibkurs schickt. Die Alternative wäre, einen intelligenten Programm-Manager einzustellen. In beiden Fällen sollten sie die Regel durchsetzen: "Kein Kode ohne Konzept".
Lernen Sie dazu alles Wichtige durch Lektüre meiner 4-teiligen Artikelserie .
Es gibt diesen ausführlich beschriebenenn Produktivitätsgewinn, der erzielt wird, wenn Geistesarbeiter genügend Raum, Ruhe und Ungestörtheit genießen. Das klassische Software-Management-Buch Peopleware dokumentiert das ausführlich.
Hier fängt's an, schwierig zu werden. Wir wissen, dass Geistesarbeiter am besten in dem Zustand sind, in dem die Arbeit fließt (engl.: "flow"/"in the zone"), wenn sie sich also voll auf ihre Arbeit konzentrieren und sich von ihrer Umgebung völlig gelöst haben. In diesem Zustand wird all die produktive Arbeit getan. Schriftsteller, Programmierer, Wissenschaftler und sogar Baseballspieler können davon berichten, wie sie sich im "Flow" befanden.
Das Schwierige daran ist, diesen Zustand zu erreichen. Wenn man versucht, zu messen, ergibt sich, dass man im Schnitt 15 Minuten braucht, um zur maximalen Produktivität zu gelangen. Manchmal, wenn Sie müde sind oder bereits eine Menge kreativer Arbeit erledigt haben, erreichen sie die "produktive Zone" einfach nicht mehr, und verdaddeln den Rest des Tages mit Surfen im Internet oder mit Tetris.
Das nächste Problem ist, dass man ganz leicht gestört werden kann, und dann ist man wieder raus aus der Zone. Geräusche, Telefonanrufe, das Mittagessen, die fünf Minuten zum nächsten Café oder die lieben Kollegen -- alle das haut einen raus aus der Zone. Wenn ein Kollege mit einer Frage kommt und damit eine Unterbrechung von nur einer Minute verursacht, kann das einen so aus der Bahn werfen, dass man eine halbe Stunde braucht, um wieder produktiv zu werden. So etwas gefährdet ernsthaft ihre Gesamtproduktivität. Wenn Sie in einer lauten Schreibtischarena arbeiten, wie sie von Dotcoms gerne eingerichtet wird, so wird Ihre Produktivität abstürzen, weil die Geistesarbeiter unentwegt gestört werden und nie die "produktive Zone" erreichen.
Programmierer sind besonders agefährdet. Ihre Produktivität hängt von der Fähigkeit ab, eine Menge Details gleichzeitig im Kurzzeitgedächnis zu halten. Mit jeder Unterbrechung können diese Details den Bach runtergehen. Wenn Sie mit der Arbeit fortfahren wollen, haben Sie schon entweder die Namen der lokalen Variablen vergessen oder wie weit Sie den Suchalgorithmus bereits umgesetzt hatten. Sie werden alles von Neuem anschauen müssen. Das bremst, und es dauert, bis Sie Ihr gewohntes Tempo wieder erreicht haben.
Es ist eine einfache Rechenaufgabe. Nehmen wir an - wie auch unsere Informationen vermuten lassen - dass die Unterbrechung eines Programmierers, und sei es für nur eine Minute, 15 Minuten produktiver Zeit verbrät. Nehmen wir das Beispiel der beiden Programmierer Jeff und Mutt, die in aneinander angrenzenden, offenen Karrés arbeiten, so einem Verschlag wie bei Dilbert. Mutt hat vergessen, wie die Unicode-Version der strcpy-Funktion heißt. Er könnte nachschauen, was ihn 30 Sekunden kosten würde, er kann Jeff fragen, was nur 15 Sekunden dauert. Weil der ja direkt neben ihm sitzt, fragt er Jeff. Jeff wird abgelenkt und verliert 15 Minuten produktiver Zeit - nur um für Mutt 15 Sekunden einzusparen.
Nun setzen Sie jeden in ein eigenes Büro mit eigener Tür. Wenn Mutt sich jetzt nicht an den Funktionsnamen erinnern kann, kann er nachschlagen, was noch immer 30 Sekunden dauert, oder er könnte Jeff fragen, was jetzt aber 45 Sekunden dauern und Aufstehen erfordern würde (keine leichte Aufgabe bei der durchschnittlichen Fitness von Programmierern). Also schlägt Mutt nach, verliert 30 Sekunden, und vermeidet so einen Produktivitätsverlust von 15 Minuten bei Jeff. Ha!
Kode direkt in Maschinensprache zu schreiben, ist eins der letzten Dinge, die man auf einem Wald- und Wiesencomputer noch nicht tun kann. Wenn Umwandlungen mehr als nur einige Sekunden dauern, wird es sich auszahlen, die neueste und schnellste Hardware zu kaufen. Dauert es auch nur 15 Sekunden, langweilen sich die Programmierer während der Rechner arbeitet und wechseln schnell mal zu The Onion, wo sie dann hängenbleiben und so Stunden an Produktivität verbraten.
Fehlersuche in einem Dialogprogramm ist mit nur einem Bildschirm mühsam wenn nicht gar unmöglich. Für Dialogprogrammierung machen 2 Bildschirme die Arbeit um vieles leichter.
Viele Programmierer müssen hin und wieder Bitmaps bearbeiten, sei es für Bildschirmsymbole (engl.:icons) oder für Werkzeugleisten, aber den meisten steht kein guter Bitmap-Editor zur Verfügung. Der Versuch, das mit Microsoft Paint zu erledigen, ist ein Witz. Aber sowas wird von Programmierern verlangt!
Bei meinem letzten Job bekam ich automatisierte Spam vom Systemverwalter, in dem er mir mitteilte, dass ich mehr als ... Achtung! ... 220 Megabyte Plattenplatz am Server belegte. Ich verwies ihn darauf, dass bei den heutigen Festplattenpreisen die angefallenen Kosten deutlich niedriger seien als für das von mir verbrauchte Klopapier. Zehn Minuten für's Aufräumen meines Verzeichnisses sei sagenhafte Verschwendung von Produktivität.
Erstklassige Entwicklerteams quälen ihre Programmierer nicht. Auch geringfügige Frustrationen durch schwachbrüstiges Gerät summiert sich und macht Programmierern schlechte Laune. Und Programmierer mit schlechter Laune sind unproduktive Programmierer.
Um es noch weiter weiterzuspinnen, Programmierer sind leicht zu bestechen: mit den neuesten coolen Gerätschaften nämlich. Das ist sogar billiger, als ihnen konkurrenzfähige Gehälter zu zahlen!
Wenn Ihr Team keine ausgewiesenen Tester kennt, mindestens einen je 2 oder 3 Programmierer, dann liefern Sie entweder fehlerhafte Produkte aus, oder Sie verschwenden Geld, weil Programmierer für 100 $/Std. die Arbeit von Testern für 30 $/Std. tun. An Testern zu sparen, ist ökonomisch so daneben, dass ich mich nur wundern kann, dass das von so wenigen erkannt wird.
Lesen Sie Top Five (Wrong) Reasons You Don't Have Testers , einen Aufsatz, den ich darüber geschrieben habe.
Würden Sie einen Zauberer engagieren, ohne eine Kostprobe seiner Kunst zu verlangen? Sicher nicht.
Würden Sie einen Partyservice mit Ihren Hochzeitsessen beauftragen, ohne vorher probiert zu haben? (Gut, bei Tante Marge würden sie eine Ausnahme machen, aber die würde kein Wort mehr mit Ihnen reden, wenn sie nicht ihren allseits beliebten Leberhackkuchen backen dürfte.)
Doch täglich werden Programmierer nur auf Basis eines beeindruckenden Lebenslaufs eingestellt, oder weil das Bewerbungsgespräch so spaßig war. Oder man stellt triviale Fragen, wie nach dem Unterschied zwischen CreateDialog() und DialogBox(), was man mit einem Blick in die Doku beantworten kann. Es ist doch wirklich egal, ob sie tausend Trivialitäten über's Programmieren auswendig gelernt haben. Wichtig ist, ob sie Kode produzieren können. Oder, schlimmer noch, man stellt Aha-Fragen. Das ist die Art von Frage, die einfach scheint, wenn man die Antwort kennt, die aber unmöglich ist, wenn nicht.
Bitte hören Sie auf damit. Tun sie, was immer Sie tun wollen, aber lassen Sie die Bewerber ein Stück Kode schreiben. Weitere Ratschläge lesen Sie in meinem Guerrilla Guide to Interviewing .
Für einen "Flurtest" schnappt man sich die nächste Person, die gerade auf dem Flur vorbeigeht, und nötigt sie, den Kode zu testen, den man gerade geschrieben hat. Wenn Sie das mit fünf verschiedenen Personen gemacht haben, haben Sie 95% von dem gelernt, was sie über die Tauglichkeit Ihres Kodes lernen können.
Gutes Oberflächen-Design ist gar nicht schwer aber entscheidend dafür, ob Kunden ihr Produkt kaufen wollen. Sie können kostenlos reinschauen in ein Onlinebuch über UI-Design , eine kurze Einführung für Programmierer.
Doch am wichtigsten ist: Wenn Sie Ihre Dialogoberfläche einer Handvoll Leuten zeigen - tatsächlich genügen fünf oder sechs - werden Sie sehr schnell die kritischen Punkte erkennen. Lesen Sie in Jakob Nielsens Artikel warum das so ist. Selbst ohne großartige UI-Design-Kenntnisse werden Sie mithilfe von (kostenlosen) Flurtests gute Oberflächen programmieren.