Smell if it’s well

We at the Softwareschneiderei are constantly searching for ways to gather feedback from our projects. We get feedback from our customers and their users, but we also get feedback directly from the code, be it through test results or code analysis. A great way to make your code speak for itself is to provide it some Extreme Feedback Devices (XFD).

Introducing the Smell-O-Mat

One thing we always wanted to have was “code smells” that really smell for themselves. When we ran across an ultrasonic humidifier that can produce room-wide smells by dispensing essential oils, we found the right device for this feedback. We bought two humidifiers and labeled them “good” and “evil”. The hardest part was to find a smell everybody relates to “evil”, but won’t distract you too much from your work. Whenever our code analysis finds a new real code smell, the “evil” humidifier is turned on for some minutes. If an existing code smell is fixed, we get the “good” smell.

The effects

We do not produce code smells all too often. But once in a while, it happens. And this incident can now be perceived throughout the day just by breathing. On the other hand, fixing old smells is a source of refreshing air. Whenever the office atmosphere needs replenishment, all you have to do is to fix some code smells in our large code base (they do get rare!). Of course, most junior developers just open a window for that.

We chose grapefruit being our “good” smell, so our work area tastes mostly limony now instead of just “developer’s thoughts”, a fragrance that yet has to bottled.

The technical solution

Technically, the integration of the two humidifiers with our reporting infrastructure was very easy. Every XFD is controlled by an IRC bot that understands certain commands suitable for the device and hangs around at our central IRC server. As an humidifier only understands “on” and “off”, it could be controlled just like the ONOZ! lamp. We connected the humidifiers to a remote controlled power supply, switched it on and let the bot control the supply.

Our reporting infrastructure forwards its results to an aggregation software that interprets the numbers and produces IRC commands for the device bots. All of this is done with a combination of website scraping (Hudson as our continuous integration server has a wonderful XML API) and IRC messaging.

The history of XFD so far

Over the last years, we gathered XFDs for almost every human sense. We have visual effects, audible feedback using speech synthesis and even bought an USB rocket launcher for forced feedback needs. With the Smell-O-Mat, we can now deal with smelling, too.
The last human sense we have to address is tasting. Plans for the “coffee salter” were impeded by our sense of humanity. We keep searching.

---

Read more about our Extreme Feedback Devices:

• The Code Flow-O-Meter: http://schneide.wordpress.com/2008/10/06/extreme-feedback-device-xfd-the-code-flow-o-meter/
• The LED Bar: http://schneide.wordpress.com/2008/11/17/spelling-the-feedback-the-led-bar/
• Audio Feedback: http://schneide.wordpress.com/2008/09/04/give-your-project-a-voice/
• The ONOZ! Lamp: http://schneide.wordpress.com/2008/10/27/extreme-feedback-device-xfd-the-onoz-lamp/

Make it visible: The Project Cockpit

We are a project shop with numerous customers booking software development projects as they see fit, so we always work on several projects concurrently in various sub-teams.

We always strive for a working experience that provides more productivity and delight. One major concept of achieving it is “make it visible”. This idea is perfectly described in the awesome book “Behind Closed Doors” by Johanna Rothman and Esther Derby from the Pragmatic Bookshelf. Lets see how we applied the concept to the task of managing our project load.

What is the Project Cockpit?

The Project Cockpit is a whiteboard with titled index cards and separated regions. If you glance at it, you might be reminded of a scrum board. In effect, it serves the same purpose: Tracking progress (of whole projects) and making it visible.

Here is a photo of our Project Cockpit (with actual project names obscured for obvious reasons):

How does it work?

In summary, each project gets a card and transitions through its lifecycle, from left to right on the cockpit.

The Project Cockpit consists of two main areas, “upcoming projects” and “current projects”. Both areas are separated into three stages eachs, denoting the usual steps of project placing and project realization.

Every project we are contacted for gets represented by an index card with some adhesive tape and a whiteboard magnet on its back. The project card enters the cockpit on the left (in the “future” or “inquiry” region) and moves to the right during its lifecycle. The y-axis of the chart denotes the “importance” of the project, with higher being more important.

