Mastery comes from failure

In software development, and many other disciplines, people strive for mastery – you want to get better to be great something. For some reason failure is often seen as the opposite of mastery – after all masters don’t fail – or do they?

We often see talks and read great blog posts about all these great achievements of amazing people but almost never about major failures. But, how are failures important and useful? Well, let me tell you a little story from back when I was teaching an introductory web development course:

We were in the practice stage and I was doing my usual rounds looking at what the students did and helped them to resolve their problems. After glancing at a screen and saying that the problem could be resolved by running the migrations the student looked at me with disbelief and said:

Tobi, how can you just look at the screen and see what’s wrong in the matter of seconds? I’ve been trying to fix this for almost 15 minutes!

My reply was simple:

I’ve  probably made the same mistake a thousand times – I learned to recognize it.

And that’s what this post is about and where a lot of mastery comes from in my mind – from failure. We learn as we fail. What is one of the biggest differences between a novice and a master? Well, quite simply the master has failed many more times than the novice has ever tried. Through these failures the now master learned and achieved a great level of expertise – but you don’t see these past failures now. This is shown quite nicely in this excellent web-comic:

“Be Friends with Failure” taken (with permission) from doodlealley. It focuses on art, but I believe it applies to programming just as much and I recommend reading the whole comic  🙂

For this to work properly we can’t program/work by coincidence though – when something goes wrong we must take the right measurements to determine why it failed and what we could do better the next time around. Post-mortems are relatively popular for bigger failures, in a post-mortem you identify the root cause of a problem, show how it lead to the observed misbehavior of the system and ideally identify steps to prevent such faults in the future. For service providers they are often even shared publicly.

I think we should always do our own little “post-mortems” – there doesn’t have to be a big service outage, data leak or whatever. Why did this ticket take longer than expected? Which assumptions we had were wrong? Could we change anything in our process to identify potential problems earlier on in the future? This interaction with my co-worker didn’t go as well as it could have been, how could we communicate better and more effectively? This piece of code is hard to deal with – what makes it hard to deal with, how could it be made easier?

Of course, we can’t only learn from our own failures (although those tend to work best!) but from mistakes of others as well – as we observe their situation and the impact it had and see what could have been done better, what they learned from it and what we can ultimately learn from it.

Therein lies the crux though – people are often afraid to share their failings. When nobody shares their failures – how are we supposed to learn? Often it seems that admitting to failure is a “sign of weakness” that you are not good enough and you’d rather be silent about it. Maybe you tell your closes friends about it, but no one else should know that YOU made a mistake! Deplorable!

I think we should rather be more open about it, share failures, share learnings and get better as a group.

This was signified for me as a couple of years back a friend asked me if it was ok to give a talk (I organize a local user group) about some mistakes made in a recent project. I thought it was a great idea to share these mistakes along with some learnings with everyone else. My friend seemed concerned what the others might think, after all it is not common to share stories like this. We had the talk at a meetup and it was a great success, it made me wonder though – how many people are out there that have great stories of failures and learnings to share but decide not to share them?

I’ve heard whispers of some few meetups (or even conferences?!) that focus on failure stories but they don’t seem to have reached the mainstream. I’d love to hear more failure stories! Tried Microservices/GraphQL/Elm/Elixir/Docker/React/HypeXY in your project and it all blew up? Tell me about it! Your Rails monolith basically exploded? Tell me more! You had an hour long outage due to a simple problem a linter could have detected? You have my attention!

What I’m saying is: Please go ahead and share your failures! Sharing them you learn more about them as you need to articulate and analyze, everyone else benefits, learns something and might have some input. Last but not least people see that mistakes happen, it demystifies this image we have of these great people who never make a mistake and who just always were great and instead shows us where they are coming from and what’s still happening to them.

My Failures + Lessons learned

