Iteration Zero and Continuous Delivery

[00:03] (external link, opens in new tab) Before we actually talk about unit testing what I'd like to talk about is how I like to structure a new project in terms of setting up a methodology because I believe that this is a a good start to the project gives it a good runway to continue and a bad start to a project. What's a bad not a bad start, but a start that's not configured correctly can lead to a lot of a lot of extra work later along the way.

[00:36] (external link, opens in new tab) So, for example, on the first iteration of a project, what I like to do is to have what I call a shipping skeleton (external link, opens in new tab). It's how I write skeleton skeleton. Now, a shipping skeleton is basically a continuous integration (external link, opens in new tab) configuration. It's it's a it's an empty project that only outputs something like hello world.

[01:09] (external link, opens in new tab) Okay. And what I'd like to do is then to take this little piece of hello world and take it through all the actions until I can call it released. So if I have a kanban board with X amount of steps, I want to be able to have a shipping skeleton that has made it through those X amount of steps and I want to automate as much of that as possible. So if that means unit testing, if that means integration testing, if it means deployment,

[01:39] (external link, opens in new tab) Great. So for example deployment if I have to deploy to some kind of a hardware then I will on the first iteration set up the hardware that is maybe staging that looks like the real one maybe in software that looks like the real one but also the actual one where it will deploy it. So if I'm deploying to a machine, I want that machine right there in my development room and if the machine cannot be in the development room, I need the machine right there where the product owner is because I want to be able to deploy all the way up to here automatically in a few minutes hopefully and just say, "Okay, I just deployed." Then call the product owner and say, "Hey, do you see a hello world on your machine right there?"

[02:19] (external link, opens in new tab) And that's a good demo. That's how I want to be able to see and get feedback as quickly as possible. Deployment means that you can get feedback. Deployment means that you release continuously. So a continuous release solution that uses continuous integration servers like team which I like to use are an example of something that I would set up all on the first couple of weeks. So I wouldn't write any actually functional code. I would just have a product that doesn't do anything that has gone through all the steps that I can demo as quickly as possible to someone

[02:54] (external link, opens in new tab) Can tell me how wrong I am. Okay. So, the purpose of this is to hear that I'm wrong or to hear that I'm right. And usually it's to hear to that that I'm wrong because you cannot be actually right about what you're building on the first month of a product. you're probably going to be wrong up until the last month of the product, but you're going to be less and less wrong as time goes by. So, the idea is that you start with the notion that you're probably wrong about what you're trying to build. And so, you want to get it out to the customer as quickly as possible so you can remove all those wrong assumptions.

[03:30] (external link, opens in new tab) So, if it takes me 10 minutes from here to here, that's a good feedback cycle. it takes me 10 hours still better than having it two weeks. And if you think about iterations and a lot of times in projects I've seen people do iterations where they only show a demo at the end of the iteration. If you have heard of scrum or things like that, show demo every two weeks or every three weeks. Why why not show a demo during the iteration and fix what you're doing during the iteration?

[04:04] (external link, opens in new tab) You if you if you have that kind of setup, a shipping skeleton, then all you have to do is then once you deploy, you get rid of all the hard stuff cuz getting all this stuff going like getting the machine and getting it approval and opening the firewall and h having an IP setup and all that stuff, you're going to have to do that anyway. But once you get rid of all that crap at the beginning, then all you're left with is to fill out all the details in a product that's empty, only says hello.

[04:39] (external link, opens in new tab) And then you say, okay, deploy it. Oh, it should actually say hello world. So you deploy another one and then you add one and you just fill in the details from that moment on. And then release becomes boring. Demos become deploy to demo is is just another things that you do. It's just you press a button. And so there are no end of iteration demos because end of iteration demos are like a ceremony. We don't need a ceremony if we do this. The only ceremony we need is the the phone call after a deploy

[05:09] (external link, opens in new tab) Telling us how wrong we are for something or someone coming into the room and say, "Yeah, that's not what I meant." Okay. Now, as part of this, now this is the this is the backbone of a development cycle. That's the heartbeat. Okay. So, if I can deploy 10 times a day, I have a heartbeat of 10 times a day. I used to feel that the heartbeat is the is continuous integration. So, as as long as I can check in and build and things would pass, then that's great.

