Montag, 22. August 2011

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Mein Blog ist tot. Lang lebe mein Blog.

Englisch Version

Hi,

mein neuer Blog Agile Trail ist online. Er wird zukünftig alles enthalten, was ich über Agile, Lean, Veränderung und Verbesserung zu schreiben habe. Mein alter Blog "Klick um Klick" ist ab sofort tot.

The king is dead. Long live the king.
Chess Kings and knight by Andreas Kontokanis
Seit 1422 haben die Franzosen als Erstes den Ausspruch Le Roi est mort, vive le Roi!, was bedeudet Der König ist tot. Lang lebe der König. Damit wollten die Franzosen klar machen, dass im Moment des Todes des alten Königs der neue König ohne jede Unterbrechung die Amtsgeschäfte übernimmt. Meinen alten Blog schaffe ich ab und schreibe unterbrechungslos weiter im neuen Blog.

Diesen Blog "Klick um Klick" startete ich vor fast fünf Jahren, und ich habe eine Menge gelernt über Werkzeuge (Blogging, Schreiben, Veröffentlichen) und über Inhalte (Agile, Lean, Veränderungen, Verbesserungen). Der Blog hat seinen Zweck erfüllt; der Name hatte eine Bedeutung.

Ein Klicker ist ein Gerät, dass beim Drücken ein klickendes Geräusch erzeugt. Es wird in Obedience, Hunde-Training, benutzt, um eine Belohnung mit einem Geräusch zu verknüpfen. Das ist das Klicker-Training: Wenn diese Association hergestellt ist zwischen Belohnung und Klick, dann braucht der Trainer keine Belohnungen mehr, nur noch Klicks. Wird Positive Verstärkung genannt, B. F. Skinner lässt grüßen.

Meinen Blog Klick um Klick benutzte ich, um Feedback über mein Verhalten zu bekommen. Und das habe ich bekommen, Klick um Klick, in Form von Kommentaren, Diskussionen, neuen Bekanntschaften und einer Menge Spaß. Vielen Dank dafür, lieber Leser. Das hat mir sehr geholfen, mich auf meinen Agilen Pfad zu bringen.

Na, Lust bekommen, mir auf meinem Agile Trail zu folgen? Ich würde mich sehr darüber freuen!

Liebe Grüße,
   Bernd

Montag, 1. August 2011

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

My Swiss Alpine K78 Ultra Marathon 2011


I did the Swiss Alpine K78 Ultra Marathon 2011. That was a tough one.


That was my first Swiss Alpine K78: 79.1 km distance and +/- 2370 m altitude. It's the highest ultra marathon you can run in Europe. Top point was Sertigpass at 2739 meter above sea level. See more facts here.

K78 start at Davos Platz at 7 a.m.
Start was at 7 a.m. on Saturday. Great weather, sunshine and warmth. The first 32 km until Frevgias were a nice warm up for what would follow. I enjoyed the fantastic Swiss countryside. We ran through tunnels, along mountains and next to wild creeks. Relaxing.

In this run I learned to read the altimeter. In all other runs I  did so far, the question was: How long until…? Here the question was: How high until…? We started in Davos Platz at 1538 m ASL (above sea level). Until Frevgias (km 32) we lost 519 meter; Frevgias is the lowest point in the race with 1019 m ASL. That was the easy part of the race.

K78 altitude profile (original)
Have a look at the altitude profile: There you can see what seems to be a little bump in the graph after Frevgias, from Frevgias (km 31.1) to Funtanislas (km 39.0). The peek of that bump is Crestas da Buel with 1476 m ASL, and Funtanislas is at 1282 m ASL, so I climbed 457 m in 5.8 km.

I was irritated because every runner around me was hiking instead of running on the way to Crestas da Buel. Didn't expect that so early in the race. It was my first K78, so I adapted quickly and hiked up to the top instead of running. The others would certainly know why.

Bergün (km 40.3, shortly after Funtanislas), is considered to be the beginning of the hardest part of the race. It's the start of a climb to the Kesch-Hütte, from 1282 m ASL (Funtanislas) up to 2632 m ASL (Kesch-Hütte). That's 1350 m straight up! And it was unbelievable. I never experienced something like this. I counted every 100 m on my altimeter, expected my legs to quit any second because the path was so steep. Nobody runs here, not even the winners of this race.

I hiked without a break. 2 km before the top you can see the Kesch-Hütte. The 1350 m height are spread on a distance of 13.9 km, and it took me 2:25 hours for that part alone.

The weather was fine - until the Kesch-Hütte. I passed the doctor ("Heya, how are you feeling?" - "*gasp* *gasp* Guess! *gasp* *gasp*" - "Okay, he's responsive. Have a good run then!"), and right after that the weather changed. It was about 4° C, and it started to rain. The hard part was over, right? Wrong…

The descent was horrifying. I'm a noob when it comes to high alpine mountain running, so I struggeled with everything: the stones, the mud, the rain, the height, the cold, the depth. Runners were overtaking in a crazy speed; I saw a lot of them at the sanitarian after the race, with wounds from sharp rocks. I was really frightened about the terrain, and I decided to play it safe, and run slowly.

View from Platta Naira backwards (about km 54.8)
After the Kesch-Hütte, the way leads to Platta Naira (2397 m ASL), so that was another 235 m straight down. The scenery was kinda ugly, I usually see this in movies like Cliffhanger: Rocks all over, creeks and the path sharing the same way, fog, clouds, rain, cold. And the height.

I thought the hight would have an effect like difficulties to breath, a higher heart beat, head aches or similar. But instead the only effect it had on me was that I really had to focus on what I was doing. I had to concentrate all the time, had to watch every step. But that was all. Lucky me :)

above: Sertigpass and runners, not marked
below: Sertigpass and runners, marked
Hardest part over? Not yet. Next hurdle was the Sertigpass. From the Platta Naira (2397 m ASL) to the Sertigpass (2739 m ASL) I had to climb another 342 m in less than 4 km - and what a steep climbing that was! And it was really frustrating to see what was coming: 800 m before the Sertigpass there is a lake called the Ravaischsee. When you arrive at that lake, you see the path over the top. That pass leads around the lake right to the Sertigpass - almost 200 m height in less than 800 m distance - and we're talking about a point in time when all the runners had already pulled of 58 km!

On top of Sertigpass
Hard? Nope, get's harder. On top of the Sertigpass we had a visibility of 5 to 10 m. Fog or cloud, I didn't know, I didn't care, cause it was about 2° C and I really was looking forward to get to some lower ground. What I didn't know was that we climbed over the Sertigpass from the south, so the way down was on the north side. Yep, that's the ugly side. It was very windy, very steep, lots of rocks. Without the little flags in the ground the path wasn't always clear to me. If there was a path, it was often so muddy that there was no chance to slow down accordingly. More sliding than running. It was very hard to concentrate on not tumbling and landing on the rocks.

Just to give an idea of the speed I had on the way down. From Sertigpass (2739 m ASL) to Chleinalp (1871 m ASL) I ran down 868 m on a distance of only 8 km, and that took me only 42 minutes on that mean ground.

