Vergleicht man die Softwareentwicklung mit klassischen, eher industriell ausgerichteten Berufen, fällt ein Aspekt besonders aus: Während in industriellen Berufen die Arbeitszeit in der Regel deckungsgleich mit der Anwesenheitszeit ist, gilt dies in den Berufen der Softwareentwicklung nicht.

Fast jeder Softwareentwickler kennt den Effekt, dass es gewisse Zeiten am Arbeitsplatz gibt, in denen man sich mit allem beschäftigt, nur nicht mit der eigentlichen Arbeit: Man ruft E-Mails ab, stöbert in Foren, liest Nachrichten, ruft nochmals E-Mails ab, …

An solchen Tagen befindet man sich nicht im Fluss. Selbst wenn man an solchen Tagen versucht, produktiv zu arbeiten – es gelingt einfach nicht. Joel Spolsky hat dies in einem äußert lesenswerten Blogeintrag namens Fire and Motion beschrieben. Sein zwischen den Zeilen eingeschobenes Fazit lautet:

Maybe as a software developer I really can't control when I'm productive, and I just have to take the slow times with the fast times and hope that they average out to enough lines of code to make me employable.

Das Interessante daran ist nicht, dass dieses Verhalten verbreiteter ist als allgemein angenommen – schließlich wird kaum ein Arbeitnehmer diese Einstellung öffentlich zugeben.

Das Interessante daran ist, dass ein solches Verhalten all zu menschlich und durchaus auch in Ordnung ist – sofern das Ergebnis stimmt.

Anders formuliert: Wenn ein bestimmtes Ergebnis in einer bestimmten Zeit mit einer bestimmten Qualität vorliegen muss, ist es für das Ergebnis zunächst unerheblich, ob der dafür verantwortliche Entwickler eine Stunde oder zwei Wochen benötigt hat.

Dass in diesem Fall nicht nach Zeit abgerechnet werden kann, sondern ein fixer Betrag für das Ergebnis vereinbart werden muss, liegt auf der Hand. Nichtsdestotrotz: Für das reine Ergebnis spielt die dafür benötigte Zeit keine Rolle – sofern das Ergebnis stimmt und alle Bedingungen wie beispielsweise Qualität oder Zeit eingehalten wurden.

Ein solches Arbeiten lässt dem Arbeitnehmer viele Freiheiten, insbesondere im Hinblick auf seine Arbeitszeit und damit prinzipiell auch auf den Arbeitsort. Nun könnte man vermuten, dass ein solches Arbeiten illusorisch ist – Fakt ist aber, dass es von einigen Firmen bereits gelebt wird. Die Bezeichnung hierfür lautet ROWE – Results-Only Work Environment.

Ralf Westphal hat darüber schon einige Male berichtet, doch auch die Häufigkeit der Erwähnung in Zeitschriften nimmt zu: Spiegel Online und das Wall Street Journal sind dafür nur zwei Beispiele von vielen.

Wird ROWE als funktionierend akzeptiert, steigt zugleich auch die Bereitschaft, Arbeit in verstreuten Teams gutzuheißen: Dass räumliche Nähe überbewertet wird, zeigt sich bei ROWE mehr denn je: Denn sofern das Ergebnis stimmt, spielt nicht nur die dafür benötigte Zeit keine Rolle – auch die Lokation wird irrelevant.

Dass ROWE zu Beginn ungewohnt und nicht funktionsfähig erscheint, liegt auf der Hand: Zu sehr sind Arbeitnehmer die klassische Arbeit in einem gemeinsamen Büro von 9 bis 17 Uhr gewöhnt, als dass sie überhaupt jemals über mehr Freiheit nachgedacht hätten. Ralf hat diese Haltung in einem Kommentar bereits schön beschrieben:

Die meisten suchen nach einem Nein zur Verteilung. Immer wieder wird der Kopf in Skepsis gewogen. "Ei, ei, ei, das ist aber schwierig... Hm... Ne, besser Colocation..."

Das versteh ich nicht. Was ist denn das für eine Argumentation? Die ist nämlich immer aus dem Blickwinkel von Kunde und Chef. Denen will man mit möglichen Friktionen durch Distanz keinen Schaden zufügen.