In the “upcoming” area, projects are in acquisition phase and might drop out to the bottom, either into the “delay filing” or the “trash”. The former is used if a project was blocked, but is likely to make progress in the future. The latter is the special place we put projects that went awry. It’s a seldom action, but finally putting a project card there was always a relief.

The more natural (and successful) progress of a project card is the advance from the “upcoming” area to the “present” bar. The project is now appointed and might get a redefinition on importance. Soon, it will enter the right area of “current” projects and be worked on.

The right area of “current” projects is a direct indicator of our current workload. From here on, project cards move to the rightmost bar labeled “past” projects. Past projects are achievements to be proud of (until the card magnet is needed for a new project card).

If you want to, you can color code the project cards for their urgency or apply fancy numbers stating their volume.

What’s the benefit?

The Project Cockpit enables every member of our company to stay informed about the project situation. It’s a great place to agree upon the importance of new projects and keep long running acquisitions (the delay filing cases) in mind. The whiteboard acts as an information radiator, everybody participates in project and workload planning because it’s always present. Unlike simpler approaches to the task, our Project Cockpit includes project importance, urgency and volume without overly complicating the matter.

The whiteboard occupies a wall in our meeting room, so every customer visiting us gets a glance on it. As we use internal code names, most customers even don’t spot their own project, let alone associate the other ones. But its always clear to them in which occupancy condition we are, without a word said about it.

Ultimately, we get visibility of very crucial information from our Project Cockpit: When the left side is crowded, it’s a pleasure, when the right side is crowded, it’s a pressure

Spelling the feedback: The LED bar

Our fully automated project ecosystem provides us with feedback of very different type and granularity. We felt it was impossible to render every single notable event into its own extreme feedback device (XFD). Instead, we implemented an universal feedback source: the LED bar.

You know the LED bar already from a shop window of your town. It tells you about the latest special bargain, the opening hours of the shop or just something you didn’t want to know. But you’ve read it, because it is flashing and moving. You just can’t pass that shop window without noticing the text on the LED bar.

Our LED bar sells details to us. The most important issues are already handled by the ONOZ Lamp and the Audio feedback, as both are very intrusive. The LED bar is responsible to spell the news, rather than to tell it.

A very comforting news might be “All projects sane”, which happen to be our regular state. You might be told that you rendered “project X BROKEN”, but you already know this, as the ONOZ Lamp lit up and you were the one to check in directly before. It’s better to be informed that “project X sane” was the build’s outcome. After a while, the text returns to the regular state or blanks out.

Setting up the LED bar

We aren’t the only ones out there with a LED bar on the wall. Dirk Ziegelmeier for example installed his at the same time, but blogged much earlier about it. He even gives you detailed information about the communication protocol used by the device and a C# implementation for it. The lack of protocol documentation was a bugger for us, too. We reverse engineered it independently and confirm his information. We wrote a complete Java API for the device (in our case a LSB-100R), which we might open source on request. Just drop us a note if you are interested.

Basically, we wrote an IRC bot that understands commands given to it and transforms it into API calls. The API then deals with the low-level transformation and the device handshake. This way, software modules that want to display text on the LED bar from anywhere on the internal net only need to talk on IRC.

The idea of connecting an IRC channel and the led bar isn’t unique to us, either. The F-Secure Linux Team blogged about their setup, which is disturbingly equal to ours. Kudos to you guys for being cool, too.

Effects of the LED bar

The LED bar is the perfect place to indicate project news. Its non-intrusive if you hold back those “funny” displaying effects but versatile enough to provide more than simple binary (on/off) information. Its the central place to look up to if you want to know what’s the news.

We even found out that our company logo (created by Hannafaktur) is scalable down to 7×7 pixels, which exactly fits the LED bar in height:

Try this with your company’s logo!

---

Read more about our Extreme Feedback Devices:

• The Code Flow-O-Meter: http://schneide.wordpress.com/2008/10/06/extreme-feedback-device-xfd-the-code-flow-o-meter/
• The ONOZ! Lamp: http://schneide.wordpress.com/2008/10/27/extreme-feedback-device-xfd-the-onoz-lamp/
• Audio Feedback: http://schneide.wordpress.com/2008/09/04/give-your-project-a-voice/

