Crowdfunding a Book about TDD and Cryptography

March 5, 2014

Those who follow me on twitter and understand German already know that I’m in the midst of crowdfunding a book:

The book has three purposes:

  • Capturing the state of test-driven development as I see it
  • Choosing code examples from a domain that is both interesting and challenging: Cryptography
  • Providing up-to-date learning material about TDD for the German speaking development community

Currently basic funding for about two months fulltime work is covered, but not much more. I’m somewhat nervous that when summer comes I’ll have to stop working on the book in order to feed wife and offspring. So maybe you want to support me and sponsor a few more pages? Even if you cannot read German, there might be something in it for you: I will definitely publish some of the advanced material on this blog in English. For example, a series of interviews with “Veterans of TDD” is already in the make. And – who knows – maybe the English version of the book will follow suite.


Support a new TDD book on the crowdfunding platform Startnext.

I’m Not Quitting, I’m Letting Go

December 3, 2013

Since the end of Netdosis I’ve been thinking about what to do now for a living. I’ve known for a while that I couldn’t just go back to Agile coaching – but I didn’t know why my feelings against it were so strong. So I sat down, did a lot of reading and a little bit of thinking, and presented my after-the-fact rationalization in the form of a talk given twice, once in English and once in German (video of the talk). Here’s the digest, combined with the insights I got from all the feedback.

I make my case by bringing forward three claims:

  1. We cannot prove that Agile practices work better than any other process
  2. Agile comes with adverse reactions
  3. Being focused on Agile as a solution distorts our view

Let’s consider the points in more detail:

1. We cannot prove the efficacy of Agile practices

During the last decade there have been many attempts within Software Engineering to copy medicine’s approach of proving that a drug or a therapy works to the benefit of patients. Clinical trials are supposed to be the backbones of Evidence-Based Medicine; in order to be reliable those trials must follow strict rules, some of which are: randomness, triple-blindness, adequacy of study groups and the usage of real endpoints.

The equivalent of clinical trials in empirical software research are called controlled experiments. There were experiments on pair programming, test-driven development and a few other techniques. You might want to read Making Software) for typical examples or The Leprechauns of Software Engineering for bad, invented and badly interpreted ones.

The problem with programming experiments is that they sometimes randomize participants, but they usually – if not always – fail to gather adequate study groups and fail to use real endpoints:

  • They are typically run with a limited number of computer science students. I like to compare that to a clinical trial about the benefits of brain surgery performed by 3rd-year medical students.
  • They never measure anything like the real “endpoint” of software development like “the effort required to develop a sufficiently complex feature and maintain it for a couple of years”.

Whereas those two problems could theoretically be overcome by pouring enough money (think: Millions of Euros) into a study to sponsor a few dozen teams of professional software developers who evolve the same kind of system for – say – five years, there is one flaw in programming experiments which IMHO cannot be got rid of: the lack of blindness. Can you imagine yourself developing software TDD-style without knowing you’re using TDD? When you don’t have (triple-)blindness, any result of your experiment might come from the technique under research or it might come from some unknown contextual circumstances, aka placebo effect. You will never know!

This fundamental difference to (some type of) medical therapies leads me to the conclusion that controlled experiments will NEVER be able to prove that one development practice works better than another one mostly independent from its context. But please… Do not confuse this lack of proof with proof for the opposite.

Conclusion No.1: Since we have no basis for claiming that Agile will work any better than what our coaching clients are doing now it is unhelpful and misleading to say (to a client or in public) that “Agile is better than X” – for any X. We can only judge the efficacy of our interventions on a case by case basis – this is a whole different approach to scientific action.

2. Agile comes with adverse reactions

If our current methods of Agile coaching worked as advertised, by now there’d be thousands of organizations with a severalfold increase in productivity and a self-sustaining, self-optimizing Agile process. Instead, organizations spend millions on coaching and training just to obtain a few percent improvement regardless what you measure. And many times, the negative effects on a company will not even be considered.

One of the main sources of adverse effects is the agile utopia; as Agilists we promise a lot: higher productivity, happier employees, satisfied customers etc. In next to no cases we can keep all those promises, and we’ll thereby create a bunch of disillusioned and disappointed people. Those will either stay (and henceforth be demotivated) or leave; neither is usually in the best interest of the organization at hand.