Of course a blog post like this would feel empty, hollow and wrong without sharing a couple of my own failures or some that I observed and that shaped me. These are not detailed post-mortems but rather short bullet points of a failure/mistake and what I learned from it. Of course, these sound general but are also ultimately situational and more nuanced than this but are kept like this in favor of brevity – so please keep that in mind.

  • Reading a whole Ruby book from start to finish without doing any exercise taught me that this won’t teach me a programming language and that I can’t even write a basic program afterwards so I really should listen to the author and do the exercises
  • Trying to send a secret encryption key as a parameter through GET while working under pressure taught me that this is a bad idea (parameter is in the URL —> URL is not encrypted –> security FAIL) , that working under pressure indeed makes me worse and that I’d never miss a code review again, as this was thankfully caught during our code review
  • Finally diving into meta programming after regarding the topic as too magic for too long, I learned that I can learn almost anything and getting into it is mostly faster than I think – it’s the fear of it that keeps you away for too long
  • Overusing meta programming taught me that I should seek the simplest workable solution first and only reach for meta programming as a last resort as it is easy to build a harder to maintain and understand than necessary code base – sometimes it’s even better to have some duplication than that meta programming
  • Overusing meta programming also taught me about the negative performance implications especially if methods are called often
  • Being lied to in an interview taught me not to ask “Do you do TDD?” but rather “How do you work?”
  • Doing too much in my free time taught me that I should say “No” some times and that a “No” can be a “Yes” to yourself
  • Working on a huge Rails application taught me the dangers of fat models and all their validations, callbacks etc.
  • Letting a client push in more features late in the process of a feature taught me the value of splitting up tickets, finishing smaller work packages and again decisively saying “No!”
  • Feeling very uncomfortable in situations and not speaking up because I thought I was the only one affected taught me that when this is the case, chances are I’m mostly not the only one and others are affected way more so I should speak up
  • Having a Code of Conduct violation at one of my meetups showed me that I should pro actively inform all speakers about the CoC weeks before the talks in our communication and not just have it on the meetup page
  • Blindly sticking to practices and failing with it taught me to always keep an open mind and question what I’m doing and why I’m doing it
  • Doing two talks in the same week (while being wobbly unprepared for the second) taught me that when I do that again none of them can be original
  • Working in a project started with micro services and an inexperienced team showed me the overhead involved and how wrongly sliced services can be worse than any monolith
  • Building my first bigger project (in university, thankfully) in a team and completely messing it up at first showed me the value of design patterns
  • Skipping acceptance testing in a (university) project and then having the live demo error out on something we could have only caught in acceptance/end-to-end testing showed me how important those tests really are
  • Writing too many acceptance/end-to-end tests clarified  to me how tests should really be written on the right level of the testing pyramid in order to save test execution time, test writing time and test refactoring time
  • Seeing how I get less effective when panic strikes during production problems and how panic spreads to the rest of the team highlighted the importance of staying calm and collected especially during urgent problems
  • Also during urgent problems it is especially important to delegate and trust my co-workers, no single person can handle and fix all that – it’s a team effort
  • Accidentally breaking a crucial algorithm in edge cases (while fixing another bug) made me really appreciate our internal and external fallbacks/other algorithms and options so that the system was still operational
  • Working with overly (performance) optimized code showed me that premature optimization truly is the root of all evil, and the enemy of readability – measure and monitor where those performance bottle necks and hot spots are and only then go ahead and look for performance improvements there!
  • Using only variable names like a, b, c, d (wayyy back when I started programming) and then not being able to understand how my program worked a week later and having to completely rewrite it (couple of days before the hand in of the competition…) forever engraved the importance of readable and understandable names into my brain
  • Giving a talk that had a lot of information that I found interesting but ultimately wasn’t crucial for the understanding of the main topic taught me to cut down on additional content and streamline the experience towards the learning goals of the presentation
  • Working in a team where people yelled at each other taught me that I don’t want to deal with behavior like this and that intervention is hard – often it’s best to leave the room and let the situation cool down
  • Being in many different situations failing to act in a good way taught me that every situation is unique and that you can’t always act based on your previous experience or advice
  • Trying to contribute to an open source project for the first time and never hearing back from the maintainers and ultimately having my patch rejected half a year after I asked if this was cool to work on showed me the value of timely clear communication especially to support open source newcomers and keep their spirits high
  • Just recently I failed at creating a proper API for my Elixir benchmarking library, used a map for configuration and passed it in as an optional first argument (ouch!) and the main data structure was a list of two-tuples instead of a map as the second argument – gladly fixed in the latest release
  • probably a thousand more but that I can’t think of right now 😉


“Be Friends with Failure” taken (with permission) from doodlealley.

We can also look at this from another angle – when we’re not failing then we’re probably doing things that we’re already good at and not something new where we’re learning and growing. There’s nothing wrong with doing something you’re good – but when you venture out to learn something new failure is part of the game, at least in the small.

I guess what I’m saying is – look at failures as an opportunity to improve. For you, your team, your friends and potential listeners. Analyze them. What could have prevented this? How could this have been handled better? Could the impact have been smaller? I mean this in the small (“I’ve been trying to fix this for the past hour, but the fault was over here in this other file”), in the big (“Damn, we just leaked customer secrets”) and everywhere in between.

We all make mistakes. Yes, even our idols – we sadly don’t talk about them as much. What’s important in my opinion is not that we made a mistake, but how we handle it and how we learn from it. I’d like us to be more open about it and share these stories so that others can avoid falling into the same trap.

Slides: I love Programming

Here are the slides from the lightning talk I gave at a RailsGirls Berlin event on Saturday. It’s basically a lightning talk version of my blog post “I love Software Development, because it’s very collaborative and communicative”.

As such it is about how the view the general public seems to have about programmers/software developers is actually pretty wrong as we actually communicate and collaborate a lot.

Enjoy – and thanks everyone again for the great event this Saturday! And of course to everyone laughing and smiling, that makes presenting so much more fun 😀


I love Software Development, because it’s very collaborative and communicative

I often have the feeling that programming and software development is largely misunderstood. Many people seem to still have ancient believes about how software development works. Believes potentially scaring them away from pursuing a career in software development. Let’s fix this.

