Thank you, 2011

It’s December. That means it’s time to write a long, rambling post looking back on the year. It’s been a very exciting and eventful year for me, so I’m actually appreciating having the time to do this.

Last new year's eve I tweeted the following. And I wasn't wrong.

2011 is gonna be amazing, you just watch!

I’ve changed jobs, moved from Düsseldorf to Hamburg, took part in a lot of conferences and events, organised a few things myself and in all of that met a huge amount of amazing people that truly inspired me. Thank you, everyone! It was an amazing year.

xtc Berlin

Late Tuesday evening, the night before the ALE conference started, I sat in the hotel bar of the venue talking to people who had arrived early. Looking around, I thought, "cool, it's like an extreme tuesday club in Berlin". Since then I've been thinking about what it would take to actually create something like this in Germany.

So what is the extreme tuesday club?

A regular London meeting (weekly) for Agile/XP/Kanban/Scrum newbies, practitioners, and experts. (*)

That's not very elaborate but I like that it casts a fairly wide net in terms of target audience.

There are already a lot of different software and agile related user groups in Berlin and I like what I've seen of them so far. But each of these only cater to a specific topic or technolgy.

I'm looking for something less formal. Have a beer, talk to people about what they're working on, share war stories, cross-pollinate new ideas, ask for help or give help, if wanted. I would hope it would be as inclusive as possible. So, newbie or expert, programmers, PM/POs, design people, start-uppers, whatever - as long as you care about what you're doing and want to talk with people about it, it should be fine.

I did a little open space session at ALE on this and there seemed some general interest and I said I would just try and get this rolling and just see what happens.

Someone suggested the Cafe 100 Wasser as a pub to go to. And that's where I'll be, this Tuesday from around 8pm onwards. I'd be happy for you to join me. If you do plan to come, please let people know on Twitter.
[we've since changed pubs around quite a bit. Twitter is probably the safest bet to find out where people are. We're now usually at the Prater Garten in Prenzlauer Berg]

Some closure (ha!) to 7 Languages in 7 Weeks

I'm currently trying to work through a backlog of things I've been meaning to blog about. And at the top is this post. The whole experience deserves being wrapped up properly. But I'll keep it brief.

When last I wrote about it, I was somewhere in the middle of week 6, working with clojure. This is probably my favourite of the languages in terms of learning new things and offering new perspectives while also having enough momentum that I might actually be able to do something with it at some point. I really hope this doesn't fall victim to my inherent lazyness.

The last week dealt with Haskell. At this point I was so busy with moving apartments and starting my new job that I barely managed to read the chapter but didn't get to try the examples. It sounded interesting but maybe a bit too strict. Others in the study group seemed to like it a lot though.

So, what's left to say. I really appreciated the study group and being able to learn from other people's code on github.

I enjoyed the weekly google hangout sessions with the others, when I was able to join them. I particulary liked how aimee facilitated those, keeping track of threads of discussions and making sure everybody got to say something.

The book requires quite a bit of commitment to get the most out of it but where I did that I felt it was well worth it.

I certainly recommend doing this together with other people. And share your experience with the world. 

All in all, I stick to what I said in my first post on this.We live in amazing times!

Learning clojure just in time

It looks like we've moved to clojure at just the right moment.

As mentioned, I started using emacs for the first time again in ages. While I still struggle remembering all the useful key combos I did get a little bit of help in the transition by installing aquamacs. It keeps buffers in tabs and lets you use cmd-c,x,v while you're trying to remember how to work the yank buffer.

I'm really liking clojure so far. I'm finally writing tests again (not sure I actually ever did for any of the other languages) and it's nice to have that inside emacs and also have the REPL to try things out.

So, Day 1 only had two excercises. I'm going to just point to aimee's entry on that, because we both came up with pretty similar code.

But let's look at the second exercise

Write a function called (collection-type col) that returns :list, :map, or :vector based on the type of collection col.

I got the following:

I wasn't quite happy with repeating the col argument for each condition. So I started to play around with using the various test methods (list? vector? map?) as keys in a map and then filtering the keys based on the collection argument given. I eventually gave up on it, because it is a rather silly approach. But it was an interesting opportunity to play around with the language.