From Chleinalp (km 64.3) it was a normal run again. The scenery was back to green meadows again, the path to normal cart roads and streets, the weather warm (about 15 °C), no fog and almost no rain. I enjoyed the rest of the race, running through very nice forrests until the end in Davos Platz after 79.1 km.

I expected my muscles to shut down sooner or later during the race due to the climbing and the - more strenuously - downhill running. But they didn't shut down. Must have been the training. I was pleasantly surprised :)

My last meters before the finish
After all, the run was great. The Swiss countryside are lovely, and even the ugly conditions in the mountains rendered the scenery very impressive. The people in the moutain villages were very supportive, and especially the cow bells swinging locals were absolutely awesome :-)

After the finish - happy and exhausted :)
I reached the finish after 9 hours, 35 minutes and 1 second. From 1218 finishers out of 50 countries I achieved a nice 256th position. The winner Jonas Buud (Sweden) finished in 6:11:02 - for the fivth (!) time - and Lizzy Hawker (Great Britain) in 7:16:17. Congrats! Absolutely amazing. Only 6 people ran this race under 7 hours.

See more photos in the gallery.

Freitag, 15. Juli 2011

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Explained to Dad: What I Do as an Agile Coach


Overweight?
Fat funny dog by ichibod

My parents usually ask me about what it is that I do to make a living. Same with friends who are not in IT. I struggle most of the time. For me it's really difficult to explain what I do as an Agile coach - training, consulting, and coaching - to someone outside the Lean and Agile domain. And when I do, it sounds nerdy.

Not so the other day. Here's how the conversation went:

Dad: "So you're flying over to that customer of yours next week, right? And what is it actually you're doing there?"
I: "I show them ways to improve themselves by so called Agile and Lean methods. I do that with training, consulting and coaching."
Dad: "Aha."
That's the sound my father makes when he's not sure how to handle what I say.

Dad: "But what is it you do all day? How can I picture that?"
I: "Well, let's imagine my customer feels overweight."
Dad: "Aha."
My father is a little bit overweight.

I: "I can help overweight people. In the first meeting, the customer tells me his goals, what he wants to achieve. Sometimes his doctor showed him bad examination results, or he just does not feel good anymore with his body.

"After the first meeting I can roughly assess the situation, can tell if they are really overweight, or if they just feel overweight and the symptoms might caused by something else. Then I ask them if I should help them with the methods I know, like doing sports and optimize the diet. (By the way, my real methods are called Scrum and Kanban.)

"That's when I'm the trainer: I present my methods to the customer, so he knows what he's dealing with. Besides that he learns about the methods, we can establish a common language with words like 'resting heart rate' or 'metabolism', so we can talk to each other on a common ground."

Dad: "Okay, sports and another diet. Does not sound too complicated to me."
I: "No, and that's not why they call me. Everyone can look up those methods on the internet or read a good book about them. But there's more to it than just the training. There's also the consulting part.

"Take sports: I analyze the sports background of my customer, figure out how long he can run in 12 minutes (called the Cooper test), or what his resting pulse rate is. Based on that I develop a training program for him. Same with the diet: I measure his weight, his body fat, figure out what he eats all day. From that I develop a diet plan which should help him lose weight."

Dad: "Hm, but I've seen such plans in magazines. There are magazine for the stuff you do, too, are there not? Why do the customers pay you instead of buying a magazine?"
I: "Because I offer made-to-measure plans, only for that particular customer.

"But let's imagine my customer would find a good plan for his needs in a magazine, then he would still benefit from my work. This is where the coaching part comes into play. As a coach, I help my customer find his way through all that change that's necessary to lose weight."

Dad: "Aha. And that's what you do all day?"
I: "Jup. Hey! What's the meaning of that look of yours?"
Dad: "I don't mean to offend you, but... Well, it sounds so simple what you do..."
I: "Simple? Losing weight is simple? You know it's not."
We both look at his belly.

I: "Often customers want to lose weight, but at the same time they don't want to change their diet or start doing sports. If they are willing to change the diet, I have to explain again and again why they should eat less sugar and what's that got to do with their dicky heart.

"Sometimes the customer 'reframes' my advice. My advice could be drinking water instead of coke. After a while, the customer might not like drinking water anymore. It's just not tasty anymore. He might change to diet coke, which could complicate his health more than staying with the original coke. Then I'm there helping him to understand what he's doing and what consequences that means for him and his goals.

"Sometimes the customer can't get up and find the energy to go for a run, even he knows exactly that and why he should. Then I motivate him, show him the negative consequences if he does not run and the already visible positive consequences of what he achieved with all his running before.

"Sometimes the customers is so eager to lose weight, that he runs too much, e.g. every day instead of only thrice a week. Then I'm there for him, appease him and let him know about sustainable pace, that he's not ready yet to run that often.

"And there are thousands of other challenges I face at the customers every day when I coach."

Dad: "Wow, that's impressive! Didn't know you're doing all this at your work."

I think he was really impressed. And for the first time I think I could explain what I do for my living - training, consulting, and coaching - in a non-nerdy way.

If you are a not a nerd, do you understand, what I tried to explain?

Dienstag, 5. Juli 2011

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Pecha Kucha Guide

Pecha Kucha in Japanese

I happened to organize a few Pecha Kucha events (German) in the last years. Also I did present a few topics in the Pecha Kucha style (German). In a few weeks I will be host of another Pecha Kucha session at the Agile 2011 conference in Salt Lake City, together with Martin Heider, which is roughly a replay of last years quite successful Pecha Kucha event at XP 2010 conference in Trondheim.

Whenever we invite participants to share their memes with the audience in a 20-times-20-style, we send them a few words for their preparation. We gathered feedback in the last two years about those words, and it turns out that they were quite helpful to a lot of people. We also improved them over time, and now we want to share them with a broader audience.

Please download this two page PDF called "Helpful Things to Know About Pecha Kucha" (151 KB).

Dienstag, 13. Juli 2010

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Dieser Blog flattr-t

In eigener Sache: Dieser Blog versucht sich an Flattr.

Flattr ist ein Micropayment-Dienst auf freiwilliger Basis. Das funktioniert so: Beliebige Inhalte wie Blogposts, Bilder, Videos usw. können mit Buttons von Flattr versehen werden. Das ist so ein Button:

So einer klebt auch an diesem Blogpost. Klickt der Blog-Besucher auf den unteren Teil des Buttons (da, wo "Flattr" drauf steht), dann bewertet er diesen Blogpost, er flattr-t ihn. Die Zahl im oberen Teil des Buttons erhöht sich dann. Sie zeigt an, wie viele Besucher den Blogpost ge-flattr-t haben. Ein Klick auf die  Zahl bringt den Besucher auf eine Flattr-Seite mit Statistiken.

Was genau heißt es jetzt, etwas zu flattr-n? Hier kommt das Micropayment ins Spiel: Wer flattr-t, verteilt Geld. Vom Flattr-nden zum Ge-flattr-ten. Das funktioniert nach einem ausgeklügelten System: Wer sich bei Flattr anmeldet, muss zunächst sein Konto füllen, mindestens EUR 2 im Monat. Danach darf er auf Flattr-Buttons klicken. Seine Klicks werden von Flattr gezählt. Am Ende des Monats werden alle seine Klicks aufsummiert. Sein Monatsbudget wird durch die Summe all seiner Klicks in diesem Monat geteilt. Dieser Betrag wird dann an jeden von ihm Ge-flattr-ten ausgezahlt bzw. dessen Konto gut geschrieben.