In this blog post I’ll show why the mental image of one person sitting in a cellar all by him-/herself is as wrong as it can be. I’ll explain why I believe that the most important ability of a software developer is his/her ability to communicate.  And I’ll highlight why I enjoy software development so much. (hint: there are also slides about this)

The typical misunderstanding

Let me take you through a somewhat normal conversation for me with strangers at a party:

A rather typical conversation at a party.
(Note for clarity: the depicted conversation wasn’t about this and those people are actually dear friends of mine, not strangers)

Bingo! You’ve just won yourself a speech of how that is basically the opposite of what I do. My work is filled with lots and lots of communication. Let me walk you through some of the most important and most frequent communication activities in Software Development.

Communication within the team

Team Spirit, December 2006
Team Spirit, December 2006 (Photo credit: JF Schmitz)

Most software isn’t built by a single developer. It’s developed by a team or even multiple teams. I mean does anyone really believe that a single nerd in a cellar builds Facebook and another one builds Windows?

This software is built by large collaborative teams. In a team you have to work together to achieve something.The parts developed by members of the team have to interact and play nice with each other. To Facilitate this the authors have to communicate. As software often solves complex problems, these systems also have to be carefully designed. This is best done in a group of people in front of a whiteboard – not in front of a monitor.

Modern software development actually focuses a lot on the team developing software and how they work together. Let’s take a look at the Manifesto for Agile Software Development, the foundation of most modern software development processes. It values:

Individuals and interactions over processes and tools

This is the very first point made highlighting that good software development is about people and how they work together. It’s not only communicating about the project, solving difficult problems together – of course the normal small talk and “grab a drink together after work” is included as well 😉 Motivation is very important.

It doesn’t stop here though. Often software projects are big enough that multiple teams have to collaborate to realize them. There is a lot of communication going on there as well. But there are still other people developers should communicate with like the system administrators and the customers. Wait, what – the customers?

Communication with the customers

Yep the customer. The ones ultimately using the applications. Or the client wanting the application.

Unfortunately that thought might seem alienating at first, but think about it. Those are the people who ultimately know what the application should do. They are the ones that will be using it, it should fit their purposes. The only way to know if the application reaches its highest goal, satisfying the customer, is through frequent communication and thereby feedback. That starts with asking them what the application should do and how it will be used. It doesn’t stop there though, it is enhanced through demos of a prototype of the application to verify understanding.

Some people take this even one step further. In one of the all time classic books about programming, The Pragmatic Programmer, it is recommended that you spend as much as one week working with the your users before writing an application. This way you should get to know what their work is like.

All of this generates invaluable insights and builds trust.

Look, there are two of them in front of just one monitor!

A friend and me doing some Pair Programming

Yep that’s two developers in front of just one monitor. Actually it’s me and a good friend of mine. So what do we do? Well naturally we are working. We are doing Pair Programming. That is one of us is actually writing the code while the other one observers. We both design the code and talk about it. We work together.

Some people think that this is a waste of time. Hell those are 2 programmers, give them 2 PCs so they can write twice as much code!

It’s not as simple as that. In software development we constantly solve problems. Solving them together leads to a solution sooner, higher quality code and more knowledge spread across the team. The benefits of Pair Programming are worthy of a whole blog post of their own.

Despite the benefits Pair Programming is still a pretty debated topic. Some people despise it. Some people only apply it to difficult problems. Some people say that all production code must be written in Pair Programming.

For me I love Pair Programming: It makes programming a lot more enjoyable, at least to me. When you try to solve a complex problem sometimes you hit the wall. You just don’t know how to solve this problem. You’ve run out of options. It can be really frustrating. That never happens to me when I’m Pair Programming. We, as a team, never seem to run out of ideas on how to solve a given problem until we find one that works. On top of that I can communicate and collaborate with someone all the time. How much more awesome can it get?

And what’s my point with this? During a good normal work day, I actually communicate and collaborate with at least one person almost all the time. Sweet.

Communicating through code

Now I really gotta be kidding right? What does code have to do with communication?

A lot actually. Let’s see what Kent Beck says in his book “Smalltalk Best Practice Patterns” in the Introduction chapter:

“(…) when you program, you have to think about how someone will read your code, not just how a computer will interpret it.”

Kent Beck

And that someone refers to the people in your team as well as yourself. As a team you work together meaning that you have to be able to understand and extend the work of your colleagues. And of course you must be able to understand what you wrote some months ago or even just some weeks ago. You might be surprised how difficult this can get with poorly written code.

Good code must communicate well. The best code, in my eyes, is the code that is the easiest to understand. Code that pretty much speaks to its readers. Writing such code can be very challenging. You can find me discussing with my Pair Programming partner about naming questions for like 2 minutes – it is important.

(Taken from OSNews)

Does everyone work like that?

Not every company empowers their teams. Not everyone loves pair programming. Not every company cherishes communication. Not every company works Agile. There are people out there still following the Waterfall process, which has been a misunderstanding from the beginning, where at first rigorous documents are made and then the programmers are locked away to “just code it”. Why do people keep doing this? I have no idea. I just know that there are enough tech companies looking for developers out there so you don’t have to end up at an old-school command & control enterprise.

