The Importance of Liability in Software Engineering

Transcript:

Joe Krebs 0:10

Agile FM radio for the Agile community, www agile.fm. Welcome thanks for tuning in to another episode of agile FM today I have Jacopo Romei if I pronounced that correctly with me, based out of Torino in Italy. And he is my guest today got to speak about a topic today. It's called extreme contracts he published about this or long, long time ago in Italian. And just recently in 2023, he also finished his English version of his book, extreme contracts. So that's all available. He is also available at his domain name, Jacopo Romei.com. And we will also spell that out on the Show page. So people can just click on the website, as well as the three chapters of the book that will be available on the on the show page. But first and foremost, welcome to the podcast.

Jacopo Romei 1:15

Ciao. Hi, how are you?

Joe Krebs 1:18

I'm doing great. How are you?

Jacopo Romei 1:21

I'm quite good, quite good. Just a reference. My name is can be pronounced your from Germany and you can pronounce it very easily. Jacobo, the J is Ja!

Joe Krebs 1:31

Yah, cool. Boy, it is okay. Thank you. Thanks for clarifying. And it is important, right? So sorry about that. Extreme contracts is a word extreme in it. People in the Agile community familiar with extreme programming, maybe the first thing that would stand out is the word extreme. It's like, how does this relate? Why is it extreme? And why contracts? What's so special about contracts, I picked up a YouTube talk from you about extreme contracts, you're very passionate about contracting, work, and we just want to touch base on on that topic. So what's so different about extreme contracts versus regular contracts?

Jacopo Romei 2:10

So, u m, I've been a developer since 1996. And I've been an entrepreneur in IT. And then along the years, I shifted to where the broader range of knowledge work. Okay, so let's not to get too much into the details of my job. But and what I noticed when I was doing my intrapreneurial experience is that the commonly used contracts, were somehow capping the maximum performance of my companies, organizations and teams, and even I didn't do as an individual. And so I started experimenting with different and non ordinary ways to negotiate my agreements. And so I mean, I just asked myself, well, what if I could shape a contract from scratch the way I really wanted it to work and support my collaborations with my customers and providers. After a few years experimenting, I started in 2010. And then I realized that there were common principles among the most successful contracts and agreements that I made. And so since I was a very, I still am a very huge fan of Ken Beck's work, Extreme Programming Explained. Actually, I just decided to, to think in somehow in similar analogous terms, so basically, what the word extreme and extreme programming means, what if we bring everything that works every principle and every practice that seems to work? To the extreme? So what if we go from back in the time it was like from two years releases to one month releases? So what if we bring them to one weekly releases or daily releases? Okay, what, what if we go from one to 10? If we go to 11? Right, so I thought the same with negotiating contracts for digital work. And it worked, actually, after a few experiments that, that of the building upon I decided to, I needed a brand actually, I needed a name to, to name the, the group of principals. And so I decided to go for extreme contracts, who was actually that's what they are.

Joe Krebs 4:31

Yeah. And we want to definitely explore maybe one or two of those principles, if it see how far we're getting. But one thing that really stood out in your talk about extreme contracts in the first place, I think that was very deep as contracts are because there there because of a lack of trust.

Jacopo Romei 4:49