Das ist natürlich eine löbliche Haltung. "Brav, liebe Angestellte, dass ihr so für uns Unternehmer denkt."

Ich habe zunehmend das Gefühl, dass die Kritiker von verstreuter Entwicklung noch kein Projekt miterlebt haben, in dem verstreute Entwicklung funktioniert hat.

Aus dieser Empirie wird der naheliegende, jedoch falsche Schluss gezogen, dass diese Empirie eine entsprechende Regel rechtfertigen würde – da eine verstreute Entwicklung anscheinend nicht funktioniert, wird auf das vertraute und vermeintlich bewährte Konzept von Colocation zurückgegriffen wird.

Dabei wird übersehen, dass es durchaus erfolgreiche verstreute Teams gibt – doch niemand fragt sich, wieso es bei diesen Teams funktioniert und was diese Teams von dem eigenen unterscheidet. Niemand hinterfragt die eigene Arbeitsweise kritisch und versucht, den Ursachen gemäß Root Cause Analysis auf den Grund zu gehen.

Insofern kann ich mich Ralf nur anschließen, wenn er fragt:

Niemand, nicht ein einziger hat so reagiert. Warum? Warum sucht keiner ein Ja zur Verteilung für sich selbst – um dann natürlich zu überlegen, wie das Projektziel immer noch erreicht werden kann?

Ist Autonomie/Freiheit so furchtbar? Ist es soviel angenehmer, die lieben Kollegen jeden Tag 9-17 sehen zu müssen? Steht das Wohl des Projektes (das anscheinend an der Colocation hängt) höher als mein Wohl?

Ein Faktor dabei sind wie bereits gesagt die Arbeitnehmer, die sich verstreutes Arbeiten auf Grund fehlenden positiven Erlebens wenn, nur sehr schwer vorstellen können – und es für etwas exotisches, fremdartiges halten, das nur bei hochspezialisierten Teams funktionieren könne, aber nicht in ihrem eigenen.

Dass man Dingen, die man nicht kennt und die zudem noch fremdartig erscheinen, zunächst skeptisch gegenübersteht, ist all zu menschlich. Insofern besteht die einzige Möglichkeit, hieran etwas zu ändern, darin, die Skepsis zu nehmen – indem positives Erleben vermittelt wird.

Ein anderer Faktor sind jedoch auch die Arbeitgeber, beziehungsweise deren Vertreter – im weitesten Sinne also das Management. Und warum fällt es dem Management schwer, sich auf ROWE einzulassen? Weil ROWE bedeutet, Kontrolle abzugeben und Vertrauen zu müssen.

Dass diese Kontrolle bei Softwareentwicklung ohnehin mehr Augenschein als Fakt ist, wird dabei gerne übersehen.

Doch vom Management wird noch mehr gefordert, als lediglich Kontrolle durch Vertrauen zu ersetzen: Implizit wird nämlich die Existenzberechtigung des Managements in Frage gestellt: Wenn sich – allen agilen Methoden zu Folge – die Teams selbst organisieren und dann noch nicht einmal kontrolliert werden – wer braucht dann noch Management?

Aus Selbsterhaltung wird also lieber am bewährten Status Quo festgehalten, zumal die meisten Arbeitnehmer dies ohnehin nicht in Frage stellen. Dass aber unter diesem künstlich aufrecht erhaltenen Status Quo vor allem die Motivation der Arbeitnehmer leidet, wird missachtet.

Auf diese Art erweist sich ein Unternehmen einen Bärendienst: Nicht nur, dass ein aufwändiges Management zur Kontrolle der Arbeitnehmer beschäftigt wird – die wie gesagt nicht wirklich gegeben ist – nein, zusätzlich erbringen die Arbeitnehmer auch nicht die Leistung, die sie erbringen könnten und sogar gerne würden, wenn sie sich nur rundherum wohlfühlen würden.

Die Folge dessen ist, dass entweder Überstunden angeordnet werden, die allerdings die Motivation noch weiter senken, oder weitere Mitarbeiter eingestellt werden – wobei eine Aufgabe nicht unbedingt dadurch schneller erledigt wird, dass mehr Leute zeitgleich daran arbeiten.