So with all this talk about communication one might ask: “What about the introverts? What about people who don’t like to talk as much?”

Well I’ve worked with some people who might qualify as introverts. Let me tell you this: I’d love to work with each and every one of them again.

See communication is not a one-way street. It’s not just about talking, it’s at least as much about listening. People who just talk but don’t listen are bad communicators. Maybe more introverted people don’t talk as much. However with the ones I know I found that if they say something it is of immense value. And they are very good listeners as well. Plus they enjoyed Pair Programming as much as I did. I would say they are good communicators and collaborators. To me bad communicators and collaborators are those that don’t work together with the team and spend most of their time simply criticizing others.

Wrapping up

Look we got post-its too! (Thanks for the photo to Andreas!)

So what’s the lesson here? Well today’s Software Development is a lot different from what many people think it is. You work together as a team. You talk. You draw on white boards. You have those funny little post-its to coordinate work. Some people work together all day long. You have fun. You actually communicate with he people using your product.

As I hinted at first all this makes me believe that the ability of developer to communicate is more important than his/her technical ability. Developers are part of a team. If they excel technically but don’t know how to share their expertise with the team then they’re not helping much. Even worse, people who spend meetings just criticizing ideas can easily kill the motivation of a team and slow them down significantly. Luckily I haven’t met many of them.

Good communicators and collaborators on the other hand do everything for the team. They help and motivate each other. They happily share their knowledge and are always ready to learn new things.

So my point is this: Do you like solving problems? Do you like to work in a team? Would you like to work in a continuously evolving field with lots of new technologies and opportunities? Do you like to build something awesome helping many people?

Congratulations, software development might be just the thing for you!

3D Planning Poker

This post introduces a technique, which we have labeled “3D Planning Poker”. It is aimed at helping agile teams with their user story estimations. It was invented by Jannik Streek, who is coauthoring this post together with me. At first we have a look at estimations, mentioning our perceived short comings of Planning Poker and then we introduce our suggested technique.

Estimations and (normal) Planning Poker

Estimation of user stories is an important task when developing software. It is especially well known and practiced in agile software development processes. Teams rely heavily on estimations during their iteration or sprint planning meeting in order to commit to a reasonable amount of work during the next sprint/iteration. Obviously false estimations can be a huge problem. Therefore good estimations are desirable.

Due to this reason a couple of methods were invented, most prominently Planning Poker. Planning Poker provides an easy estimation method which gets everyone involved. Moreover you get the unbiased estimation of every team member since no one knows what the others will estimate when they show their own estimations. However in our minds it suffers from a couple of problems:

  • Quietness: if you have people in your team who are not that extrovert, you will probably have the problem that they will not be that active in your discussions.
  • Late feedback cycles: You will only get adjusted estimations after a re-estimations round which also takes time. Often it would be beneficial to get more direct feedback.
  • Tiredness: Usually estimation is kind of a boring process: Sitting around and estimating can be time-consuming and dull. Thereby tiring the whole team. Moving around the room can be done during breaks, but maybe it would be even better to include that in the estimation process?
  • Slow to get the big picture: At first you have to look at every card of your team members in order to recognize what the team estimated overall. Cards have to be shown around because not everybody can see them (the card of your neighbor is hard to see, for instance). It takes some time before you know what everyone estimated.

Introducing 3D Planning Poker

We want to introduce 3D Planning Poker in order to address these short comings. It’s a technique / process which was actually developed during a course in Software Engineering at the Hasso Plattner Institute. The basic idea is to have an estimation method with “live” feedback and movement to don’t get tired during the estimation. At the same time we experienced that even rather introverted people get more motivated and active.

The technique works like this: In your room you put your usual estimation numbers (for instance: 1, 2, 3, 4, 5) up as big numbers on the walls. Make sure that the numbers are in order. At first a user story is discussed, as usual. But then when you are actually estimating everyone should just move to the number on the wall matching his/her personal estimation. Everyone should move at once so people don’t get biased when they see where everyone else already stands or in which direction co-workers are heading. When everybody arrives at “their” estimation number you can easily see where most people stand and how far apart people stand. That gives you a nice visualization of the estimates and thereby an immediate impression of the current “estimation situation”. The people with the biggest difference in their estimation also have the biggest (room) distance between them. Just like with normal Planning Poker the people with the most diverging estimations should explain to each other why they estimated the way they did.
A really cool thing about this technique is the live feedback. People are allowed to move to new estimation numbers during a discussion, which gives you immediate feedback. Plus: there is no need for a re-estimation as the team estimation changes dynamically. In our meetings it was the norm that during the discussion people got convinced by an argument or simply noticed that they misunderstood the story, so they moved into one direction or the other. Sometimes even one of the people discussing would get totally convinced and moved to the spot of the other disputant.

3D Planning Poker in action
That’s what 3D Planning Poker looks like.