Yeah. I mean, I mean, after so many years, I still strongly strongly believe it. So basically, so what what What's the reasoning behind contract? So, we have to start working together. And we have to know whether you will be delivering you will deliver if you have to know whether our pay or not. So we have doubts, okay, we have fears, we are afraid that we will not be behaving correctly, right. And this fear, the fear of someone else not behaving correctly is called lack of trust. Okay, there is another name. And so contracts are basically a way to surrogate that trust into a piece of paper back in time or in an in an email or in a blockchain based device. And I don't want to get into the smart contracting part, it's not the topic for today. But contracts are a way by which we substitute trust with something that we hope will be enforceable in case things go wrong. And what I noticed along the years is that everybody everyone was had works with two groups of people, there is a bigger group of people we trust, and with which we don't need to send formal papers to sign agreements to be formal and discuss a lot the thing that we are going to do together, and there is another small group, usually made of new leads, that are asking us to, for long conversations, long calls, long video conferences, long email, much much information going back and forth. And actually, these two groups are also different for a long another dimension revenue. And actually, the most of our revenues come from the people we trust. And by the by which we are trusted. And I'm in. So I decided to create a set of principles, I decided to experiment with contracts, as I was saying before, to optimize the time, we require it it is required to build the trust that we need to go to shift the our leads from the first group, sorry, from the second group to the first one. So basically, how fast rather than optimizing contracts for failure recovery, so basically optimizing the contract for how well they will be protecting us in a court. So I prefer the contracts to be creating dynamics by which we go very fast to trust in each other. And in the end, eventually, maybe not even needing the contract.

Joe Krebs 7:40

So this is why so this is very interesting. You're not saying that extreme contracts are no contracts at all anymore.

Jacopo Romei 7:45

No.

Joe Krebs 7:46

that's not what we're saying. Right? What you're saying it's, it's more about, like putting the right content together. And there was another thing that stood out in your work is that a waterfall agreement will never work for non waterfall process.

Jacopo Romei 8:03

So I started carrying about it was 2003 the time in May, I started coding my first unit test. Okay, so I got into that. That's the day I I like to think as the my beginning in the Agile world, okay, cool. But after a few years, I realized that with my teams, or other teams, I even owned, we were we were going on discussing again, and again, the way we could improve our practices, our deployments, our bug tracking, our testing, and blah, blah. So all these technical end, even sometimes, even a bit. management practices, okay, like the stand up meeting, or the retrospectives and blah, blah, blah, but only know, every time in the end, we were required, required to deliver a fixed scope, with a fixed budget with a given quality that usually was not, there was never question which is absurd. And in a given then set deadline. And I mean, in the mean, thinking, I'm taught to think about the root causes of the problems. And when I investigated these problems, I ended up having often a problem with the contract with agreement with the expectations of the customer. And so I decided to fix that root cause, despite we can read in the Agile Manifesto that we should pray for collaboration rather than that rather than contract negotiation. But still, if contract negotiation is the roadblock for a proper collaboration, still, we have to fix that

Joe Krebs 9:45

right the scope, right? So when we're talking about scope off of any kind of effort, but isn't that like also based on your experience? Like I can only speak for myself here when working with clients? Isn't it also like a dilemma of business agility that we have have many flourishing product and IT organizations using agile and we have a very traditional procurement department. And when you work within these constraints, I mean legally bound, it is a legal document, you're signing it, and you're adhering to certain sections within your document. And if they are screaming waterfall, it is it is very hard to work this way. Because you do need to deliver, I would assume, right? You cannot just say like I signed a contract or now we'll work Agile is like it the contract itself might be in your way. But what's your experience with that?

Jacopo Romei 10:31