Doch – ist die Existenzberechtigung des Managements wirklich in Frage gestellt, wenn nach ROWE gearbeitet wird?

Ich meine nicht. Das Management muss sich nur als etwas anderes begreifen als dies in der Regel der Fall ist: Das Verb to manage bedeutet außer leiten und verwalten nämlich auch bedienen und besorgen: Nimmt man diese Bedeutung einmal wörtlich – welche Konsequenzen ergeben sich daraus für das Management?

Entwickler sind bekanntermaßen im Vergleich zu anderen Arbeitnehmern relativ teuer. Provokant gefragt: Warum räumt das Management dann nicht ungefragt alle Hindernisse aus dem Weg, die der effizienten Arbeit der Softwareentwickler im Weg stehen?

Warum müssen sich teure Entwickler in der Realität mit anderen, nebensächlichen Aufgaben aufhalten, statt sich auf ihre Arbeit konzentrieren zu können? Zu diesen nebensächlichen Aufgaben gehören klassischerweise Aufgaben wie:

• Sicherstellen, dass im Drucker und Kopierer stets genügend Papier vorhanden ist und gegebenenfalls nachgefüllt wird.
• Umständliche Formulare ausfüllen, wenn ein Buch für die persönliche Weiterbildung und die des Teams angeschafft wird.
• Aufwändige Reisekostenanträge ausfüllen, nachdem sie von einem geschäftlichen Termin zurück sind.

Diese Liste ließe sich problemlos noch um zahlreiche weitere Punkte ergänzen: Warum übernimmt nicht das Management diese Aufgaben und lässt die Entwickler einfach nur das machen, wofür sie ursprünglich und eigentlich eingestellt wurden und was sie auch am Besten können – entwickeln?

Genau das war der Antrieb für Joel Spolsky, FogCreek Software zu gründen, die sich an dem selbst gewählten Motto

We help the world’s best developers make better software.

orientiert. Auf der offiziellen Über uns-Seite der Firmenwebseite von FogCreek Software wird die Firma folgendermaßen beschrieben:

We had a different idea. What if the programmers were treated like rock stars? What if management’s number one responsibility was recruiting extremely talented software people, treating them well, and then getting the heck out of the way while they did great work?

At Fog Creek Software, management, not coding, is the support function. Management’s first responsibility is to create an abstraction layer for developers: to create the infrastructure so that programmers really just have to program:

Genau das beschreibt, was ich als Managament as a Service (MaaS) bezeichne – und genau das beschreibt, was für ROWE und verstreute Entwicklung zwingend erforderlich ist.

Vor einigen Monaten habe ich FogBugz als webbasierte Projektmanagementsoftware vorgestellt, die Peter Bucher und ich seit Ende letzten Jahres für ein gemeinsames Projekt einsetzen.

Mein damaliger erster Eindruck

FogBugz läuft dank intelligenter Nutzung von AJAX extrem schnell, arbeitet bislang fehlerfrei und ist vor allem ausgesprochen intuitiv bedienbar. Man merkt, dass die Software mit viel Liebe zum Detail erstellt wurde, und das Wort hochwertig trifft absolut zu.

hat sich inzwischen mehr als bestätigt: Selten habe ich eine Software erlebt, die derart ausgefeilt und durchdacht ist – und bei der man bereits während der Verwendung das Gefühl bekommt, dass die Anwendung auf sauberem Code im Sinne von Clean Code basiert.

In den vergangenen Tagen habe ich nun das dazugehörige Buch Painless Project Management with FogBugz von Mike Gunderloy gelesen, das sich auf die seit kurzem nicht mehr aktuelle Version 6.0 von FogBugz bezieht – aber dennoch für den Einstieg in FogBugz sehr lesenswert ist.

Nach einem unterhaltsamen Vorwort von Joel Spolsky behandelt das Buch in sechs Kapiteln die folgenden Themen:

• Managing Projects with FogBugz: Das erste Kapitel beschreibt in einem groben Überblick die Philosophie von FogBugz und demonstriert an Hand eines fiktiven Beispiels, wie der Lebenszyklus eines Falls in FogBugz aussehen könnte.
• Managing Cases: Das nächste Kapitel beschreibt die verschiedenen Kategorien von Fällen, deren Aufbau sowie die Navigation von FugBugz. Auch auf die verschiedenen Eingabemöglichkeiten für Fälle – vom Webformular über das Einlesen von E-Mails bis hin zur programmatischen Eingabe – wird eingegangen.
• Making FogBugz Work for You: Das dritte Kapitel beschreibt die Konfiguration von FogBugz, mit einem besonderen Augenmerk auf der Multimandantenfähigkeit der Anwendung: Wie kann eine einzelne Installation von FogBugz so konfiguriert werden, dass sie sämtliche Projekte perfekt abbildet?
• Getting the Big Picture: Das nächste Kapitel widmet sich ausgesprochen umfangreich dem Thema Projektmanagement und –planung. Dazu wird ausführlich das sogenannte Evidence Based Scheduling vorgestellt, das – zugegeben – die Möglichkeiten von TFS und Project weit in den Schatten stellt.
• Communicating and Collaborating: Das fünfte Kapitel beschreibt die Möglichkeiten zur internen und externen Zusammenarbeit – insbesondere die Bereiche Wiki, Foren und E-Mail-Integration werden hier abgedeckt.
• Integrating with FogBugz: Das letzte Kapitel enthält schlussendlich alle übrigen Themen, die sonst nirgendwo Platz gefunden haben. Dies reicht dabei von der Integration einer Versionsverwaltung über die REST-API von FogBugz bis hin zur automatischen Erstellung von Bugreports aus .NET heraus.

Alles in allem lernt man also ausgesprochen viel über FogBugz, zudem liest sich das Buch sehr flüssig. Außerdem ist positiv anzumerken, dass der Autor das Buch sehr kompakt gehalten hat – es umfasst gerade einmal 197 Seiten, enthält aber dennoch alle wissenswerten Details.

Gerade im Vergleich zu der doch sehr teuren und administrativ aufwändigen Alternative TFS in Verbindung mit Project ist FogBugz eine ganz klare Empfehlung wert – und dieses Buch ebenfalls.

Vor zwei Wochen habe ich begonnen, mich ausführlich mit Extreme Programming zu beschäftigen, nicht zuletzt deshalb, weil diese Methodik – zumindest in weiten Teilen –meine persönliche Vorgehensweise widerspiegelt.

Als essenziell wird im Extreme Programming die Einhaltung von Programmierstandards angesehen, da diese als Rahmen für die gemeinsame Verantwortlichkeit aller Entwickler für den geschriebenen Code fungieren.

In einer Diskussion mit Peter Bucher zu diesem Thema kamen wir zu dem Schluss, dass es für uns beide nur schwer vorstellbar ist, nach gänzlich anderen als den von uns eingehaltenen Programmierstandards zu entwickeln. Aus dieser Feststellung resultierte schließlich die Frage, warum uns Standards und deren Einhaltung eigentlich so wichtig sind.

Ich für meinen Teil möchte folgende Antwort auf diese Frage geben: Im Mai 2009 hatten Peter und ich das Thema Woran erkennt man einen guten Entwickler? für unser Streitgespräch ausgewählt. Als wesentlich habe ich damals zwei Eigenschaften genannt:

• Smart: Zum einen muss er “smart” sein. Joel Spolsky meint damit, dass ein guter Entwickler kreativ, aufgeschlossen und neugierig sein muss, dass er zudem bereit sein muss, ungewöhnliche Wege zu gehen, und dabei gleichzeitig in der Lage, gegebenenfalls um eine Ecke mehr zu denken als ein durchschnittlicher Entwickler.
• Gets Things Done: Zum anderen muss er seine Aufgaben allerdings auch erledigt bekommen – und zwar in der vorgegebenen Zeit. Denn all die zuvor genannten positiven Eigenschaften nützen nichts, wenn es einem Entwickler nicht gelingt, auf den Punkt zu kommen und seine Aufgaben zeitgemäß abzuschließen.

Beide Forderungen gehen dabei auf Joel Spolsky und sein Buch Smarts and Gets Things Done zurück. Ralf Westphal hat meinem damaligen Blogeintrag kommentiert und strengere Kriterien gefordert:

Auch wenn ich Joels Kriterien "smart" und "gets things done" gut finde, so sehe ich nicht, dass er damit einen guten Entwickler charakterisiert. Sie sind für ihn nötige, aber keine hinreichenden Beschreibungen. Er benutzt sie ja auch vor allem in Bezug auf die Bewerberauswahl. Da hilt es nämlich, nicht nach dem perfekten Kandidaten zu suchen, sondern sich schon mit einem smarten, der seine Aufgaben auch erledigt, zufrieden zu geben.
Das ist aber nur der Anfang! Denn wenn einer nur smart und verlässlich ist, dann ist er noch lange nicht produktiv. Er muss womögl erst noch lernen, seine Smartness und Verlässlichkeit mit den relevanten Werkzeugen und Materialien einzusetzen.

Ich muss zugeben, dass Ralf damit vollkommen recht hat: Angesprochen und explizit charakterisiert wird dadurch nämlich nur auf die äußere Form der Arbeit – die innere hingegen bleibt verschwommen.

Deshalb möchte ich heute nachlegen und bei dieser Gelegenheit auch direkt die Frage beantworten, warum Peter und mir Standards und deren Einhaltung so wichtig sind.

In dem Computerspiel Quake III Arena gab es einige Auszeichnungen, die man als Spieler erreichen konnte. Eine davon war Accuracy, die für eine Trefferquote von über 50% verliehen wurde. Laut dict.cc bedeutet dieses Wort außer Treffsicherheit und Treffgenauigkeit auch Exaktheit und Sorgfalt.

Und genau damit bezeichnet Accuracy eine aus meiner Sicht ausgesprochen wichtige Anforderung an einen Entwickler: Die Liebe für Details, und die Fähigkeit, auch auf jeden Punkt und jedes Komma zu achten – und nicht nur oberflächlich mal eben schnell über Code hinweg zu gehen.

Interessanterweise verfügen alle Entwickler, die ich kenne und deren Arbeit ich schätze, über diese Eigenschaft – sich nicht mit dem Erstbesten zufrieden zu geben, sondern nachzuhaken und genau hinzusehen. Das merkt man dann nicht nur an der Art, wie Code geschrieben wird, sondern beispielsweise auch daran, wie Code gedebuggt wird.

Für diese Entwickler sind Programmierstandards dann nämlich kein lästiges Hindernis, das es einzuhalten gilt, sondern ein hilfreiches Rahmenwerk für die äußere Form, das es ermöglicht, sich auf das Wesentliche zu konzentrieren.

Aus diesem Grund erachten auch Peter und ich Programmierstandards als dermaßen wichtig: Sie erfüllen eben nicht nur die im Extreme Programming verfolgte Intention, gemeinsame Verantwortlichkeit zu etablieren, sondern ermöglichen uns auch, den Code des anderen schneller zu verstehen und uns gegenseitig zu helfen.

Die spannende Frage ist: Lässt sich diese Liebe zum Detail erlernen, oder ist sie – zumindest zu einem gewissen Grad – angeboren?

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

• 1. April 2009: Interfaces vs abstrakte Basisklassen
• 1. März 2009: Sinn und Zweck von AOP
• 1. Februar 2009: Die Forderung nach Softwarequalität
• 1. Januar 2009: SOA vs WOA
• 1. Dezember 2008: Dynamic Language Runtime: .NET, quo vadis?

Heute, am 1. Mai 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Woran erkennt man einen guten Entwickler

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

So sehr sich die IT-Branche von anderen Branchen unterscheiden mag, eines haben sie alle gemeinsam – es müssen gewisse Voraussetzungen erfüllt werden, damit qualitativ hochwertige Produkte entstehen können:

• Was: Zunächst werden hochwertige Rohstoffe und -materialien benötigt – denn wenn bereits eine Komponente eines Produktes minderwertig ist, wird es schwierig, darauf ein hochwertiges Gesamtprodukt aufzubauen.
• Wie: Des weiteren ist ein gewisses Know-How und Handwerkszeug erforderlich, um zu wissen, wie die zu Grunde liegenden Rohstoffe und -materialien miteinander verarbeitet werden müssen.
• Wer: Schließlich muss dieses Know-How auch von irgendjemandem ein- und umgesetzt werden. Hierbei gilt: Je besser jemand sein Handwerkszeug versteht, desto eher ist er auch in der Lage, es umzusetzen.