The only concern regarding this method is that people might be influenced by others, because they see them walking to an estimation. So Charlie could always try to follow Steve to his estimation. But this bias is observable, as the team can notice when someone always follows other people or always stands next to specific persons. You lose the total unbiasedness of Planning Poker but you get some more movement, live feedback and possibly more engagement.

In order to achieve the best results you should have a team in which everybody trusts each other and actually has the courage to choose a number by him- or herself. That’s why we believe that this technique might be unsuitable for freshly formed teams. However we encourage you to try it with more mature teams especially if you notice that planning meetings are becoming a “boring routine”, which they should not be.

What do you think about 3D Planning Poker?

We shared this idea with some people at the XP 2012 conference and got very positive feedback, which actually motivated this blog post.
What are you thinking? Please share your opinions, ideas and/or concerns with us! Do you have other kinds of techniques or processes in your team for estimation that you would like to share? Did you try 3D Planning Poker and would like to share your experiences? Please comment!


Jannik & Tobias

Teaching Agile

graduation hat

I’ve been at the XP 2012 conference and I had a great time and a lot of interesting conversations. One topic that particularly intrigued me is how we can teach agile software development at universities. There are, to my knowledge, quite some universities that don’t teach agile software development at all or do it very badly.

I attended a good talk by Mark Lainez. He, and some of his colleagues, use their spare time in order to give presentations and hold workshops about agile at Belgian universities. This is super awesome. They do this because they saw a lack of “Agile” education at universities in Belgium. However this is not only a problem in Belgium. It is much more widespread than that.

This post is mainly aimed at people like Mark and lecturers at universities, who want to introduce “Agile” to universities. I’m lucky to be at a, in my eyes, particularly good university. As I’m a student myself I’d like to share my thoughts on what worked for me, what didn’t work and what might work when learning about agile software development.

Theory is good – but people need practice

Let me tell you something about my studies at the Hasso Plattner Institute: We learn about design patterns in our third bachelor semester! Awesome right? The bad part: Few students care at first. You need a big project in order to understand the benefit of design patterns.

It’s the same thing with teaching agile, people need to work on something real in order to realize the benefits. People need to practice pair programming in order to see how much it improves their code, their skills and their productivity. I was very skeptical about pair programming at first. However I had a key moment with pair programming. I noticed that I hardly got stuck anymore on hard problems whilst pair programming. When I run out of ideas to solve a difficult problem my partner usually has a good idea to solve the problem. If that does not work then we can discuss and come up with a new approach. You have to experience this in order to really appreciate its value.

However it’s really hard for external speakers to arrange a course with the development of a whole project at a university. Therefore I recommend, inspired by what Mark did, little workshops where you introduce people to pair programming or other techniques.

Furthermore put an extra effort in a really good presentation. Students usually have higher expectations for external speakers than for “normal” lecturers. Try to get them engaged, for example with games. There are lots of little games you may play. These games usually don’t take too long, you get people engaged and most importantly you make your lecture memorable. You can find a list of suitable games at

At my university we had the Lego Scrum exercise. I liked the Lego Scrum exercise very much and I remember that my fellow students mostly felt the same. At the very least it is something that everyone remembers. Here is a little video of us doing the exercise (sorry for no subtitles!):

I highly encourage you to embed those games into teaching agile software development. I believe that they can truly make a difference. But once you got the students engaged and they know about the theory, then it’s time for practice! Time for a project! Or more?

Don’t conduct one agile project, conduct 2!

Let me tell you something more about my bachelor studies: We are supposed to develop our first project with agile software development methodologies in our fourth semester. And you know what? It was a disaster. But a disaster that was needed.

We were using eXtreme Programming (XP) for the first time. We had enormous problems with estimations, user story slicing, iterations, test driven development (TDD) and probably everything else you can imagine. We did a whole bunch of mistakes. It was not just my group. Nearly every group I remember faced similar problems. For instance nearly everybody wanted to do TDD but ended up with a code (line) coverage between 20% and 50%. When we didn’t get our user stories done during our first iteration we simply prolonged the iteration by one week. Yes we really did that.

Of course, there were bright spots. We used pair programming and loved it. Our planning went pretty smooth towards the end. However I honestly don’t know how I’d feel about agile software development if this would have been our last agile project.

Luckily we conducted a second project in another course, which has already been praised. There we were using Scrum in a team of 50 people (with sub teams of course). We developed a customer relationship management system in Ruby on Rails. Our planning and retrospective meetings were facilitated by students who took the course in previous years. It was interesting to see how much we all improved as we grasped the concepts better. Moreover it was a good experience in inter team dynamics.

It was good but we still had a long way to go. Unfortunately not everyone seemed to like the concepts as much as we did. We were one of few teams to choose an agile development process for our bachelor project, were we were (mostly) free to choose how we want to work.

Adaptive vs. Innovative

Clarke Ching opened my mind to another important aspect: Adaptive small changes when rolling out agile or the “all at once” package. I believe that some of the problems we had were related to this. If you try to implement so many new and different concepts all at once, you will most likely end up implementing every change just a little. There are just too many new things which you can’t possibly really implement the first time around.

