\\\ Home \\\ Blog \\\ Profile \\\ ☕

All categories

Software Experiences by Robert Nickel

pigeonhole principle

Too many pigeons for the holes?

Robert Nickel - December 28, 2020  🏷️  Thinking

While learning for my discrete mathematics exam, I stumbled across the pigeonhole principle. A pigeonhole is where pigeons like to sit. I started liking it, when I discovered, that it is so obvious in the metaphor but, at least for me, took a while to become able to really apply it. The pigeon metaphor goes like this:

If there are more pigeons than pigeonholes, at least one hole will host at least two pigeons.

🐦 --  📭
🐦 --  📭
🐦 --´


Please tell me how many people in Sydney have the same amount of hair on their head? Lets estimate the maximum amount of hair: 150K. In Sydney live around 5.3M people. Preliminary conclusion: At least 2 people in Sydney have the exact same amount of hair.

The pigeonhole principle goes further: It also tells us, how many people (at least) in Sydney have the same amount of hair. Just divide the pigeons by the pigeonholes and ceil the number.

5.3M / 150K ~= 35,3 ceiled to 36.

Conclusion: At least 36 people in Sydney have the exact same amount of hair.

I believe there are many real world situations, in which the pigeonhole principle makes a lot of sense, and I cannot wait to stumble across some of them. To be honest: For this example, it would be more effective to count (or estimate) the amount of bald people, assuming they are the biggest group with the same amount of hair.

Homework: At my wedding we had 125 guests. There were 6 different main courses and 3 different side dishes, and each guest took one main course and one side dish on their plate. How many people at least had the exact same meal?

Software Experiences by Robert Nickel

Closing feedback loops

Hammurabis understanding of evolutionary loops

Robert Nickel - June 05, 2020  🏷️  Thinking | Agile

A long time ago, King Hammurabi of Babylonia, wrote a code of law, the so called Code of Hammurabi, which holds some surprisingly effective thoughts regarding the contract between a landlord and a house builder.

„If a builder build a house for a man and complete it, (that man) shall give him two shekels of silver per SAK [a length unit] of house as his wage.“ [1]

A bigger house costs more money. But isn‘t it interesting, how the house builder is not paid depending on the time it took to build it? There is no hourly rate, which means, the landlord wont get any unhappy financial surprises, which is good. But wait a second! Doesn‘t that mean, that a house builder will do anything as fast and cheap as possible, wouldn't that be a catastrophy? He might put those people in danger, who want to live in this house later on. The key question is: How can the owner of the house assure, that it has a good quality, if he only pays depending on the size of the house?

Hammurabi thought about this, did some risk management, and solved this „quick and dirty“ approach by the following law:

„If a builder build a house for a man and do not make its construction firm, and the house which he has built collapse and cause the death of the owner of the house, that builder shall be put to death. If it cause the death of a son of the owner of the house, they shall put to death a son of that builder.“ [2]

There is no need to explain, that the house builders will do their absolute best to prevent houses to collapse and kill someone, because they have so much skin in the game for an unlimited amount of time, meaning they can be killed because a house collapsed, they built 20 years ago. How exactly assured Hammurabi the quality of houses? By closing a feedback loop for the craftmanship of house building. Those who are really good at building houses will be able to keep building houses, while those who fail doing that will be stopped putting peoples live in danger. It might sound like a cruel practice from our modern cultural perspective, but it led to ridiculously good houses, there is no doubt. The house building quality solution is not a solution for house building anymore, maybe because of technological advancement and regulations, but I believe we can learn a lot from Hammurabis structural solution here. He shows us, that we need to close the feedback loop and reduce its complexity. This is, in my opinion, the single most important task of agile software processes. What I mean goes far beyond „You build it, you run it.“.

One example: A software architect, who does architectural work on a project and then leaves over to the next project, has zero skin in the game of the old project, and is therefore hardly able to improve. In a frictionless world, this architect would maybe get verbal feedback from people on the lower technical levels, that experience the actual haptical feedback that result from his decisions. But in the real world, complexity, reputation and hierarchy fog this verbal feedback, which complicates improvement for the architect further. And this is just one example for the concept of closed feedback loops, and therefore having skin in the game.

Lets enhance our motto: „You build it, you run it .. and you bleed for it.“, where bleeding is metaphorical for all the (negative) consequences that result from our decisions. It may be a phone call in the middle of the night, it may be doing overtime that originates in our own mistakes or might be getting fired. Especially the last point might sound extreme on the first glance, but think about this on a theoretical level first: Do you really want to build a team, in which people don't experience negative feedback on their own actions? Do you prefer working with people who survived the sometimes brutal reality, or would you rather work with people that have set up (and used!) safety nets a little too often? Please get this right: I am all for improvement that is based and being able to fail and learn. In order to be able to innovate, it is crucial to have playgrounds with limited consequences to failure. On the other hand I am worried, that an extensive lack of consequences will lead weak software craftsmen, who build houses that collapse.