Die Behauptung, dass gute Entwickler also essenziell für den Erfolg einer Firma oder eines Projektes sind, liegt auf der Hand. Die spannende Frage ist nun jedoch: Woran erkennt man einen guten Entwickler?

Interessanterweise haben die meisten Menschen eine Vorstellung von einem guten Handwerker: Er arbeitet ordentlich, zuverlässig, kennt sich in seiner Domäne aus und weiß, welche Konsequenzen sein Handeln auf das Gesamtprodukt und potenziell sogar dessen Einsatzgebiet hat.

Nun könnte man annehmen, dass sich diese Merkmale auch auf Entwickler übertragen lassen. Genau das ist es, was Ralf Westphal und Stefan Lieser in ihrer Initiative Clean Code Developer in Worte versucht haben zu fassen: Sie haben Prinzipien, Regeln und Praktiken zusammengetragen, die gemeinsam ein Wertesystem bilden.

An Hand dieses Wertesystems können sich Entwickler zum einen weiterbilden, zum anderen sind Auftraggeber aber auch in der Lage, bestehende Leistungen und die dahinter stehenden Entwickler zu bewerten.

Das Projekt Clean Code Developer hat in den vergangenen Wochen sehr viel Aufmerksamkeit erfahren – zu Recht, wie ich finde. Allerdings sollte man sich davor hüten, zu glauben, damit wäre alles gesagt oder erfasst, was einen guten Entwickler ausmacht.

Es geht in diesem Projekt bewusst nämlich lediglich um das Wie, also um das oben bereits angesprochene Know-How und das Handwerkszeug. Eine Frage bleibt jedoch gänzlich unbeachtet und unbeantwortet: Was zeichnet einen guten Entwickler im Hinblick auf den Entwickler als Person aus?

Anders formuliert: Über welche persönlichen und charakteristischen Eigenschaften muss ein Entwickler verfügen, um erfolgreich und gut sein zu können?

Mit dieser Frage hat sich unter anderem auch Joel Spolsky beschäftigt, der darüber ein äußerst lesenswertes und – wie immer bei Joel – sehr amüsant geschriebenes und dennoch lehrreiches Buch mit dem Titel Smart and Gets Things Done: Joel Spolky’s Concise Guide to Finding the Best Technical Talent. geschrieben hat.

Die Quintessenz lautet: Ein guter Entwickler muss im Wesentlichen zwei Merkmale aufweisen:

• Smart: Zum einen muss er “smart” sein. Joel Spolsky meint damit, dass ein guter Entwickler kreativ, aufgeschlossen und neugierig sein muss, dass er zudem bereit sein muss, ungewöhnliche Wege zu gehen, und dabei gleichzeitig in der Lage, gegebenenfalls um eine Ecke mehr zu denken als ein durchschnittlicher Entwickler.
• Gets Things Done: Zum anderen muss er seine Aufgaben allerdings auch erledigt bekommen – und zwar in der vorgegebenen Zeit. Denn all die zuvor genannten positiven Eigenschaften nützen nichts, wenn es einem Entwickler nicht gelingt, auf den Punkt zu kommen und seine Aufgaben zeitgemäß abzuschließen.

Dieser Vorschlag kommt meiner persönlichen Vorstellung von einem guten Entwickler schon recht nahe, und trotzdem fehlt mir noch ein essenzieller Aspekt: Der innere Drang zur Weiterentwicklung.

Ein Aspekt, in dem sich die IT-Branche von jeder anderen Branche ganz gravierend unterscheidet, ist ihre Schnelllebigkeit: Was heute noch elitär und akademisch ist, gehört morgen schon als etablierte Commodity zum Mainstream und ist übermorgen hoffnungslos veraltet.

Nur derjenige, der in der Lage ist, der zunehmend schneller werdenden Entwicklung der IT-Branche zu folgen, und sich immer auf dem Laufenden hält, der bereit ist, stetig zu lernen und Altes wieder über Bord zu werfen – nur der wird in der Lage sein, dauerhaft smart sein zu können.