I mean, our experience is probably quite common, I agree with you, usually Procurement Offices are a roadblock in the true agility of the of any development experience. Still, okay, so on one side, if I if I were the one who owns the company, the organization, the one who basically paid those procurement officers to, to, to provide for a better for a good selection of providers, I would be worried because actually, we are we have a part of an organization which is somehow hindering the performance of the of the overall performance of the organization they belong to. So if someone owning procurement, or paying for a procurement officers in Now in this podcast, please, please, please, please question their work. Because actually, it's absurd that the strategy of a company gets set by a part of the organization rather than from the, from the organization itself. Okay. On the on the other hand, from from the provider point of view, I think we have a few things to try. First, there is a chance not that I will start from the most radical, just to say that it's not the only one. Okay, so I want to get rid of the most radical approach, which is there. It's a it's an option, which is not working for corporation or for bad procurement officers. But that's, I mean, that's too easy. Someone I know, does it and they're thriving. So it's possible, it's doable, and we can all we could all agree to starve procurement offices, the way that procurement officers around the world, but I mean, this is not really stick. I'm pretty aware of it of this. On the other. Second option that we have is there is one principle among the extreme contracts principle, which is called chaos in small doses, okay. And one thing that I cared so much along these years was to craft principles that could be somehow picked up cherry picked and adapted to our context, so that everybody, in their own context might find a solution to improve their negotiation their agreement. In the procurement department space, one thing that I that I learned to use was the principle called chaos in small doses models, which basically mean being shipped crafting agreements that are short in time, even keeping all other vital variables intact. So basically, considering all the other details the same, we could just shorten the amount of time, money and basically risk that we are exposing ourselves to, and work with those procurement officers with traditional rules in a smaller in a smaller time and space. Someone might argue well, but that's very inefficient, you have to renegotiate every time and you have to negotiate quite often. On the other hand, in my experience, usually the procurement procurement practices that we hate are usually meant to scale in a repetition quite well, sexually, they have somehow Taylorist legacy Okay, heritage. So usually after the first time after the kickoff after the beginning, repeating a collaboration with a procurement officers that have already that has already met you, it's quite easier and you can renew the agreement quite easily. If you have a good agreement, if you have a strong bond with the real actual buyer within the organization, usually at that point, the second the third, the fourth collaboration, the procurement office will not be a problem anymore.

Joe Krebs 14:46

Yeah. The very interesting that there would also be trust building I would assume starting in such small batches wide. You know, you go through a very small agreement, you get to know each other you work together. You're building a relationship with a procurement. And what's also fascinating about extreme contracts is that you really, you're highlighting already. I mean, we're in the Agile community, we're focusing on value, right? So it's all about value to be produced. And I think it's fascinating right now. It's, it's June 2023. Many people go back to work or have, you know, arrangements where they work certain hours at home, and it's more flexible since COVID. The workplace and even those things were like defined in the past, right? You will be having working hours and Monday to Friday. And in all of those things, and it is really, I think, what we're noticing when is it's a perfect example, it's about value, right? Where do you where do you produce the most value? Is it? Is it in your office? Is it in your environment? Or is it? Is it on the train? Or is it on a plane? Or is it at home? You know, where? Where can you produce the value, and I think if you are focusing on value, and it's one of your statements here is in you are actually free to focus on all of those things you would like to do like refactoring or unit testing, right? Because they're not, they're not part of of the contract anymore? You say you're focusing on value, but you're not focusing on the actual tasks to be performed? Faster? Yeah. Do you want to, you want to give a little context of why you came to that conclusion, which I think is great.

Jacopo Romei 16:21

Okay, so once, three things First, the usually, professionals are not aware of the value they create. So this is a main topic we could discuss about only this topic for like hours and hours, and we won't, but I mean, the point is, I usually when I ask audiences in conferences, like hey, what do you sell code? And actually, it's amazing, because actually, if I, I mean, Joe, if I ask you, do you, would you like, Would you be more glad to receive from a 10 kilograms of gold or 100 kilograms of gold? And I'm pretty sure you will answer as a gift. He will answer one under kilograms. Okay, fine. No, for the same problem. For the same automation of a solution to a given problem, would you like to receive 10 lines of code, or 100 lines of code? Gold is an asset, while code is a liability. Okay. So basically, if if we provide the same value for more code with more code, actually, we are having a big, so a bigger problem maintaining the code, fixing bugs, and blah, blah, blah, okay, and this is true for mostly, most of knowledge work, everything we do usually is not the value that we're selling, the value that we're selling is the reason why people are paying for us. And so, okay, this is what this was the first point, second point, if we sell our time, like in time and material contracts, but even in fixed price, usually you you are estimating for the amount of days that you will be working for the customer, right, you end up selling the cost and not the value of your delivery. Which brings us to the third most critical point. If we sell our time, if I sell to my customer, my hours, they are entitled to question the way I spend my time. Just actually, that's why they are buying. And instead, if we want to sell the value the problem or the solution to their to their problems, actually, all of a sudden, we become free to use our time the way we want. Yeah, you will get more leads nice. It's gonna be a website or newsletter or temporary shop in the main town. Okay. Okay, fine. But the point is that if you get more leads, and I can prove that I brought more leads to you. Actually, that's enough. And if I want to write unit tests, if I want to write documentation, if I want to share the burden with many people, or just alone, it's my business. And I want to decouple my knowledge work from customer interest. As much as we all decouple the work that was needed to build our glasses, our cars, our pens, from the price and the value that we assign to those objects in our lives. I don't know how much my pen is. I know how much is worth. But I know how what was its cost when the producer made it, and no one questioned it. But that's the reason that's because we don't pay the time of the workers that made our washing machine. And instead, we as professionals, knowledge work professionals, we keep on selling our hours. So don't we shouldn't get surprised to be questioned the way we use our time.