And, of course, be aware! Don‘t let someone else put YOUR skin in HIS game. It has happend more than once, that a release plan, that was promised by a project manager led to overtime for engineers, or that product owners are blamed for quality issues, that were caused by „I will fix it later“ minded engineers. See my article The Two Dimensions of an Increment right below to get more detail on this topic.

I found the inspiration for this thoughts in the book Skin in the Game [3] by Nassim Nicholas Taleb.

[1] Harper, Robert Francis, Ph.D. The Code of Hammurabi, King of Babylon about 2250 B. C. Autographed Text, Transliteration, Translation, Glossary, Index of Subjects, Lists of Proper Names, Signs, Numerals, Corrections, and Erasures, with Map, Frontispiece, and Photograph of Text. p.81, §228
[2] Harper p.81, §229, §230
[3] Taleb, Nassim Nicholas. Skin in the Game, Random House, 2018.

Software Experiences by Robert Nickel

Scaling innovation

The McDonald's of Software Development

Robert Nickel - August 29, 2019  🏷️  Thinking

Often when I tell people, that I am a Software Engineer, they explain their idea of a game changing app, but don't know how to make it real. People backtrack when they find out about the cost of software development, because they fear the risk and often have no clue about this whole craftmansship. This does not mean, that the ideas are worthless, many of them are really good and some are actually game changing, I believe. So there is value, but no one picks it up.

Why is there no McSoftware that paves the way for low-budget projects to become real? It could be a franchising company with a world wide network of managers and lawyers, a great branding and very efficient value streams, just like the fast food restaurant equivalent McDonald's.

I thought about this a lot, especially about the question, how I could build this. And I came to this result: If it would be achievable, someone would probably have achieved it already, or at least something similar. But that is not the case, as far as I know. The reason: software development barely scales. The software itself scales indefinitely, and therefore there is no reason to produce the same thing cheaper then the competitors. Software breathes innovation. And innovation does not scale at all, that is in its nature. Innovation in general is the effort of many but the success of few, and those Einsteins who get humanity to the next level might get the prestige and/or the money.

What can we get out of this? The bad news are, that you will need to have the game changing idea and the resources to make it real. But on the other hand, due to higher level programming languages, reusable components and frameworks, better ways of teaching and learning technology and more digital natives with upcoming generations, it is getting cheaper and more accessible over time to develop innovative software that changes the world.

Software Experiences by Robert Nickel

Thinking humble

The quality of an answer to an open question

Robert Nickel - July 08, 2019  🏷️  Thinking

I used to work in the same team for more than 2 years, and now I left and joined a much smaller team in a green field project. We had the chance to set up parts of our methodology on our own, and one part was the question: "How do we as a team want to estimate?".

It was consciously expressed as a very open question, and a colleague of mine immediately responded: "In hours please!". Before this project, she was in a project where one story point was equal to two hours of work, and you get into trouble, if you take more than the estimated time. The improvement/simplification she proposed was to not divide by two (which sounds like a random number in this context) when estimating story points instead of hours. I do not want to discuss this way of estimating non-linear work here.

The question she answered was not: Should we estimate time, effort, complexity, risk, business value or something else, on which scale (Fibonacci numbers, natural numbers, binary..) and in which unit (hours, days, story points, T-Shirt sizes, our own scale, apples..)? Her perspective to the question was one dimensional (which factor per hour), in a multidimensional answer-space. I believe her answer was smart in that one dimension, but not useful, when considering more of the dimensions we know of. This is not her failure or stupidity, it is her experience with this world of "agile" software development, and was extended in the next few minutes after other colleagues told their opinion.

It made me think: Am I answering multi-dimensional questions on a one-dimensional scale? Of course I do, basically everything I think of, I have to think in words I know and cannot think in languages or other concepts I have never heard of. In a lot of open questions, there are a lot of answers from dimensions I would never even consider, but are equally valid or much better than those I would consider.

This means, that the quality of an answer to an open question is not defined by the number of other answers that were considered from the same dimension, but by the number of dimensions, that came into consideration in the thinking process.

My colleague could not have found a great solution by trading off the number of hours per story point to be 1, 2, 3 or any other number, but we could find a good solution together, by exchanging thoughts and experience with other people, that do consider other dimensions. It is not easy to think out of the box, I therefore propose to visit other peoples boxes and have a curious look out of their windows. Also dare to step out onto their balconies. I think this is a basic concept in teamwork, friendship and familiy.