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 the

Truncated by Planet PHP, read more at the original (another 3359 bytes)