What’s more, our utopia is other people’s dystopia. Going back to open-plan offices, working with competitive colleagues on a minute by minute basis and having to report their “progress” every single morning, might look like a nightmare to many. Those will either stay (and try to sabotage the change) or leave; neither is usually in the best interest of the organization at hand.

There are many more ways to do harm by forcing the Agile way:

  • Important customers might leave because they don’t get what they were once promised.
  • Lower (temporary) output can lead to less turn-over and less profit.
  • If you bring on change that doesn’t stick or doesn’t produce the intended improvements there’s a good chance that the company won’t be able to go back to the old status quo and will be in a more dysfunctional state than before.
  • Last but most important to me: The company’s energy is spent on some non-essential process change, although it could be used for the important stuff.

One last thing about the unwanted side-effects of treating our clients with the Agile medicine: There are many  valid reasons for people to not change (right now or in the way we want them to). “People over Process” should teach us to respect that.

Conclusion No.2: Before and while we’re applying Agile drugs and surgeries, weighing risks vs benefits is one of our most important duties.

3. Wearing Agile glasses distorts our view

We Agile pundits are so convinced of our theories why Agile practices are superior that we tend to develop a huge blind spot in our vision and just don’t see how people succeed with different approaches – or we dismiss their success as pure luck, or as un-sustainable or as a rare edge case. To get you started here’s a few “un-agile” practices I’ve seen work reasonably well:

  • There are (lots of) successful distributed software projects.
  • Sometimes code reviews work and pair programming doesn’t.
  • High quality software with little or no test automation exists.
  • Component teams can also deliver and feature teams can fail.
  • Some software has been successfully built using a top-down design approach.

Moreover, parts of our Agile “theory” are just made-up. E.g. scrutinize the “evidence” for the “perfect” team size of 7+/-2. Afterwards, try to validate the alleged flattened cost-of-change curve with empirical data.

Conclusion No.3: There is no lack of pundits in the field of software development. Most of them are one-sided and bring their improvised theory and ready-made solutions to the table. That way they tend to promote their preferred solution without having understood the problem in the first place. Agile consultants are no different.

What I will change for myself

Bashing the state of the art is easy. Doing things better is a lot trickier. This is what I’m going to try:

  1. I’ll get rid of “Agile” (or “Scrum” or “Lean” or ) as a label. Together with the title I get rid of Agile’s potential nocebo effect.

    Finding a new job title is tricky, though. My current one *Software therapist* might be more inventive than “Agile consultant” or “Scrum coach” but it’s not better in any objective sense. Let me know as soon as you come up with something.
  2. I will try to become a problem helper – instead of a solution provider. It’s essential to identify the types of problems that trigger my passion. As for me, I found out that the more management-related issues do not fit any more, so I’ll stick with clients who can profit from technical and team-related support. Working on problems that matter – to me and to the people I work with – is crucial for keeping up energy and passion.
  3. Being a problem helper requires that I have the tools to tackle the issues at hand. Agile methods will remain an essential part of my toolbox, but they cannot be the only ones. Getting rid of tools that don’t fit my style and storing the sharp ones in a safe place are as important activities as collecting ever more stuff.
  4. Putting my skin in the game…

Putting skin in the game

Professionals – like consultants, coaches, trainers or investment counselors whose main activity is to give advice – all operate under a common pattern: They benefit from the upside of their job, i.e. they get money for advising. Sometimes they even get more money when their client seems to benefit more. Their client, however, has to bear all the risk. When the client looses money, the consultant will – in the worst case – not get their pay. Have you ever seen a CEO of a stock corporation who will cover essential parts of “his/her” company’s loss?

This asymmetry in risk is especially tragic because it is mirrored by an asymmetry of information: The consultants are experts in their field – and therefore have more knowledge about the risks than their clients do. We can spot this asymmetry in all kinds of dysfunctional and immoral behavior – the financial crisis being the most prominent example.

