LHOTSE is the internal code name for our project to re-develop www.otto.de: in-house, based on open source software and using agile methodologies such as Scrum and XP. LHOTSE went live on 24th October 2013 – three months before schedule. Although it took us roughly two years to develop, with a team of more than 100 experts, getting LHOTSE live was practically a „non-event“. So, why did everything work out so well?

Seit einigen Jahren mischen Smartphones und Tablets den klassischen PC-Markt auf. Immer mehr Menschen gehen mit ihren mobilen Geräten ins Internet. Diesem Trend versucht OTTO mit diversen geräteoptimierten Shops sowie hybriden Apps gerecht zu werden. Daraus resultiert eine nicht zu unterschätzende Design-, Code- und damit auch Feature-Fragmentierung.

Seit 2010 gibt es aber auch einen anderen Ansatz, um auf die Multi-Device Problematik einzugehen, und zwar Responsive Webdesign. Zum ersten Mal wurde der Begriff von Ethan Marcotte in einem Artikel für das Magazin A List Apart verwendet. Er beschreibt ihn dort wie folgt:

„Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design.“

Aus technischer Sicht bedeutet das ganz konkret: Eine einzige HTML Struktur mit dazugehörigem CSS für alle Endgeräte, also keine Fragmentierung mehr. Besonders interessant wird Responsive Webdesign unter dem Gesichtspunkt, dass die Grenzen zwischen den Geräten zunehmend verschwimmen.

Fast feedback is a cornerstone of agile software development. When developing the LHOTSE project at Otto, we tried to be as agile as possible and many of our means and methods revolve around fast feedback. Here is a list of my favourite things we do to foster fast feedback. It does not at all cover everything we do in our daily work, let alone everything one possibly could do.

All methods have one thing in common: They try to let the development team know as early as possible when things are going into the wrong direction. The key hypothesis is: The sooner you recognize a mistake, the easier it is to fix it. If you introduce a bug in the software, it is easiest to fix it right away, when you still know what you where doing and when you can associate the bug with the small change you just did. When you learn about a bug later, you first have to identify the change that introduced it, then try to remember the intentions of that change. When adjusting the change, you have to be careful not to break anything that was built on top of it later.

The term Commitment was removed from The Scrum Guide (pdf) and replaced by the term Forecast back in 2011. Here is my rant against the concept of commitment as it is still used by many otherwise agile teams. If you don’t do scrum, but any other development method that ties a fixed set of development tasks to an iteration, then this article is also for you. You must not mistake ceremonial commitment with the commitment of individuals and teams to deliver excellent work. We all agree the latter is a great and desirable thing. In this article I am only talking about the former.

Sprint commitment means, that a team of software developers have to commit to finishing a fixed number of stories in the next iteration. I guess the hope often is, that due to the pressure created by such a commitment more stories are developed per time unit. I also heard the reasoning commitment would improve planability of a development project or that it increases the motivation of developers. I think that is all wrong.

Beim Pair Programming sitzt man also mit einem Paar (gewöhnlich 2) Programmierern an einem Rechner und bearbeitet den gleichen Code. Und das soll sinnvoll sein? … Wir Programmierer im Shopoffice-Team finden: Jawohl! Wir schreiben besseren Code, produzieren weniger Bugs, sind konzentrierter bei der Arbeit und am allerwichtigsten: Wir haben mehr Spaß bei der Arbeit. Klar verwenden wir Pair Programming hier im Team schon sehr ausgiebig – aber es gibt immer etwas zu verbessern. Warum also nicht mal jemanden ins Team holen, der über mehr Praxis in diesem Bereich verfügt und Erfahrungen mit Pairing in verschiedenen Projekten gemacht hat? Wir haben uns für Thomas Much entschieden, der uns für einen Sprint lang bei der Arbeit begleiten sollte. Thomas war als Java- und Pair Programming-Coach schon in zahlreichen Projekten unterwegs und genau davon wollten wir profitieren.

In vielen Projekten erfolgt die Entwicklung von neuen Features in dem einen oder anderen Branching Modell wie zum Beispiel Git Flow: Features werden zunächst auf einem separaten Branch entwickelt und erst nach „Fertigstellung“ des Features wieder integriert. Beim Mergen der Änderungen kommt es dann gelegentlich zu Konflikten und wenn man Pech hat, landet man in der „Merging Hell“. Moderne VCS wie GIT machen Branching + Merging zwar deutlich einfacher, ändern aber auch nichts daran, dass es gelegentlich schwierig ist, konkurrierende Änderungen zu einem lauffähigen Deployment zu integrieren.

Das Hauptproblem mit Feature Branches ist aber ein anderes: Wann ist ein Feature „fertig“, kann also integriert werden? Erfolgt die Abnahme einer Story auf Basis des Feature Branches, muss nach der Integration eine weitere Qualitätssicherung erfolgen – denn sonst könnten sich Fehler in der Kombination mit parallel entwickelten Features einschleichen. Erfolgt die Qualitätssicherung erst nach der Integration auf einem Release Branch, könnte sich herausstellen, dass das Feature eben doch nicht fertig ist, weil die eine oder andere Anforderung nicht erfüllt ist.

Continuous Integration verfolgt daher einen anderen Weg: die Entwicklung erfolgt auf dem HEAD und jeder Commit wird direkt automatisiert integriert. Jenkins, TeamCity oder andere Tools helfen dabei, regelmässig alle paar Minuten einen aktuellen Build zu erstellen und auf einen CI Server zu deployen. Die Abnahme der Feature erfolgt entweder auf dem CI Server oder einer separaten Stage der Build Pipeline.

Eines der Ziele, die wir uns für die Lhotse Plattform gesetzt haben ist Continous Delivery: Änderungen sollen nicht nur kontinuierlich integriert, sondern auch rasch in Produktion genommen werden, sobald die Abnahme erfolgt ist. Wie wir das in der Praxis erreichen wollen, ist ein anderes Thema. Damit wir aber prinzipiell in der Lage sind, jederzeit eine neue Version live zu stellen, muss das System in der Lage sein, ohne Unterbrechung auf ein neues Release umzuschalten.

The easiest way to crash your site.

With all the latest trends in the web such as “Social Sharing”, “Distributed marketing campaigns” or just simple website trackings, people tend to forget about one tiny simple fact:

Dependency on 3rd party vendors stability.

If your website is your sales channel or even your only product you must have the ambition to keep it running and fully functional 24/7 and with 99,99% uptime per year.

Auf unserem letzten Barcamp habe ich eine halbstündige Session „Pair-Programming for Non-Developers“ gehalten.

Warum das, …also, warum „for Non-Developers“?

Wir setzen hier bei Otto Pair Programming in der Softwareentwicklung ein und ich werde immer mal wieder gefragt warum wir das tun – vor allem auch von Nicht-Entwicklern. Deswegen habe ich mir eine Session überlegt, in der ich Pair Programming für Menschen fühlbar und erlebbar mache, die nicht aus der Softwareentwicklung stammen.