Was? "Nicht einfach", sagst Du? Okay, hier ein Beispiel: Du hast auf Deinem Flattr-Konto ein Monatsbudget von 2 EUR angegeben. Im Laufe des Monats flattr-st Du 100 Blogpost, Videos usw. Am Ende des Monats ist damit so ein Klick 2 EUR / 100 Klicks = 0,02 EUR pro Klick wert. Wenn Du in diesem Monat auf diesen meinen Blogpost den Flattr-Button geklickt hast, dann bekomme ich auf mein Konto von Dir für diesen Monat genau 0,02 EUR gut geschrieben. Hättest Du nur einen einzigen Beitrag ge-flattr-t - diesen vielleicht? :) - im Monat, dann würde der Ge-flattr-te von Dir die vollen 2 EUR bekommen. Flattr verdient dabei, behält von jeder Konto-Gutschrift 10 % ein.

Lohnt sich Flattr-n? Wohl eher nur für die großen Blogs. netzpolitik.org hat eine Bilanz für Juni veröffentlicht, und da sah's wohl ganz nett aus. Aber nichts umwerfendes. Auf jeden Fall nicht mein Motiv, Flattr auf diesem Blog einzusetzen. Meine kühnsten Träume werden wahr, wenn ich etwas das raus bekomme, was ich rein gesteckt habe.

Warum Du flattr-n solltest? Um Danke zu sagen oder um jemanden zu belohnen für Inhalte, die Du gut findest. Das Ding ist freiwillig, keiner zwingt Dich. Alternativ twitter drüber. Oder erzähl's Deinen Freunden. Flattr ist für mich auch nur eine weitere Art, das gute Wort zu verteilen. Mir geht's um Feedback, und Flattr ist ein aktueller Feedback-Mechanismus.

Noch ein Grund zu Flattr-n: Um zu geben, wenn Du nimmst. Du musst Dich bei Flattr anmelden, um ge-flattr-t zu werden oder selbst zu flattr-n. Wenn Du also empfangen möchtest, dann bist Du automatisch in der Lage, selbst zu geben. Und das freiwillig: Wer's mag, der zahlt, wer's nicht mag, der zahlt nicht. Meine Traum-GEZ. Und wenn das bedeuten würde, das die Online-Werbung zurück geschraubt würde... ja, okay, man wird ja noch mal träumen dürfen.

Mein Grund zu Flattr-n: Ich wollt's gerne mal ausprobieren. Die Flattr-Buttons tauchen immer öfter vor meiner Surf-Nase auf. Und da wollte ich endlich mal drauf klicken. Und wenn ich mich dafür schon angemeldet habe, dann kann ich auch gleich selbst die Buttons auf meine Posts kleben.

Die schlechte Nachricht: Wer sich selbst bei Flattr anmelden möchte, kann das momentan nur mit einem Invite-Code. Dafür bin ich @flattrme gefolgt. Die wollen dann dort, dass Du "Bitte, bitte" machst, aber wenn man über diesen Schatten springt, bekommt man flugs seinen Invite-Code und kann los legen.

Das Einbinden der Buttons in den Blog ist dann weniger spaßig. Automatisch geht das nur halb. Ich habe mit Hilfe von Nicolas Gramlichs Flattr Button Plugin für Blogspot (übrigens mein erster ge-flattr-ter Inhalt!) die Buttons auf die Blogpost bekommen. Das geht automatisiert. Trotzdem muss man jeden einzelnen Beitrag auf Flattr posten, sonst ist der Inhalt für Flattr inaktiv und dann sieht der Button so aus:


Ich habe wenig Lust, jeden einzelnen Post dieses Blogs zu aktivieren, ergo bleiben alte Posts wie dieser vorerst inaktiv.

Fazit: Spannende Sache. Glaube, dass Flattr und ähnliche Konzepte in Zukunft durch starten werden. Schaue mir das mal aktiv von hier aus an.

Montag, 12. Juli 2010

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Kanban und Scrum aufm Entwicklertag Karlsruhe 2010


Vor Kurzem war ich für it-agile auf dem Entwicklertag in Karlsruhe und habe dort zwei Sessions gehalten.

Die erste Session war auf dem Agile Day und es ging um Kanban: "Kleine Kanban-Kunde" hieß denn auch der Vortrag, in dem ich ein wenig über die Historie von Kanban, wie eine Firma mit Kanban anfangen könnte und wie sich Kanban gegenüber Scrum verhält und sich beide super ergänzen können.

Die Resonanz war klasse: Feedback konnten die Teilnehmer über rote, gelbe und grüne Karten geben, die sie nach der Session am Ausgang abgeben konnten. Rot war schlechtes Feedback, gelb mittelmäßiges und grün war gutes Feedback.

Für meine "Kleine Kanban-Kunde" gab's von etwa 60 Teilnehmern 39 grüne, keine gelbe und keine rote Karte. Yeah!

Mehr Infos zu Kanban gibt's bei it-agile.

Die zweite Session war auf dem VKSI Day und die habe ich zusammen mit meinem aktuellen Kunden Johannes Feulner (Xing, Twitter) von fun communications GmbH (Webseite, Twitter) aus Karlsruhe gehalten. Es ging um "Scrum mit fun".

Ich durfte Johannes interviewen und er hat frei von der Leber weg erzählt: wie die Situation von fun vor Scrum war; wie er zu it-agile gefunden hat; was die einzelnen Schritte hin zu Scrum waren; was gut und auch, was schlecht gelaufen ist. Wir beide haben uns nett miteinander vor und später auch mit den Teilnehmern der Session unterhalten.

Das ist schon immer eine großartige Sache, wenn sich Kunden auf so etwas einlassen. Ein besseres Lob für gute Arbeit kann ich mir gar nicht vorstellen. Der Kunde kann zeigen, dass er mit der Zeit geht und moderne Softwareentwicklungs-Methoden einsetzt. Und so ist's für uns beide gute Öffentlichkeitsarbeit - win-win eben.

Erfahrungsberichte "ziehen" nicht so gut: etwa 25 Teilnehmer gesellten sich zu uns. Das Feedback war auch hier wieder toll: 18 grüne Karten, eine gelbe, keine rote. Leider stand auf der gelben nicht drauf, warum sie keine grüne war... :)

Mehr Infos zu Scrum gibt's auch bei it-agile.

Dank an dieser Stelle an den Ausrichter des Entwicklertag Karlsruhe, die andrena objects AG!

Donnerstag, 24. Dezember 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Prime Factors Kata - First Try

This is my first try of the Prime Factors Kata. It's my first Katacast of a kata at all. I performed it with Groovy.

Stefan wrote about katas (in German) a while ago, where he described his experience as an attendee of the contest "TDD with the pros" ("TDD mit den Profis", TmdP) at the XP Days Germany 2009 in Karlsruhe. TmdP is similar to "Programming with the Stars" at Agile 2009 in Chicago, where I was an attendee of.

