In der Softwareentwicklung bedeutet Dogfooding, dass Programmierer ihre eigenen Softwareprodukte benutzen sollen. Populär wurde das ganze 1988 durch Microsoft gemacht. Seit dem gibt es diverse Erfolgsstories für Dogfooding.
Selber damit arbeiten
Das Konzept ist einleuchtend: Wenn Programmierer mit den Tools arbeiten, die sie auch entwickeln, sind diese viel schneller genervt von Programmfehlern und diese werden so auch viel schneller gefixt. Zusätzlich weiß man, dass die Software von Kollegen benutzt wird und nicht von einem anonymen Kunden. Dies führt dazu, dass ich mir beim Erstellen und bei der Usibility mehr Mühe gebe. Eine Kritik, die direkt vom Kollegen gegenüber kommt, fühlt sich um einiges realistischer an, als eine Email oder ein Eintrag im Bug-Tracking System. Dogfooding motiviert also Softwareentwickler, ein besseres Produkt zu bauen.
Programmierer als QA?
Selbstverständlich löst Dogfooding nicht die QA ab. Entwickler haben manchmal nicht den gleichen Blickwinkel, wie die tatsächlichen Nutzer der Software. Auch übersieht man gerne Unzulänglichkeiten in der Software, da man das dahinter liegende Framework / Design im Auge hat und weiß wie schwer es ist, die Funktionalität anders umzusetzen. Aber als Ergänzung zur QA ist dies eine tolle Praxis.
Internes Continuous Delivery
Wenn die Software ständig released wird, also die aktuelle Version aus dem Repository häufig auf die internen Produktivserver deployed wird (mindestens wöchentlich, besser häufiger), lernt man frühzeitig die Fallstricke beim Deployment. Man findet ziemlich schnell heraus, wenn ein Datenbankskript nicht funktioniert, oder man eine Konfigurationsdatei vergessen hat. Gleiches gilt natürlich auch für die Funktionalität der Software. Auch wenn man kein externes Continuous Delivery machen kann, erhält man zumindest durch Dogfooding viele Vorteile dieser Methode. Die Feedback-Zyklen verkürzen sich und Probleme können somit schnell behoben werden. Dies geschieht dann meist sehr zeitnah mit der Implementierung der Funktionalität, so dass Entwickler noch genau wissen, wo und wie sie den Code fixen können, ohne lange suchen zu müssen.
Dogfooding bei Atlassian
Wir bei Atlassian arbeiten mit unserer eigene Software, bevor diese unsere Kunden benutzen. Wir steuern (fast) alle Workflows intern über JIRA. Und glaubt mir: Wir sind die härtesten Kritiker! Man findet ziemlich schnell heraus, wenn etwas nicht funktioniert und unser Workflow dadurch gestört ist. Die Entwickler reagieren ziemlich schnell mit einem Fix, da sie natürlich nicht die Arbeit anderer Kollegen stören wollen. Momentan testen wir JIRA 5 auf Herz und Nieren! Da wir Confluence natürlich als unsere Intranet-Software einsetzen, ist das ganze Unternehmen vom Marketing über Human Resource bis hin zur Dokumentation am Dogfooding beteiligt. So also auch bei der Einführung von Confluence 4. Hätten wir die Version nicht selber für 8 Monate getestet, hätten beispielsweise die neuen Autovervollständigungs-Funktionen auf einer deutschen Tastatur nicht funktioniert.
Motivation? Häh?
Klar! Dogfooding motiviert, bessere Software zu bauen und wer will heutzutage kein Continuous Delivery machen und beim Hype dabei sein?
Noch immer nicht motiviert?
Hier gibt’s mehr:
Einführung
Teil 2: Unterbrechungen vermeiden
Teil 3: Anerkennung
Teil 4: Brown Bags
Teil 5: FedEx Days
Teil 6: 20% Time
Teil 7: Spaß haben und Gutes tun
Sven Peters 