Extreme Feedback Device: Die ONOZ! Lampe

If you are interested in the english version of this article, check out https://schneide.wordpress.com/2008/10/27/extreme-feedback-device-xfd-the-onoz-lamp/

Wenn zwei gute Ideen irgendwo auf der Welt zusammentreffen, dann entsteht unter Umständen eine weitere, noch bessere Idee. Vor einiger Zeit passierte genau das in der Schneide.

Die erste Idee:
Es begann mit einem Blogeintrag von Alberto Savioa, der am 1. April 2004 u.a. die Idee der zwei Lava-Lampen als Anzeige für den Status eines Projekts formulierte. Einer der Gründer der Schneide war an diesem Tag leider zu beschäftigt, um die Idee gleich aufzugreifen. Das tat Mike Clark mit seinem Buch “Pragmatic Project Automation” und veröffentlichte gleich auch noch eine Bauanleitung für die Lava Lampen.

Die zweite Idee:
Die zweite gute Idee erreichte uns in Form eines kleinen Bildchens, das sich hervorragend für Signaturen oder hämische Kommentare eignet:
onoz-omg.gif(Im Original offenbar von Jonn Wood).
Wir fanden, dass unser Verhalten nach dem zerbrochenen Bau eines Projekts sehr treffend abgebildet war und übernahmen das Bild in unser Kulturgut und den Begriff “ONOZ” in unseren Sprachschatz.

Das Zusammentreffen:
Wir entschieden uns frühzeitig, die Lava-Lampen auch bei uns auszuprobieren. Aber erst mit dem Bild fanden wir dann die für uns passende Realisierung: Wir verzichteten auf die grüne Lampe (“alles O.K.”) und verwendeten statt einer Lava-Lampe eine normale Schreibtischlampe mit genug Helligkeit. Für den Wegfall der grünen Lampe haben wir vier gute Gründe:

  • Es spart Strom
  • Wir brauchen keinen zeitgesteuerten Ausschalter
  • Wir haben farbenblinde Mitarbeiter
  • Die Anzeige ist nicht mehr redundant

Die ONOZ! Lampe:
Mit geringen Investitionen haben wir ein System ausgebaut, das zentral den Zustand aller Projekte der Schneide überwacht, indem jeder Bauprozess sein Ergebnis an einen Serverprozess schickt. Geht ein Bau schief, sendet er ein X10-Signal an die Lampe und alarmiert uns dadurch unübersehbar. Erst wenn alle Projekte wieder baufähig sind, geht die Lampe servergesteuert aus.
onozlamp.jpg
Die Lampe ist bei uns so zentral plaziert, dass sie keiner übersehen kann. Im Normalfall ist es einfach nur eine Lampe. Im Fehlerfall allerdings ist es ein glühendes Infernal unseres Scheiterns. Beinahe sind wir auch bei der Namensgebung gescheitert: Die Lampe hieß zuerst “ONOEZ! Lamp”, was scheinbar die einzige nicht gängige Schreibweise des Ausrufs ist.

Die Folgen:
Die Lampe funktioniert großartig. Allein ihre Präsenz wirkt beruhigend, solange sie aus ist (was glücklicherweise die überwiegende Zeit der Fall ist). Sobald sie angeht, bindet sie alle Aufmerksamkeit für einen Moment auf sich und macht jedem klar, dass es ein unaufschiebbares Problem gibt. Ein bisschen wirkt sie wie die Reißleine im Toyota Produktionssystem, bei dem die ganze Fabrik angehalten wird, sobald ein Problem festgestellt wird. Mit dem Unterschied, dass bei uns ein unbestechlicher, immer aufmerksamer Mitarbeiter – unser Continous Integration System – die Reißleine bedient.

Mehr über unsere Extreme Feedback Devices:

Extreme Feedback Device: Das Code Flow-O-Meter

If you are interested in the english version of this article, check out https://schneide.wordpress.com/2008/10/06/extreme-feedback-device-xfd-the-code-flow-o-meter/

Seit heute hat die Schneide ein Extreme Feedback Device (XFD) mehr: den Code Flow-O-Meter.

codeflowometer.jpg

Unser vor einiger Zeit gekaufter Zimmerbrunnen (der erfreulicherweise nicht ganz so schief ist, wie der Artikelname befürchten lässt) ist jetzt mit den Repositories gekoppelt. Sobald ein Commit durchgeführt wurde, werden die Details in eine eigene Logdatei geschrieben und triggern eine bestimmte Zeitspanne Pumpenaktivität beim Brunnen. Die Brunnensteuerung geschieht über einen kleinen Daemon, der die Logdateien auswertet und mittels X10 die Brunnenpumpe an- und zeitgesteuert wieder ausschaltet.

Damit haben wir eine direkte Benachrichtigung über Änderungen im Repository, die sich einigermaßen dezent im Hintergrund hält. Das anfangs präferierte Audio-Sample “Haleluja!” für jeden Commit wurde wegen der erstklassigen Störerqualitäten wieder verworfen. Aber wozu ist diese Benachrichtigung gut?

Eine der Regeln agiler Programmierung besagt: “Commit early, commit often” bzw. “Code in Increments”. Sobald allerdings ein Continous Integration System unerbittlich bei jedem Commit nach Fehlern oder auch nur Nachlässigkeiten sucht (z.B. mit Checkstyle), ist die Versuchung groß, erst einzuchecken, wenn “das Issue erledigt”, also die Möglichkeit für frühes Feedback vorbei ist. Wenn das CI-System dann auch noch extrem reagiert, beispielsweise mit einer ONOZ! Lampe, kriegen das auch noch alle mit. CI erhöht also nach unserer Beobachtung die Zeitspanne zwischen zwei Commits, da man das negative Feedback eines gebrochenen Baus vermeiden möchte.

Als “Gegenstück” zur ONOZ! Lampe und der Versuchung, lieber später viel als jetzt ein bisschen einzuchecken, spielen wir jetzt ein weiteres Entwicklerspiel:
Keep the Flow-O-Meter running!
Der Brunnen fließt nur, wenn wir unseren Code Flow auch veröffentlichen. Die Größe eines Commits fällt dabei weniger ins Gewicht als der Commit an sich.
Werden wir es schaffen, den Brunnen am Fließen zu halten?

Erfahrungen folgen.

PS: Der verlinkte Artikel über Continous Integration von Martin Fowler wurde gerade letzte Woche wieder überarbeitet und ist wie immer lesenswert.

Mehr über unsere Extreme Feedback Devices:

Keine Süßigkeiten am Freitag

In der Softwareschneiderei sollte am Freitag, den 23.02.2007 ein neues Ereignis namens “Candy Day” stattfinden. Leider mussten wir den Termin dann absagen bzw. verschieben, da sich Luke krank meldete und wir nicht ohne ihn starten wollten. Daher müssen wir wohl noch eine Weile auf unsere Süßigkeiten warten.