Improving your software project by being intolerant

During the holiday I read a book mentioned to me by Pim Elshoff: “Skin in the game”, by Nassim Nicholas Taleb. Discussing this concept of “skin in the game” with Pim had made me curious about the book. It’s not such a fat book as one of Taleb’s other books, which is possibly more famous, called “Antifragile”. “Skin in the game” is a much lighter book, and also quite polemic, making it an often uncomfortable, but fun reading experience. I can easily see how people could get mad about this book or aggressive towards its author (not that I’m encouraging or approving of that aggression!). While reading it, it reminded me of Nietzsche, and his despise of the “common man”, who Taleb calls “the intellectual” - someone who has no “skin in the game”, let alone “soul in the game”. Taleb’s ideas are interesting, just like Nietzsche’s are, but they could easily be abused, and probably so by misinterpreting them.

Intolerance wins

Something that’s controversial, yet interesting for me as a developer in a team - from Chapter 2, “The Most Intolerant Wins: The Dominance of the Stubborn Minority”:

Society doesn’t evolve by consensus, voting, majority, committees, verbose meetings, academic conferences, tea and cucumber sandwiches, or polling; only a few people suffice to disproportionately move the needle. All one needs is an asymmetric rule somewhere—and someone with soul in the game. And asymmetry is present in about everything.

Taleb, Nassim Nicholas. Skin in the Game: Hidden Asymmetries in Daily Life (p. 83). Penguin Books Ltd. Kindle Edition.

This made me aware of something that I had observed several times before, whenever I was part of a software development team - or “software development society”: the biggest impact on quality (to be interpreted in many different ways) isn’t made by reaching consensus, or voting, or being tolerant to other people’s opinions or ways of coding at all. What makes the biggest impact is the opposite: being intolerant of all those different styles, approaches, and being stubborn about your own way. As the title of the chapter says: “the most intolerant wins”.

For example, how do you improve the coding style of a project? Maybe by discussing which styles you all like, and agreeing on one, then agreeing that all of you will apply it from now on? No, you can only achieve a consistent coding style by enforcing it everywhere and being very intolerant about it (that is, only allowing commits that conform to this particular style).

Another example: would you leave it up to your fellow developers to decide whether they will use static methods to fetch dependencies, or they inject all dependencies as constructor arguments? If you allow both, the result will be a mess. You can’t even rely on a single class using either of these options - a class may even use both at the same time! (See also “Negative architecture, and assumptions about code”). You will be considered a tolerant developer, but it’s not for the good of the project. Again, intolerance is needed to drastically improve and guard the quality of your project.

One more example: if you know that the project would be better off with a Docker setup, do you ask management for permission to make it so? Do you vote? You won’t get the minority vote, let alone get scheduled time for it during regular work hours. It may very well be that you have the biggest chance of success when you just do it. There’s one rule though: if things become messy, take full responsibility and adapt: you made a mistake, just roll it back (or don’t roll it out in the first place). This is where you make sure you have skin in the game.

Do more than you talk

This leads me to quoting Taleb again:

[…] always do more than you talk. And precede talk with action. For it will always remain that action without talk supersedes talk without action.

Taleb, Nassim Nicholas. Skin in the Game: Hidden Asymmetries in Daily Life (p. 122). Penguin Books Ltd. Kindle Edition.

Over the past 20 years I’ve had lots of conversations with developers and managers, that eventually turned out to be just talk, no action. I don’t know about your experiences (would love to hear about them though!), but this is a very common characteristic of “conversations in tech”; lots of meetings, lots of discussions, cool ideas, great plans, but none of it is going to happen. For many reasons of course, like:

• The managers in the meeting just want to keep the developers happy, so they allow them to make great plans, which will never be executed.
• The developers are not happy about their job anymore, so they construct this shared dream about how things could be, “if only…”.
• Everybody realizes that the great plans are to great to ever be finished, so nobody even dares to start doing the work.
• The people who talk, feel that they must reach consensus for everything. They never reach it.

I’m sure that, from experience, you can add several more reasons to this list.

I find that some of my most impactful work on projects in the past has been when I preceded talk with action. I did something, believing it was the right thing to do, putting in some of my own time, and proving “that it could work”. I did this work outside of the system of employer-employee, in unbillable time, and without (a lot of) consensus. Without exception, starting a change resulted in other people jumping in, supporting, and completing the work.

In fact, this is what I recommend people to do, when I get asked (and I often get this same question): “How can I change X in my team?” My first advice is always: don’t ask, just do it. Of course, this comes with certain ethical clauses, like:

• you shouldn’t be wasting your employer’s time,
• you shouldn’t do what you know will harm your relation with other team members,
• etc.

Still, within these margins you can easily accomplish much more than you thought was even possible, given the current project and the project team.

Having skin in the game, being antifragile

When reading “Antifragile”, I was struck by something Taleb writes about being self-employed:

Further, for a self-employed person, a small (nonterminal) mistake is information, valuable information, one that directs him in his adaptive approach;

Taleb, Nassim Nicholas. Antifragile: Things that Gain from Disorder (p. 85). Penguin Books Ltd. Kindle Edition.

I always thought this to be a good reason to be freelancing: the mistakes you make force you to adapt, to learn. You get immediate feedback from what you do, and use it to become a better freelancer. Because you want to make your business sustainable and not end up with a bad reputation, becoming unhireable.

However, reconsidering this, I think it’s not smart to link “being self-employed” to “learning from mistakes”. What matters is the feedback loop involved in the work. If you could make a mistake, but it will never be linked to you, or you will never hear about it anyway, there’s no way you could learn from it. And this is what may very well happen to any freelance software developer: a mistake you made (a bug you produced, a bad design you imposed, a coupling issue you introduced), may surface years after you made it. Since companies usually can’t pay (a team of) freelance developers for longer than one or two years, you are very likely to miss the mistakes that you make, and therefore not learn from them. You’ll likely even make the same mistakes in other projects for years to come.

So, do I recommend you not to start freelancing? Well, no. But I do recommend you to look for ways in which you can tap into the mistakes you produce, to evaluate how things are going, and to look for ways in which you can improve.

• Book Review