Joe Krebs 19:57

That's why early on is like this is where we're crossing from I think the word you said is professional, ethical, where the ethical example the software engineer, but I do want to go a little deeper on the liability thing you just mentioned, because I don't know if somebody might be listening to this and said, Oh, wow, we're 10 lines of code or 100 lines of code, do I really care? Do I really care if I get the value? And I would say you do care, right? Because you might have maintenance on 100 lines of code versus 10 lines of code, you could say, less is more, or maybe the 10 codes, the 10 lines of code might be very ugly and haven't been refactored. And nobody wants to touch that segment. So it's a liability, right. It's not like you can measure this in lines of code. And I think that is also an important point that I hope nobody's out there having a contract in places as you're writing 1000 lines of code every day. That will be that would be very sad.

Jacopo Romei 20:47

I've heard a few actually, along the years, I've heard a few and not only in one country. I mean, it's, I've read about this in forums, like by the end of the 90s, or like 10 years ago, I mean, it was like people getting paid by the lines of code. But also, I mean, another objection that we might hear is a but there might be value in writing more lines of code, if they are more maintainable if they provide with a more elegant and clear structure. And I agree, obviously. But I mean, this is nitpicking, if you want to get the point that we're making here, dear listener, you can.

Joe Krebs 21:31

This is awesome. Should we explore maybe another one? We already saw chaos in small doses. But but maybe maybe we do. skin in the game sounds very interesting. Maybe? Well, we'll take that as an example. And just to give people an exposure to that they can obviously read up on that in your book, extreme contracts, but skin in the game. I use that a lot myself, like for other references. How does that relate to extreme contracts?

Speaker 2 21:59

Well, I'm okay. So the saying skin in the game is quite old, but I'm using it in the same with the same meaning and the same usage that I learned reading Nassim Taleb books, anti fragile, and the Black Swan, and even the book itself titled skin in the game. So I'm using skin in the game as a device to reduce risk in all situations. Okay, so the main, one basic example can be if I ask John to build a bridge, and then I asked him to sleep under the bridge, for the first two years after I think I've been built it, probably John will be induced will be given a positive incentive for the quality of the construction, and for somehow providing all that redundancy that gives us safety in life. Okay, we got two lungs, we got two eyes, we have two pilots on planes. And if we go with risking things in engineering, we should provide with options and ways and redundancy to to provide us with ways to the riskiest situations. Usually, when we have designers and programmers and professionals that have no skin in the game, they sell efficiency, which is somehow a way to over optimize things, because the reduction of cost can be sold quite easily. Okay. So, for example, so if we asked John to build the bridge, and then we don't ask him to live under the bridge for two years, he might give us like, an experimental shape, or an experimental design new materials that have not been tested by centuries, and so on. And once in a while, I mean, I'm thinking about the city of Genoa, in Italy, where there was a huge bridge that fell down. I mean, yeah, I mean, the skin of the people in the game is a way by which we can induce a different landscape of rate. Okay, so let me be more concrete because actually, what I'm not saying that John would be somehow militious somehow trying to to game us, okay. But what I'm saying is that our systemic prudence kicks in when we ask people to respond for their their actions. On the other side, we want people to enjoy the results of work they do above expectations. Yeah. So that they have double incentive to perform is actually the problem. So one other suspicion of lack of skin in the game is usually that when I deliver late, I am punished some way one way or another, you can even be dissatisfaction mail. Okay. Right. When I deliver earlier, usually, I don't get any prize. And so I mean, this basically creates no incentive for me to deliver before the deadline. I'm only I'm only having an incentive to on time. Yeah, exactly. So which literally means slightly late, because there is not on time. So okay, so, and skin in the game is the thing that should be reflected in our agreements, I think people working together on anything should be enjoying benefits for over delivering, they don't have to be equal, but they have to be in the same direction. So basically, it's it's like, I mean, for the nerdiest out there, it's I would say that the vector is the point in the same direction but not having the same magnitude. And all the people involved should suffer a little bit of pain if things go worse then then planned that's usually usually usually especially in corporation, we have very huge asymmetry in which people deciding things are able to go away with short term advantages short term benefits and leaving the the mid-term, long-term harm suffered by someone else who was forced to be there, right, which is I mean, from an organization point of view, there is increasing the risk of failure and bankruptcy or failure in general