Extreme Feedback Device (XFD): The ONOZ! Lamp

When two good ideas meet, there’s a chance for an even better idea to be born. This happened to us some time ago, when the ONOZ! Lamp came up.

(This is a free translation and revision of an earlier article written in german)

The first good idea

On April 1st 2004, Alberto Savioa published a blog entry about an idea of two lava lamps (green and red) displaying the current build state of a project. I was somewhat distracted that day, marrying my wife, so the idea came to us two years later. Mike Clark wrote his wonderful book “Pragmatic Project Automation” and included not only the idea of the lava lamps, but also detailed construction guidance.

The second good idea

One day, an email contained a little animated gif with two panic guys running around.

Investigation suggests Jonn Wood as the author. We thought the guys act exactly like us after a broken build (one of the worst things that may happen here), so the gif and the word “ONOZ” were integrated into our company culture.

The birth of another idea

After we read about the lava lamps, we wanted to own them, too. But only after inspiration from the animated gif, we were sure about our specific realisation. We merged the two states into one lamp (on/off instead of green/red) and did without the lava. A normal desk light would do the job now.
We even have a good justification for the omission of the green (lava) lamp:

• it saves energy
• no timer switch is needed for the nights/weekends
• our team includes colorblinds

The last reason is a good one when you look at this simulation of colorblindness:
These are pictures of the original green and red lava lamps:

This is how it looks to a colorblind employee. These images were generated by Vischeck, a website trying to inform about colorblindness practically.

Not much of a difference. If you swap them around secretly, ten percent (the percentage of colorblinds in the male population) of your team will panic without reason.

The ONOZ! Lamp

With little investment, we build a system supervising the build state of all our projects. Every build process sends its result to a server that checks for failures. If a build failed, the lamp gets switched on over traditional X10 signals. We can’t overlook the sudden burst of luminance, we panic a bit and try to fix the build. The lamp turns off when all projects are back to normal.

The ONOZ! Lamp is just a lamp standing around, until something ugly happens. Then it turns into a glowing infernal of failure. We nearly failed to give it a correctly spelled name, too. We named it “ONOEZ! Lamp” first, which seems to be the only invalid spelling of this exclamation.

The effects

The ONOZ! Lamp works great. Its mere presence has a comforting effect, as long as it is off. Which is the case most of the time. When it fires, the effect is like an alarm stopping all work. And the operator giving the alarm is always alert and incorruptible: our continuous integration server.

---

Read more about our Extreme Feedback Devices:

• The Code Flow-O-Meter: http://schneide.wordpress.com/2008/10/06/extreme-feedback-device-xfd-the-code-flow-o-meter/
• The LED Bar: http://schneide.wordpress.com/2008/11/17/spelling-the-feedback-the-led-bar/
• Audio Feedback: http://schneide.wordpress.com/2008/09/04/give-your-project-a-voice/

Extreme Feedback Device (XFD): The Code Flow-O-Meter

This is a free translation and revision of an earlier article written in german.

Since March 2007, the Schneide uses another Extreme Feedback Device (XFD): the Code Flow-O-Meter.

So what is this thing?

We bought a portable fountain made of slate, filled in water (no additives) and connected the power supply cord with a X10 application module. Then we programmed a litte IRC Bot (using the ten-minutes-to-success java IRC library pircbot) that triggers the module. We were then able to control the fountain by speaking to it over IRC.

Afterwards, we piped the commit messages of our source repositories to a little script that determines the “impact” of the commit by measuring the amount of changes to the code. This sounds more sophisticated as it really is, the number of changed files was a good enough guess for it. This impact is related to a duration, the more impact, the longer the timespan. Now the script tells the IRC bot to activate the fountain for that amount of time.

This way, we have a direct but unobtrusive notification about what is going on in the repositories, as this is the most important location of our company (talking about the numerous safety nets we applied to it would require another blog post). Initially, we thought about playing an audio sample singing “alleluia”, too, but this became ridiculous soon.

But why do you want this notification?