Therefore I believe that it could be beneficial to run workshops specialized workshops or exercises prior to the project. These exercises could focus on estimation, pair programming, TDD or… you get the idea. This way students get the opportunity to familiarize themselves with a method prior to using it in a project. Or you could tell students to simply focus on a set of changes and not try to implement all of XP all of a sudden. I just had the feeling that it was a bit too much, so maybe these techniques could be used to mitigate the problem.

The Takeaway

Theory is good and necessary, but practice shall never be underrated. If you give a lecture as an external speaker make sure to make it memorable. Engage them. Share your enthusiasm with them. You won’t convince them all. That’s alright. But if you give it all, you will successfully plant the idea of “Agile” in their heads. And I’m very thankful for everyone, who does this.

Become a student volunteer for the XP 2012 conference in Malmö (May 21-25)

Hello everyone,

I’m responsible for the student volunteers of the XP 2012 conference in Malmö, Sweden. The XP 2012 is a big international conference about agile software development. If you are a student and want to join the conference, this might be an opportunity for you. The following is simply a repost of the content that I put up at the XP 2012 home page in the volunteer section. So if you are interested in joining a big international conference about agile software development in order to meet with representatives from research and industry read the following text (or check out the link) and contact me! Oh and yes, of course I’ll attend as well 🙂


Do you want to go to the XP 2012 conference? Does the conference fee seem to be over your budget? Are you a student? Then you can be a student volunteer for the XP 2012 conference!

What requirements do I have to fulfil in order to become a student volunteer?

In order to become a student volunteer you need to:

  • be a student
  • speak English fluently, Swedish (Pratar du svenska?) would also be good, but not necessary
  • be interested in agile methodologies and development practices
  • be able to pay for your travel expenses and accommodation yourself, as unfortunately we can not pay for this. If you don’t know how to get to Malmö or where to sleep please feel free to contact us.

What do I get as a student volunteer?

As a student volunteer you get:

  • free admission to the conference – the full conference normally costs 10995 Swedish crowns (~1240€), even as an early bird
  • the opportunity to listen to a wide variety of talks about software development from leaders of the field from both research and industry
  • contact to people from research and industry – including possible future employers
  • insight into the organization of a large scale event
  • free food at the conference
  • a T-Shirt
  • the printed proceedings of the conference

What do I have to do as a student volunteer?

As a student volunteer it is your task to:

  • help preparing the venue for the conference
  • help with organizational tasks before and during the conference
  • help guide visitors of the conference to the right places
  • be present in the conference rooms and help with technical problems

It is our goal to have enough student volunteers so that not everybody has to be on duty all the time, so you can take a break and visit the talks and presentations you are interested in.


If you are interested or have any questions please feel free to contact me at or

If you are worried about travelling to Malmö or finding accommodation also feel free to contact me, maybe I can help you or we can get a group discount at a Hostel.

Frequently Asked Questions (FAQ)

What is the registration process for a student volunteer?

Simply send me an email, that is enough to get registered as a student volunteer if we still need student volunteers. If you get an email from me confirming that you are accepted as a student volunteer, then this is enough.

How many student volunteers do you need?

The number of student volunteers we need is highly dependent on the number of attendants of the conference. Once we have enough student volunteers, applicants will be put on a waiting list in case we decided that we need more student volunteers or in case somebody got sick.

Why Waterfall was a big misunderstanding from the beginning – reading the original paper

You probably know that there is the Waterfall process – by now feared by most as “the father of the plan driven approach”. Some may even know that Waterfall was supposedly “invented” by the paper “Managing the Development of Large Software Systems” by Dr. Winston W. Royce in 1970. But have you ever read it? Why should you? It’s probably just an endless explanation of how great Waterfall is… or is it?

What if I told you that it is the exact opposite? If I told you that it is a paper identifying this pattern (without naming it Waterfall) and describing its deficiencies and proposing enhancements? Don’t believe me? Well let’s see what Mister Royce writes right after introducing the pattern on page 2:

I believe in this concept, but the implementation described above is risky and invites failure.

Doesn’t sound so positive, does it? Oh and that’s not even the best part! The best part is that the paper actually includes some thoughts that I would classify as agile.

Wait what?

Yes back in 1970 the paper, that supposedly invented Waterfall was describing its deficiencies and actually contained some agile thoughts. I really recommend you to go ahead and read this paper. Or stay with me and let me explain it to you – or do both.

The reason why I’m bringing all of this up is that it seems that all of this is a little known fact. I mentioned it to two of my lecturers (both PhDs) during discussions about agile vs. plan driven. The fact that they didn’t know this kind of shocked me, so I decided that this probably needs some more exposure – and this is all the exposure I can give.

But all is not lost, I actually learned this fact from a lecturer, Dr. Joachim Schnitter, at my home institute – so thanks to him!

The misunderstanding

Royce doesn’t define the Waterfall model and recommend it, he identifies the pattern and shows one of the major problems of the Waterfall model as the testing phase occurs at the end of the development process:

The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed.