Die erste schlechte Nachricht lautet: Zu viele Entwickler finden sich selbst in dieser Beschreibung nicht wieder. Zu viele Entwickler verfolgen nicht, was auf dem Markt geschieht – zumeist mit der Begründung, dass es doch bisher auch funktioniert habe, und man durchaus auch ohne den Einsatz neuer Technologien entwickeln könne.

Die zweite schlechte Nachricht lautet: Als Auftrag- oder Arbeitgeber hat man schlechte Karten, daran etwas zu ändern. Der Drang, Veränderung und neue Entwicklungen zu verfolgen und mitzunehmen, besteht entweder in jemandem – oder eben nicht. Und wenn nicht, dann bekommt man ihn auch von außen nicht dazu, so zu werden.

Seit einigen Jahren verfolge ich begeistert die Artikel von Joel Spolsky, die er in seinem Blog Joel on Software und seinen Büchern veröffentlicht. Seine Artikel sind ausgesprochen lesenswert, und kommentieren auf amüsante und zugleich nachdenkliche Art Entwicklungen, Technologien und Themen der IT.

Einige der Artikel ziehe ich seither immer wieder zu Rate, weil sie in gewissem Sinne zeitlos und allgemeingültig sind, wie beispielsweise Fire and Motion und The Joel Test: 12 Steps to Better Code.

Neben dem Schreiben seines Blogs ist Joel Spolsky zudem Gründer der Firma FogCreek, die er wie folgt charakterisiert:

We didn't start with a particular product in mind: our goal was simply to build the kind of software company where we would want to work, one in which programmers and software developers are the stars and everything else serves only to make them productive and happy.

Eines der Produkte von FogCreek ist FogBugz, eine webbasierte Projektmanagementsoftware, die Joel Spolsky unter anderem in seinem Artikel Painless Bug Tracking erwähnt. Auf Grund all dessen, was ich bisher über FogBugz gelesen habe, hätte ich die Software schon lange gerne eingesetzt - dem stand leider immer im Wege, dass sich die Kosten für mich als Privatperson nicht gerechnet hätten.

Seit Dezember 2008 arbeite ich nun aber mit Peter Bucher an einem gemeinsamen Projekt, für das wir neben Subversion als Versionsverwaltung auch ein Bugtrackingsystem auf Basis von .NET einsetzen wollten. Es sollte kostenlos verfügbar sein, trotzdem aber über alle relevanten Funktionen eines solchen Systems verfügen.

Während unserer Recherchen sind wir auf BugNET gestoßen - eine zwar kostenlose, aber wie sich inzwischen herausgestellt hat leider absolut instabile und fehlerhafte Software. Da wir jedoch auf keine wirkliche Alternative gestoßen sind, haben wir uns in den vergangenen Monaten damit herumgeschlagen.

In den vergangenen Tagen bin ich nun durch Zufall wieder einmal auf die Webseite von FogBugz gestoßen, das inzwischen nicht nur als Datenträger, sondern auch als von FogCreek gehostete Lösung angeboten wird - allerdings ist auch diese Lösung für uns als Privatpersonen zu teuer.

Jedoch habe ich noch eine weitere interessante Entdeckung gemacht: Die gehostete Version gibt es nämlich auch in einer sogenannten Student and Startup Edition, die für Einzelpersonen und Teams mit maximal zwei Teammitgliedern kostenlos zur Verfügung gestellt wird. Alles, was zu ihrer Nutzung notwendig ist, ist das Erstellen eines entsprechenden Accounts unter Angabe einer E-Mail-Adresse.

Der erste Eindruck ist ausgesprochen gut: FogBugz läuft dank intelligenter Nutzung von AJAX extrem schnell, arbeitet bislang fehlerfrei und ist vor allem ausgesprochen intuitiv bedienbar. Man merkt, dass die Software mit viel Liebe zum Detail erstellt wurde, und das Wort hochwertig trifft absolut zu.

Wer also noch auf der Suche nach einer geeigneten Projektmanagementsoftware für maximal zwei Teammitglieder ist, dem kann FogBugz nur uneingeschränkt empfohlen werden. Abschließend von meiner Seite aus noch ein großes Lob an FogCreek, und Danke für die kostenlose Bereitstellung!