DEV Community: Robert Nickel

Hammurabis Understanding of Evolutionary Loops

Robert Nickel — Thu, 17 Sep 2020 10:25:38 +0000

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 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.

The two Dimensions of an Increment

Robert Nickel — Wed, 11 Mar 2020 11:54:12 +0000

This post discusses the segregation of responsibility of an increment between technical people and business people. I experienced a very unclear understanding of this topic on both sides, which usually leads to wrong decisions and poor quality. I believe the proposed model will lead to a better sense of responsibility and therefore greater results.

Lets start by some definitions: An increment can be everything between a whole product, that was developed for years to a small feature that was developed in the last iteration/sprint. It has many dimensions. For this model we need only two of them: the business perspective (also referred to as functional), and the technical perspective.

Business people are those that work on the business perspective of an increment, by defining and refining the problem, doing business research, talking to stakeholders etc; they answer the "what?". In scrum these are the product owners (POs). Technical people on the other hand are those who tackle the technical perspective on an increment. They develop a solution to a problem, by answering the "how?". And they work in a team, why not call them "tech team" for this article. If the tech team says, they want to do a technical task that does not directly provide business value, but is necessary to keep the system alive, what should happen? Should the product owner agree to do it? The tech team as a whole is responsible for everything that happens on the technical dimension, including a sufficient level of quality ("We do not deliver Shyt!"), operations and security issues. Other examples are architectural, programming language and cloud platform related decisions, and there are many more. Since it is "their" solution to the problem, you call the tech team in the middle of the night, when the software isn't running! Additionally, they are the only ones that know how to fix it.

Therefore, the business people should not actively agree to the technical task, that was mentioned earlier; they shouldn't bother at all! The questions that are asked on the business dimension are often similar to "What do we need to do?", "What is our (functional!) priority?", "When will we be done with this stage of the backlog?" and "Should I take this as one feature, or rather split it into two?". The business people should decide everything, that belongs to the business perspective, and shouldn't decide anything that does not belong to that dimension. If they would do the latter, they would take away the responsibility of people, who are better at doing that, which is a guarantuee for a loss of value from a wholesome standpoint. The business peoples decision making power starts and ends at business questions.

This is a very clean and strucutural (and massively simplified!) solution to a typically "unclean" problem. I have worked with engineers who believe, it isn't their responsibility to take actions on technical topics, because they do not feel responsibile. The technical debt piles up, which leads to quality issues and paralyzation in the development process. But they want to get told by the business people, or at least get allowance, to deliver good quality. That is not what being a craftsman and taking responsibility looks like.

On the other side, I have seen customers and managers, who believe that the business people are responsible for everything, even technical things like architecture and quality. And of course, as common as the "unresponsible engineer" is the "I-will-take-it-all-business-person", who wants to decide on huge technical decisions or backlog items based on a two minute explanation. This persons often "allows" the tech team to decide on the smaller issues, because he "trusts" them with that. He mixes up the two given dimensions of an increment with importance or size.

To make this more clear, think of the following example: As a member of the tech team, I have to keep my operating system up to date and secure all the time. On the long term, there is no way around it in order to be able to develop a feature, and I am responsible to do this. The very important question here is:

Why am I responsible for doing this very small technical thing?

Is it because it is a technical thing to do, or is it, because it is a small thing? If the answer is the former: Great. Scale that up. You don't need to read this any further. If the answer is, because it is a quick and small thing, than you have that unclean structural problem that was mentioned above. There is no exact way in determining beforehand if a task is above or below a given threshold in size, complexity, importance, criticality etc. It is a subjective and discussable thing, that depends on experience, perspective and even the mood of people. At this point one could be tempted to think: "If it is close to that threshold, I will know if it is in my area of responsibility or not.". Yes, you might, but someone else might have a different perception, and this relies by far to much on that subjective metric. A very clear segregation in responsibility, between the business perspective and the technical perspective (and people who are well aware of it) is a good thing that leads to great results in software development.

Responsibility is the power to make decisions and absorb the positive or negative consequences.

In order to embrace the segregation of responsibility, I propose that you start by cleaning up your backlog (or any other form of todo list you have). Group the items in "functional" and "technical". If some items are on the edge between those two, focus on the functional aspects first and kick out the technical questions or decisions, they will follow. The functional items the the reign of the business people. If you are one of them: This is the area you can make decisions on, and you have to take the full responsibility for your decision. This is your area of influence, doing a great job here will be easier without having all those technical aspects in mind.

Now have a look at all the technical items. What you see is the reign of tech team. If you are part of the tech team: This is what you decide and take the responsibility for. Ask yourself for every legacy item you have: Which problem does my technical item solve, and is that really necessary and relevant? Clean up and discuss it with the other tech team members. You have to see the whole picture (the beyond-sprint-perspective), because you will be accountable for it.

Just to get this right. I am not proposing to reduce the communication between business people and technical people. As a technical person, it often is a good idea to challenge business requirements. The technical people will sometimes have to justify, why they decide for a specific framework or why you want to switch the programming language etc. But by all the technical decisions you do and execute, you should always (at least every iteration) also deliver things. Have in mind: the tools you use, are tools to solve a problem. Tools are not useful without a problem to solve. Talk to each other :-)

One concern I have often heard: How can you take away the responsibilty for big and time consuming technical backlog items from the business people? They will need to meet agreements and make promises about release dates etc.! That is a valid question, and the answer is underwhelming: A technical decision is equally not in their responsibility, as protecting the engineers from getting hit by a bus. They simply cannot control it, and they shouldn't. At this point, business people have to let go the urge to control that and trust the tech team, which will deliver solutions, which will lead to more trust. It is an upward flywheel.

I hope that this clarification about the dimensions of an increment, that should be taken into consideration when taking responsibility for a software project in any role, helps to build highly valuable software with less stress for every involved person. Please keep in mind, that the more formal segregation I propse is no silver bullet. It is just a small piece in the big puzzle of software development, that can only work, if you have a non-broken tech team, that is abled and willing to take responsibility.