[05:44] (external link, opens in new tab) But if I don't deploy it, it doesn't mean anything. I could be right until I find out that I'm totally wrong. So the purpose of this deployment is that deployment is an example of compiling. A deployment is a form of compiling your code against reality. That's how you should think about it. Just like if you work in languages like C, you write the the code, but the compiler will tell you immediately whether you got it right or wrong. Right? Now when we write in Ruby, we don't have a comp compilation step.

[06:19] (external link, opens in new tab) >> That's that's a heartbeat right there as well. >> But the the reason we have one of the one of the ways to know you're right or wrong in Ruby is to write as many tests as possible. But being right or wrong against whether the code is correct is not the same as being right or wrong against the product owner. So deployment is a form of compilation and you should do it as as much as you do actual compilation almost. Now before you get all this done there is another form of requirements gathering.

[06:54] (external link, opens in new tab) So you do this but then you start plugging things here and here. For example, what goes up in the top here? Here you might say oh I'm writing the specs. This is where tools like Cucumber (external link, opens in new tab) would fit in because in Cucumber you can have the product owner and you collaborate on writing something in a natural language in standard s sentences which you can then transform

[07:24] (external link, opens in new tab) Into acceptance tests (external link, opens in new tab). Okay. Now acceptance tests are very high level. They're basically the stories that say this is what is supposed to happen in the application. They are a form of compiling against reality (external link, opens in new tab) in a way. They're just one level below product owner test. Product owner test is the product owner actually using your product physically manually saying yeah that that's cool or no that sucks.

[07:56] (external link, opens in new tab) So acceptance tests are a way for you to try to capture as much as possible from the product owner and automate checking that stuff. And once for example, you might have a story here that says I should be able to log in to the system. I log into the system and then I should see something that says hello, you're logged in. This is your username. Now to accomplish this high level user story you might need to you it might fail for a long time.

[08:29] (external link, opens in new tab) It might fail for a few days and then you fill up that user story by writing unit tests or maybe some integration tests. You might have rights to write maybe 15 or 20 or 500 tests to get a single user story running. So this is going to be red and you might check in. going to be red for a long time but at some point it's going to be green then you can say hey when we deploy can you also look at this user story because it's passing now so an acceptance test that was written in something like cucumber you can use as an example of what to demo

[09:08] (external link, opens in new tab) Okay so that's that's where that's the that's the way I think about the life cycle in the simplest form is that you write specs either continuously or at the beginning in iterations or not just the beginning of the product because the understanding of the product owner also changes continuously and reality changes. You can never have the the perfect specs. If you think that you can write great requirements for three years and they will never change that's very very optimistic.

[09:40] (external link, opens in new tab) Okay? Because what actually happens that I used to go talk about this if if you think you can get the perfect requirements because a lot of people think oh this project failed because we didn't get the requirements just right if we only got the requirements just right then we would have done the right thing but even if you talk the took the product owner got all the requirements right you would sit with them for two months and just got all the requirements you would have a book and then you would take the product owner and you would fire them.

[10:12] (external link, opens in new tab) They can never talk to you ever again. You would cut cut their vocal cords. Okay? You could never take the requirements can never change. Still reality can change. So the requirements can don't make sense anymore. For example, oh we we're switching to a new type of hardware. Or the competitors are now doing X so we cannot do Y anymore. So things will change and even the person who gave you the requirements doesn't know it yet. So specs keep changing and updating continuously with the application

[10:44] (external link, opens in new tab) Because that's the only way that actually works and that's why you need the demos as well because it even if it works according to the demo or the acceptance test reality might change and then you go ahead write new specs and change the program and so that means that the program like a book can never actually be finished. It can only be snapshotted to the current reality and say, "Okay, it's good enough for what we need right now. Okay, you can never have the perfect program with just the right amount of features because things change." So it can be perfect for the current time.

[11:19] (external link, opens in new tab) And so at some point, maybe after a year or two years, you'll just stop the project and you won't develop to it anymore. Or maybe in a while you'll start developing for it more. But it can never be done. You can say that when all acceptance tests are done then the project is done but then more acceptance tests can be added. So it's only on the mind of the product owner when the project is done. That's the only thing you cannot say we're done when all these pass. Does that make sense? Are there any questions about this?

[11:51] (external link, opens in new tab) So if you're starting a new project tomorrow, the first thing I would recommend is to have this backbone with either machines, hardware, software, everything. Just configure everything. So we have a pipeline, a build chain if you will where you can take something from zero to 100 and actually show something. Okay? And then you'll go to your product owner say, "Tada." You say, "What? You just showed me it says hello world." What? I said, "Yes, but this hello world, you know how how how

