 If people will be just wandering in, that's fine. We can get started. So we're going to talk about evolutionary design. And we'll talk about why first of all to achieve evolutionary design. Then we'll talk about how to really do it. And then we'll look at some examples of all the way. And we'll also talk not just about technical things, but we'll also talk about certain things about how to really work together as well. That's the integral part of how we can be successful in doing this. So let's get started. This time to ask a question or make a comment is when you have it. So please don't wait till the end. Any time is a great time for questions, comments, things that may have worked for you, things that have not worked for you, just about anything. It's a good opportunity for us to mingle, ask questions, discuss, so don't hesitate at all. So let's talk about why should we look at evolutionary design? Why should we not just be happy in designing and then coding? So if you really look at software development lifecycle, in the old waterfall approach, we had the faces for requirements gathering. And then we had analysis design. And then we had implementation. And then we had testing. And then we would have other stages like maintenance, what have you. Now, the problem in this particular approach is that when you have these kinds of clear faces, we call this the waterfall approach. It turns out that the gentleman who created the waterfall approach, Winston Royce, really didn't mean to create it as waterfall at all. I think of one of the things that was understood and misunderstood, major big night. In his paper, he actually says this doesn't work. He actually says, for you to be successful in this, you have to repeat this cycle very frequently. And you may say, well, why did this become so popular? Well, one of the things we have learned over time is we don't have patience to read. And one of the things also is, why we want things to be simple, we are quite happy with simplistic things that are easy to comprehend. And it turns out in his paper, he had two pictures. And one picture was this diagram that said, requirements, analysis, design, implementation, testing, as a nice block diagram. And below that diagram, he had a little note that said, this doesn't work. But somebody who read this diagram, kind of looked at this diagram and said, I get it. This is easy. And then he flips over, and there was a complicated diagram with loops and feedback cycles. And he said, this is complex. I don't want to look at this. And he went back to this page, and he photocopied this diagram, leaving out the note that said, this doesn't work, posted on the log, and that became the practice that everybody started following. Now, you may look at this and say, well, if this is so bad, we have to blame somebody for creating this. How can we blame for creating this? Winston Royce cannot be blamed, because he didn't really mean it. Winston Royce's son has been going around the world saying, my father never said to do this. In fact, every time somebody uses this, probably turns in his grave, so who can be blamed? Any ideas? Satitions? Don't be shy. I'm just trying to get you to talk. Yourself? Oh, come on. We are innocent. We are victims of this as much as everybody else. We cannot blame ourselves. You're being modest, but no, we don't want to blame ourselves. Folks can be blamed. And I don't say managers for guys. They are also victims of this. Yeah, you have a suggestion? You're going to say managers? No? Anybody else? So if you don't know whom to blame, whom do you normally blame? The government. That works really well as in there. So let's blame the government. Well, in fact, in this case, it's OK to blame the government. Because what the government did was, remember how government always promises to spend wisely over money and waste more money doing it? In this case, it was the Department of Defense at the United States government. And they said, let's go get a bidding for doing software. And you know how they ask for bids, and you want to make sure you spend the least amount of money building something? And when they said we want bidding to build software, they got a bid. But somebody in the department said, hey, here's an idea. Why don't we ask for a bid for each of these separate phases? Can you bid for requirements gathering? Can you bid for analysis for design for implementation? And when they got these bids, they found something interesting. So they had all these companies, C1, C2, C3, C4. And each of them coded a certain dollar amount for each of these different phases. And what they found out was they had a total cost at the very end for each of these companies. But something less than any of these values was by taking the requirements gathering cost from one company and taking the smallest amount for analysis, taking the smallest amount for design from another company. And when they cherry picked each of these companies that coded the least amount of money, and you total all those values, guess what? That sum is less than any of these amounts. And they said, aha, look how we could actually bid this project for the least amount of money by giving this work to different companies. Well, then what happened? Well, the first company came in and said, what do we do? We don't want to build the software, just do requirements gathering. Oh, done, one day delivered a document and went away. What does the second company do? They said, well, fine, here's the requirements document. We drew a picture of analysis, we are done. And the design company said, what do we do? These guys already have an analysis model. Well, let's add some color to these documents, right? And they gave another picture and walked away. And then finally the company that was supposed to program, also known as the victim company, eventually came to program it. And what did they find out? That none of this ever made sense. And they're sitting there and working and working and working and they couldn't get the work done. Now, I remember being on one project. And this was back in time several decades ago. I was on this project. And I saw this project schedule on the wall. And as you enter the company on the wall, there's a schedule. And guess what, everything was black in color, which means you are on schedule. Well, that's good news, right? You've not already failed before you start on the project. That's good. And everything was on schedule for a while. And everybody was happy until we got to the design phase completed. We got to the programming phase. And you start seeing reds. And we are already slipping. And I remember one day the manager telling on the project, you know this project was going so well until these programmers got together. And if you look at the programmers, the project will never fail. Now, why do things fail when programmers get together? Is it because programmers are stupid? Is it because they cannot get any work done? Well, no. The reason is, how do you validate a requirements document? You can spend seven hours reading it. But is it a validation? How do you validate an analysis document? How do you validate a design? Well, I don't know the answer for a lot of those questions because there's no good answers. How do you validate a program? Very simple. You run it. And what happens when you run it? You use it. And what happens when you use it? You hate it. Have you ever written a program where you write the code and you show it to the users and the users come and hug you and say, this is excellent. This is exactly what we wanted. You guys are rocket cool. Have they ever said you that? It happened to me once. And then I got this double worker from my dream. And I wish I had slipped longer. But in real life, it never happens. You show something and they're like, well, that's not what we really wanted. Hey, but your requirements document says that's what you wanted. Well, that's not what we meant. This is called the observer effect. Observer effect is the minute you observe, you want to change it. You no longer want what was told. You want what you want now when you observe it. So observer effect is something we have to be very careful about. And the simple matter of the fact is that you can never freeze requirements. You can tell you want to freeze requirements, but your customers are not going to do that. They want change. And they want change all the time. They want to change the application as they understand better. And what you really want to afford is that change. So if you're going to be designing your code, you're designing your software, and then come back and implement it, that never works. One of the mixed-down of our field is that there is design, and there is coding. No, there is no design and coding. Coding is design, and design is coding. You can draw pictures, nothing wrong with it. And you can visualize and try to abstract what you're thinking. There's nothing wrong with it. But that is not a full design. That is a part of the design idea. I probably have heard people tell you that they drew all these design diagrams, and I've done that in the past. I used to spend countless hours drawing design diagrams. And I've told this, and you've probably heard other people tell you this too, right? Have you heard people say that the code has deviated from the design? Have you ever heard that being said? The code has deviated from the design. Oh, no, that's not true at all. The code never, ever deviates from the design. The code always in sync with the design. What they are telling you is that the design has deviated from the design document. Well, there's one way to fix it. Don't document the design that way. Then it never deviates from the design document, right? And what if you can visualize the design very quickly? Then the design document is in sync with the design, never print it. Because if you ever print a design document, even before the design document dries up in its ink, the design is going to change. So you cannot capture it. So think of a design document as a map. Imagine you live in the city, and you have a map. And you travel abroad. And you come back in three years with exactly the same map. And then you go to a corner and say, wait. This says there's a street here. I remember there's a street here. And how come there's a temple right in the middle right now? And then you say, the city has deviated from the design. No, you have an old map, a stinking old map. You need to get a newer map before you come back to the city, right? So that's exactly how design is. Design constantly evolves. And it's living and breathing in the code. And why can't we design all up front? And the reason why we cannot design all up front is there is absolutely nobody on earth who can think about all the details thoroughly ahead of time. Nobody can do that. If somebody tells you that they can do a fantastic design, and they can think through everything, there are only two possibilities. You are talking to God himself. Or you're talking to a moron who has no clue. And what are the chances, which one this is? If you have the divine presence, absolutely use it. If somebody tells you that they've designed, and once they've finished the design, they never, ever changed it. What they're telling you is their project got canceled. Because any project that is relevant has to change and evolve. Why should it change and evolve? Because our understanding of the situations change and evolve. And that is the reason. Now this is common sense. But common sense is not common after all. Now think about how would you plan a trip? I travel almost every week. And I travel with very minimal luggage. Why? Because agility is very important. Time is very important for me. I plan a lot of things. But how do I plan a trip? How do you plan a trip? Well, the way you plan a trip is, let's say you want to book an air ticket. What if I try to book an air ticket the night before I travel? Let's say I want to go to London tonight. In fact, I'm going to London tonight. But let's say that I don't have a ticket yet. And I'm going to go buy a ticket right now. What do you think? Is it a good idea or a bad idea? Be loud, be vocal. Good or bad, one, two choices. Bad idea. Why is it a bad idea? Thank you. That's absolutely correct. The airline would want me to turn all my properties over to them. And more. It's cost. Cost is exorbitantly high if I buy an airline ticket today. So what should I do? As soon as I confirm my trip with a certain amount of reasonable expectation, the first thing I do is I buy an airline ticket. Why? I want to reduce my cost. Makes sense, right? I want to decide where I should have my meal on Tuesday night. So three months ago, when I bought my airline ticket for tonight, I'm going to find out where I'm going to have my meal on Tuesday night and call up that restaurant. And I'm going to make a reservation for 7.15 PM. Good or bad? Well, OK. Sometimes the answer is, depends. If I'm having a very important meeting with a very big dignitary, maybe that's a good idea. But you say, I'm going to get you wailing your tennis shoes here, what are the chances you're going to meet somebody important? OK, fair enough. So it's a bad idea. Why is it a bad idea, though? No worry about being wrong. It's perfectly OK to be wrong. There's no right or wrong answer. But why is it a bad idea? Yes, Karthik? And certainly, you would not take your request. He may not take my request. Maybe this guy says, oh, this is an important restaurant. Maybe it is. And decides to take a restaurant. Maybe he takes my request and throws into a trash bin. So why shouldn't I do it? Say that again, my priority may change, correct. But there's another problem also, right? The cost of doing it early is high. Now, wait, wait, wait, wait. How is the cost of doing it high? You're saying, Venkat, why are you wasting your time instead of doing something more useful? You're wasting your time calling a restaurant, which you can just walk into and have a meal. And you took a precious 10 minutes of your time when you could be doing something else important. Remember, any time you invest time on something, you are taking time away from something. So be very wise in what you choose to do, because there are so many other things you compromise on doing. So it's very important that we spend our time wisely. So that's the high cost to me. And I would say, look, I may not even be hungry on Tuesday night. Or I may be in a different meeting. Or maybe I might work. And a colleague says, do you want to go over here to this ballpark? And maybe we can have a watch a game and have a meal. I want that flexibility. I don't want to make my decisions ahead of time. In other words, if the cost of something is very high, then do it early. If the cost of something is low, or if you want the flexibility, or you don't simply know, then postpone it until the last responsible moment. Because doing it early actually costs more. But oftentimes we don't think about it. And I'm very sensitive to this. When somebody calls me and says, can I talk to you about this? I say, no, you cannot. I'm sorry. I don't want to invest my time on this right now, because this can wait for later. That's normally my answer. I tell this to almost everybody, my boss, my wife, which is even more difficult, and to a lot of other people. And I say, no, I'm sorry. I cannot invest my time on this right now. It is not a good investment on my time. Because we don't need to make this decision now where it can be decided later. So that is something to keep in mind. But why evolutionary? Because honestly, we don't have a clue. We really don't. And there's nothing wrong with it. It is an admission that we are in a field where things change very rapidly. And we need to really support it, not be in denial of that. That is very important. And that is why we have to be evolutionary. Design never happens in one sitting. It always has to evolve. And by planning ahead, we actually fail. But it's even worse. What happens is we create a design in the beginning, and it no longer works. But what do we do? We hold on to it. Why don't we hold on to it? Because we did it. How many of us have the courage to go back to work and say, all I did yesterday is stupid? I got to throw it out and start over. How many of us have the courage? Very few people have the courage to do that, right? Why? Because we feel we will lose the respect of the team. What do you mean? We hired you to do this stuff. And you tell me you wasted an entire day yesterday doing this, right? So what do we do? Hey, you know what? It doesn't matter. It doesn't work. Hold on to it. We do this, right? We do this because we have to hold on to decisions we make. But what if we have the courage to say, no, I am not going to do this now because I don't know enough. I don't have the information on my hand. I'm going to postpone this. And I will do this as soon as I know about it. So let's talk about architecture. Now, again, don't hesitate to speak up. What is architecture? The basic layers. I heard the word layers. Anything else? A blueprint? Excellent. What else can you think of? A broad framework. A broad framework? Awesome. Anything else? All of those are right answers. Absolutely. It's a technical stack. I would normally say it is a higher level or a coarse-grain design. A design is fine-grained. And architecture is a coarse-grain containing layers of framework of components that interact with each other. Absolutely, we can think of all of these. Well, let's think about this for a second. Let's say we are starting on a project. And when we start on the project, we are often asked, what is your architecture? Now, my recommendation is, you must be able to create an architecture document, which is less than five pages long, hopefully two pages. If you give me an architecture diagram and an architecture document, which is 100 pages long, anybody has come up with a document, a design document, that's given to you on a project, which is that big? Have you ever seen one? Come on, you all have seen it, right? Yeah? Yes or no? Yes. It's been given to you, right? You're new to a project, what do they do? Here's your design document, go read it. Now, so you've been given a large document. Raise your hand if you really read it. Nobody in this room, right? Raise your hand if somebody asked you if you read it and you kind of said, yes. Yeah, we see the hands go up, right? We all do, of course, we all do, right? In fact, I'll give you a challenge. If somebody gives, if you're asked to create a design document, which is 100 page long, take the document on the 30th page, OK, 31st page. Put a thousand rupees in it. Go ahead, it's well worth spent. And give it to this person who's supposed to read it. And then when the person comes back and says, what do you think? Great document. Did, was there any doubt in it? No, crystal clear. Everything was good. Thank you. And then say, can I look at the document again, please? And open page 31 and guess what you're going to find. That thousand rupees. And they say, did you notice this? And how, what are the chances that this person was so honest that decided to leave it there for you to pick it up later? Right? Joseph Capulot, Pastor Kenan once said, he has never come across any human who was interested in reading a 17,000 page document. And he said, if he ever finds one, he will kill him to get him out of the gene pool. So the point is really very simple. No one has the patience and the time and the interest and the ability to read and comprehend such a document. That's just not going to happen. So if you want to give me an architecture document, you must be able to tell me what that layer is, what the big picture is, and you need to be able to give that to me in just about five pages or less. Then you have a chance of me reading it. But let's talk about the architecture for a minute. Suppose this is a timeline of a project. When do you normally create the architecture? Initially, maybe here, right? Sometimes even here, even before we start. Let's continue. Continue, well, who's that? All right, there, okay. We'll talk about that. So, leave the thought aside for a minute. Now, let's say this is your project timeline. Now, imagine for a minute that your project, this is the knowledge level, stuff you know about the project. Not stuff you think you know, but you actually know. A lot of times in a project, you think you know everything and then you realize you don't. But knowledge you already have on the project. Would you say that the knowledge you have on the project is kind of like this? Is that a fairly good statement? You don't have a clue about what the project is. As time goes on, you know a little bit more about the project. And maybe about 40 to 50% of the time into the project, you know most of the unknowns on the project. This little project is very similar to what you already used to. Is that a fairly good statement? Yeah, that's how the projects are normally, right? You start from the unknown and you go to the unknown. Now, let's go back and do what we just did. What we just said was we will create an architecture. Oh, by the way, how important is architecture? Yeah, we don't care. My God, it's very important. You better not get it wrong. Which one it is? Very, very difficult to change, right? Very important. Don't mess with it. It's very important. It's sacred, correct? So what we just said was, we said we will do something extremely important, something we cannot afford to get wrong when we have no idea what we are doing. Does that make sense? You were mentioning about the architecture document, about less than five pages, approximately two pages. Just wanting your perspective on what are the sections that you would look at from that architecture document? There is absolutely no requirements. The things that you want, I'll get back to that in a minute. Let's hold on to that question. I'll come back to that. So what do we, what do you think of this idea? Does it make sense? That we would create something so important that we cannot afford to get wrong when we have no clue what we are doing. This is called predictively irrational. We do this all the time as human beings. We'll do something which makes absolutely no sense. And why do we do it? Because somebody else said we have to do it. Or somebody frowned on us and said, you don't even have an architecture document. You don't even have an architecture? And you guys are developing a software? And now what do we do? We better have one, otherwise they'll laugh at us. So we do stuff so others don't laugh at us, right? But why should we do it? Does it make sense to do it? Yeah, but why even care about layers? Who says that those layers should be there? Where did those layers come from? Divine power. There's a guy with a beard sitting there and saying, these are your layers. And the same guy tells you what the sections are in the document do, right? So why? Why are we interested in defining things and being precise when we don't have a clue what we are doing? Oh yes, so large a time we want discipline. So I'm gonna ask them all to wear a cap in the morning every day. They gotta have tie every day. They gotta take 20 push ups every day. Would that all make my software better? Not at all. So discipline, yes I agree. But we have to do what produces value though. So when we bring in rituals that don't provide value, we actually lose more. Why? Because we are doing those rituals and at the time we spend doing the rituals, we're not doing what can really provide us the value. That is where the real trick is. I'm not suggesting chaos, but having a controlled discipline which doesn't provide results is worse than a chaos because somebody may discover a solution, got forbid in some of those chaotic situations. But when we impose an order, we're telling people you better not spend time on value because you're supposed to do this. Oh but it doesn't give me value. No, we need more discipline. We want rigor because we have a bigger team. So how do we deal with it? So the question is what if, well can I decide the architecture here? In the very end, can I do that? No, the answer is no. I used to work for a guy. He used to call a software developer practice called RAD. Anybody remembers what RAD is? Rapid application development. That's not what he meant. And when he said that I said, you mean rapid application development, he said no, requirements after delivery, right? Absolutely. It'll be completely compliant into the requirements because you wrote the requirements after you dealt with the product. That's kind of like that, right? Let's draw the architecture diagram and it's all done. Well, it'll be absolutely correct. So no, we cannot do it at the very end. Why? Because we want the architecture to give us that conformance, right? So when do we develop the architecture? Well, what if we say the architecture has to be ready by about this range? Hey, why am I postponing it up to that point? Because that's when I know what I am doing. I don't know anything until then, so why run towards it? So that is a question for us to ask. We want to be able to evolve the architecture. Now you said, hey, what about conformance? What about discipline? Now I find a few very important problems. Now you go to companies and you ask them, what do they do? What do they people, what do people tell? What is their position? Somebody says, I'm an architect. Have you heard that? I'm an architect, right? Or somebody says, I'm a senior architect. Now no longer you want to be an architect. You want to be a senior architect. Well, okay, what else can you be? I'm a senior software engineer. What else can you be? I'm a principal engineer. What else can you be? I'm a chief scientist. I was sitting the other day, somebody came to me and said, what are you? I'm a programmer. He stepped back a few minutes and said, I'm sorry, what are you? I'm a programmer. He said, no, you cannot be a programmer. You've got some gray hair. You cannot be a programmer. He said, why not? Programming is another profession. I love being a programmer. I'm a programmer. No, no, no, no. Tell me honestly, what is your position? You cannot be a programmer. No, what's wrong with being a programmer? It's something you should be proud of being a programmer, right? Why should I not be a programmer? Because it's a status symbol. Well, the real status symbol is being content with ourselves, I think. Are you doing what you care? Not what your title is for somebody who knows nothing about that title. And we're trying to please somebody who has no clue. Why are we doing that? Pretending in life. So what do you do? I create software. I love doing that. That's all matters, right? So what about architects? Well, you probably have Kamukro's architects. What do architects do? Oh, they do important work. And you go to them and say, what do you do? I architect software. Do you write code? No, I architect software. There's a name for these guys. They're called PowerPoint architects. Very dangerous people. They'll show nice PowerPoint slides. Before anything useful gets done, they quit. And they leave a mess behind for other people to deal with. PowerPoint architects are dangerous, right? What do they do? They do pictures, pretty pictures. And then they will come and tell you, you will have seven layers and seven sections in your document do. Now, why do I need seven layers? Because that's the best practice. Have you read these books that tell you what architecture should look like? Go do the seven layers. And what do we all do? We fit everything in that seven layers now. And we conform to all of this. And then you ask them, when did you write code the last time? Oh, back when 30 years ago, when I used to be a coder for three months. Right? Well, how could you be an architect if you don't know how to write code? There's a fantastic paper. This is your assignment for tonight, a homework for tonight. You have to read this. Not only do you have to read it, you have to make sure everybody on your team reads it. It is a very short paper, not more 700 pages. It's three and a half pages. It is called Who Needs an Architect. This is a fantastic blog by Modern Fowler. And in this article, he talks about who is an architect? Who needs an architect? He defines who is an architect. And he says, an architect is somebody who removes himself. He is working hard to put himself out of work. A good architect doesn't architect. A good architect builds a team to architect. Goes back to your question. What if I have responsible people in my team who can think, who can communicate, who can coordinate and come back and say, hey, this is what we are doing. Does it make sense? And I feel that a lot of other projects are missing this, a design format who runs around in the team making sure everybody is designing focused in the right direction. That is very important. A good architect doesn't architect and say, I created this architecture. You all better follow it. No questions asked. That's not an architect. That is a PowerPoint architect. Dangerous guy. A good architect says, go experiment. Come up with ideas. Let's share some knowledge and let's see where we wanna go. And says, hey, that's a great idea. Have you considered this? Should we go in this direction? A great architect is a mentor. Not somebody who dictates to the team, but mentors the team with good practices. Who evolves the architecture. Who evolves the design. He lets the team do the design. I was working on a project. And I had a guy who worked with me who was a little bit older than me at that time. And it still is. And at this point, I asked him, hey, I've got this little user story. Can you go implement it? He said, yeah, I'll implement it as soon as you give me the design document. He was older than me. And for some reason he thought, I'm more senior and I have to do the design somehow and give it to him. So what do you mean? That I have to design it and give you. He said, yeah, in all the jobs I do, they give me a design document and I code it. Well, that job is called typist. Who wants to be a typist on a project? Have you ever done this where somebody gave you a design and you put your design on the site and then you typed it and you're done? Has it ever worked? It never works. If you say it works, you probably are just typing away not worrying about whether actually it worked. You've become a full typist, full fist typist, right? And you can never code without designing. You may say, well, I know a guy at work. He never designs. He always codes. Well, don't tell this guy. But go very quietly to the office on Monday and just watch him from behind. You'll notice him do this. Have you seen this? What's he doing looking at the ceiling? That's called JID, just in time design. He's just not formally writing the design on a piece of paper, right? Nobody codes without designing. Design and code has to live with each other. So an architect is a person who enables a team to do the design. And you're not letting them run wild, but you are constantly communicating with them. So how do you deal with a large team? Divide and conquer. Small groups, hey, 10 guys, five guys. And within each of the group, you have the leadership team to create the design. And those people coordinate with the team architect. And the team architect is not delivering, it's not a push, but it's an evaluation and we raise the team up. That's very critical, right? That's very important to do, be able to sustain it. So we talked about the knowledge curve and the architecture. So how do you create architecture? Well, so I used to work in companies where we would do the architecture in the beginning. I've done that. I used to do that. That's where my initial career was, doing all the wrong things. You know, I look right now, I look back at my life 15 years ago and 10 years ago. And I laugh. And I say, was I that stupid doing those things? And my biggest fear today is, what will I do 15 years from now, looking back at what I do today? And how much more I'm gonna laugh at myself? But it's good to laugh at ourselves at some point, right? Because then we are learning and we are changing. So it's okay to admit and laugh at ourselves and say, oh boy, I was so stupid back then. Maybe I'll be less stupid tomorrow than I am today. So I used to do that. I used to build this architecture all upfront. And what would I do? I would create the layers of the system. And I'm not telling you layers are bad. Creating the layers when we don't know anything is bad. So we'd create these layers. And guess what we would do? We would have these layers in the system. And once we decided this is our architecture, what would we do? We would spend the next six months building this layer. And once we finish this layer, we'll spend the next six months building this layer. And then we will come back and build this layer. And guess what happens when you do this? When you do this, you come back eventually and find out a lot of things you did here is totally useless. You did overwork. You did more work like trying to plan my Tuesday evening dinner six months ago. Why? Because I need it. I mean after all I have to eat on Tuesday night, don't I? And we build all of this, right? And what happens? The time and money we spend building this, what are we doing? We are spending money and time on it. What does it mean? We are taking money and time from something else we could be doing. What is it? Delivering value to customers real early. So don't build a software like this. Now you may say, oh boy, how do I build without this? How do I even possibly build without it? Well come up with a little vision of your architecture. Nothing wrong, but that vision is just that, an idea. Something you will violently modify when you begin to learn more. You say, this is what we do based on what we know right now, and I challenge you, change this every day. Put that as a slogan on the wall. Architecture is for change. Don't hold a fort around it. Don't try to defend it. Please change. And you say, that's a vision. That's a direction we want to go, but we're willing to change it every time we know more. Then what do we do? So then we say, here is our user story one. And what we're going to do is we're going to build the minimum amount of code through the slices of the architecture, but only enough to support this user story. I would have everything working, but only enough. I'm not going to perfect it. Don't confuse not perfecting it to poor quality. You're not doing everything, but what little you're doing, you're doing it to a very good quality. Good test written, good accessing of automated tests, good quality of code, other people review the code, you follow good design principles, all that goes in, not some shabby code written quickly. Then you take user story two and what do you do? You build the vertical slice again of only the architectural components you know right now. You may introduce a few in between when you learn and what do you do when you do each of these steps? Who is doing this? Guess what? The active programmers coding the user stories are doing this. You say, wait, wait, wait. The programmers are doing this, absolutely. Who's designing? The programmers are designing and coding. And who's going to take a look at it? The team leader, the architect reviews this continuously and says, are we going in the right direction? You say, but my programmers are incapable of doing all of this. Well, then don't hire them. You're not running the project with kindergartners, right? You're hiring people who are qualified and build a team that can do the work, that raises up to the challenge and does things. You don't want typist on your team. You want programmers on your team who care about their craft, who read and learn and get better. That's what we are interested in. Not somebody who says, I'll come to work and you tell me what to type and I will type it. And if you want me to get better, I'll type faster tomorrow. No, I don't want your typing speed to be improved. I want you to be improved, right? So that is the key. So you're building vertical slices. Now there's a challenge here, right? What's gonna happen if I build this in vertical slices? There is a risk. And the risk is we are incrementally building this evolution and it is quite possible that we have built this architecture along the way and we come to use a story N and all of a sudden that does not fit into this at all. And suddenly we say, oh boy, how do we deal with this? We looks like to do this, we gotta make a lot of change. Now we are in a panic mode, right? Is it possible? Absolutely, right? It is possible. So what do we do? How do we prevent that from happening? Well, remember, you already answered the question before. You said, get your London ticket three months ahead. Why did you say that? Because you had a prediction of the cost. So when you look at agile projects, you don't say, hey, my agile project has, you know, stories, I'm gonna just divide them into pieces and stop working on it. That is nonsense. What you do is you say, here are my, all my stories on my project. There's a little part, a knapsack, whatever you wanna call it. And all my stories are in here. And I'm gonna put them into smaller parts or knapsacks and divide them. But how am I gonna divide them? What am I gonna bring into the first few iterations? The ones I bring in here are the most valuable. These are the most critical features. If you don't have these features, there's no point doing this project. If you don't have these features, there's no point releasing this application. These are the most valuable. What about these things? It would be nice to have them. But if you don't have them, nobody's gonna thrive. We can even postpone them if we want to. That is the first prioritization. The second is the impact. What is the impact of these stories on the architecture? You want to start with the most impactful to the least impactful. If you do this, what happens? The chances of the story you am coming and attacking you is much less. In fact, I would say it's non-existent if you are given only these stories and if you know about the value and the impact. But it's impossible, however, in reality. How? Because your customer goes out to the market, looks at something else, comes running back to you and says, oh, guess what, I found out. I found like, our competition is doing this and we totally missed out. We need to do this now. And maybe that's easy to accommodate on your architecture. Great, you can do it. Or what if you find that's going to majorly impact your architecture? You sit down and have a conversation. You say, hey customer, we want to work with you. But remember, this is something you discovered last night. And we have worked hard, but we can only work with what we know and what we can anticipate. Much like how you didn't anticipate this, there are things we cannot anticipate. You are human, we are human too. So there's a cost of accommodating this. And we need to decide how important this is for you in a way that we can push some of these low-value things further and accommodate what you want and here's the cost of being the change. And we will do it. But you're minimizing that by arranging this in priority. If you don't arrange this in priority, you will keep being hit by the problem over and over and over, and that's not economical. So that is why when I plan a trip, what do I do? Here are the things I need to do. I need to book a hotel, I need to book an airline, I need to book a taxi, I may have to rent a car, I may have to go purchase a few things, I may have to have meals at a certain places, I may have to have business meetings. All of these are things I have to do in a trip and more. And what do I do? I consider things that are most expensive and hard to change, and I do it first. And the things that are the easiest to change and less expensive, I postpone until the last moment when I no longer can postpone it. Make sense? That's exactly what you do to eliminate the risk. Is you eliminate the risk by prioritizing what you do and you do that that way. But if I'm developing an architecture, but if I have pieces in my architecture that are not done yet, how in the world can I know that these things are actually gonna work? Now, let's be very clear about one thing. Human beings are not good at imagining things to a fine level detail. We are really good at imagining things at a very broad level. We are innovative. You come with a crazy idea and say, what about this? But we're not good at very small details. We miss out a lot of things. Now imagine for a minute, you are looking for an office. And let's say your office is gonna be on this area on the stage. And you're gonna bring in heavy furniture and people are there waiting with heavy furniture and they are complaining. Once we lift it, we gotta drop it down and they're gonna charge you money for lifting this and replacing it. Imagine that for a minute. They put a big bureau here, a big desk here, and you say, don't put this here, move it there. Imagine that's gonna cost you. For everything they lift, they charge you money. There are a couple of things I can do. I can tell them, yeah, let's be a hand child. Come on, guys, over here. Bring it on over here, put it over here. I don't like it here. Can you move it over there, please? Okay, move it over there. I don't like it over there. Can you move it over here, please? And what's the problem? The problem is time, money, wasted, right? And these guys are complaining as they're lifting and moving things and they are, as one guy holding, here's your new charge for you now, right? Or what else can you do? Any ideas? Say that again? Don't be shy, come on, don't be shy. Make, well, you cannot defer the decision. We saw what happens if you defer the decision right now. It's too late, the cost is increasing when the things have been moved in. Small furnitures. Small, no, the furniture's are fixed. That's my office, I need to move it here. But how do I decide this? Yeah? Draw it. So what you can do is, I could, here's something, not draw it, even better than drawing, right? Cut out a piece of paper. Cut out a piece of paper in the shape of your new office, right? Imagine this is a paper you cut out and it's on this desk. And then in small pieces of paper, cut out things that are in the same proportional dimension as your furniture and other things. And now you put this on the table and you get this piece of paper and say, I'm gonna move things around. And I'm gonna put this over here, put this over here, stand back and say, hmm, how do I like? Here's another thing, do that first. But the second thing you can do is, go to the store at the end of the street and say, guys, you are throwing away all those boxes, right? Can I get those boxes? Children love doing this at home. You go to the children and say, guys, make me boxes. And they make these stupid boxes that are empty, but they're in the same dimension as your heavy furniture. Now what do you do? You come to your empty office and you bring all these boxes and you put them around, right? And then you say, how does this look? And now out of seven you're like, you have a vision of how this is gonna look like. That makes no sense? And then you say, I'm gonna move this big, huge furniture from here to there and how many people you need to do this? Just yourself, that's correct. Jesus, I'll do it. Absolutely, right? You just drag it and you push it with your foot and it's there. Why? Because it's an empty box. And you move it around and you have vision of what you're looking at. Well, that's exactly what trace of bullet approaches. The trace of bullet approaches, you mark things out. And by marking things out, you're saying, I know we're gonna have all of these, they're not functional yet, they're not ready yet, but it's put marks in place. So it gives the feel for how this is gonna look like and how it's gonna work together and slowly we'll start replacing. In fact, you can even do this. You can leave all of this here. And when the guys come over and you say, guys, every item is marked, all you have to do is remove that empty box and put the furniture in that place. You're done. Very clearly you have said exactly where things should go. So a trace of bullet, where does the word trace of bullet come from? Well, let's imagine you are in the sport of hunting. Well, hunters, they wanna go for hunting. They sit there and they kind of point and shoot or in warfare also. But what if you want to hunt? Well, imagine I am standing somewhere in a forest. And imagine there's a deer, I wanna hunt. I'm a vegetarian, I normally don't be so cruel. So this is just an example I wanna give you. And I wanna hunt that particular deer. Well, I could take an aim. And I wanna make sure it's a one-shot head. Well, I could do a lot of math. I could bring a calculator or a computer, a supercomputer. I could measure my distance. I could measure the angle. I could measure the wind speed. I could measure a lot of other things that may influence this. And bam, I could fire and say, awesome. What are the chances it will work? Well, with my skills, probably not, right? But R, I could do, imagine now I'm not shooting a deer that's standing. I wanna shoot a deer that's running. Is it easier or harder? Much more difficult. Imagine I'm on a jeep, which is bumpy and jumpy. While the deer is running also. What is it now? Even more difficult. Now what kind of math do I perform now? It's called shoot at will, right? Because no matter math is gonna help you at this point because you are not gonna have the time, the feedback cycle to measure the things and say, yep, that's how we fire. Well, to make things easier, they have these bullets where some of these bullets have a phosphorus material in the tip. And the minute you shoot, it doesn't just fire, it fires leaving a trace. That's where the word trace and bullet comes from. It leaves a trace. It shows you what angle the bullet is traveling and where it falls. And in medical, the brain is the fastest computer probably in these areas, right? Because the feedback loop is enormous. And immediately says, oh, you're going over there and immediately you can make adjustments. And so in other words, you change the course of your action based on the feedback loop you are getting. And that's where the trace of bullets are. And these guys use it to really master the sport of shooting things and when they're in motion, when the object is in motion, they learn from the feedback loop and they change the direction and angle of doing this. And that's what they really do. So we talked about a few things here, but what I would like to do next is I want to look at a very quick example. We've got a couple of options on our hand. We can take a break if you want to take a break or we can keep going for the second section. Choice is entirely yours. Raise your hand if you want to break. Okay, so 10 minutes break. Let's do it. I set the clock here for 10 minutes. I'll start in 10 minutes. Let's continue. So what I want to do is, we're gonna just write pseudocode. I know most people who don't have a computer here with them. So that's okay. We'll just write a pseudocode. We'll take maybe three minutes. It shouldn't take more than that at all. So just write pseudocode for this little exercise. And don't worry about being right or wrong. The goal is not to tell you you're wrong and you did something stupid. The goal is to learn. If you do extremely well, great, you got it. If you did something that could be improved, we improve it, right? That's the whole point. So here's a quick exercise. We get three minutes for this. Write a little pseudocode, right? Don't worry about things like, whatever comes to your mind, doesn't matter. What language doesn't matter. But just write down things that come to your mind on how you were designed this. And it's a very simple problem. So here's the problem. Is that point size big enough? For the people in the back row? Excellent. So very simple problem. This actually is a problem from my good friend, Neil Ford's book on productive programmer. So I'm just using the example from his book. But it lends itself really nicely to the problem that we're gonna look at. So write a small program. Do a brute force code for now, pseudocode, that will compute the perfect number. Your program will take an input as a number and report the given number is perfect. Or the given number is not perfect. But what's the perfect number? A perfect number is a number greater than zero where the factors minus the number itself add up to the number. For example, for six, the factors are one, two, three, and six, right? Factors are things that can divide that number. So one is six is divisible by one, six is divisible by two, six is divisible by three, and six is divisible by six itself, right? When you divide it, the reminder is zero. Don't consider six. Total every other factor. So one plus two is three, three plus three is six. And so six is equal to the given number six itself. The number is considered to be perfect. So there you go. I'll give you three minutes. And oh, sorry, I apologize for not saying this. I kind of assumed it. Move around and pair with somebody. Don't do this alone. So if you're sitting around, it doesn't matter who it is, it doesn't have to be somebody you know. Somebody you don't know is perfectly even better. So move around, and if you're in a place where you have three people I'm watching you, get up and move to a place where there are other people to pair up with. Move around, move around. Pair up. I want to hear noise in the room. Talk. Discuss. There you go. So I see a pair here, a pair here. Grab a piece of paper, write down a pseudocode. Don't be shy. Write something. Nobody is going to criticize you for what you do. Just a pseudocode. You don't have to write every single line of code. Just a pseudocode. I was up. What did we do? Anybody want to hear it? Great factors, ignoring the number. Ignoring the number. Okay. So we assign it to an array basically called as factors. Then we have another way we've got sum of factors, which is basically like sum of, I mean we have a function sum, which takes factors as the number of factors, yeah. So then we return, say, sum of factors is equal to equal to the number of factors. Very good. Anybody who had a different solution? Yeah. Okay. So what is zero when I add and return if sum equals number? Very good. Excellent. Anybody else who had a different solution than these two? Okay. We didn't check in the, before calling the input section, we checked whether the number is there or not. Okay. Very good. So a little variation from the second. Excellent. Anybody who had a solution different from these two, please. A number of class. Excellent. And then any other class or just this class? Okay. All right. Anything else? A public method. A public method, okay. Very good. Anybody who had any solution other than these three solutions? Very good. One, two, one. Right, so a variation of that. Right, that's perfectly fine. So, all right, this is good so far. We'll call it solution one, solution two, solution three. Let's start with solution three. Raise your hand and keep it up if you did something like solution three. I think one team should hand, you did. So that's one. Anybody else? One. Just keep in mind one. Raise your hand if you did something close to solution two. So one hand per pair. That's easy for me to count. One per pair. One, two, three, four, five, six, seven, eight. Yes, yes? No? Eight, nine, 10, 11, 12. Keep that in mind. 12 people, 12 pairs. All right, keep that in here. This is 12. Okay, and this was one. And let's get back to this one here. If your solution was close to solution one, raise your hand. One, two, you cannot raise, you're already raised. Only one time. One, two, three, four, five, six, seven. Okay, good. Now, what we are doing should be good if everybody else is doing the same thing, right? Because we want to live in a world where everything is like what's available to us. This is what we do normally, so it's gotta be good. So it probably should be the winner. And we believe in democracy, right? I live in democracy, you live in a democracy, we have to vote. Majority wins 12 out of 12. Karthik, you need to leave the room. Well, so why should one be better than the other? Well, I'm gonna go back to this one here for a second. Just for a second, let's entertain the start. You had a number of class that's perfectly fine, but within the public method you wrote, does it fall close to solution one or solution two? Quick answer, I don't have much time to wait. One, so you had several methods in your class. Okay, so I'll add one over here if you have many methods in the class. Okay, so, great. Now, which one should we favor is the question to ask. We'll come back and visit it, right? We'll come back and visit it. But before we go further, let me change the problem just a little bit. Don't jump up to answer this yet. Each one of you know whether you did solution one or solution two, but the answer doesn't have to be the same. It could be different for each group. But I'm gonna change the problem just a little. And the change I'm making to the problem is that in this case, the problem, the customer just walked in. You know how customers are, right? And the customer tells us, I want you to tell me if a number is abundant. What does that mean? Sum of factors minus number is, number is greater than that. So number is greater than sum of factors minus number. So just keep that in mind. Don't jump up to solve the problem at this time. So a customer walked in and said, hey guys, I want the perfect number. I still want it, but I also want you to report from time to time whether a number is abundant. So in your solution that you have developed, right? How many functions, how many functions do you have to change to accommodate this new feature? One function, but that's the only function you have. So you have to change everything you have. So how much you have to change? Well, in the other solution, how many functions do you have to change? That's correct. You're gonna write a new function and how long is the function going to be? It's gonna reuse most of what you already have, right? So in this case, let's take a show of hands. How many of you have to change something at all to accommodate this new feature, raise your hand? Don't be shy, it's okay to be wrong. We are here to learn, right? So one, only one prepared. One, two, three, four. Nourishes all the way up to the ceiling is like, yeah, I wanna show you that, great. One, two, three, four, five, six, seven. Well, you don't have to change anything, right? You just said that. So why do you raise your hand? You're gonna write a new function. Yeah, I'm gonna change existing functions, but I'm saying, plus my company. So one, two, three, four, five, six, seven, eight, nine, 10, 11, 11 of us, which almost comes to that number, right? One team is hiding, doesn't raise their hand. The others, of course, if they did it the same way, probably don't have to change a thing. They would just have to add a new function. Now let's think about this for a minute. If you're given a choice between changing something that you already have and writing something a little bit, something new, which one would be easier? Writing a little bit new, why? Because you don't have to understand that nonsense that's already here, right? That's how we feel about it. Even if it's our own code, right? We don't wanna change existing code. It is the right new code. If somebody tells you, knock this out and rebuild it, versus extending by adding a room, which is better. Extending and adding a room is better, right? Because that's low cost compared to knocking the entire house. Do we ever knock entire house and rebuild it? Sure we do, right? Absolutely. But not hopefully every two years. Maybe once in 50 years, maybe once in 60 years when that's expired, we wanna really rebuild it because of all the other concerns we have, right? Well, we don't do that too often. We add extensions very often. So, but let's get back to this and think about what really made the top design better than the bottom design? Can we think of a few reasons? This is fundamentally root level. Why is the top design better than the bottom design? So, don't worry about being wrong. Throw a few words at me. One at a time. Modeler. Modeler, let's leave the thought aside for a minute. Modeler, we'll come back to it. Any other thing? Separation of concern. Absolutely. We separated concerns. Yes, any other term. You can do it. You all went to school. You all did work. You all learned these stuff. And if you worried about being wrong, you would have quit the profession the first day the compiler gave you a error, right? We live in a profession where the compiler spits on our face every day. And what do you do? You wipe it off and continue coding, right? That's what we do for a living. So never hesitate to say stuff. So what else is the reason? Think about it. Anything else? Just you? We said modeler. What else we said? Separation of concern, we said? It looks simple. It is what is simple? It looks simple. It looks simple. Readability. Readability, awesome. Yes, what else? Readability probably doesn't contribute to the result here because Naresh, as good as he is, probably writes the code readable as well as anybody else in this room can. I could write a readable code that has to also change 100%. But absolutely, readability is important too. No doubt about it. How about the word cohesion? Heard about that? Cohesion. What is cohesion? Cohesion means, yeah, it's focused. It sticks together, like things together, dislike things apart, right? There's another thing that the first one has, the other one, the bottom one doesn't, slap, single level abstraction. Notice the second code is going through multiple levels of details. The top one is like a recipe, right? Have you ever heard people say you should not write long methods? Have you heard that? How many of you have written long methods? There's some brave people on this side. Absolutely, right? I like these people. Yeah, of course. But I know you didn't want to do it. You were young, you needed the money, right? Absolutely. We wouldn't do it otherwise. We were forced to do it. They put the gun on us and said, you gotta write long methods. So we did, yeah, we all did. I have written long methods too. How many of you think writing long methods is a good idea? Not anybody in the room, right? How many of you see long methods that work every day? Every day, we all raise the hand. And did you raise the hand for the previous question? There's always this one guy in the room. And why? What? Job safety, that's a good reason. But that's a job you will hate eventually, right? And well, usually one guy raises the hand and says, yeah, this is an important reason to do it. Absolutely, it's always a reason. Now, notice how we all know this is wrong and yet we do it, right? But is it possible to write methods which are not long? Absolutely, yes. But it only happens if we want to. Or we could say, well, that's part of the world we live in, so we'll go and continue to write more long methods. But at some point we have to say, I'm out. From tomorrow, we're gonna move in a different direction. Does that mean from because you decided the next day you come to work in the morning and all the methods are short? No. That means that's where you wanna move towards, right? That's all it is about, right? When I say you should never have long methods, that doesn't mean you go delete all the code tonight. It means you say, you know what, I understand why there should not be any long methods. And from tomorrow, we're gonna do two things. We're not gonna write long methods, any new long methods. And we're gonna start writing short methods. Any new code we write. And we're gonna start refactoring long methods and the short methods moving forward. Because that's what we wanna move towards, right? That's all we say. No, don't have any long methods means don't write any new long methods and start moving towards long methods by refactoring. But that doesn't mean you go start every long method. Only things that are actively being used, actively being maintained, actively being refactored or being added features to, whatever that is. And you wanna work towards that. So one of the things that this gives you is this may not be really long by the definition of long, but it gives a single level of abstraction, right? Whereas this one has multiple levels of abstraction, it fails a single responsibility principle and all those things that are leaked towards. So let's talk about a few things about good design. So what are some of the things about good design? Well, first is, keep it simple. We'll talk a little bit more about keeping it simple in a few minutes, we'll come back to it. But program with intent. What is programming with intent mean? This is something I strive a lot. If you can ask me, hey Venkat, I'm gonna look at your code, let me see how good it is. I'll tell you right away, it is really bad. I cannot write good code in one sitting. But I work towards it. I would come up with a code, I'd give it to other people and say, review this. Help me to make this better, right? I cannot start there, but I always wanna end there, right? I cannot start in that situation and say, oh, mine is gonna follow all of this. But as soon as I create my code, I try to go there. And I work with people to say, look at my code, how can I improve this? So program with intent. What is programming with intent mean? Programming with intent, just this is a very simple example, and yet we can look at it, right? So look at this code. Which of these two code specifies your intent more clearly, right? In the second one, I do a lot of stuff, right? Nere ship me up with this example, right? To say, hey, here's a little example, which is not a good representation. Well, this is no intent. It is doing everything. This is not giving a direction to somebody. You say, hey, what are you doing? Oh, I am standing up, looking at the wall, smiling, taking two steps, turning left, turning right. And somebody says, I'm sorry, I don't know what you're doing. You just told me the steps you are taking, but what is the full intention of you doing this? And we never said that explicitly, right? That intention didn't come out. What is the top one? We are very clear in our intention. What are we saying? I'm gonna get the list of factors first. And once I get the list of factors, I'm gonna sum them next. That's intention, right? And once I get my sum, I'm gonna compare. That is programming with intention. You spell out every single detail in ways people can actually quickly understand without the energy needed to learn what you're doing. That's one thing. How does it really help with evolutionary design? Well, a code that is easier to understand is easier to evolve. A code that is harder to understand is harder to evolve. A code that is simple is easier to evolve. A code that is complex is hard to evolve, right? That's one thing. We'll come back to more. Avoid duplication. Now, I had a clever guy in one of my classes. And he said, I don't have to change any code. I only have to write one new method. And his answer was the second one. And I was a bit surprised. I said, how do you say you don't have to change anything? You just have to write a second method. He said, it's very simple. All I have to do is copy and paste it. Which is the right answer, right? I will just copy this whole code, and I'll paste it. And I will just change it a little bit. That's the new method I wrote. Is he wrong? Not wrong in his answer. Very tricky. By definition of the word, he's right. We can always convince ourselves. I didn't change anything. I just copied and pasted it on a new one. What did we do? We duplicated the code. And what happens when we duplicate the code? We increase the cost of maintenance. We write the drive principle. And tomorrow, I give you a third feature, which is find a deficient number, where the number is less than the sum of all the factors minus one, minus number. And what would this guy do? Copy and paste it one more time. And now this is being copied and pasted three times over. And tomorrow, if we decide to change the definite factors, how many places do we have to change the code? Two places, right? He said, two, isn't it three? No, we only do two first. Until the tester tells us we are wrong, and then we do the third one, right? That's what happens when we copy and paste it, right? It becomes hard to find where these changes are. So that's why duplication is so evil. But in the first approach, how many places do we have to change it? One, when the change happens, right? Because that authoritative representation is in one place to make that change. So avoid duplication of code. So keep it small, keep it cohesive, keep it minimal. Yeah, at least. We're gonna do that towards the end, so I'll come back to it. So good point, but stay tuned, absolutely, excellent. So keep it small, keep it cohesive, and keep it minimum. And keep it minimum, simply says, that when you are writing code, do the absolute minimum code you have to do. Now I'll tell you one thing, this is a big problem. We all convince ourselves that we cannot do a lot of things in life. We literally do. We go to people and say, we can never do this. Until we see the other guy has done it, then we say, we can do this too. Then we come up with all these excuses, right? And then we tell ourselves, oh, we cannot have this. But why do those people have it? Well, because they are different than us, we cannot have it. We don't deserve to have those good things. Because, and we always come with a reason, because. But what if we start where we are and evolve to it? Hey, what if we start where we are and say, I'm gonna write minimum code? How do you write minimum code? By asking. You know what? I don't wanna write a single line of code unless I know for sure it's needed. I'll have the courage to do that. What if we do that? Why can't we do that? Who tells us not to do it, right? But a lot of times we say, oh, we got better, write it, because we don't wanna look bad in the eyes of other people. We gotta be compliant with the rest of the world, the rest of the team, the rest of the members. One important feature is reversibility. What is reversibility? Reversibility is the ability to revert back from a decision you make. You know what? We did this before, we don't want this anymore. Reversibility, what does it give you? Reversibility gives you the ability to change, to throw back, throw away bad decisions and move towards good things that are much better knowing what we know right now. That is reversibility. Can you think of an example of one thing that's very hard to reverse? What, tattoo? Depends on where you got it. Yeah, I mean, where you got it on the body, not what the store is, but both places, I guess. Yeah, tattoos are one thing, but I was talking about software. What is hard to reverse? Nothing? Can I think of one thing hard to reverse? Attitude. Attitude, oh no, stick to programming for a minute. Yeah, attitude, I agree, but stick to programming. You go to a project and say, I wanna change this. What is, what is like, whoa, whoa, whoa, are you serious? One thing, come on, you all know this. One thing hard to change in software development. Anybody? English? End date. End date, no. Look at the code, look at the code. Language. How do you change your programming language that you wrote the code in? Is it easy to do? No, very difficult to do. Very expensive to do. You have a large system and I say, don't code in Java anymore. Code in Python. Tough luck, right? Very hard to change. What is easy to change? Well, that depends on how we designed it, but maybe I decide to go between one web service to another, which provides the same service. If it had a fairly good dependency in version, I could easily translate. But if I made a very poor design choice, where I duplicated the code 300 places, how easy it is to change the service now? Tough luck. I remember this very clearly. We were using an object database, this was back in time several decades ago, using an object database. And it so turned out, every class inherited from a base class, every single class inherited from a base class. And I joined this project. I was not involved in the original design. And I started programming, and what do you do when you're new to a project? You first start doing what's around you, right? We started doing this. And all of a sudden the database vendor came to us and said, we have modified the API completely. And I'm not kidding. It took us eight months to make this change. You can imagine what the cost of development is. Eight months, no new feature, just changing code because the vendor changed the API. We learned the lesson the hard way. We learned how worst our design was. And what did we do? We didn't just change the API. We said, we learned our lessons, we will not let this happen. We created a level of abstraction and all the access to that app has been through that layer and the rest of the code talked to it. Now there's a little bit of a caveat here, right? We modified the code to do that. Every layer of abstraction you introduce gives you a bit of flexibility. But every layer of abstraction you introduce may take away from performance as well. It's a balance we have to strike. Just because layering is good, we don't do more layers. You gotta be very careful about it. But what did we learn in this lesson? What we learned in this lesson is coupling is bad. Duplication is bad, right? And we have to make sure when we think about things, you gotta ask yourselves, how frequently we wanna reverse this? If something has to be reversible, then we should ask what's the cost of reversing? A database must be reversible. I was working on an application about three weeks ago and I had developed everything with one particular database. The day before production, the night before going to production, that's always the fun time, right? The night before going to production, I came across a constraint. I cannot use this database anymore. I gotta switch over to another database. So I installed this new database that I have to use. And thankfully, this is where the heavens are looking at you with a blessing. I had 100% automated test cases. I swapped my database with the new one, ran my test, four of my tests failed. Poof, going in smoke in front of me. I'm like, uh-oh, what happened? I look at what went wrong, find what the error was, modified my code, ran the test again in the old database, make sure it's still working. In the new database, also make sure it's working. Great, now I can. So what was the cost of reversing in this case? Those four failed test cases and fixing those code to make those tests pass. Thank, I was fortunate in this case. It took me about 15 minutes of effort to do this. Not eight months as I had done in the previous job that I mentioned, right? But reversibility is very important. But there's a cost to reversibility. If I tell you, you must be able to reverse the language, what are you gonna do? You're gonna create your own language which will compile it to this other language. Also known as a bad idea. Because why? The cost of reversing is very high right now. The cost of reversibility must be affordable compared to the benefit we get out of it, right? That's something we have to ask very well. So my argument is, I'm not saying make everything reversible. I'm saying make everything reversible that is possible to make reversible. And understand the cost of reversing and understand the benefit of reversibility. And then favor that. Things like database should be reversible. Things like web services you're different on should be reversible. Third party components you're different on better be reversible. Algorithms you use better be reversible. So many things have to be reversible, right? And if you don't make things reversible, it becomes expensive to maintain the code. So make it as reversible as far as possible but understand what is reversible, what's not. And postpone certain decisions to the last responsible moment. Ken Beck said this, and I think this is a wonderful way to think about it. He said, courage is postponing the decisions of tomorrow to tomorrow. That is a wonderful way of thinking, right? Why do we make decisions today? Because we are afraid of whatever it is we are afraid of, right? But he said courage is postponing the decisions of tomorrow to tomorrow. Imagine this for a minute. Imagine, I have to make a decision. You know somebody during the break was telling me, oh, Venke, we gotta make some decisions up front. Well, no, don't convince yourself you have to. And the gentleman said, oh, I have to decide. On day one, the OR mapping tool we have to use. No, we don't. I actually worked on a project for a bank. We very clearly decided we are not going to decide the OR mapping tool until the fourth iteration, fourth spring. The team was up in arms. They said, are you crazy? We have to decide the OR mapping tool today before we wrote any single line of code. Why? Why are you so fearful to decide this later? And they were in a system. They said, no, no, no, no. This has to be done. That's the way we do stuff. Oh, no, you can tell me that's the way you have done stuff. That doesn't mean that's the way we have to do stuff. And we said, no, we will not use an OR mapping tool until we grow. In fact, fourth iteration, we disallowed the use of databases. You may say, that's stupid. You cannot have this applicant with a database. Agreed, but we don't need the database in the first spring. We can provide enough features to get the feedback without it. And when we did it, the team came back and said, that's weird. Things aren't working. And they're able to get feedback from the customers, asking if that's what we should be doing. And we didn't waste any effort writing the database code at all, because we don't need it right now, right? So this is something, question. Question yourself all the time and say, why? Why should I not do it differently? Just because you have done something some way doesn't mean you have to do it that way. You can do it differently. And not all one night, you cannot say I'm going to change it tomorrow morning, but move quickly towards it and say, I'm going to do it that way from tomorrow, one step at a time. Absolutely we can do it. So let's everyone implement a certain feature. Let's imagine for a minute, I can do it now or I can do it later. Just take an example of this, right? I want to implement this feature. I can do it now or I can do it later. Well, to do it now, it is going to cost X amount of dollars. To do it later, it's going to cost Y amount of dollars. Imagine for a minute, X is greater than Y, right? What do you think? Should I do it now or should I do it later? Later, it's cheaper later, why do it now? You say, how could it be less tomorrow than today? Maybe I'm implementing other features and by the time you get to this, lock code is already done, it'll be cheaper, right? So I'm going to postpone it tomorrow. Why? Because I don't need it until later, I can postpone it. Well, another example. Let's say it's dollar X and dollar Y, I'm sorry, dollar X again. Should I do it now or should I do it later? It's the same cost, whether you do it now or later. When should I do it? I want a louder answer. Later, why? Because it makes no difference. And that money and time you have, you can spend on something that you have to do now. Right? Hey, the airline ticket is promised. It will never change between now and three weeks before you fly. When should I buy it? Giving everything else is the same, I would buy it later. In fact, I have something that I have to reserve for Thursday night. And I decide I'm going to do it only on Wednesday night. Why? Because it doesn't matter. It's the same price that I do it now or on Thursday, Friday night, I'm sorry, Wednesday night. And I said, I will have the money with me more, much longer. I don't have to give it to the company before it's due, right? It's a decision we make. Well, okay, I have a feature and it'll cost Y to do it now and X to do it later. What do you think I should do? Remember, X is greater than Y. What's your answer? Thank you. So the word is consider. Word is think. He didn't say do it now. He said it depends. Well, the first is how certain you are that you definitely need this feature. If you're 100% sure you need this, then the next question is how much do you know about this? Do you know a lot about this? How certain are you? So put a number on need and a number on certainty. If those two are very high, please do it now because it's expensive later. But also find out why it's expensive later than it is now. That is also important to know, right? That could be good reasons for it. Absolutely. But evaluate it, but notice in at least two out of three conditions, it is better to postpone. By the way, I wanna emphasize one thing. I'm not by any means suggesting to you procrastinate. We are, some of us are really good at it, right? I actually want to write a blog about procrastination, but I never got around to writing it, right? That's procrastination. Oh, I'll do it later. I'll do it later. When I wanna do it later, I'll decide that later. That's procrastination. Procrastination is when you're delaying what needs to be done. I'm not suggesting procrastination. I'm actually extremely proactive. I do things very early. If you're very interacted with me, you would say, make it your crazy. You're doing this so early. I do it very early things, very, very early. I've never procrastinated. Well, at least since I learned the trouble of procrastination. But I postpone a lot, but not procrastinate. I postpone by clearly saying, this is not something I have to do right now because of these reasons. Not because I cannot get myself to do it, right? Don't procrastinate, but postpone. That's very important. Avoid technology infatuation. I want to emphasize this. A lot of times people say, oh, I can't do this because it's cool technology. This leads to what's called RDD. Stands for resume driven development. Hey, why'd you do that? Because I can put this on a resume and get my next job on this technology, right? Bad idea. Only use things that actually make sense to use our project. Hey, that is the case. I learned these other things. That's what nights and weekends and user groups are. You should have a user group where you meet every month so you can try new things by pairing up with other people, right? In a lot of cities in the world, we have user groups. We meet every month. Every month on a Wednesday night or a Tuesday night, we spend three, four hours together as groups. We bring a speaker. Somebody comes and speaks about certain things. We can get familiar with it. And then once in a few months, we'll have a code retreat and we'll sit down and code with each other and we'll learn from each other. That's a social interaction we have to build. If you say, well, my city doesn't have it, that's called opportunity. You build it. Every user group was created by somebody who wanted to make a change. Not because somebody said that doesn't happen. There's always people. There's thousand people who will tell you this cannot happen. But the world changes because of one guy, one gal who said this is possible. I don't want to live like I did. I can change where I am. I can move towards something different. You don't sit down and say, this is not possible. This is not the world we live in. You have a vision for the world you want to create and you do it. And the way you do it is saying, you know what, we can do this too. I want to have a user group. You don't have to have a user group with 70 people. You need a user group with two people because you want to learn, right? Ashish, what I will talk about later about things he has done in Delhi, for example, right? You've got people come together and you have people interacting with each other. You want to be able to do that, right? You want to build a community. And guess what? It is hard. You'll have a thousand people who will say, I've got to go feed my dogs. I've got to go put stuff on my cow. That's okay, that's their priority. But you find two guys who are passionate about coding, bring them together, let them sit and pair up and learn something new. Not on real project which doesn't deserve it by spending these hours learning. What about extensibility and reuse? Do we have to ignore that? No, very important. Reuseability is very important. Extensibility is very important, right? Very, very, very important. But there are a couple of things I would, this is a balancing act, right? I cannot tell you, do this and you're done. There are no best practices, that's why. But it's a balancing act. Hey, Venkat, you are speaking out of both sides of your mouth, you're saying this and you're saying this. Which one should I do? Well, I'm sorry, there's no good answer. You have to balance. Sometimes you have to do this, sometimes you have to do this. Well, don't create granular code all the time. But don't ignore creating granular code all the time. You gotta know, you gotta balance and decide when it makes sense. For in the example we talked about, you could argue, hey, could I just create that code the way I did and come back and refactor it later? Sure you can. But only when you couldn't anticipate it. But by applying a little bit of modularity, you could do a lot better already. But what is not good is when you create a massive hierarchy of classes and extra bloated code, you don't wanna do it. Why not? Because that is something you probably don't need. And it's easy to create it when you need. You could refactor it when you need. So you could have done the second way of writing code, but the first time you see the change come through, you could have refactored it into the first type of code. Nothing wrong with that, right? But over time you learn, hey, I might as well do the first style instead of second style. What is wrong is not doing the second style. What is wrong is doing the second style and not changing it when the change comes the first time and copying and duplicating the code. But you gotta refactor the code to remove the duplication. So what about extensibility? The problem with extensibility is you have to know what you're extending for. What if you prepare for extensibility and that's not the type of change that comes your way? Now you will have the extensibility deal with, your code doesn't handle it, you still have to modify the code and you have more bloated code with you, right? So how do you know something is worth preparing for? There are two things you need to plan for extensibility. You need two things, a good programming and design skill. You gotta be good at programming and design. You must be able to see through and say, hey, that's what the problems could be in the future. But that's not enough, right? There's another thing you need. What is it? Knowledge of the domain you are programming in. If you don't know what domain you are programming in, how could you anticipate? I programmed in engineering fields, various different engineering, not computer programming, right? Are there real engineering words where they build machines? And as a programmer I would come up with all these crazy things. Hey, what about this, what about that? And the engineers would laugh and say, you know what, I'm really glad you're looking out for those things, thank you. But this will never happen based on a lot of physics. This will never happen based on chemistry, right? And I would say, good, I ask those questions, I don't have that knowledge, I have to ask it as a programmer who is interested in design. So I mean these two, but look at people that you work with. There are four kinds of people, right? There are four kinds of people. First kind of people who are really good in programming don't have a clue about the domains. Have you seen people like that? Absolutely, right? Second set of people you work with who really know the domain extremely well don't know anything about programming. Have you seen them? Absolutely. The third category of people, very small number of people who are good at both. And the fourth category, well we'll not talk about that, right? So when you have these kinds of people, what do we do? Majority of the people are one of these first two. Either know the domain really well or know programming really well, but that's not enough. So how do you really make this happen? Collaboration. You gotta make somebody who knows the domain very well collaborate with somebody who knows programming very well. Any decision one of these people, a group makes without the other is a disaster. They gotta collaborate with each other and say, hey, based on the domain knowledge we have, based on computer programming constraints, what should be the design? What kind of extensive strategy should we plan for? Because this could be a more expensive moving forward. The collaboration between the two group has to happen, right? And that's how design has to happen as a collaboration. Not somebody sitting in a dark room and coming over things and saying, that's what I came up with. Any design you come up with based on computer programming alone is not effective, right? You have to really build something that actually is extensible. And for that we need to have these two knowledge together. We cannot do in isolation. That's very critical. So given that, how do we really create extensible code? Nourish pointed triangulation earlier. So Ken Peck talks about triangulation and I think it's very valuable. So what is triangulation? It means you do one thing first, based on what you know. That doesn't mean you ignore good cohesion. You ignore separation of concern. You can do all of that. But don't build massive hierarchy of things. Just do what you know. And that is the first thing you do is you build what you know based on what you know. So you basically build the code to knowing what you know. So that's the first code I implement. Then a few days goes by and I realize I have to do a new feature. Do something extra. And what am I gonna do? I'm gonna implement too. And this may require me to copy and paste a lot of stuff from here to here. Do it. Knowing what you're doing, not by being ignorant. And once you work it, make it work what you do, you say, oh boy, these two work. I know these two are working and I know what I did, I copied and pasted and here are the changes I made and this is the part I changed between the two and look at everything else is common between the two. And that's evil. And so what now I'm gonna do is I'm gonna take what is common between those two and raise it up. And these two now can depend on what's common. Now in general, you use inheritance for it but don't be compelled to do that. This would be composition as much as inheritance is. It's up to you what you wanna use. But triangulation basically is you get two working copies of something with a slightly different feature and knowing this in action, you elevate and pull out the commonality, extract it and then you say these two depend on this commonality now. That is triangulation. What is the benefit of the triangulation? The benefit is you did this based on the real knowledge of the existing system based on what you're seeing rather than a perception. Now there are 70 things you could perceive and create an abstraction and what you end up creating is a mess to deal with. In this case, the abstraction you created is very practical. It's based on what you know and what is needed not on some perceived notion. So in a sense going back, I would sum that back to this one, which of these two is good? And I would say in the beginning, neither one of them is good. Neither one of them is bad totally. The real question is, what do we do when the first change comes? When the first change comes, when we have to deal with the abundant number, did we refactor the second version towards the first version? Or did we copy and paste code and leave it like it is? That's where the real question is. But to have that awareness and then you can say, hey, knowing this, I could facilitate this to a certain extent as long as it's lightweight. But if you went with this approach and that meant creating three more interfaces and seven more classes, I would say that's overblown. You don't want to do that triangulated, right? That's where it gets a little tricky based on what we need to do. So quickly a few principles for you to think about. So how do you keep things simple? The first principle is Yagney principle. You aren't gonna need it. So you need to have the courage to say, I don't need it right now. Maybe not for a long time. I'm gonna postpone this. Ron Jeffries coined this Yagney principle and Yagney basically is to have the real courage to say, I don't think I need it right now. I'm gonna postpone it until I think I need it. We've developed so many features not knowing whether we really need it because we feel that we need it. So postpone things. Keep it dry. Don't duplicate. Don't duplicate code. Don't duplicate effort. Don't do similar things in several places. Not copying and pasting code. But one change requires other changes in other places. Find a way to remove that duplication of effort. Single responsibility principle, we saw that in the code already, right? In the little example we saw, we saw that already. One single responsibility for everything. And keep the code cohesive and reduce coupling. But in a lot of places, eliminate coupling rather than reducing it. I remember Nanesh was organizing a software design and testing conference. This was in Philadelphia. I walked into the room and they had an open space group. You probably remember this experience from years ago. There's a room full of people. And I walked in, I said, you're gonna sit quietly. And they were talking about how they all love doing design and allowed right in testament development. But they really hate it because all their tests are brittle and it breaks very often. After a few minutes I quietly said, guys, maybe you were, you're having trouble with this because you were designing socks. And everybody in the room got angry at me. And they all said, who are you? You come here and tell us how we designed socks. How dare you tell us how we designed socks? Everybody's angry, right? That's the easy way to make everybody enemy. You tell everybody who's designed socks. And I said, well, I write code that sucks all the time. I thought you guys are like me. And I go make something work and I learn I change. I thought you guys are like me. Well, let's talk about a problem. And then they said, here's a problem. Look at this problem. We have this test over here. We have this code here. We mark this out and look at how it sucks. The minute we change the design, we have to make all these changes. I said, yeah, that's a great example. And the problem here is not mocking. The problem here is not dependency inversion. The problem here is you shouldn't have the dependency in the first place. And when you bring in dependencies, when you don't need it, you have to suffer through it. That's when the next morning I wrote a blog. And the blog was called a knockout before you mock out. And if you Google for this blog, you will find it. I wrote this blog the morning after this conference. And essentially the idea is you don't spend your time coupling to things that you don't need to couple to. So we assume, oh, this is the design, bringing the mock objects. Well, where is the coupling? What if you don't have to depend on this? So knockout before you mock out, meaning remove your dependency. Then you don't have anything to mock. And of course, there are times when you cannot remove your dependency, only in those cases don't be coupling, right? So the best thing is to remove coupling. The second best is to decouple, meaning depend on an interface rather than a concrete class. And that is something we can do if you're willing to do it. So eliminate coupling where possible. So in short, make your code modeler, make your code testable. And to summarize, how do you proceed with this? The way you proceed with this is you take all your user stories, and the very first thing is you prioritize your stories. Prioritize your stories based on the most valuable to the least valuable. Based on what you know so far. Start solving the user stories from the most valuable to least valuable, most impactful on architecture to the least impactful on architecture. And then once you do that, start going through all the layers of the application, all the layers of the application. So you go from the, all the way from, all the peers, all the way from the model level, if you are dealing with the model level to the UI level, build the entire stack. If something is not ready yet, do mocks for that using the phrase of bullet concept. Put a mock service when the mock service is not ready. Don't go off and spend six months building the service at this time. And then you can build that layer. And then once you build this layer, you can build the next and next and next. Actually I have one last experience before I go further with this. I had the wonderful opportunity to pair up and work with the team. And I started pairing with this team. These programmers were really good programmers. But they were all very focused on one thing. They had a division of labor. One there was good at writing the database code. One there good at writing the UI code. One there good at writing the logic algorithms. You go to the team and you tell them, can you do this thing? They'll say no, we cannot. Why not? Because we are good at this, we are ignorant of that other thing. That's the way they live. And I went there and I sat with this guy and I started pair programming. And it was so funny to watch this. We started implementing one feature, user story. So we went through and started building. And this guy was very good at programming the low level details. So we started there, we wrote test cases, we wrote this code. As soon as we wrote this code, this guy said, this is great, this code is working. Should we build this entire class with 15 fields? No, you don't. You build one field and make it work. So he builds one field. And then as soon as we build one field, he says, okay, that's working right. Now can I build the second field? I said, no, we don't build the second field. We do the controller here. So he said, okay, and he built the controller here, write test and did that. He said, that's good, that's working. Can I go back to the second field now? I said, no, we do the UI. He said, no, no, no, no, no, no, no, we don't do that. I said, what do you mean you don't do that? Oh, I never write UI code. That's not my job. I finished this code. In fact, because you are here, I even wrote this, how to stop right here. And that's not my job. I will not write the UI code. No, sorry. I can go back and write more code here if you want to. And I wait for a second, I leave it over and said, okay, I got a question for you. If you tell me you don't know how to do this, I'm gonna teach you in the next hour or two. If you tell me you don't want to do this, you and I walk right now and go to the team leader and have a talk. Which one would you like? He was upset. He said, what, you want me to write the UI code? I never write the UI code. I said, again, if you don't know how to do it, I'll teach you how to do it. You don't have to be the best to do it, but you have to do it. But if you don't want to do it, we're gonna go have a talk with the boss. What do you want to do now? Okay, fine, I will go by our own mind. We are confined by our own environment. We tell ourselves that's the world we are in so we cannot change it. But change only happens because we want it, not because we are told. And that's for each of us to decide. Whether you want to change what you do and what you work on and learn, nobody else can do that for you. That's your decision to make. But these are very valuable to try to really control their emotions and say, I'm gonna postpone this to a later time. I'm gonna make a decision later on, not right now. And I'm gonna go back and revisit, learn. And I'm gonna have other people actually be part of my work and not make decisions for others. But how if the team make decisions? Those are the things that will not happen unless you want it to happen. And it will not happen overnight, but you gotta work towards it. But the benefit of evolutionary design is it makes it possible to evolve the system. It is impossible to develop an application that never changes. And when change has to happen, you gotta work towards making that change. And there's a cost. And whenever you tell me something is costly, you are ignoring the current cost. And I would ask yourselves, what is the current cost? Then come back and evaluate how much the new cost is going to be. Then you can decide whether that's the right thing to do. And if it is the right thing to do, there's always one saying, right, either change the behavior of the people you have or change the people you have. It's not gonna happen without that. And yeah, there's a lot of science, there's a lot of engineering, but it also comes with people things. Most problems we deal with are not technical problems. Most problems we deal with are people problems. And we cannot solve them by being blind to them. So work hard, it's a lot of fun, it's a great field to work in, but that's what it takes to do it, right? To make mistakes, to learn, to do, to redo. Design doesn't happen in doing things. Design happens in redoing things and refactoring things. That's the evolutionary nature of what we do. I hope you found that useful. Thank you.