Then I noticed multi-methods and became interested. Method dispatch based on the result of a function applied to the arguments of the method. This is pretty powerful and will probably take a while to get comfortable with. I used the rather simplistic approach of dispatching on the class to do the second exercise again.


This is silly, too. And it works pretty sloppily. The empty list creates an instance of PersistentList$EmptyList which doesn't seem to match PersistenList. But whatever, it's good enough and it got me thinking about multi-methods. There is more on those in this blog post.

And now it's on to day 2, where apparently we see the list comprehensions I was so impressed with in Erlang enter clojure, too.

Excuses, Excuses. Also, Emacs.

My, I've been a bit lazy, I guess. Has it really been that long?

Starting a new job and trying to find a new place to live has taken quite a bit of my time. So it was that during the Prolog week I started to struggle finding the time to do the examples. Then during the Scala week I didn't do much at all other than reading the chapter. But with Erlang I had some more time again and at least managed to do the day 1 and 2 stuff. With Clojure this week I hope to give it even more attention.

For all of it, I neglected writing about it. So to get this rolling again I'll do a quick rundown.

Prolog

Prolog is old and weird. The book compares it to Rain Man, which seems apt. Having never done any work with any logic languages this was very new to me. It was a very big shift in thinking. I appreciated that. It's one of the reasons to work through the book after all.

I think Prolog as a language is not very practical for me. But the chapter provided some really useful basics for understanding the syntax of Erlang and for pattern matching, which shows up in the Scala and Clojure chapters, too.

Scala

Scala was, as mentioned, somewhat neglected by me. Some of the syntax in the examples (especially for the actor stuff) seemed a bit weird to me and I really should actually work through them to get a feel for it. Minor inconsistencies in syntax are probably the main thing bugging me about what I read about Scala so far. And defining your default constructor inside the class definition while still having the option for actual init methods really rubbed me the wrong way.

Still, XML as a first class language construct looks very nice and getting around some of Java's noise is also charming. I reckon we'll cross paths again at some point and I can give it a closer look.

Erlang

Next came Erlang. And that was quite a bit of fun. Having been eased into the syntax by the Prolog chapter helped a great deal. I was quite fascinated by list comprehensions. I'm not sure if their power comes at the cost of maintainability. But it's hard for me to judge that given my lack of experience with the language and syntax.

I didn't even get to play with the actor stuff but I suppose people are happy with it and specifically with the Erlang implementation.

At some point I should really revisit Erlang. It's different enough to challenge the mind to take a new look at old habits. And it looks interesting in general with its focus on concurreny.

Clojure

I'm trying to dig a little deeper this week again. Clojure is interesting to me because for a long time I've wanted to try and make sense of a Lisp language.

In the process of reading up on it I noticed that a lot of people seem to prefer using emacs as an editor for clojure. So I installed that. (As a complete Mac noob let me point out that brew install emacs and brew install emacs --cocoa are two very different things. I have yet to learn why [cf. mac noob] but you probably want the latter.)

I had been using emacs (XEmacs, to be honest) for quite a while as my primary development environment. But that was some 7+ years ago and I never really touched it again. I'm incredibly amused that a lot of the key bindings are coming back to me anyway. And it feels kinda nice. Maybe I will rejoin the battle for the one true editor.

Sidenote: emacs installation notes for anyone who bothers. From someone who has no clue what he's doing:

• brew install leiningen clojure clojure-contrib 
• brew install emacs --cocoa
• git clone https://github.com/technomancy/emacs-starter-kit.git ~/.emacs.d
• alias emacs='/usr/local/Cellar/emacs/23.3/Emacs.app/Contents/MacOS/Emacs -nw'
• lein new someproject
• add :dev-dependencies [[swank-clojure "1.2.1"]] to the (def-project entry in someproject/project.clj
• lein deps
• lein swank
• start emacs in another shell
• (you may or may not need to install some elpa packages for slime and swank and paredit and whatever. See if it works with the just the stuff from the emacs-starter-kit or otherwise ask google. I did get annoying errors doing this and have no idea why it worked in the end. Sorry.)
• M-x slime-connect
• edit e.g. someproject/test/someproject/core.clj
• execute tests with C-c C-,
• you can also do other things with the REPL inside emacs but you best google for that

I hope that can be of help.

Back to the study group...

It seems like most of us have been struggling keeping up with the pace of the book, with everyone taking the odd week off from working through all the examples. But we were lucky that it seems to have mostly been different weeks, so there was always at least one person who could explain more details about a given language. So while I was very lazy there have been a lot of really interesting posts from others in the group.

• aimee on Prolog
• and again on Scala (fuck the pope!)
• Alberto on Erlang (check out the Solution = list comprehension. It's quite impressive)
• Susan with an Erlang follow-up
• More posts here

We've also continued our weekly chats which are always a source of inspiration for me. As of recently we're using the Hangout feature of Google+ and it's really good. Since Skype keeps crashing my little Win7 netbook I'm happy to have found a better replacement.

Tl;dr

It's really nice to see how the chapters of the book build up on each other. I think the book has made me more adventurous to just play around in new languages. It is still nice to have this little virtual study group to help push me along. Technology is still awesome, too (git pushing from a train via tethering to the phone. Magic!) I reinstalled emacs after all those years.

[Insert clever play on the name Io]

And so goes the second week and the second language on our seven week trip. Compared to the first week in Ruby, I struggled a lot more with Io. It's a language with very simple rules which, for me, made the edge cases all that more confusing. I also was a bit preoccupied with other, unrelated issues and so I skimped on a lot of the examples. Thankfully, Alberto did a lot of that work and wrote about it in a series of excellent posts. If you want to know more about Io, you should really read those.

As such, I'm going to keep it short with my own observations. As an abstract, Io is a prototype based OO language where everything is either an object or a message passed to it.

• I was unable to build Io in Windows and I don't know what I would've done if I hadn't found some forum posting with a link to pre-built binaries. 
• I particularly liked the way conditionals were also just messages, apparently just extending the base boolean types
• Yet I don't really understand message precedence and how something like self sum / self size works. self size obviously gets evaluated before being passed to the divide operator, which I didn't expect
• getSlot('foo') code print will print a method definition, similar to Javascript's foo.toString() (where 'foo' is a method/function)
• sadly, that is not usable for the language constructs as they are written in C
• Io has a pretty solid concept of coroutines, actors and futures, much unlike Javascript. Quickly writing some parallel code might indeed be one of the languages strong points

It seems the book deliberately started with Ruby to ease me in and then started to get a bit more challenging with Io to progress to Prolog, which I guess will be quite a bit different from what I'm used to. 

I'm again grateful for our study group. Our little skype conference showed that I wasn't the only one struggling with Io and I'm not sure I would've gotten much out of this chapter if it wasn't for other people's blog posts further explaining things. This isn't really a failure of the book as much as I just wasn't able to commit the time to really dig into the examples.

And now it's on to Prolog, which should get interesting, as I haven't worked with logic languages before. This time, installation is easy, as there is a package in cygwin that provides the 'pl' executable. (And, once again, let me recommend also getting mintty.)

First language done; inspiration had

Continuing on through Seven Languages in Seven Weeks I've finished the chapter on Ruby. I'll quickly list a few more things I've noticed and then do a little initial retrospective.

• I was a bit confused with how method definitions apply to classes v. instances and how module inclusions and extending classes work into that
• Interestingly, I feel reminded of similar troubles I had with understanding Javascript prototypes, functions and new. 
• obj.freeze appears to be a way to dynamically declare variables final. I suppose that could be useful
• you can always pass blocks to functions even without having declared them as arguments
• there is what I'd call reverse varargs that lets you explode arrays to match method arguments using the same notation as varargs, which I quite like. def foo(one, two, *rest) …
  foo(*[1,2], 3, 4, …)
• Having things like .methods on all objects to do reflection for debugging/getting to know the language is really helpful
• if I had worked through this before and added a bit of rspec knowledge I might have been able to contribute a lot more on the occasions I paired on Ruby at code retreats

Code is here. 

So now a little bit about the learning experience. I'm greatly enjoying this so far and I think it comes down to three things.

The book

The book is great for getting you started in a language. As I mentioned on twitter I left with more questions than answers. But I now have a vague idea of where to look to find those answers. It's a really great achievement to pique the interest to go into the details of a language and to not make you feel completely lost doing so. I'm already looking forward to learning about Io.

The group

I'm also really enjoying our little virtual study group. People share their questions, answers or just share their fun in the learning. There's a lot of interesting blog posts already (aggregated here) and also quite a bit of activity on the github network for the project. I find this both liberating and motivating. It's safe ground for exposing your ignorance and at the same time I feel challenged not to slack off and actually keep working on it and do things like writing blog posts. 

The technology

And I love the technology that enables this and the fact that there are people that care enough to take part in this. We live in amazing times! Programming is fun and being able to share that with others makes it even more fun. I love that it's so easy to organize this on twitter more or less on a whim (at least my taking part was on a whim). I love that to get started reading I only needed a few clicks on pragprog (even if the kindle version has its little issues). I love that github lets me see how others solved the problems given in the book, both reassuring me that I did something right or helping me along to find better solutions. And then of course it's great to be able to just download and try out all these languages.

Seven Languages In Seven Weeks

I'm stuck trying to put my thoughts on estimation, conferences and switching jobs into writing. So many unfinished drafts, oh my!

So instead I'm now trying to write the odd post about my experience working through Seven Languages In Seven Weeks.

aimee daniells had the great idea to start an online study group for said book (not gonna type that title again, nu-uh). And since it helps distracting me from worrying about finding a new place to live within the next 3 weeks I gladly took the opportunity to join. (Sidenote: if you're looking for a flatmate in Hamburg please do get in touch.)

The book is very interesting to me because I don't know all that much about any of the languages but have been meaning to take a closer look at Clojure, Ruby and Erlang for some time. It's nice to have something concrete that gets me doing that.

The first language is Ruby. I've worked through days 1 and 2 now and here's a quick summary of what I took away from it.

Ruby has a lot of syntactic sugar. Enough to almost certainly give you diabetes. Parts of me (the old, elitist parts) feel somewhat uncomfortable with that. Other parts of me (the ones trying to get work done in Java) just feel jealous.

There were some more notes I took that I'll just list here without trying to add context (or sense)

• The kindle version of the book doesn't wrap the code examples correctly with larger text sizes. That's pretty annoying. Does no one test these things?
• When googling for the api docs one should be careful that one reads the docs for the correct version of ruby one is using. I spent 10 minutes wondering why str.match(regexp) { block } never executed the block until I figured out that that feature just didn't exist
• String and exec expansion seem to behave pretty much like in bash. Single quote string get left alone, double quote strings get processed and backticks execute native programs. (I hope I'm not misremembering my bash there)
• if and while have counterparts in unless and until. Sugar++
• Sugar++ would not actually work. Sugar += 1 does, however. And I think I like why that is the case
• Numeric zero and empty strings evaluate to true, which i find pretty disgusting
• Running in a windows shell I successfully ran into encoding issues for Umlauts. Probably Windows' fault. I hate character encoding
• Cygwin can install ruby and Umlauts look ok there. Calling the windows ruby executables from inside cygwin, which I tried first, had some really weird issues
• On that note: mintty still rocks
• Enumerable has all the nice sugar you can only get via Google's guava in Java. And with blocks it's a lot better readable
• And you can mix all that into your own classes, with just a bit of duck typing. Very nice
• All that duck typing really makes me long for some grapes
• If I understand it correctly, Hashes can lazily evaluate values from keys which reminded me of the guava MapMaker. Also very nice. 
• Hash.invert seems almost too sugary but could be useful
• Same goes for String.next. Instant tooth decay!
• A File API with permissions and methods to create symlinks? I never dared dream of that (although, wasn't there something in that regard in the works with Java, too? About time anyway)
• IO.readlines/foreach is really handy. Convenient enough to never look at perl again. 
• The automatic closing of files when using blocks is also nice. Kinda like using() in C#, implicitly. (Wasn't there also something like that coming to Java? I can't remember all the things that may or may not go into the language)
• I felt pretty clever doing Array.new(16) {|x| x+1} until I saw (1..16).to_a

Code is here.

All good fun so far.

Ignoring long-term planning and estimating

I got on the agile bandwagon fairly late considering people are now celebrating the 10-year anniversary of the agile manifesto. But it's been a good 2 years now and I feel like it's a good time to sum up some of my experiences. And I'll start by writing something about estimating that's recently been on my mind a lot.

I get the impression that a large part of what people use to sell Scrum to managers is the ability to get better estimates and more reliable long-term planning. That tracking velocity and assigning storypoints to your features somehow enables you to determine what exactly you can release half a year from now. I don't think that's entirely honest. You still have no way to reliably predict accidental complexity; and team fluctuation, shifting priorities and delays in external processes that you depend on will still leave you guessing when you'll have that big new release ready.

The constant feedback obviously helps to at least be able to react to some of these obstacles. A looming deadline works wonders to get stakeholders to prioritize the features they want implemented. But I think all of this is looking at agile development from an old-fashioned angle, that is likely to be more frustrating than necessary.

Those big releases and big new major versions of your products just don't make all that much sense if you're not actually burning your software to disks to be put onto shelves. If you have a new little feature that will help your customers have a better experience using your product why wait to release it? If that feature actually doesn't help your customers, why wait to find out about it?

If you're a long-term agilante (agilista? agilero?), that is probably pretty obvious. But personally, I don't think I really grasped the power of that until recently. Really taking the idea of short iterations with incremental changes to its conclusion is not something I've seen much of in the time I've been developing software. You may read about some of the big poster-child internet companies working that way and increasingly, little start-ups seem to have a lot of success with it. But once companies get to a certain size they seem surprisingly eager to hold back on actually releasing their software.


And, with that said, I have decided that I do not care about estimating any more. I do care about the people on the team, I care about splitting items up into fine-grained tasks [edit: 'features' is probably the better word]. I might even care about tracking time spent on tasks to get feedback on whether we've become stuck on something. I care and take pride in the quality of the code we deliver. I care about people using that software and the feedback they can give. I don't care about dates in the future that may as well be arbitrary.

I conveniently ignore any kind of marketing needs or grand c0mpany strategy. Because, really, why shouldn't I? If we can consistently release new features in a short timeframe and the quality is good, why shouldn't the company strategy adapt to this rather than the other way around?

This idea is fairly fresh in my mind and I'm really looking forward to seeing what it develops into. I'm pretty sure I've missed a few things. And I'm curious what other people think about this...

Edit:
And to aptly prove the motto of this blog, Naresh Jain wrote about this two ears ago. Well worth reading.

Code Retreat - was ist das?

Edit: es hat sich viel getan. Code Retreats finden mittlerweile ziemlich häufig statt. Auf der Seite der Softwerkskammer findet man mehr dazu. Die Veranstaltungen sind immer kostenlos und es lohnt sich auf jeden Fall, mal teil zu nehmen.


Vor kurzem habe ich an einem Code Retreat teilgenommen (Leo gibt für "retreat" u.a. Klausurtagung, was das ganze einigermaßen trifft) und war davon sehr angetan. Ich plane gerade, selbst einen solchen Event zu organisieren und im Zuge dessen lohnt es sich einmal ein paar erklärende Worte auf deutsch zu schreiben.

Ich bediene mich dabei sehr ausgiebig bei dem was Corey Haines und andere schon zu diesem Thema geschrieben haben. Am Ende dieses Artikels verweise ich auch noch auf einige weiterführende englische Seiten.

Was ist das Problem?

Im normalen Arbeitsalltag wird kaum Zeit darauf verwendet, seine Fähigkeiten zu verbessern. Man nimmt vielleicht hier und da an Schulungen teil oder arbeitet sich gegebenenfalls in neue Frameworks ein. Aber wir arbeiten nicht gezielt daran unsere Arbeitsweisen zu verbessern oder unser bestehendes Know-How zu vertiefen.

Und wenn wir dann unter Zeitdruck stehen, fallen wir zurück auf die Techniken, die wir beherrschen, auch wenn wir wissen, dass es bessere Möglichkeiten gibt. Das klassische Beispiel hier sind Software-Tests. Es ist nahe liegend, dass ein Projekt mit hoher Testabdeckung mehr Sicherheit beim hinzufügen von Änderungen bringt. Damit aber sowohl die eigentliche Testabdeckung, als auch das Durchführen von Änderungen mit einem vertretbaren Aufwand erreicht werden können, braucht es einiges an Erfahrung und Übung. Und wenn man diese Erfahrung nicht hat und der nächste wichtige Termin naht, ist es dann doch einfacher, die Tests zu ignorieren und direkt drauf los zu programmieren.

Einige Leute bringen an dieser Stelle auch gerne den Vergleich zu Musikern. Genau wie diese ihre Fingerübungen machen, kann man auch als Entwickler sein Können trainieren. Statt dessen geben wir aber jeden Tag ein Konzert. Das hat natürlich auch seinen Wert und man wird auch nicht vermeiden können sich hier und da zu verbessern. Man kann sich wahrscheinlich auch eine ganze Weile diesem Trott hingeben. Aber irgendwann nimmt einem die Eintönigkeit dann doch die Freude an der Arbeit.

An dieser Stelle kann man auch gleich einen Strich ziehen. Wer mit seinem Können zufrieden ist und sich damit wohlfühlt, sollte wohl nicht weiter lesen. Zufriedenheit ist schwer genug zu erreichen. Lernen sollte freiwillig und aus eigenem Interesse passieren.

Was kann man tun?

Wenn man sich bewusst die Zeit nimmt, gibt es eine Menge Dinge die man tun kann. Eine gute Möglichkeit, die vor kurzem in der GOOS-Mailingliste erwähnt wurde ist, sich gelegentlich einfach mal eine halbe Stunde Zeit zu nehmen, bestehenden Code zu verbessern. Dies sollten wirklich nur kleine Änderungen sein und man sollte sich an seine Zeitvorgabe halten. Ist man nach dieser Zeit nicht mit dem Ergebnis zufrieden, verwirft man seine Änderungen. Da dies ja primär als Weiterbildung zu sehen ist, sollte man gar nicht davon ausgehen wirklich Code zu committen. Und wenn dann doch eine Verbesserung dabei heraus kommt, umso besser!

Mehr und mehr finden sich auch Code Katas im Netz. Hier werden überschaubare Aufgabenstellungen wieder und wieder gelöst, um in ähnlichen Alltagssituationen praktisch reflexartig darauf reagieren zu können. Diese sind sowohl ein guter Weg selber zu üben, als auch interessant anzuschauen. Es gibt eine ganze Reihe von Leuten, die freundlicherweise ihre Lösungen im Netz bereit stellen, zum Teil auch als Screencasts. (http://codingkata.org/ http://www.katacasts.com/ http://codersdojo.org [Link aus dem Kommentar hinzugefügt]) Gerade für Einblicke in neue Programmiersprachen sind konkrete, bekannte Beispiele sehr hilfreich.

Überhaupt ist natürlich die Zusammenarbeit mit anderen wahrscheinlich die beste Möglichkeit, neue Dinge zu lernen.

Darüber hinaus gibt es natürlich auch noch andere Dinge. Unter anderem halt Code Retreats, sonst würde ich ja nicht diesen Artikel schreiben.

Was sind jetzt also Code Retreats?

Code Retreats folgen einigen relativ einfachen Regeln:

• Aufgabenstellung ist Conways Spiel des Lebens
• Mittels pair-programming und, nach Möglichkeit, test-getrieben, versucht man das Spiel zu implementieren
• Das macht man für 45 Minuten. Danach wirft man den geschriebenen Code weg. Keine Backups, kein committen in ein Repository. Einfach nur löschen
• Man nimmt sich ein paar Minuten Zeit, um in der Gruppe darüber zu reden, was man gelernt hat
• Man fängt wieder von vorne an (6-7 mal)

Da es eigentlich nicht möglich ist, innerhalb von 45 Minuten fertig zu werden, braucht man gar nicht erst zu versuchen, Abkürzungen zu nehmen und kann sich nur darauf konzentrieren, "perfekten" Code zu schreiben. Es macht auch nichts, für einen Durchlauf eine komplett neue Herangehensweise auszuprobieren (z.B. keine else-Blöcke, keine primitives, nur Funktionen/keine Objekte, keine Methoden mit mehr als zwei Zeilen, ...). Egal was man probiert, man riskiert im Durchschnitt nur 22,5 Minuten.

Es geht ganz klar nicht darum, die Aufgabenstellung zu lösen, sondern auszuprobieren, wie man anders an die Aufgabenstellung heran gehen kann. Insbesondere eignet sich das Format auch gerade dazu test-getriebenes Entwickeln zu üben.

Für mich war außerdem auch sehr interessant zu sehen, dass der entstandene Code nur einen Teil des Produkts der 45 Minuten ausmachte. Das entstandene Wissen über die konkrete Problemstellung brachte jeden neuen Durchgang deutlich näher an das Ziel als den Vorherigen.

Weiterführendes

• http://coderetreat.com/how-it-works.html Eine kurze Beschreibung des Ablaufs eines Code Retreats
• http://programmingtour.blogspot.com/2011/01/on-goals-of-coderetreat.html Ein etwas weiterführender Beitrag zu den Zielen. Enthält auch ein Video mit der Einleitung, die Corey Haines zu Beginn eines Code Retreats vorträgt
• http://www.infoq.com/presentations/Software-Craftsmanship-Beyond-The-Hype Die Präsentation von der QCon 2010, durch die ich auf das Thema gekommen bin
• http://vanryswyckjan.blogspot.com/2010/11/code-retreat-ghent.html ein Erfahrungsbericht
• http://financialagile.com/reflections/8-software/38-coreys-code-retreat und noch einer

Remember back then?

...back in 2010? That was a nice year. I have to say I'm pretty happy with how it turned out. There were some setbacks, first and foremost the departure of two colleagues whose knowledge and support I valued very highly, who left for new cities and new challenges. But such is life. But I learned a lot this year and got to make a lot of interesting experiences and meet a lot of interesting people.

It was a long year and this will be a long post. It will be self-indulgent and most likely only for my own benefit. So there.

First off, I finally took the time to finish reading Domain Driven Design, or "the great blue book in the sky" as I heard someone (probably Neil Robbins) call it. It was very timely as we were just in the process of redoing a fairly large part of our application. It gave me the confidence to split up the refactoring along the life cycle of our main entity, transforming it along the way. That way we were able to concentrate on the first step in the life cycle without having to change everything down the line, too.

Said refactoring was also the first time I remember of deliberately doing "refactoring toward deeper insight". The experience of taking what we had learned about the domain in the previous year and applying that to our domain model was surprisingly rewarding. The end result was a lot simpler and closer to how people actually worked. It gave us the opportunity to introduce new functionality that would otherwise have been extremely cumbersome to implement.

The whole process was not without its flaws though. We underestimated the amount of code we had to change, even with the reduced scope. Especially the front-end proved that good UI design is very hard and time-consuming. In hindsight we probably should have spent more time on considering how the changes might have been divided further into smaller, releasable pieces. In the end we were left with a long time between deployments and suffered all the communication issues that missing regular feedback loops can give you. It was still a good learning experience and it showed me how much I appreciated our previous, shorter deployment iterations.

In march I went to QCon, which I wrote about before. The inspiration I got turned out to have a fairly lasting effect. To get back to the kind of enthusiasm I had when I started out and to be able to really consciously enjoy coding again is something I am extremely grateful for. This wasn't necessarily all due to QCon but it encouraged me to be more introspective about how I work. In particular it had me putting more effort into getting better at TDD. At some point the whole "using tests to drive out the design" bit finally clicked and it made me a happier person.

There is still a lot left to improve though. Most of our bug-fixing work is now purely front-end stuff, ironing out layouting issues and Javascript behaviour across different browsers. But we're getting there. Writing jasmine tests is something I'll hopefully get better at and which integrates well enough into our builds. My colleague Benjamin put an amazing amount of work into getting a useful Selenium tool-set and tests for us. The environment for these is sadly still somewhat brittle but hopefully that will get better with Selenium 2.

We've made a lot of progress in automation anyway. Our test-environment gets automatically redeployed by Teamcity now. These are still very tiny baby-steps towards continuous delivery that conveniently ignore some of the larger issues like schema evolution and the need to switch to a DVCS but at least I think it's stumbling in the right direction.

I was also happy I got to help in making collaboration with our designers on different teams a little easier. Working on a bunch of projects in parallel while trying to consolidate on a consistent look & feel is something that has taken even more effort than I expected. And since look & feel is usually the most immediately apparent contact point for stakeholders, it is always under scrutiny. I underestimated that, too, even though I really should know better. All the more reason to push for further front-end test automation.

Later in the year our team worked on a new project and decided to base it on JSF 2, mostly so we could get the know-how. The other teams were already using it and it seemed reasonable to look for common ground there. I did learn a lot, but I didn't get much done. Having no one on the team with any prior experience meant we had to go through all the little beginners mistakes you get when you stumble into some new technology. Some of those early issues just rubbed me the wrong way which made me get increasingly frustrated. And I'm afraid my growing resentment probably didn't help the mood of the team.

This did bring up a few interesting questions about the effectiveness of aiming for a heterogeneous development environment. Questions which I don't really have answers for but still could ramble on about for hours. So I should probably put that in another post some day.

In November I was lucky enough to take part in a Code Retreat. Having been intrigued by that ever since I saw Corey Haines talk about it at QCon, I jumped at the chance to try it out. This, too, is worthy of its own post and so I won't go into details here. Suffice it to say that I liked it a lot and plan to organize a code retreat in Düsseldorf, to show it to more people.

(As an aside, I just stumbled over a google result for a code retreat in Wroclaw which brought a smile to my face. I always enjoyed my time there, when I visited there for another company, back in another time. And I always had a very high opinion of the people and their programming skills there. So, I guess this fits quite well.)

After Code Retreat Ghent came Google Developer Day Munich. It was nice to meet my now ex-colleague Sebastian again. And same as in Ghent, I was glad for the opportunity to chit-chat with other people in our profession. It never hurts putting things in perspective and hearing what others are passionate about. And of course, rambling about things I'm passionate about. (Something I find myself doing more of these days, I think. But maybe it was just the free beer provided by Google.)

The effort Google puts into these events was impressive and I really liked how non-partisan the speakers were. They openly acknowledged the existence of competitors (foremost Apple) without looking to discredit or awkwardly ignore their work.

I wasn't looking for anything in particular since my work currently targets neither HTML 5-capable browsers nor mobile phones, but at the end of the day I felt more sad about that fact. I wasn't aware how exciting some of the HTML 5 stuff is and I'm really looking forward to that becoming the norm and what people will be able to do with it.

Well, that about does it for two-oh-one-oh. Remaining, then, is the goals I've set myself for 2011 (I'm not yet convinced of spelling it 20!!).

• Organize a code retreat, possibly making it a recurring event
• Look for more of these opportunities to learn from others
• Subversion is a nightmare to merge stuff with and I'm eager to switch to git but it would mean having to get used to a different workflow for everyone in the team. Maybe I'll start with a git kata.
• Follow through on all the "I should really write a blog post about that"
• Write more posts in german. 
• Read GOOS, finish reading REST in Practice, glance over Continuous Delivery.
• Try to solve more problems event-driven

Hmm... last and possibly least I just realized that I also started writing on this blog (and on twitter) this year. I guess I'll keep that up.