An effective solution to this problem is to put people’s skin in the game. Here’s an example from the Code of Hammurabi: “If a builder builds a house and the house collapses and causes the death of the owner of the house, that builder shall be put to death.” This approach works in two ways:

  • When their skin (or money or live) is at stake people tend to be more careful and thorough while weighing risks and benefits.
  • Bad builders (and bad consultants) will become rare in the long run since they either die or go bankrupt.

The idea is ancient but it recently got fresh support from Nassim N. Taleb, e.g. in Antifragile and The Skin In The Game Heuristic. Taleb claims that it’s the moral thing to put your skin in the game even if your customer does not require it. The question remains…

HOW can I put my skin into the software game?

Be the first customer of your product. Founding a software-based start-up is one means to do that, investing serious money in your client’s is another.

Never teach or advise something that you either haven’t done yourself before or wouldn’t do if you were in your students’ shoes. For full-time trainers or teachers this can be hard.

Become an employee. Most employees have more skin in the game than the outside consultant. Being employed without invested can only be a first step, though.

Attach your compensation to your client’s long-term satisfaction. E.g. add a massive refunding clause to your contracts – and explain it to your customer.

Personally, I am at the very beginning of putting my skin into the game: I’ve removed a few technical topics from my portfolio in which I’m only well-read – but not invested. I’ve made the experience that the mere suggestion of adding a refunding clause into the contract changes the communication style. People, especially managers, do not expect others to willingly take a share of their risk.


Agile is still (one) part of my professional life but calling myself Agile is not. Putting more skin into my professional life is dear to my heart: Don’t follow my advice, look at what I do.

Stuff I read while preparing the topic and the talks:

N. Taleb: Antifragile

B. Goldacre: Bad Pharma

G. M. Weinberg: The Secrets of Consulting

L. Bossavit: The Leprechauns of Software Engineering

A. Oram, G. Wilson: Making Software

N. Taleb, C. Sandis: The Skin In The Game Heuristic for Protection Against Tail Events

Christian Weymayr: Die Homöopathie-Lüge

O. Maasen, C. Matts, C. Geary: Commitment

Richard Feynman: Cargo Cult Science

Netdosis Afterthoughts

September 30, 2013

Almost 2 years ago I told you about why I was leaving the field of Agile coaching and that I’d be co-founding a start-up called Mydosis Netdosis. Very recently we eventually stopped the project and sold the assets to a company which – among other things – is building software for drug therapy safety. There are two questions which might be of interest to you:

  • Why did we fail?
  • What does a failed founder do when he’s got no money left for a new start-up venture?

Why did Netdosis fail?

Since there is never a single reason for failure I’ll just enumerate a few points that IMO contributed; they sure don’t give the full picture. First of all, our idea did not scale to millions of users but only to some tenths of thousands, or maybe hundreds of thousands (if we consider the international market). This resulted in a business plan in which the projected numbers were just one magnitude too small to make any serious investor interested – we had exactly zero investment negotiations. The other context-related issue is the medical domain itself: The German health system is a perfect mess of lobbyism, over-regulation, conservatism and ego-centric medical directors. Innovative ideas just don’t play a role there and one needs really good connections and a sky-high frustration tolerance to get a foot in the door.

But we’ve also made lots of mistakes on our way:

  • It took us many months to realise that our most important collaboration partner had no real interest in selling but was mainly scientifically interested
  • We waited much too long before getting a medical expert who was on our side
  • We tried to ignore the differences among us founders, which in the end led to the premature exit of one founder

So I still don’t know if there would have been a way to success but I’m positive there would have been a faster way to fail. I personally spent a very good 15 months of doing almost exclusively technical work. The only thing I regret is the amount of money we spent on lawyers and similar folks.

What will I do now?

When in early 2013 it became clear that Netdosis would never earn my and my family’s keep I rebooted my consulting business and found a few new clients who pay me for technical help and training. Having been very explicit about never going back to Agile Coaching I’ve been trying to do things differently. If you come to GOTO Berlin or XP Days Germany you’ll hear me talk about the changes I’ve tried. See you there?

Say Goodbye, I won’t be Back

December 2, 2011

Yesterday was my first day in a new position. I’m now co-founder of a start-up called Mydosis. But this blog post is not about what’s coming, it’s about what I’m leaving behind.