Joe Krebs 26:50

is a perfect example for a lack of skin in the game like for many offshore contracts, where the whole product was being outsourced offshored onshored, nearshored, whatever whatever it is, by the model, it is basically like delegating everything, but being in control of saying, Are you shipping the right product, which is obviously in a model like that extremely challenging, but also not having any skin in the game? If I if I assess this correct.

Speaker 2 27:17

let me give let me bring this point even further, we can say that traditional contracts have complete lack of skin in the game because fixes I mean, I would traditional contracts, I mean, or either fixed price contracts or timing material contracts, okay, I know there are many variation varieties, but basically, these are the two main, like, most of the contracts fall into these two categories. Both these categories of contract lack skin in the game, because in a fixed price contract, actually, the customer is shifting all the burden on the provider, if everything anything goes wrong, for any reason, even systemic reasons, okay. The provider, the supplier has to work past the deadline, which basically means this is nice, because it basically it means working for free, unless you plan for a buffer, which is basically planning for, for stealing money if everything goes fine. I mean, this this, this breaks my head. Yeah, in, in the case of timing material contracts, on the other hand, the risk is completely shifted on the other side, and if anything goes not as planned for any reason. And I mean, we started thinking it might be over in 10 days, and then it requires 20 days. I mean, who cares? The customer is going to pay. I mean, this is not exactly the tone. I expect when we are talking about skin in the game.

Joe Krebs 28:49

That is not going to create a healthy customer relationship, right, either. If you're thinking about trust again, right, where we started with our podcasts where

Jacopo Romei 29:00

we all go back to the way we try to build trust and the way our contract usually erode our trust. Yeah, that's, that's, that's completely crazy how we can I mean, many people might say, Well, yeah, but it's this is normal. I mean, it's so common, but normal is is a word with two meaning normal is somehow means frequent. But normal also means just right. Okay. And I don't think contracts which are not normal, should be normal.

Joe Krebs 29:32

That is awesome. Jacopo, now, yes, here we go. I want to say thank you for spending a few minutes here with me and talking about extreme contracts. I am super thrilled to bring this topic to Agile FM listeners, I think it's really, I mean, a lot of people probably look at templates and documents and contracts, etc. And you're like, maybe something's wrong with that, but I think I feel like an episode of like this and hearing it from you. And obviously you're publishing about this and as I said, beginning to our chapters available on agile FM link there. So you can just go in and start reading for at least three chapters. There is a bigger book in the making. So maybe we'll that's the starting point for, you know, changing the, you know, future DNA of contracts within organizations and obviously, focusing on value. Great name of it too obviously, resonates very well with the Agile community catchy. Thank you for making it and being so passionate about it. Thank you so much.

Jacopo Romei 30:35

My pleasure. Thanks to you.

Joe Krebs 30:38

Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.