One of the rules of agile (or good) programming says “commit early, commit often”. But as soon as every little commit gets examined by a continuous integration server, all automated tests and a large number of software quality metric tools, the liability to keep the changes local a little bit longer grows. “After all, it’s ready when it’s done, and this is soon enough to check in” was a common justification especially among the less experienced programmers. But that’s the best way to miss the early feedback. And early feedback is effective feedback.

So we installed our portable fountain as a counter-incentive against late commits and started a little game. The rule of the game is simple:
Keep the Flow-O-Meter running!
When you commit, the fountain flows. The size of your commit is not as important as the commit itself, so its better to commit often. If everyone does it, the fountain may flow the whole day.

The Code Flow-O-Meter may be regarded as a measurement device of “progress”. Things are in a state of flux as long as it is running.

And did it work?

Yes, definitly. The Code Flow-O-Meter has become our little pet. Everyone loves it because it’s friendly and comforting. Think of a tamagochi, but without the annoyances. You only need to change and commit something to feed it and get the reward, nothing more.

As an additional gain, everybody else loves it, too. When we show it to a customer, they first see an ordinary portable fountain. When we explain and demonstrate our working cycle (code, commit, review) to them, something magical happens. I tend to think they involuntary get the notion of something happening after the commit when the fountain comes to life. This may be the concept of a build server, otherwise being invisible and intangible, materializing in the fountain. When we continue to explain what happens after the build, like the ONOZ! lamp lighting up to indicate a failed build, it’s already clear to them that the process does not end with the waterflow. The Code Flow-O-Meter serves as a link between the developer’s local work and the build feedback arriving out of nowhere some minutes later.

---

Read more about our Extreme Feedback Devices:

• The ONOZ! Lamp: http://schneide.wordpress.com/2008/10/27/extreme-feedback-device-xfd-the-onoz-lamp/
• The LED Bar: http://schneide.wordpress.com/2008/11/17/spelling-the-feedback-the-led-bar/
• Audio Feedback: http://schneide.wordpress.com/2008/09/04/give-your-project-a-voice/

Give your project a voice

We are all very into Extreme Feedback Devices (XFD), so we decided to use all our senses to gather feedback from our projects. This becomes a real challenge once you think about it, because we are naturally very focused on (and limited to) visual feedback.

So we decided to put audible feedback to work.

All our projects get continuously built by two servers in parallel. The first server checks for compilation and test errors, just like a good CI server should. The second server applies every quality metric we found helpful to the code and spits out huge amounts of numbers for every single build.

We identified the numbers that really matter to us and established a simple mechanism to scrape them from the result web pages. Then we associated a sound sample with all possible changes and plugged some speakers to our feedback server.

So now, expect our projects to clearly articulate their news.

To give you an idea of how it sounds, here’s a short list of possible audio samples:

• Fixed an important bug: “Impressive”
• Reduced code crap: “Excellent”
• Introduced a bug: “Humiliation”

Imagine the words spoken like in an old Quake game. Now you can have an eventful build and be yelled at like “Impressive Excellent Humiliation”.

We reserved the biggest coding failure we can imagine happening here to a special audio sample. If somebody introduces new code crap (as determined by Crap4J), he gets ordered to “CUT THE CRAP!” at incredible volume. We used the voice of the inventor of XFDs, Alberto Savoia, taken from his delightful training video for management by numbers (position 2:03ff). The audio quality isn’t convincing, his command surely is.

If you wonder what it’s like to be suddenly interrupted by different voices rebuking or praising you – it’s healthy. You get used to it very quickly, yet the information always catches on. And the information is always relevant.

We call it our “audible remorse”.

---

Read more about our Extreme Feedback Devices:

• The Code Flow-O-Meter: http://schneide.wordpress.com/2008/10/06/extreme-feedback-device-xfd-the-code-flow-o-meter/
• The ONOZ! Lamp: http://schneide.wordpress.com/2008/10/27/extreme-feedback-device-xfd-the-onoz-lamp/
• The LED Bar: http://schneide.wordpress.com/2008/11/17/spelling-the-feedback-the-led-bar/

Gedanken zu Online-Hilfen

Eine gute moderne Software hat eine kontextbezogene Online-Hilfe. Bei einer sehr guten modernen Software wird diese nie benutzt, aber das ist ein anderes Thema.