I’m leaving behind a career as an Agile consultant. I used to call me “Agile coach” but nowadays I see Jerry Weinberg’s definition of consulting – “influencing people at their request” – a much better fit for what I had been trying to achieve during the last 10 years. Which gets me in the middle of my frustration with the idea of bringing Agile to the masses.

During the first years of Agile development, Agile promotion and Agile influencing was a source of joy and positive fulfilment for me. Most of the time I had to deal with developers and teams who actually embraced the “extreme” ideas I brought them. Sure, their managers were initially unwilling to accept two people working on one computer or the team insisting on doing the estimations themselves. But in the end every team member knew they personally were much better off – even if they had to make a few compromises to interface with the non-agile rest of the company.

Then the nature of my assignments changed. Suddenly it was the CEO or at least s.o. from upper management who initiated the “Agile transition” in order to “adapt faster to a changing market”. At the beginning I deemed that a good thing, since I had always been complaining about the lack of management support. However, the work itself got ever more frustrating and ever less rewarding, especially when dealing with teams who were pushed towards Agile and hadn’t had the chance to choose for themselves. From then on, I spent most of my time trying to convince somebody of something that he or she didn’t actually want to do. If this sounds to you like a depressing way to earn your money, it was. Even when showing very hands-on techniques – like TDD or refactoring – I felt the lack of enthusiasm; first in my clients but then more and more in myself.

Slowly it dawned on me: We, as Agile consultants, have been abused by management to do all the convincing and motivation for them. In my opinion it should be the most essential part of their job to bring the right people together for the new challenge, might it be a new product, a leaner approach for the old product or a complete turn around of the company. Instead they hired us to do the impossible: Change their employees in a way that suits their latest business strategy. Accepting such an assignment often made us violate the “first Agile commandment”: People over process.

“People over process” can – and often should – mean: not doing an agile transition at all. Human beings have a right to choose which changes they want to go through and when. There are many valid personal reasons for not doing TDD, not taking accountability and not moving into a common team room. Let’s accept those reasons without being contemptuous and without trying to manipulate. Heck! – it’s the managers’ task to align their employees’ personal goals with those of the company. The few successes and the many failures during my time as Agile consultant have taught me one thing: It needs different people to make a different company. Rare exceptions will only prove the rule.

So, my dear fellow-coaches, my dear friends, we had a good time together. Sometimes even a great time. We brought teams from being overwhelmed by bugs to a zero-defect continuous feature flow. We turned around a company who was under severe legal pressure by its customers to a +50 net promoter score. We convinced senior managers that giving up control will enhance their teams’ productivity. But, on the way, we made some people unhappy, maybe a few very unhappy, and sometimes didn’t even notice.

I hope to see you all around, but I won’t be back to the party.

Simplified Use of Locks in Groovy

October 25, 2011

I am currently writing an article about the challenges and pitfalls of concurrent programming for a German software magazine. Since the magazine’s readers come from all kinds of platforms and programming languages I’ve chosen Groovy as a concise means to present my examples. Groovy – together with its associated library GPars – comes with good support for easy synchronization and locking (e.g. @WithReadLock, @WithWriteLock and @Synchronized). However, I do not want to introduce the concept of AST transformations so I came up with a new way of using locks in Groovy – originally motivated by Chris Broadfoot. Here’s a short example:

class Shelf {
    final products = []
    final lock = new ReentrantLock()
    void putIn(Product product) {
        lock {
            if (isFull())
                throw new StorageException("shelf is full.")
            products << product
    boolean takeOut(Product product) {
        lock {
            return products.remove(product)

It looks like lock was a new keyword but actually I achieved that with a tiny bit of Groovy meta programming:

Lock.metaClass.useFor = { Closure operation ->
    try {
    } finally {
} = { Closure operation -> delegate.useFor(operation) }

Now that I used it in a couple of examples I suggest it should be considered for inclusion in GDK. What do YOU think?

P.S.: Don’t get me wrong about the usefulness of explicit locking. In most cases other concepts – like parallel collections, data flows and agents – should be preferred.


Get every new post delivered to your Inbox.