He further on states that faults found there will most likely result in a major redesign of the software, he describes the devastating effects of this as:

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

To me this analysis is pretty much right on target in describing Waterfalls biggest problem, highlighting that he doesn’t recommend this approach at all. He is suggesting improvements.

So how is this paper agile?

It is certainly not totally agile, but it contains thoughts that go in the right direction and really resemble some current agile practices. Winston Royce proposes 5 enhancements to the “Waterfall” model, they are as follows:

  1. Program design comes first
  2. Document the design
  3. Do it twice
  4. Plan, control and monitor testing
  5. Involve the customer

Let’s focus on the latter 3 as the first 2 aren’t pretty agile to my mind (especially not number 2 as it highly emphasizes documentation):

Do it twice

Royce basically advocates that if your software product is original, the version delivered to your customer should actually be the second version of the product, at least for critical areas. He goes on to explain:

Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort.

He explains that this is done to identify problems early on, so they can be tackled appropriately later on. All of this sounds like a “spike” to me. You go on to build a part of your system, which you have little knowledge about, in order to increase your knowledge about this part of the system . You do so in isolation and throw the code away afterwards. He says that you should do this, but for the whole system.

Plan, control and monitor testing

In this section he once again argues that it is bad, that the testing comes last. However he does not jump to the conclusion that testing should come first, but he greatly emphasizes the importance of testing for the success of a software project. He also says that code should be checked by a second party, as many errors are easy to spot. I know it’s a very far stretch but that reminds me a bit of one of the motivations for Pair Programming, although he doesn’t suggest anything like it.

Involve the customer

This basically stands for itself as it is also one of the four core values of the Manifesto for Agile Software Development. He more explicitly says:

Involve the customer – the involvement should be formal, in-depth, and continuing.

He also states what it is like when the customer is not involved and the development team is basically left alone:

To give the contractor free rein between requirement definition and operation is inviting trouble.

He suggests 3 points after the initial requirements generation, where “the insight, judgment, and commitment of the customer can bolster the development effort.” These are: Preliminary Software Review (after Prelimnary Software Design), Critical Software Review (after Program Design) and Final Software Acceptance Review (after Testing). Although this is not an on site customer yet, it is much better than “make a contract and then let the contractor work alone in the dark on the system according to the contract” – don’t you think?

So was Winston Royce agile?

Certainly not, but he had some really good ideas on how to improve software development, some of which may be classified as “agile”. But why have most of us never heard of this before?

So how did Waterfall become so popular if the deficiencies were so well-known?

What I write now is just a rumor, nothing more. I’ve no way of telling whether it is true or not and clearly no reference.

So from what I’ve heard sometime some guy of the Department of Defense was given the task to look for a software development process to develop a new system. He found the paper of Royce, read the first page (which is quite positive) and saw the figure at the top of page 2 depicting what we now know as the “Waterfall” model. As it was simple and seemed good he went on to propose the depicted process, without ever reading about the deficiencies and proposed enhancements. Maybe it’s just an urban legend, maybe it’s true – I don’t know. Either way I’m sad that Winston Royce has been so misunderstood.

Lesson learned

It can be very beneficial to go back to the roots and read the original sources, even over 40 years after their initial publication. If some more people would have done this, maybe we would have (mostly) gotten rid of Waterfall as a Software Process by now. However it is still there and going strong. To each his own, but I prefer agile methodologies, practices and associated software development processes. To me they are way more productive, effective and fun. And it is always good to know that a CMMI level 5 company can highly benefit from a switch to Scrum – doubling the productivity and reducing defects by 38% (and many more benefits). I encourage you to go ahead and read about it in the Scrum Papers, the section (paper) is titled “Scrum and CMMI Level 5: A Magic Potion for Code Warriors”. Have fun reading it and I hope you enjoyed this read as well!

ThoughtWorks Boot Camp

I just spent the weekend in Hamburg at a ThoughtWorks boot camp. So this blog post is for people who want to know what a boot camp at ThoughtWorks is like. Also there is information about ThoughtWorks in this post but if you don’t already know them you should check out their homepage.
Oh on a little side note, since I don’t know whether or not everybody would agree to this I won’t mention names in this post, although this post is solely positive.

Personally it will still take me some time (~ 2 years) to finish my studies, but I’d love an internship at ThoughtWorks and wanted to get into touch with them as soon as possible, that’s why I took the voyage from Sweden to Hamburg.

ThoughtWorks is not your average company. So the hiring process is not average as well, at least not what I’d expect as average – it was my first “real” job interview. And I felt really comfortable but continue reading if you want to know more…

Day 1

The boot camp started off at 8:30 on Saturday with a nice breakfast and a “meet and greet” with some ThoughtWorkers and fellow applicans. The dress code was casual, no one wore a suit. Most people were wearing jeans and a t-shirt or/and a pullover. Everybody was really nice and open. There were ThoughtWorkers present you could just go ahead and talk to them.