Wir haben in der Schneide verschiedene Ansätze ausprobiert, die alle einen großen Nachteil hatten: Die eingestellten Inhalte waren an manchen Stellen unverständlich oder zu knapp und der Benutzer konnte nicht viel dagegen tun. Daher befassen wir uns gerade mit der Idee, eine Online-Hilfe mit einem Wiki zu koppeln. Auf diese Weise könnten die Benutzer ihre Online-Hilfe selbst verbessern und fortschreiben, so dass die Inhalte hilfreicher werden.

Um die Vor- und Nachteile dieses Ansatzes nicht erst durch den Kunden testen zu lassen, haben wir einen Selbstversuch gestartet. Die Online-Hilfe betrifft allerdings keine Software, sondern die Schneide selbst.

Eine Online-Hilfe für den Arbeitsplatz

Wir haben uns das Konzept der “WikiTags” ausgedacht, kleine Aufkleber mit einer Wiki-Adresse und einem Symbol, das auf diesen Umstand hinweist.

 

Mit diesen WikiTags rüsten wir gerade alle Räume und Gegenstände in Reichweite aus, so dass sie einem Eintrag in unserer Firmen-Online-Hilfe (unserem Wiki) zugeordnet sind. Über ein kleines Eingabefeld in unserem Intranetportal gelangt man direkt auf die betreffende Wiki-Seite (der sogenannte WikiWarp), kann dort die Informationen zum Gegenstand (z.B. Bedienhinweise oder Bezugsquellen) einsehen und auch gleich verbessern und ergänzen.

Wir haben also eine halbautomatisch aktivierbare Online-Hilfe für unsere Firma implementiert und die ersten Erfahrungen damit gesammelt. Was ist die einprägsamste Erfahrung? Wir brauchen kleine, portable Anzeigegeräte für spezielle Anwendungsfälle (siehe Bild).

Bubble, bubble, Build’s in… Bubbles!

Vor kurzem war unser Code Flow-O-Meter fast ausgetrocknet. Auch Zimmerbrunnen verlangen nämlich regelmäßig Wasser, sogar eher mehr als Zimmerpflanzen. Beim Nachgießen fiel mir auf, dass der Brunnen mittlerweile ziemlich veralgt ist. Also beschloss ich, mit etwas Spülmittel dem Wasser eine frischere Note zu geben.

Den nächsten Check-In machte Luke von einem weit entfernten Büro. Ich hörte das Plätschern des Brunnens und sah dann aus den Augenwinkeln ein großes, weißes Etwas vom Brunnen in die Bücher kippen.

Spülmittel in Zimmerbrunnen hat die Eigenschaft, massiv Schaum zu bilden.

Das Algenproblem ist nach wie vor ungelöst, aber die Bücher sind wieder trocken. Nur das Brunnenschild hat bleibende Schäden davongetragen. Leider hatte ich keinen Photoapparat zur Hand, sonst hätte ich im Lachen noch ein paar Bilder schießen können.

Der Eintragstitel ist übrigens eine Abwandlung eines Artikels auf Pragmatic Automation.

Extreme Feedback Device: Die ONOZ! Lampe

If you are interested in the english version of this article, check out http://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:
(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.

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:

• Das Code Flow-O-Meter: http://schneide.wordpress.com/2007/03/04/extreme-feedback-device-das-code-flow-o-meter/
• Die LED Bar (englisch): http://schneide.wordpress.com/2008/11/17/spelling-the-feedback-the-led-bar/
• Audio-Feedback (englisch): http://schneide.wordpress.com/2008/09/04/give-your-project-a-voice/

Extreme Feedback Device: Das Code Flow-O-Meter

If you are interested in the english version of this article, check out http://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.

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:

• Die ONOZ! Lampe: http://schneide.wordpress.com/2007/03/11/extreme-feedback-device-die-onoz-lampe/
• Die LED Bar (englisch): http://schneide.wordpress.com/2008/11/17/spelling-the-feedback-the-led-bar/
• Audio-Feedback (englisch): http://schneide.wordpress.com/2008/09/04/give-your-project-a-voice/