[12:25] (external link, opens in new tab) Far it traveled to get to you, right? Like you got a ladder with a with a stamp on it, but you know what that stamp had to go through to get to this letter so your eyes can actually see it." That's the build chain right there. So, you invest in it and once you get it right, you can just start publishing things. Just publishing things immediately almost. And that's a great feeling because you feel productive and you know you're on the right track because you actually see the demos question.

[13:18] (external link, opens in new tab) They offer. >> So, how do you >> Okay. So, first I'll just repeat it for the sake of the video as well. How can you actually keep everyone happy in a situation where everyone keeps changing their mind? And the answer is it's okay that they're not happy that you keep changing your mind if you're the product owner because what is the job of a developer? What is the job of a team? Is to answer the requirements of the customer, right?

[13:51] (external link, opens in new tab) So if you decide that it's too annoying to keep changing their mind, then you start having like contracts and then you get to situations where you say, "Okay, you said we have to do X, but if you change your mind, you have to pay us." That's that's what consulting companies do. You have to pay us $1 million because you changed your mind. And now what happens? Well, the customer said, "Ah, but so you you're treating like like that.

[14:22] (external link, opens in new tab) Okay, you promise it's going to take x amount of time, x amount of money. If you get it wrong by $1, I pay you $1 million less. How's that?" And then it becomes a war, right? So instead of having that awful awful war, what we have to understand that our job is to answer the current requirements of the customer. If the customer wants to keep changing their mind and they're paying us, that's okay. They can change their mind for 10 years because it's their money.

[14:56] (external link, opens in new tab) If I want to change the color of my car every week and I have the money to do it and I take the car to a paint shop every week, do they care? No. They say, "Oh, I will take your money. Thank you." That's what they do. If you're the you're developers and you get paid the salary to get the product working according to the requirements of the customer, that's what you do. That's okay. Now, it doesn't mean that there are no trade-offs. When people keep changing their mind, there are trade-offs for keep changing your mind.

[15:29] (external link, opens in new tab) But your architecture has to support the ability to change some things. So, the architecture needs to be able to support change. But there are costs. For example, you can explain the cost of changing the mind and then the customer can decide whether they want to change their mind or not. But the cost is not not necessarily they have to pay you more money, but it's about time. So if we look at a triangle of resources, you probably know this. Everything in software can be about time, about quality or about the features.

[16:05] (external link, opens in new tab) And you can only pick two of these at any one time for any project. That's usually what happens. You can have something really quickly with great amount of features, but the quality is going to suck. You can have time with a good quality with a high level of features, but it's going to take a long time. Okay. Now, there's actually a fourth resource if you think about it, which is the the the amount of people or the amount of money that you spend in. So you can replace it that one of the these becomes money instead of time.

[16:36] (external link, opens in new tab) If you say no this is money okay because time is money in a way you say so you can spend a little money you get a lot of features but the quality is going to suck or you can you can have high quality and you but you don't have a lot of money you're going to have less features. Okay. So there there is always a power shift there. So the there is always a trade-off. Now if you have that trade-off system,

[17:06] (external link, opens in new tab) Even if you if you even if you don't write it down, you you're still paying for that trade-off anyway. So whenever a customer changes their mind, the answer is yes. What do you want to do instead? For example, someone says, well, it shouldn't say hello world. It should say goodbye world. Okay. Now you're already working and you're let's say kanban style and you have these nodes to do and you have these done and you have one done.

[17:37] (external link, opens in new tab) You say okay we're currently working on all these things and these are in the backlog. Now you just introduced this new feature right here. Do do you all know this? Have has anyone ever worked with this kind of board before? This is not a kanban board. This is just a task board. A kanban board is something that's that that has a bit more rules, but you have a a to-do, you have a progress, new progress,

[18:07] (external link, opens in new tab) Done it. That's the basic three situations. And every time you have something, you start working on it, you put the note here, you finish working on it, there basic stuff. So if someone comes to me and says, I want to change my mind. I don't say no because it's not my job to say no. It's my job to say yes. is a team leader but I say okay how what's the priority of this new note and I take them to the whiteboard to the task and say okay which note should we remove or to put just below it is this more important than this and then now it's a question for the customer to decide is it more important for me to have goodbye world or to actually be able to do the login first which one is more important it's not about which one do you want instead it's which one do you want first because it's all about priorities.