One of the key moments for me on the first day was when one of the ThoughtWorkers wanted to tell something about the company in general and suggested that we all just sit down on the floor. I guess this wouldn’t happy in many companies, everybody would sit down in a big meeting room which would give it a real formal flair. It was a cool informal session, we could ask whatever question we wanted and it had a real friendly atmosphere. The atmosphere of a company I want to work in. Some of the key takeaways were that ThoughtWorks has a really flat hierarchy and that you can go to almost everybody and talk to him/her. Moreover ThoughtWorkers travel a lot, to wherever the client is. Therefore it was the first time for many of them that they saw the German office, despite working in the German office for quite some time. Also ThoughtWorkers seem to meet up quite friendly, when they are in the same town in order to have a beer (or 2).

It was emphasized, that we are not competing with each other for a job. ThoughtWorks is looking for talent and will hire the people that they feel fit the company. This philosophy was made apparent when one of the employees told his story: He is Canadian, but they didn’t have a job for him in Canada but wanted to hire him anyway. So they asked him if he would want to work in Australia and he agreed. Since then he has also worked in India and Germany (during the course of 2 years).
All of this resulted in a kind atmosphere in between us boot camp attendees, I got to know some pretty nice people.

After that a coding exercise started, it was a pretty basic task involving the modeling of some real world objects. It was said that we should especially pay attention to 4 things:

  • clean code
  •  good object oriented design
  •  best practices
  •  tests (preferably Test Driven Development)

We had 4 and a half hours time to develop the little application. Two of the developers were our customers we could ask whenever we had a question about the specification. Also we could just chat with each other or some ThoughtWorkers.
When I ran into Ruby problems I’ve never run into before (more on that in a later blog post) another boot camp attendee, that was also doing Ruby, came over and paired up with me to solve the problems since he already solved the problem. Thanks again!

In the end I wasn’t content with my code since so much time passed chasing those weird bugs. But it was still solid and the program did what it was supposed to do. And I learned a lot so those bugs won’t bug me again.

After that we had lunch – ThoughtWorks ordered some pretty tasty pizza. Oh speaking of food and drinks, we could just go to the fridge and grab whatever we wanted and during the coding exercise they would come around and hand us sweets.

After that big break with some good conversations it was time for logic tests. I don’t want to spoil it too much but the first test was difficult because there were 50 questions and just 12 minutes time. The second test was hard because it demanded high concentration and good analytical/algorithmic thinking. I liked the second test pretty much 🙂

After those tests it was again time for interesting conversations and a nice wrap up where everybody said one sentence about what the day was like for him/her. I stayed a little longer after everything was officially over (concerning day 1), since I enjoyed the conversations. And indeed I had a nice long conversation with a ThoughtWorker about… just about everything: what working at ThoughtWorks is like, what I do, what he does, code katas, TDD, whether Berlin or Hamburg is the better city and many more things.

Around 20:00 you’d get a call whether or not you made it to day 2 and luckily I made it.

Day 2

On day 2 the devs had 3 interviews. Well all the devs but me, since my studies still take me some time and therefore it wasn’t that urgent. I just had the cultural interview, which was basically about what I’m like as a person, what I do in my free time, what I’ve already done but also what it is like to work at ThoughtWorks and my expectations about a job at ThoughtWorks. So basically, nice chatting mixed with questions like “What would you do if…”.

The others had a management interview and a technical/pairing interview where they talked about technical things and played a bit with the code, that they wrote yesterday. Since I was especially interested in the latter (feedback on what I’ve done is always good) I approached the developers doing this and asked if they would be so kind and willing to give me a little review of my code since I didn’t get that interview. And luckily they agreed and we had a nice look at my code, making it a lot more beautiful, again after everything was officially over. But fortunately they seemed to like it overall 🙂 Thanks again at this point for taking their free time to give me feedback.

Wrap up

I liked it, especially the more or less little things. You could approach every ThoughtWorker there and have at least a little chat with them. I could call everyone by their first names (which is especially atypical in Germany). And they all seemed to be enjoying to be there, meeting potential new ThoughtWorkers. I think I have at least had a little chat with every ThoughtWorker present. One ThoughtWorker even paid for my lunch on Sunday (thanks!). We got thanked so many times for attending the boot camp. It felt great.
I’d describe the atmosphere as almost familial as I could always talk to everybody. When I had weird problems with my code I just asked a ThoughtWorker if he’d mind taking a look at it since my tests were behaving weird and I simply couldn’t find the reason. He came over and together we tried to figure out the problem, unluckily unsuccessfully on our first try but it was a good time anyway.

My wish to join ThoughtWorks grew during this weekend as I really felt comfortable there. I sure hope an internship works out, that I can work there when my studies are finished and that I get a T-Shirt*.

So all in all I can only recommend attending a ThoguhtWorks boot camp to everybody interested in Agile and Software Engineering. It’s a really cool atmosphere and I sure learned a lot. To me it felt more like a group of smart people that wanted to get to know people and choose whom they would want to work with in the future.

*I’m kind of a T-Shirt nerd. I got T-Shirts of nearly everything I like. Starting with bands, but also programming languages, operating systems and even my favorite browser.