Stefan was in the final of TmdP with his pair partner Franziska Widmaier. Their task was to calculate all prime factors of a given number, which is the same task as in the Prime Factors Kata. Stefan and Franziska had to finish this task in less than 7 minutes - and they failed to do it in time.

Stefan and I started to work on that kata right after the XP Days ended. Our first shot was in the train from Karlsruhe back to our home town Hamburg. After that we met once via Skype and wrote each step we took during the kata. I practiced a few times per week for the last five weeks or so and showed my performance to Stefan today. He said that it'd might be time to show the result to the world, and here it is:

On Youtube:




I've also shared the Katacast on vimeo and on viddler.

My to-do list for the next try so far:
  • Use a parameterized JUnit test instead of not isolated parameters in a map
  • Use more of TextMate's shortcuts and optimize on a keystroke level
  • Find out why 63 is too big... wtf? [Update: @datenreisender found out that this is related to a bug in Groovy.]
  • [Update: @datenreisender suggested in the comments to use primefactors instead of numbers2primeFactors[number] in the assertion.]
My heartfelt thanks to Stefan, with whom it was a lot of fun preparing that kata!

Happy Christmas!

P.S.: If you want to rate my performance, then post a comment with the number 0 (very bad) to 10 (very good). This kind of rating was inspired by Micah Martin. Any additional feedback is very welcome!

[Update: Stefan Roock made a Kata Bunkai - a commented kata - for this kata. Check it out!]

Freitag, 11. Dezember 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Running only one of JUnit's Tests


Green Bar with only one of JUnit's Tests

I managed to run all of JUnit's tests. And I failed for some time to run only one test. Here's why and how I finally succeeded.

One test I kept a close eye on: org.junit.tests.running.classes.ParameterizedTestTest. I opened it in Eclipse and tried to run it. A window occured and asked me to select a test:



What was that? I never saw such a window before. Was it something new in Eclipse 3.5.1? I looked around and looked also into the outline of that test class:



After a closer look I thought I knew what that test selection window was all about: One was able to pick a specific test method in one test class. All of the test method names in the test selection window were also in the outline view of that class. Yes, that would make sense. And that would be actually a great thing, since it was never possibile to do that in previous Eclipse versions and that would be a very useful feature for many reasons.

Okay, new feature, cool. But how could I run one test class with all test methods together? Like I was used to do in all the previous Eclipse versions before? I asked other Eclipse users in my current project, but nobody had a clue. I asked on Twitter, and got some doubtful suggestions like "I think there is something seriously broken in your eclipse installation."

After the fifth person or so I begged for help I realized what was going on. Do you see it? It's in the pictures I showed you in this post before. What I saw after a while was this line:



What a bad UI design, I thought. Why on earth would they put an entry for the whole test class in the middle of all the other test methods? Shouldn't it at least be marked in some way? Wrong assumption, again. Those items were all test classes! Oh my, now that I look at the test selection window I see all those green icons with the C in it...