[18:56] (external link, opens in new tab) You can have a million features that you want to build, but you're probably going to get maybe 500,000. Which 500,000? The answer is in the priorities. That's why you prioritize. And so now the customer is the one that decides whether they actually want to say yes or no. Well, this more important than this? Yes, it's more important. I would want to do this. Now the customer is taking the responsibility for changing their mind because they're paying the money. They should take the responsibility for it

[19:27] (external link, opens in new tab) Because we're not the ones who should say no for that. The only thing we should say is what's the priority of that. Okay? Because when we take the customer and we show them this least list, then they can actually see in context what does it mean for their decision to be enacted. It means that this feature will be delayed. means that feature will be delayed. Okay, now they can say, you know what, maybe it's not as important as I thought. Make sense?

[19:58] (external link, opens in new tab) Did that answer the question? Because I started this whole thing. But >> but it's it's a very loaded subject. But in the best teams that I was in are teams that never said no. They always said yes, let's go to the task. And then the customer felt much more in charge because they could make a decision and say, "You know what? This and this are no longer important. Screw this. I know you're working on these two. This one is so high priority.

[20:29] (external link, opens in new tab) You have to stop working on this. Put it back in the to-do and put this on the on the task." And they can do that. And that's great because this is exactly what we're supposed to do is to we are the tool to enable a product to be developed. It has to be the right product. So, it's good that they're changing their mind. Okay. Now, maybe one of the reasons those developers might like to have all these tests passing but not ask the product owner whether they're the right test is because they know that their product owner keeps changing their mind.

[21:00] (external link, opens in new tab) Developers hate that. But that's okay. That's their job. I think it's the developer's job to to do things and things change and that's okay. I hate it too, but things change. Sorry. Okay, other questions. Okay, so that was that part. You have more questions? >> No, it's more of a really >> Yeah, >> this triangle is good example stud.

[21:35] (external link, opens in new tab) >> Well, it's it's true for all projects even if they're in the middle. >> Yes. But the reason why these guys >> maintaining it >> maintaining it. >> Sure. The theory has been

[22:08] (external link, opens in new tab) Discovered. >> Mhm. >> The size of that triangle from that big love. >> Well, to to me what it sounds like is if you want to have high quality so that the application will be very maintainable and you don't want to mess with the amount of features yet, right? So you're just choosing the instant and you're willing to spend more money on it because the amount of time you have is fixed. >> Actually the amount of money you have.

[22:40] (external link, opens in new tab) >> If the amount of money you have is fixed then you can only choose the amount of features. >> So you get to choose these things. So you say okay I don't care how many features we get but they have to be really high quality because we have fixed amount of time and money. And so it's okay to let go of some features. That's a trade-off. And that's something that you have to keep in your head is that when you do these things, features take longer and you get less features done in the same amount of time. And that's okay because I like to to use this analogy again when we're talking about

[23:14] (external link, opens in new tab) About quality is that when I go to the car mechanic, he doesn't ask me whether I want to get the car fixed good or not good. Right? He doesn't give me the choice of whether I want the car fixed in a way that will work for a long time or just for today. Almost never unless it's a really big difference in amount of money. Like look, the this part is gone and there is a very cheap part and there's a part that costs a million dollars because it's a Ferrari.

[23:49] (external link, opens in new tab) You get to choose because it's a million dollars. But usually a mechanic will just do the best work they can and the time is the time it takes. There is you cannot argue about the amount of time. And so for for for code I usually don't argue about unit test. I don't give people the choice whether to write unit test or not. It's just the way I work. The way I work is that features take longer than other developers because I work with unit tests. But I don't give people the option to remove the unit test.

[24:20] (external link, opens in new tab) When I buy a car, I don't get the option to remove the wheels. It's just part of the product. I don't ask people whether they want me to debug the code or not. It's part of the work. So, unit testing is like debugging. It's something that you do between you and your computer. So, it's about professionalism. It's about the way you work. It's about being proud of the code and being able to look at the code in a year and not, you know, want to kill yourself either because you have to maintain it or because you can't believe you were that stupid at some point.

[24:50] (external link, opens in new tab) So, it's about many things, but it's also about maintainability over time. So, yeah, it sounds like you made that choice, which I highly agree with, by the way. Yeah.