Anyhow, why are there so many static test classes (yes, that's what they are, static, and the outline view told me with a little red 'S') in one single file? Because those are the input parameters for the tests. The test class contains all the tests for JUnit's Parameterized Test feature, which is a way to deal with one test method called several times with different parameters. It's more than having a for-loop going through a bunch of parameter sets, because with JUnit's Parameterized Test feature every parameter set is treated like a separate test method. With three parameter sets you'd end up with three tests, and if one test would fail, the others won't stop running like they would do in a for-loop.

For that feature you have to provide a annotated method which should return the parameters, you have to provide a constructor and instance variables for the parameters, and you have to reference the parameters in the instance variables from within the test method. That's a lot of stuff which could be broken easily. Each static test class supports a test method for the feature. Eclipse cannot distinguish between a test class as a test class and a test class as a test input parameter, and so it showed every test class in a test selection window.

Well, maybe I shouldn't program late at night, but that was really a hard one to figure out.

Mittwoch, 9. Dezember 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Running all of JUnit's Tests


Green Bar with JUnit

After Getting JUnit from Git on a Mac I wanted to run all of JUnit's tests. Here's what happened.

First I opened the whole JUnit project in TextMate. TextMate is my editor of choice when I work with Groovy/Grails and Ruby/Rails. I do whole projects with it. For those kind of languages and frameworks Textmate is suiteable, but since JUnit is a Java project, TextMate's seems to be not enough.

I tried to run all the tests within JUnit with TextMate. There are some AllTests classes, but you can't run them from within TextMate easily, because you would have to deal with the classpath on your own. There's an Ant build file, but unfortunately without a test task. Tests seems to be only executed during a build, but I don't want to build JUnit everytime when I actually want to run all the tests.

In the build file I saw a reference to org.junit.tests.AllTests. Again, it'd be a mess to build the classpath everytime I wanted to execute the AllTests class within TextMate. I switched to Eclipse after I upgraded to Eclipse 3.5.1.

There were already project files for Eclipse in the JUnit project, so I was able to be up with JUnit in Eclipse with a simple import. I executed org.junit.tests.AllTests with Alt+CMD+X T and I saw a green bar with 481 tests. Yay!

Only the execution time wasn't that good. It took me ~23 seconds to execute all the tests, which is quite more than my expected less than 10 seconds.

At least I could run all of JUnit's tests now.

Donnerstag, 3. Dezember 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Getting JUnit from Git on a Mac


I want to dig deeper into JUnit for some reasons. Therefore I want to see the latest version in the repository. JUnit uses Git. I use a Mac and never used Git before. Here's what I've done to get JUnit from Git on a Mac.

I installed Git for OS X. It's a dmg file and quite simple to install.

After that I had to add Git's bin path to PATH to use Git in the terminal. I added this to ~/.bash_profile.
export GIT_HOME=/usr/local/git
export PATH=$PATH:$GIT_HOME/bin
Worked now for me: I entered git in the terminal and saw a list of commands.

Now what? I read parts of the official Git tutorial online and in the terminal with git help tutorial. I entered my user.name and my email.adress as a key with git config --global key value where value is my name or email adress, because I should do that "before doing any operation".

I continued reading at paragraph "Using git for collaboration". There's what I was looking for:
Suppose that Alice [aka Kent] has started a new project with a git repository in /home/alice/project [aka git://github.com/KentBeck/junit.git as listed on github.com], and that Bob [aka me], who has a home directory on the same machine [aka ~/projects/junit], wants to contribute.
In the terminal I entered
git clone git://github.com/KentBeck/junit.git ~/projects/junit
Now Git downloaded JUnit. Finally JUnit was downloaded on my computer. The tutorial states that if Kent would commit changes I could be again up to date with a simple git pull.

So far so good to be able to have a look around in JUnit.

[Update: If you want to run Git within TextMate, than you can. TextMate can deal with Git from the start, but you have to set TM_GIT as a shell variable, e.g. to /usr/local/git/bin/git or wherever you've installed Git.]

Dienstag, 1. Dezember 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Der grüne Pfad


Schön, wenn einem die Arbeit abgenommen wird: Kollege Stefan Roock schreibt in seinem neuesten Blogeintrag vom grünen Pfad, den ich beim Refactoring gerne gehe. Auf einem grünen Pfad gibt es minimales Risiko, sich im Code zu verlaufen. Aber der grüne Pfad ist nicht ganz einfach zu finden, auch wenn seine Regeln sehr einfach sind:
  1. Einen atomares, d.h. nicht weiter unterteilbares, Refactoring durchführen.
  2. Tests grün laufen lassen.
  3. Weiter mit 1.
Laufen die Tests bei 2. nicht grün, sondern rot, hat man den grünen Pfad verlassen und findet sich unweigerlich in der roten Testhölle wieder, aus der es nur durch Strg-Z oder CMD-Z einen sicheren Ausweg gibt.

Was sind atomare Refactorings? Solche, die nicht weiter durch andere Refactorings unterteilbar sind, etwa Umbenennen, Extrahieren, oder Inlinen. Die meisten anderen Refactorings sind aus atomaren Refactorings zusammen gesetzte Refactorings.

Stefan beschreibt sehr schön, dass es gar nicht darauf ankommt, immer auf dem grünen Pfad zu weilen. Eigentlich braucht man den grünen Pfad nur dann, wenn es knifflig wird. Aber wer nicht oft auf dem grünen Pfad gelaufen ist, der wird ihn nur sehr schwer finden, und wer nicht oft kleine Schritte beim Refactoring gegangen ist, der wird sich unter Druck oder in sehr krudem Big-Ball-of-Mud-Code nicht mehr daran erinnern können, also genau dann, wenn es einem besonders helfen würde.

Stefan hat ein schönes Beispiel aufgeschrieben, bei dem ich ihn quasi auf dem grünen Pfad vor mich hergeschoben habe - und er zu einer, wie ich finde, sehr cleveren Lösung gekommen ist.

Gerne gebe ich den Aufruf von Stefan weiter: Habt ihr Code, der nicht auf dem grünen Pfad zu refaktorisieren sei? Immer her damit: bernd.schiffer@gmail.com oder hier in die Kommentare. Wir freuen uns über jede Herausforderung :-)

Mittwoch, 18. November 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Barcamp Hamburg 3

Logo vom Barcamp Hamburg 3

Letzte Woche war ich auf dem Barcamp Hamburg 3. Wird höchste Zeit, darüber mal zu bloggen. Das war mein erstes Barcamp. Das zweitägige Event startete letzten Freitag, ich selbst konnte leider nur den Samstag hin.

Der Samstag Morgen begann mit einem Hammer-Frühstück. Der Hauptsponsor @otto_de, in dessen Räumen die Konferenz auch statt fand, hat seine hauseigene Kantine Kochwerk für die 400 angemeldeten und etwa 330 tatsächlich gekommenen Teilnehmer ein fantastisches Frühstück zubereiten lassen. Von 9 h bis 10 h habe ich dann erstmal ausgiebig gefrühstückt und ge-social-ized. Sehr relaxed.

Um 10 startete die Session-Vorstellung: Alle in den größten Raum um jedem zuzuhören, der eine Session vorstellen wollte. Dann melden oder nicht bei der Frage "Wer hat interesse?", damit eine passende Raumgröße gefunden werden kann. Die Sessionnamen wurden danach auf einer Wand im Foyer zu Räumen und Zeiten zugeordnet (elektronische Version). Jede Session sollte nicht länger als 30 Minuten dauern. Großzügige Pausen ermöglichten gute Kontakte und regen Austausch zwischen den Teilnehmern.

Das Highlight der vorgestellten Sessions war eine von @Bastian_twitter über Prokrastinieren, die natürlich "morgen" stattfinden sollte. Dazu passt auch der geniale T-Shirt-Spruch eines anderen Teilnehmers: "Procrastinators - Leaders of tomorrow!" Geek-Humor vom Feinsten!

Anschließend starteten die Sessions. In meiner ersten habe ich von Wireframes erfahren. Das sind Modelle von Webseiten, um das Layout und die gewünschten Features besser durchsprechen zu können, z.B. zwischen Programmierer und Kunden. Die Session war ein lustiges Durcheinander von Tool-Show wie Balsamiq Mockups oder MockingBird oder auch einfach Stift und Papier und der Frage nach dem geeigneten Prozess für das Miteinander zwischen Programmierer und Kunden. Lustig: Am Rande gab's ein wenig Streit: "Wenn Du da mit einem Wasserfall-Prozess ran gehst, dann kann das ja auch nix werden..." - "Was? Ich mache keinen Wasserfall, ich mach das Agil!" Nein, ich war da nicht beteiligt. Fazit: Alter agiler Wein (aka Papierprototypen und -scribbles) in neuen Webschläuchen (aka Tools).

Bei der Folgesession ging's um Google Wave. Bin selbst (bernd.schiffer@googlewave.com) begeisterter Waver. Die Session hat enormen Anklang gefunden und der größte Raum war pickepacke voll. Die zwei Sessionowner haben Google Wave vorgestellt in den Grundfunktionen und haben damit einen soliden Job getan.

Am Vortag schien es schon eine Session mit Erfahrungen über Scrum in einem Webprojekt gegeben zu haben, so dass ich nun eine Session zu Scrum-Grundlagen besuchen konnte. Die Session war gut besucht mit 30 Teilnehmern, allerdings kam keine Diskussion zustande und der Vortragende hat auch bei 100 % Zeitüberzug und in insgesamt 60 Minuten Scrum nicht auf den Punkt gebracht. Keine Krise ohne Chance, konnte ich doch im Nachhinein in netten Gesprächen mit vielen Teilnehmern die Missverständnisse aus der Session ausräumen :-)

Mein Session-Highlight hat mich selbst überrascht: Vivian Pein, Community Manager bei Xing, beantwortete die Frage "Wie optimiere ich mein Xing-Profil für Headhunter?" Mich hat da nun gar nicht so sehr interessiert, wie ich mein eigenes Xing-Profil optmieren könnte. Wobei das ein netter Nebeneffekt war. Was mich eigentlich interessierte war der Umkehrschluss, also wie jemand gefunden werden möchte für Unternehmen, also wie z.B. it-agile mehr gute Mitarbeiter finden kann.

Ein paar Gedankenfetzen notiert (in Anführungsstriche Vivians O-Ton):
  • Referenzen in Xing (neues Feature) "gehen ab wie Schmidts Katze!" und sind jetzt schon sehr beliebte Kriterien bei der Bewerberauswahl. Was in USA und Australien schon üblich ist scheint sich demnach auch bald hier zu etablieren: Unternehmen fragen bei vorherigen Arbeitgebern nach, wie der Bewerber drauf ist.
  • Manch lustiger Zeitgenosse möchte geistreich erscheinen und trägt unter Fremdsprache "Klartext" ein. "Klartext als Fremdsprache eintragen heißt 'Labertasche' und 'nicht sozialkompatibel' in Rekruter-Übersetzung." Alles klar?
  • Auf der Suche nach einem neuen Job? "'Herausforderungen' eintragen in 'Ich suche' ist No. 1 Keyword für Jobsucher."
  • Stolz drauf, nicht gegooglet werden zu können? "Headhunter werden misstrauisch, wenn *wenig* über einen im Netz steht." Zur Angst vor ungünstigen Partybildern auf Facebook gesellt sich bald die Angst vor überhaupt keinen Bildern in Facebook. Sollte diese Info wirklich stimmen, so wäre das die für mich unerwartetste Erkenntnis vom Barcamp.
Auch gelernt: Xing nutzt UserVoice zwecks End-Kunden-Feedback.

Der Kaffee war der Hammer - weil ständig da! Das war die bislang erste und einzige Konferenz, in der der Kaffee wirklich jederzeit verfügbar war. Das Kaffee nicht immer verfügbar ist auf Konferenzen galt für mich bislang genauso als ungeschriebenes Gesetz wie ein unstabile Konferenz-WLAN. Die Barcamp-Organisatoren waren aber so clever und haben @kaffee_bazar_de als Sponsor gewonnen. Und dieses ein Jahr junge Start-Up kam mit einem Kaffee-Stand daher mit lecker und immer vorhandenem Kaffee. Tolle Sache das!

Der späte Nachmittag klang dann langsam mit tollen Gesprächen aus. Bei der Abschlussrunde haben die Organisatoren sich sehr gutes Feedback abgeholt. Völlig verdient, wie ich finde, weil sehr guten Job gemacht! Bravo und Danke, komme gerne wieder!

Vorher habe ich schon einige andere Unkonferenzen im Bereich Agiler Softwareentwicklung mitgemacht, alle mit dem Konferenzkonzept Open Space. Die Sessionauswahl aufm Barcamp war schon sehr ähnlich. Vielleicht hätten die Regeln des Open Space dem Barcamp noch ein wenig mehr Selbstorganisation und kollaborative Sessiongestaltung ermöglicht.

Interessant fand ich, dass "Agil" durchaus ein sehr verbreitetes Thema ist. Viele Webworker kommen damit in Berührung nicht etwa deshalb, weil sie selbst in ihrer Agentur dies einsetzen. Aber ihre Kunden setzen es oft schon ein oder nutzen zumindest Teile davon.

Freitag, 13. November 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Session mit Pecha Kucha auf der WJAX 2009

Auf der WJAX 2009 habe ich zusammen mit Martin Heider (Xing, Twitter) die Session "Mein Agiler Koffer" auf dem Agile Day vorbereitet und moderiert. Das Format für die Session war Pecha Kucha: Pro Vortrag 20 Bilder á 20 Sekunden = 6'40 Minuten. Was für ein Spaß :-)

Martin und ich haben zuerst in einem halben Pecha Kucha (20 Bilder á 10 Sekunden = 3'20 Minuten) die Session anmoderiert. In diesem Speed-Pecha-Kucha haben wir den Rahmen gesteckt für die darauf folgenden sechs Session-Teilnehmer, allesamt Agile Coaches in Deutschland: "Wenn Ihr für ein neues Projekt angeheuert werdet, und Ihr müsst Euren Agilen Koffer dafür packen, was packt Ihr ein?"


Und was haben die Teilnehmer nicht alles für tolle Sachen eingepackt!

Holger Koschek (Twitter, Blog, Xing) war als Erster dran und startete mit "Air Holisticon" in Richtung Rückkopplung, Verantwortung und Spaß:

Deborah Preuss (Twitter, Xing) folgte als Nächste und reiste leicht mit "Powerful Questions":

Christoph Mathis (Twitter, Blog, Xing), Rufname Krishan, packte vier Sachen in seinen Agilen Koffer, darunter das bekannte Inspect and Adapt und Treat People as Adults:

Henning Wolf (Twitter, Blog, Xing) packte seinen Agilen Koffer pickepacke voll mit sechs sehr interessanten Dingen:

Sabine Canditt (Xing) hatte das Thema etwas durcheinander bekommen - was für ein Glück für uns! Seht Euch selbst die Bilder zu "Mein Agiler Kocher äähh Koffer" an:

Das strahlende Schlusslicht bildete Jens Coldewey (Twitter, Blog, Xing), der in seinen Koffer unter anderem Pragmatismus und Humor packte:

Martin und ich haben nach den sechs Vorträgen noch den echten Agilen Koffer verlost, gefüllt mit allerlei Lernbarem in Form von Büchern und Genießbarem in Form von Spielsachen und Kaffeehausgutscheinen.

Mein persönliches Fazit lagere ich aus - in die hier eingebettete Google Wave. Bitte mitsurfen! Die Wave ist offen und jeder kann mitmachen.




Angekommen scheint die Session bei den ca. 130 Zuschauern im großen Ballsaal im Westin Grand Hotel in München: Martin und ich haben viel gutes Feedback bekommen von den Teilnehmern und den Zuschauern. Wir haben schon wieder einen Haufen neuer Ideen für die geplante Wiederauflage auf der JAX 2010. Stay tuned :-)

Bedanken möchte ich mich an dieser Stelle bei den Teilnehmern, die mit Ihrem immensen zeitlichen und kreativen Aufwand dieser Session Leben geschenkt haben. Danke und Hut ab, das war allererste Klasse von Euch! Auch bei den Sponsoren it-agile, dpunkt und infomar möchte ich mich bedanken, ohne die wir den echten Agilen Koffer nicht mit so viel Gutem hätten füllen können. Schließlich geht mein ganz großer Dank an Martin Heider, mit dem es mir sehr viel Spaß gemacht hat, dieses Event vorzubereiten und durchzuführen.

Reaktionen auf die Pecha-Kucha-Session (falls ich hier etwas übersehen habe: bitte in den Kommentaren nachtragen, dann update ich's hier):

Donnerstag, 17. September 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Grails on Rails


Gleisanzeiger an der Haltestelle Berliner Tor in Hamburg


Das war mal etwas anderes: Vorgestern habe ich zusammen mit meinem it-agile-Kollegen Stefan Roock (Blog, Twitter, Xing) beim ObjectForum Nord in Hamburg einen Vortrag über Grails gehalten - in der Historischen S-Bahn Hamburg.

Grails auf Rails war das, und zwar wortwörtlich. Der Inhalt der Veranstaltung handelte von it-agiles Erfahrungen mit Grails und sollte dem Publikum aufzeigen, für welche Arten von Webanwendungen sich Grails gut eignet und wo es Fallstricke erwarten kann.

In einer S-Bahn vortragen, das war für uns neu. Während der Fahrt funktioniert kein Vortrag, da es einfach durch die Fahrtgeräusche zu laut ist. Wir haben die Zuhörer an der Haltestelle Berliner Tor in Hamburg abgeholt, nach Blankenese auf ein für uns reserviertes Gleis gebracht, dort in Ruhe den Vortrag gehalten und sie dann wieder zurück zum Berliner Tor gefahren. Die ganze Aktion dauerte etwa zweieinhalb Stunden bei einer Stunde Vortrag.

(Böse Zungen munkeln, dass das eine Butterfahrt war. Das stimmt aber nicht, denn wir haben nicht eine einzige Heizdecke an die Teilnehmer ausgegeben. Ehrenwort!)

Der Vortrag selbst war auch nicht so einfach: Durch die Sitzgruppen im durch eine dünne Trennwand zweigeteilten Abteil konnten wir Kraft eigener Stimme nicht jeden Zuhörer erreichen. Die eingebaute Lautsprecheranlage war dagegen ziemlich verrauscht, so wie es das Klischee der unverständlichen Lautsprecherdurchsagen vom Schaffner passend beschreibt. Eine eigene Boxenanlage musste her - akkubetrieben, da es keinen 240-Volt-Stromanschluss in einer historischen S-Bahn gibt.

Und dann die Sache mit den Folien und dem Beamer. Kein Strom, kein Beamer. Und selbst, wenn wir Strom gehabt hätten, wohin hätten wir die Folien projizieren können? Wir haben uns dann mit Riesen-Post-Its beholfen, die sechs it-agile-Kollegen auf Stefan und mein Zurufen hin umgeblättert haben. Und trotz aller Unkenrufe - Was da nicht alles hätte schief gehen können! -  verlief die Aktion reibungslos.

Die Resonanz: Sowohl Inhalt des Vortrags wie auch die Location kamen gut an. Uns hat es sehr viel Spaß gemacht.

Ein paar Fotos haben wir auch geschossen:



Freitag, 21. August 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Pecha Kucha "Inkrementelles Design" (Folien und Video)

Auf der JAX '09 im Frühling diesen Jahres habe ich für it-agile in einer Pecha Kucha-Session auf dem Agile Day einen Vortrag "Inkrementelles Design" gehalten. Host war Stefan Roock (Homepage, Twitter, Xing). Das sind die Folien:

View more documents from Bernd Schiffer.

Das alles ist schon ein wenig länger her, aber jetzt hat die Konferenz-Organisation das Video auf JAX TV veröffentlicht. Danke JAX-Team! Hier das Video:


Ich rede zwar viel zu schnell, trotzdem: Viel Spaß damit :-)

Apropos Pecha Kucha I: Auf den XP Days Germany 2009 im November diesen Jahres gibt es gleich 9 Pecha Kucha-Vorträge in drei Blöcken (siehe Programm). Das sind für mich die Perlen dieser Konferenz, also nicht verpassen!

Apropos Pecha Kucha II: Auf der WJAX '09, auch im November diesen Jahres, gibt es wieder eine Pecha Kucha-Session, die ich zusammen mit Martin Heider (Xing, Twitter) auf dem Agile Day halten werde. Thema: "Mein agiler Koffer - Reisetipps mit Pecha Kucha".

Links:

Montag, 17. August 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Zu meinem Verständnis von TDD und BDD


Mein Kollege Stefan Roock schreibt in seinem Blogpost von einem "Vergleich: BDD und TDD":
"Ich [wurde] bereits früh von TDD (Test Driven Development) infiziert. Irgendwann kam eine neue Bewegung auf: BDD (Behaviour Driven Design). Wie viele andere TDDler habe ich lange nicht verstanden, was der Vorteil von BDD sein soll."
Dito. Verstehe den Vorteil von BDD bis heute nicht. Ich präzisiere: Verstehe ich bis heute nicht für mich.

Stefan scheint seinen Frieden mit BDD nun gemacht zu haben, denn er schreibt:
"[Der Vorteil] ist mir inzwischen klar gewor[d]en."
Stefan nimmt in seinem Blogpost eine Portion Ruby-Code eines TDD-Beispiels mit RUNIT her und übersetzt es in ein BDD-Beispiel mit RSpec. Dabei fällt ihm dies auf:
"Strukturell sind Test und BDD-Spezifikation identisch. Die BDD-Spezifikation ist bei den Vergleichen lediglich etwas leichter lesbar.
Der Vergleich termin.bezeichnung.should == "TDD-Dojo" ist der natürlichsprachlichen Formulierung "Die Terminbezeichnung sollte 'TDD-Dojo' sein." ähnlicher als assert_equal("TDD-Dojo", termin.bezeichnung)."
Lange habe ich gegrübelt, was mich hier stört. Und das ist mir inzwischen klar geworden. Was heißt denn leichter lesbar? Was ist natürlichsprachlich?

BDD selbst verweist als eines seiner Vorteile auf die Sapir-Whorf-Hypothese. Diese Hypothese besagt
"... dass die Sprache das Denken formt."
Nach dem, wie und was wir (be-)sprechen, nach dem handeln wir auch. Sprechen wir über Tests, so sichern wir primär Eigenschaften zu. Sprechen wir dagegen von Spezifikationen, so beauftragen wir Eigenschaften und geben an, wie sie sein sollen. Demnach weichen test und assert aus xUnit specification und should aus RSpec. Die Idee ist, dass wenn der Programmierer keine Tests mehr schreibt, sondern Spezifikationen, wenn er keine Zusicherungen über, sondern einen Auftrag (should; soll; Auftrag) an den Code schreibt, dass er dann anders denkt.

Dieses Andersdenken bezieht sich auf das letzte D in TDD: Die einen übersetzen es mit Development, die anderen mit Design. Letzteres ist für viele TDDler die eigentliche Qualität des TDD: Das Design wird getrieben durch die Tests. Es geht nicht um Verifikation, sondern um Spezifikation. Diesen Gedanken greift das BDD nun auf und fragt: Wenn wir spezifizieren statt zu testen, wenn wir schreiben, was der Code tun soll, anstatt etwas zuzusichern, dann sollten wir das auch so aufschreiben, damit wir durch die Worte wohl geleitet handeln.

Mag sein, dass das für jemanden gilt, der neu ist in TDD. Das kann ich mir gut vorstellen. "TDD? Was soll das sein? Ach, Tests? So so, verstehe, geht ums Testen von Software. Alles klar, man her damit!" Und schon ist der Neue mit falschen Annahmen bei der Sache. Nicht gut. Da hilft BDD, oder?

Seit über 8 Jahren programmiere ich testgetrieben, was mich als TDD-Neuling disqualifiziert. Meine Vorstellung von Tests sind stark kontextbehaftet. Geht's um TDD? Dann sind meine Tests keine Verifikationen, sondern meine Mittel fürs Design. Geht's um die Endabnahme, Akzeptanztests, QA? Dann sind meine Tests verifizierend. Da hilft kein BDD, um mein Handeln durch eine andere Terminologie zu besseren Ergebnissen zu leiten.
"BDD"
, frei nach Dave Astels,
"macht man, wenn man TDD richtig macht."
Und bislang war das der Strohhalm, nach dem ich gegriffen habe, wenn ich nicht verstand, warum BDD nun anders sein soll als TDD. Dieser Strohhalmgriff beruht auf meiner Annahme, dass ich bereits korrektes TDD mache. Subjektiv, vielleicht vermessen, möglicherweise anmaßend, auf jedenfall nicht objektiv bewertbar ist die Aussage, ob ich korrektes TDD mache. Das war mir immer ein sehr kleiner Strohhalm.

Wittgenstein ist da schon ein größerer Strohhalm. Von ihm las ich neulich wieder in Prechts "Wer bin ich und wenn ja, wie viele?", und von seiner Idee der Präzisionssprache. Wittgensteins Theorie besagte, dass die Sprache als Abbild der Realität dienen kann. Und er lag falsch, wurde widerlegt:
"[Der Sprache] wichtigste Funktion besteht darin, zu verstehen und verstanden zu werden. Ob etwas verständlich ist oder nicht bestimmen sowohl die Grammatik wie der Kontext. So kann der Satz 'Ich sehe schwarz' meinen, dass ich vor einem schwarzen Bild stehe und seine Farbe beschreibe. Ebenso gut aber kann er bedeuten, dass ich in einer Sache pessimistisch bin. Dem jungen Wittgenstein waren solche Sätze ein Greuel, aber die Sprache wimmelt nur so von Mehrdeutgkeiten. Die schlichte Wahrheit, die jede Idee einer Präzisionssprache zum Scheitern verurteilt, ist, dass die Bedeutung eines Satzes durch den Gebrauch der Wörter geformt wird."
Die Bedeutung wird also durch den Gebrauch der Wörter geformt. Die Wörter selbst formen nicht die Bedeutung. Es ist eine Implikation, keine Äquivalenz. Und ich benutze Worte wie Test und Zusicherung schon seit 8 Jahren. Kein Wunder also, dass die Bedeutung von TDD bei mir entsprechend geformt wurde. Das, was hinter TDD steckt, erschließt sich mir mehr über die Worte Test und Zusicherung, weniger über Spezifikation und Auftrag.

Wenn ich einem xDD-Neuling im TDD-Camp erkläre, dass er die Tests vor dem Code schreiben, dass er Einfachheit anstreben, dass er gnadenlos refaktorisieren, dass er Redundanzen eliminieren und dass er noch ein paar TDD-Gebräuche mehr anwenden soll, und wenn ich dem xDD-Neuling dann sage, dass das Testgetriebene Entwicklung ist, dann habe ich die Bedeutung von Tests im Kontext des TDD durch den Gebrauch der Worte wie Tests und Zusicherungen entsprechend geformt. Aus meiner Sicht heraus sind für einen xDD-Neuling beide Begriffsgruppen, Tests-Zusicherung und Spezifikation-Auftrag, am Anfang seiner Ausbildung gleich bedeutungsleer oder -voll. Das, was diese Wortgruppen mit dem verbindet, was hinter TDD/BDD steckt, dem Treiben des Designs also, wird erst durch den Gebrauch, also durch die Anwendung dieser Wörter geformt. Wenn das stimmt, dann ist es schnurzpiepegal, ob man nun TDD oder BDD macht.

Mein Fazit: Taten mögen den Worten folgen (Sapir-Whorf-Hypothese; BDD), sicherlich wird Bedeutung durch den Gebrauch von Worten erlangt (Widerlegung Wittgensteins; xDD). Egal, ob ich BDD oder TDD anwende, beide benutzen eine jeweils eigene Terminologie, die Bedeutung durch den Gebrauch derselben erlangt. Ergo hat weder BDD noch TDD einen Vorteil gegenüber der jeweils anderen Technik.

Versöhnlich möchte ich schließen. Precht schreibt:
"Und die entscheidende Frage beim Verständnis von Sätzen ist nicht, ob etwas wahr ist oder falsch, sondern ob die Verständigung im beabsichtigten Sinne gelingt oder nicht gelingt."
Verständigung im beabsichtigten Sinne: Egal ob TDD oder BDD, es geht nicht darum, ob Tests oder Spezifikationen, es geht darum, zu verstehen, dass in beiden Fällen Design getrieben wird.

Wir verstehen uns?

Freitag, 14. August 2009

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

Wenn's mal passt


Bin gerade in einer sehr glücklichen Beziehung. Vor Kurzem hat es angefangen. Wir kannten uns schon ein wenig vorher, aber so richtig zusammen sind wir erst seit fünf Wochen. Wir wußten damals nicht mit Sicherheit, ob es mit uns beiden klappen würde. Umso glücklicher sind wir jetzt darüber, dass wir anscheinend richtig gut zusammenpassen.

Woran ich es erkannt habe, dass es gut passte? Da war dieses Bauchgefühl, dass mir in der ein oder anderen Situation Bestätigung gab. Und natürlich haben wir unsere Differenzen über die ein oder andere Sache. Sogar über gegenteilige Ansichten hinaus kommen wir miteinander gut aus.

Wir sehen uns fast jeden Tag und verbringen dann viel Zeit miteinander. Ich würde es gar nicht aushalten, wenn wir ständig Probleme miteinander hätten. Darum finde ich es geradezu notwendig, dass wir uns gegenseitig riechen können, dass wir auf einer Wellenlänge funken. Gar nicht auszudenken, dass ich so eng mit jemandem zusammen sein müsste, mit dem ich mich nicht gut verstehe.

Wir lernen viel voneinander. Wir beide haben schon viele Beziehungen mitgemacht und haben daraus viel geschöpft. Und es sind nicht nur die Techniken (obwohl das schon jede Menge Spass machen kann, sich gegenseitig die abgefahrensten Praktiken vorzustellen und dann miteinander auszuprobieren). Es ist der Respekt, der uns gegenseitig zuhören lässt, wenn der andere spricht; es ist das offene Feedback, dass wir uns geben und vom anderen annehmen; es ist der Spass, den wir miteinander haben, ohne unser gemeinsames Ziel aus den Augen zu verlieren; es ist der Flow, in dem wir zusammen agieren.

Es ist nur ein kurzes Projekt, etwa sechs Wochen. Es ist nur ein kleines Projekt, wir zwei eben. Das Risiko war also sehr gering, zwei, die sich nicht kennen, zusammen da reinzustecken. Trotzdem hat das Nahezu-blind-miteinander-Arbeiten schon nach drei bis fünf Wochen geklappt. Wenige Zeilen Code sind entstanden, als wir nicht zusammen im Paar programmiert haben. Jedes Mem, das mindestens einer von uns für wichtig hielt, haben wir besprochen, sind dabei richtig in die Tiefe gegangen, und sind jeweils beide gestärkt daraus hervorgegangen. Architektur, Design, Pattern, solche Dinge meine ich. Shortcuts, Programmiersprach-Idiome, Tipps & Tricks, die meine ich auch. Coole Tweets, Youtube-Videos und Blogposts, auch die gehören dazu.

Ich genieße diese Zeit. Es kommt nicht oft vor, dass man so gut miteinander kann innerhalb eines Projektes. Fast nie kann ich mir aussuchen, mit wem ich programmiere. Und dann ist es eben eine gewisse Chance bishin zu reinem Zufall, wenn's passt. Das kommt vor, aber weitaus weniger oft, als man annehmen könnte.

Kernaussage dieses Posts soll sein... - nun, keine Liebeserklärung jedenfalls. Dass ich gut mit meinem Kollegen kann, und er mit mir, dass wissen wir beide seit einigen Retrospektiven. Dieser Gewissheit bedürfte es keines Blogposts. Nein, Kernaussage dieses Posts soll sein, Wert auf gute Beziehungen innerhalb eines Projektes zu legen lohnt sich. Nie arbeite ich so produktiv, so effizient, so effektiv, so nachhaltig gut, als wenn ich einen guten Partner habe.

Schönes Gefühl, wenn alles passt.