Creating Evolutionary Architecture - Venkat Subramaniam

This talk addresses the challenges of creating sustainable software architecture over time. The speaker emphasizes the importance of distinguishing between architectural and design decisions, noting that architectural choices have a far-reaching impact on the system. He discusses the necessity of evolving architectures as new insights are gained during development, and shares techniques such as prioritizing tasks based on business value and architectural impact. The session also covers the significance of simplicity, refactoring, the last responsible moment for decision-making, and the philosophy of YAGNI, which advises against unnecessary complexity. Ultimately, the speaker underscores the need for wisdom and courage in software design and architecture.

Let let's talk about maybe something that doesn't have anything to do with AI for a few minutes. So, this is a challenge we often have to deal with whether you are an architect by title or you are an architect that has to uh build software systems. One of the challenges we often face is how can we create an architecture that is going to sustain the journey through

time that we are creating. So, I want to talk about a few practices we can use to help us to create architecture that can help us to move forward as time goes on. And I'll talk a little bit about uh architecture. I'll talk a little bit about some of the challenges. And then I'll talk about maybe some practices we can follow to help us to create better

So, the first question I will start with is what is architecture? As it turns out, this is something that's really hard for a lot of us to describe as what architecture is. We do architecture, but how do we put that into terms? And I would say an architecture is um expresses what your components are and how they are interconnected and how they communicate with each other. Now,

you could say, but that's kind of like design. But as it turns out, it's a level of granularity that's different. You could say something is a design or it can elevate itself to something being So, often I say, a way to distinguish considering the impact and the consequences. Design has certain impact and consequence. Architecture has a higher impact and higher consequence. So, essentially, it can have a

very huge difference in terms of what we do. For example, this is a nice beautiful room and I can tell you maybe I don't like the stage the way it Maybe the stage has to be designed a little bit better. Maybe they should really provide better set of stairs to get onto the stage. Maybe this acoustic in the room is not that great. We need to maybe

make adjustments to it. All of those are There's an impact for it, but it's not too hard to change it. But, on the other hand, if I say I'm not really a big fan of this room, this should really have a basement below this. And you're going to say, "No, sorry. We cannot do this. We cannot just suddenly add a basement to this building because this floor

cannot sustain if you dig under this because it's it's like sitting on a foundation. I cannot just throw another room below this." I say, "Okay, that's fine. Well, can we put a floor on top of this?" You say, "No, no, you cannot do that." "Why not? Why can't I just put another floor on top of it?" That's because the walls will not support the weight of another

floor. You cannot just add another floor to it. That is architectural. I was building a house. This is where the some sometimes we are naive, right? We always tell, "Oh, these people don't have a clue." This is my turn not to So, I was building a house. And as we're building the house, we have a a floor in which we have a backyard and we have a

nice, beautiful, extensive backyard. And I want to be able to see as much of the backyard as we can. And the architect said, "I'm going to give you a window, but the window is going to have a little door you can open. And when you open this door, you can step out and you can enjoy the outside." And I said, "No, no, no, no, I don't want

this little door. I want a big door. And this door, when you sit, you can see the entire outside without disrupting your view. And I can slide this door out of the way and then this entire space is open as if the outside and the inside are very much like you get a space you can go back and forth. And the architect said, "Oh, that'll be lovely.

You can You can do this." And I said, "Who sells that kind of door? How much does it cost? How do you install that door?" "Oh, you got to go to this place and find out who is selling that kind of door." So, I did. And I found out what it's going to cost. And obviously, that door is going to be more expensive than putting this little

flimsy door which has all these metal pieces that obstruct your view. And I'm like, "Hmm, I really want that nice view, but do I want to spend that money or not?" So, this is where sometimes we are ignorant or at least not being smart enough. As I told the architect, "Hey, I've got an idea for you. You go ahead and do what you need to do. I

will let you know later on if I want to spend that money and have this big door or just this little door is enough." And he had his laughs. Just like we laugh when programmers are told, you know, in to do stuff that we think is ridiculous, right? This was his turn to laugh and say, "Venkat, good try. You cannot do that." I'm like, why not? I

I can decide later, right? He's like, no, no, no, no. If you want to put that big door, I need to do the necessary things now. I'm like, you're an architect, what do you have to do? Well, in the basement, I have to define what that wall is going to be. Because in the basement, if I put the construction as we planned right now, it can hold

that small door. But if you want that big door, I need to reinforce the basement with a lot more structure and concrete for it to support the weight of that big door. If I don't put this now, you put the big door tomorrow, I will get arrested. Because this will not take the weight and collapse. So, you need to tell me now if you want a big

door or a small door, because there's an impact on it down here. This was a year and a half before we started construction. And the key here is that's an architectural decision. So, even though you may say, hey, window is a design, right? No, window is architectural. Because it's got an impact on other things. In a similar way in a software system, there are things you can

decide that are design. What what parser should I use? It's a design issue. You can use this parser today, you can change your parser tomorrow. The impact is less. What framework should I use to build my application? That's architectural. Because if you're using a framework today, and you decide to use a completely different framework tomorrow, that's a very huge change. It's a high impact. So, there are

design decisions and architectural decisions. And we need to be able to discern between these, otherwise we are in trouble. So, now that we talked about some of we want to be able to evolve the architecture, but why? The reason is very simple. We often think that we know a lot, but it's very humbling when we realize there are a lot of things we don't know. When you

start building an application, you are learning a lot about the application while you are building it. And so, we start with some ideas, but we discover these things along the way. So, if you don't evolve the we commit to things too early, and then we realize it doesn't serve our business later on because when the needs are different, it's very difficult for us to make that work

together. there is a risk of not evolving. But, let's not be naive about it. There is a risk of evolving as well. If you are evolving things, what if you suddenly come across a particular feature you have to implement, and you realize to implement this, you have to make fundamental architectural changes? And you're like, "Oh my gosh, we cannot This is going to take us 6 months."

This is like me going to the builder and saying, "Hey builder, you are 3 months away from finishing it. You've been building this for a year, but I got a great news for you. I just decided I'm going to put this huge door on the top." And the builder will only laugh at me, right? And like, "Why are you laughing?" You You can't just do that today.

Why not? I'll pay you money. Like, "I don't care you pay me money because I have to redo the basement. I got to tear up this entire wall, redo the foundation so I can support this window, and I cannot redo the foundation. That's That's cost-prohibitive. What if we face a similar situation in software? What if you are into ninth month of development, you are 2 months away

from releasing this version, and somebody says, "We need to implement this feature." And you're like, "Oh my goodness. To do this feature, I've got to fundamentally change this part of the system. And that's going to take me 3 months of effort." Think of one more thing. If somebody comes to you and says, "Hey, this is not going to scale really well. Because it's not going to scale

really well, we got to make this whole thing asynchronous." And you're like, "Are you kidding me? To make it asynchronous, I got to go change every function and turn it from synchronous call to asynchronous call. That is expensive. I'm going to change a lot of code. And what happens when you change a lot of code? We introduce errors. We introduce bugs. And this completely derails the schedule

derails the schedule. And we are scared. That is a risk of So, what do we do? How do we minimize the risk of evolving? How do we deal with that? The answer is prioritize what you're going to do. But how do you prioritize? Prioritize based on two things. Prioritize based on the business value and prioritize based on architectural impact. So, when you schedule your project, you don't

say, "Here's a bunch of user stories. All right. Take all these user stories. That's your backlog. Sprint one, that's user story. Sprint two, this one. Sprint three, this one." That's a dangerous way to schedule because you're just saying, "Chop, chop, chop. Let's schedule this." Instead, you're saying here is all the stories, but let's prioritize it based on the most important to the least important. Why do we

want to do the most important? If I do the most important things first, then the least important, as the name indicates, are not as So, if you don't do that as effectively as the most important, you're still good. Because those are the most critical things. These can be a bit more negotiable. First thing. The second is not just look at stories and business value alone, but look

at the business value, but also ask the question, what's the architectural impact of these user stories? If a story has an architectural impact, do this sooner. If a story has less impact, do it later. If this is cosmetic, if this is less postpone it. If this is critical, do it. Just like in construction, when I went to my builder, I said, "What should I do now? What

should I do later?" He said, "You have to select the carpet." Oh, yeah, I'm going to select the carpet. Like, "Hold on. You don't need to do it now. That can wait for 7 months from now. I don't care what your carpet color is. That's your problem, not mine. So, don't worry about carpet right now. Don't worry about cabinets right now. Worry about where you want the

doors. Worry about where you want the windows. Worry about where you want the plumbing, where you want the bathroom, how many car garage you want. Because those are The others are design. I can postpone design. I cannot postpone So, that is basically the prioritization. With the experience, the builder says, "Do these first, do these later." But that's what we need to bring to the project as architects.

And tell your business, "You need to focus on these first. And you can focus on these later. Because these have higher impact. These have lower impact. That's how we're going to prioritize it. So, it really comes down to how we prioritize our application development so we can reduce the risk of evolving. Okay, fine. We have done that. We have prioritized it. But how do we still make

this architecture evolvable? And that's what I want to focus on for the remainder of the session, some practices we can use to prioritize it to make the improve the chances of The first is keep it simple. this is the problem. I don't think there's anyone in this who will tell you, "I don't want to make anything simple." Every one of us is going to agree to it,

right? If I ask you, "How do you want to write this?" Oh, I want to make it We all want to make things simple. There's no doubt in our minds. The problem is this. We don't know what simple is. That is the problem. If I ask you, "Would you like simple or complex?" Of course, I want simple. That's not the problem. It's not that we don't agree

upon it. But when you create things, you don't recognize if it is complex or if it is simple. The problem often time is you will say, "This is simple." You are saying it's simple because you're familiar with it. Or you say it's simple because you created it. Or you say it's simple because that's what you've seen people do. So, if everybody is doing, that's common. But here's

the problem. When I have something that is simple, and I have a colleague who looks at it and says, "Why are you doing that?" I'm like, "What else do you think we should do?" "Why don't we do this?" And then you're like, "Whoa, that's actually simple." Well, if that is simple, then what I was doing is not simple. But I didn't recognize it. And that is one

of the problems of simplicity. Simplicity is hard to recognize until somebody shows you something simpler. For that, I need to have an open mind to invite that thought in. The minute somebody says, "Why are you doing it? There's a better way." Well, wait a minute. I'm going to hold the I'm going to defend. I'm going to stick to this ground. And that's emotion. That's ego. We bring

it in sometimes. Okay, we bring it in a lot of times. But we need to let go of that and say, "You know what? We are going to learn from this. We're going to work together on this. This is the first draft I came up with, but if there is a better way, let's give it a shot. Let's take a look at it." So, simple. So, what

is simple? That's a question we need to answer. So, you could say we can probably start defining what simple is. You can say simple is easy to understand. So, simple is easy to understand. You look at this and say, "Yeah, that makes sense." What about complex? Your your head is spinning. I'm not able to hold this in my head. A lot of things are going on in

this. Can we make this simple, please? You could also say simple has fewer moving parts. Simple has fewer moving parts. And I'm sure somebody is saying in the "Excuse me, have you heard about microservices?" Microservices are one of the most complex things you can build. If you want simplicity, you won't use microservices. The only time the word simple and microservices appear in the same sentence is when

you say that microservices are not simple. So, the whole point is it's one of the That's not to say you don't want to build microservices ever. But you have to ask yourselves, is that complexity worth for what I want to do? Does it give me the benefit for that complexity? When a complexity gives you the benefit, you win. When the complexity doesn't give you any benefit, you

lose. Why do you want to spend more effort, more time to build something that doesn't provide value and you're losing money building? And that's where we need to be evaluating things. So, simple has fewer moving parts in it. fails less and fails gracefully. Simple fails less and fails gracefully. I'll give you an analogy to this that I will never forget. And I have to apologize. Uh I'm

going to give you an analogy based on what I know. I have never been to a gas station in India. So, I don't know how the the stations here are. Maybe one of you can educate me on this uh after the talk. But in the US, diesel and we have petrol. And when you go to a gas station, we don't have Well, well, unless you are in

a state of Oregon or state of New Jersey, you don't have humans who come to help you to fill gas. We just do it ourselves. So, you pull your get out of the car to the gas pump, get out, put your credit card, take the nozzle, you fill the gasoline. So, here I was extremely tired and sleepy because I had to work through the night for two

nights in a row. Now, I know I know what you're thinking. If you are that tired, you shouldn't be driving. That's a different lesson for me another day. So, I'm driving to home so I can quickly take a shower, get back to work. So, on the way, my gas my my my car is low on on gas. So, I pull up to the gas station and I

get down. I I You know, take my credit card and I and I'm trying to put that into my gas tank. I'm tired. I can barely keep my eyes And the nozzle will not go into the gas I'm like, "Venkat, this is ridiculous. You don't even know how to fill gasoline. Why doesn't this work?" And I'm calming down, cleared my eyes. Let me think. And then I

see where this tube is going and it says diesel. And I was absolutely surprised. And I forgot about filling gas and now I'm appreciating the design. Look what they did. This is something I didn't know. But as it turns out, in cars is shaped differently. So, a diesel will not fit into a gasoline nozzle. So, you can take a diesel pump only for a diesel car because

they designed the shape And a gasoline petrol will only go to a that is what I mean when I say it fails That's brilliance of good design. I said this in a conference earlier last year. And as I was saying it a gentleman in the room raised a hand. I said, "Yes." And he said "You don't know my sister, do you?" "No, can you elaborate on it?"

And he said, "This happened to her also. And she went out and got a funnel and filled it." That also tells you you can make things foolproof there is always a bigger fool. So, and then I said, "Really?" And he said "$3,000 of damage later." Because if you fill the wrong type of fuel, it'll damage the engine. And she lost the engine with it. But the point

is it is where your design be graceful on failure. So, to me how can I design my software in a way it fails less and when it does fail, it fails That's also about simplicity. So, when there's a network failure, I I was speaking a conf- in a in a conference. And I teach part time at the university. I've been teaching for about 35 years now. And

I was I was in a conference. And after I finished my talk, a student came an attendee came to me and said, "You probably don't remember me, but I took your distributed computing course in 1998." I said, "Oh my gosh, I remember teaching distributed computing back in the '90s. It's great to see somebody from back in time." And he said, "Well, I've got a story to tell

you." I said, "I love stories, tell He said, "Well, I was in your class and and we had a group project. And so we implemented this software. And at the end of the semester, we had to do a demo. Okay, sorry. I have to set this context for the youngsters in the room. 1990s, we barely started seeing this thing called browser. In 1990s, there was no Wi-Fi.

I need to clarify this because people who are young always look at this like, "Really? How did you escape dinosaurs, right?" So So we literally would have ethernet cables run down the room and you plug it into your computers. There was no laptop. Into your computers. So we had no laptop, we had no Wi-Fi. And so this cable comes in, you plug it into the computer. So

now that I've explained that. So he said, "We had to do a demo at the end of the semester. And we were we were doing the demo. And you were sitting there watching this And right in the middle of the demo, you quietly walked up to my computer and you disconnected the ethernet cable. And you went back inside down and said, "Continue." And my program crashed because

there was no internet connection and I failed the course. I said, "That's not a story. That's a tragedy. Why are you telling me this to make me feel bad after all these years?" And he said, "No, no, no, no. I need to tell you this because you have a very big impact on me." I said, "It doesn't matter what the impact is. How horrible I failed you

in that course. I feel bad about it now." He said, "No, no, no. You need to understand because he said this taught me a very important lesson." He said, "And the lesson you taught me I need to treat failure as a first-class citizen." That's what he said. And then he went on to say, "You see, these days when I program I don't just code the happy When

I code, I think of what could go wrong." And then he said, "In my office in my cubicle, on the wall I have a picture of evil Venkat. And I look at this picture every day when I code. I honestly don't know how this picture looks but I can visualize it. And I don't think I want anybody to have a picture of an evil Venkat in their

office and they're coding, 'Oh, I better handle exceptions, right?' But the point is, we need to think about failures and the effect of failures as well. That is part of our responsibility creating simple solutions, too. So, the idea here is that simple fails less but fails gracefully. Simple is easier to change and to maintain. So, we have to constantly work towards making things simple. So, that is

one of the first things, how can we make things simple? The second thing is, we have to refactor. So, what does refactoring do? Refactoring is a way for us to make things better. This is a few things I follow. And the first thing I follow is a realization, a lesson. And the lesson is, you can't uh make it right on the first write. This is not possible.

You cannot make it right on the first If you say, "I've got one shot at it." and I'm going to write it, and wow, that's the best code you can write. Or best system you can design, the best solution you can architect. Sorry, you cannot. Why? Because the minute you do something is when the real learning happens. And then you come back and evolve it soon after

that. So, essentially, I'm a big fan of make it work, real soon. So, make it work. And then come back and make it better So, essentially, you're saying, "I I did this, but now that I'm doing it, I can see how it can be better." Great. Now that you realized it, go for it. And this is something you can evolve and over and over and over. I

once naively said this. I said, "Refactoring." "Refactoring is but a second chance to improve the quality of code." So, refactoring To me, that is like relieving myself of a burden. It lifts the weight off my shoulder. Hey, you know what? I can do the best I can right now based on what I know, but once I do, I can improve the quality of the code. I can

refactor it. Refactoring is not just design level refactoring, architectural level refactoring as well. You can make things better. Maybe I was a bit naive about it when I said that. Let me see if I can find this So, refactoring it is but a second chance to improve the quality of code, right? Let me see if I can find it. Uh maybe I will maybe I won't. So,

this uh this is a you know, social media post. Always a challenge when you search it, right? Uh so, basically in this case, uh this is in in interesting enough uh on how we can improve what we do. So, this gives us an opportunity to to make adjustments. I I couldn't find it here right now. And and of course, this is something you can continuously improve. And

and that is a way for us to give ourselves multiple opportunities to evolve. I'm going to drop that one and keep moving. So, essentially, this is a make refactoring a regular practice. You can say, here is what we came up but based on what we know now, we're going to make these adjustments. One of Here is something to think about, This is where the challenge often is.

And the challenge is you can say it is almost always easy to add but very hard to remove. This is our our world we live in. It's almost easy to add but very difficult to remove. How many of you have seen this? There is a code. Maybe that's not the code we want. And what do people do? They don't don't highlight and delete it. They're fearful. At

the best, they comment it out. What if I need it? Or we just leave the code there as dead We're not We're not even using it. Why are not removing it? What if something breaks? The cost of adding to the cost of removing in our field, the cost of removing is than the cost of adding. This is why we have to be very careful Because if you

add it, it sticks to you. Very difficult to remove. Adding that thing that stuck on your shoes. And you're like, "Ew." And now you are working hard to remove it. You know the feeling, right? And it's very difficult to remove that off your shoes. That's how code feels. It's easy to stick, hard to get it out of the way. So, we need to take the time to

constantly refactor. This is one of the things to think about. I I I travel around the world, so I spend a lot of time outside. So, my ritual usually is I'll be at a client site or or or in a conference, and I would go away in the evening, and when everything calms down, I would go to dinner, usually take a book or a computer, sit down

in a restaurant, have a meal until they kick me out and say, "Sir, the restaurant is closed. You need to leave now." And I'm walking back to the hotel. As I'm walking back, these busy streets I walk through are almost empty. All the shops have closed. But I would always pass and I look at these restaurants. These restaurants were very busy at 5:30, 6:00, 7:00 in the

evening. But right there at 10:30 in the night as I'm walking back, the restaurants are completely empty. And I would always pass and I look through these large windows, and you see this entire floor is cleaned up. The tables are all empty, and the chairs have been folded on top of the tables. You've seen that, right? In every business except one, there is a complete cleanup that

happens at the end of the day. You know which business there's no cleanup? You know this because you're part of it. What do you do? The debugger is blinking in the window where you left with the pizza uneaten on the desk, and you come back the next morning, you push that to the trash can, and you sit down and then you continue. There is no cleanup at

all in our business. There's a reason why we suffer so much, But that's basically a way to come back and improve what we do. So continuously refactor the code that and the architecture and the design that becomes important. One of the important things to consider is this concept of reversibility. So what is reversibility? It is the ability to back out of Reversibility is a very important characteristics.

When I sit down with my team, I often ask them, we're going to make a decision and 4 months from now, 6 months from that was a bad decision. What is the cost when we realize it's a bad decision? Can we change it? Or is it very hard to change? Again, going to the construction I build a house with a three-car garage and in the middle of

construction, 7 months into it, I go to my builder and say, "Excuse me, this garage has facility to put three cars, but I really need to park four cars." And the builder will just laugh and say, "Sorry, dude, we can't just throw another car into a garage. That's expensive to change because the size of is impacted by the foundation." So, if you want a bigger garage, you

need a bigger foundation and I cannot change the foundation later on. Same thing in What is that foundation in software? You've been building the software for 2 years. I come to you and say, "I got a great idea for you." Yeah, what is it? Don't use this language anymore. Let's program in other language. Dude, you just start laughing, right? You're like, "Dude, do you do you even

know programming? You cannot just change the programming language overnight." I say, "No problem, no problem. Let's do something else. Using Spring Boot, right? Yeah, let's not use Spring Let's change it to something else." You're like, "Are you out of your mind? I cannot just change the framework because the framework is foundational to my software." Then I say, "Yeah, but what if we can you know, library that

processes XML data. Can you change that library?" You're like, "Yeah, I can do that." That's not a foundational change. libraries are relatively more reversible. Frameworks are expensive to reverse. Languages are expensive to reverse. Hey, what about databases? Oh, yeah, you can change that. Oh my gosh, thank you so much. But what do I do about these stored procedures? Oops. You cannot just change the stored procedures overnight

because they are very specific often to the databases. So, just because something is perceived as reversible doesn't mean it's But what's the moral of the story? If something is reversible, you don't have you have less risk. If something is not reversible, you have more risk. I have to take the time to evaluate things that are more risk because if it's more risk to change, I better take

more time to decide, not less effort to decide. So, if you tell me, "Here's a new system. What database should we use? What programming language should we use? What framework should we use? What library should we use?" Postpone that library. That can come later. The language and the framework and the database, let's pay more attention to them because those are hard to reverse. And so, I'm going

to be taking more time and effort evaluating what is right because reversibility is hard for those. So, when you are working with you need to ask the question, is this reversible or is it hard to reverse? And make your decision based on Because that's got consequence to what That's something to bring into the discussion as we evaluate what we are architecting and how we are approaching it.

That becomes essential. The next thing is the last responsible moment. Now, this is harder than we think. When should I decide what I should do? Think it. Where are you going to have dinner today? I don't know. That's not important to me. Unless I'm going to meet somebody very and I need to make sure that I meet them when they are in town. I need to plan

ahead. If all I'm going to do is to have a quiet evening at the end of a long day, I don't need to decide where I'm going to decide to go to dinner. And usually that happens like 5 minutes before, "Oh my gosh, I'm hungry. What is nearby? I can go to dinner." So, I can decide it the day I'm going to dinner unless I'm meeting somebody.

Hey Venkat, when did you purchase the flight ticket for this conference to come in here? Well, that's going to be expensive and seats may not be available in the flights I want to fly in. I bought this ticket in November. Literally. Not just giving an example. And I bought it in November for an April trip. Why? Because I know the flight prices can fluctuate and reflect back

on the current times. Those people who waited to buy the ticket are saying, "My gosh, it was expensive because all the nonsense going on around the world." And I'm like, cool. I didn't pay as much to buy the ticket. I know this is going to get expensive and it's going to get unpredictable. I'm I'm experienced traveling. I know when to buy things. And so there are things

I do really and there are things I do really late. This is not procrastination. Procrastination is where you have not done something that you were supposed to do. Which reminds me by the way, I really wanted to write a book on I just haven't gotten to it yet. So, procrastination is something that you keep pushing and avoiding and avoiding. My gosh, I should have really done this

before. I haven't done it yet. Last is thoughtful moment is a very active and deliberate postponement. Why? Because there are things I will know than I know now. And by knowing those things, I can make a better decision. And so there are things you should actively postpone but not any later than you can wait. I'll give you an example of this. I was on a project where

we had to decide on a database to use. And remember I was talking about reversibility, right? You have to be careful about. But we wanted to use a database. The problem was A, we decided not to use stored procedures. That's the good news. Because we don't have any stored procedures, database is more reversible for us than if we do. the product has to be deployed on a

cloud environment. But I don't know which of the cloud providers we are going to use. And different providers had different databases that was available at different cost. So on day one, my question is, what's your database? Gosh, I don't know. Because we need to know what cloud provider we're going to use. When will you know that? Oh, we're going to know that in about 4 So what

do you want to do? I decided I was going to build the the entire application with SQL Lite 3. Why? Because SQL Lite 3 is a file-based I can throw it away, recreate it in a heartbeat. And I have scripts that create my schema. And I had no clue what the schema is going to be because it's going to evolve so much in the next 4 months.

So I said, boom, use it with with this and build it. Fast forward, we are into 4 months. Now we know what cloud we're going to be deploying it on. And at this point, we need to commit to the database. Before this time, we did not have to After this time, we don't have the luxury to wait. That was the moment, last resort on moment. Why can't

I wait? Because we're getting close to the release. Why can't we do this earlier? Because we didn't know what how we're going to be using. And I remember this day, I will never forget it. We ran all the test. Every test was passing. Yeah, this is great. Now that all the test is passing, I change the configuration to use the database we want to use. I ran

all the test again, and three tests failed. That moment when three tests failed is called a moment of panic. Oh my gosh, why is 3 just failing? let me check. And I saw the error message. What does this error message mean? Literally, I put it on the browser. What does this error mean? And it says, if you see this error, you are probably using this data type,

which is not compatible with this other Consider using this other data type. That's the problem. Roll back my configuration, went back to SQLite 3, modified the schema data type, reran all my test, everything passed, commit, change the configuration to the new database, reran all the test, pass, commit, never to look back again. Now, in this case, you may say, what was the test that failed? That test

failed on one of the cases there's a small area of the system where a user would start adding some information, but that may happen months after a user has created their account. You can imagine the risk of not testing it is very high. Had we done manual testing, we probably would have missed it. Because this was an automated test, it gave us an instant feedback. I'll come

back to that in a little bit But the last responsible moment right that we postponed it until we can no longer postpone. And the benefit? We were able to figure out what database we'll use and then commit to it. But then I realized something I didn't quite capture on that day, but I realized it much later. And that was why don't people do last responsible moment? Why

is it that they rush to do things? And I honestly, I didn't think about it on that day. But I realized it much later. most people when they do manual testing, manual testing takes time. So, if you make a drastic change a month before you go to release, you don't have time to do all that manual testing. And now you're going to say, "If you make all

this change, good luck. We're not going to take responsibility for that, right?" And so, you're like, "My goodness, the team doesn't have time to test it. I don't want to take the blame. Let's make all this decision early on." So, we're going to be driving ourselves towards doing things early because the risk of testing it is higher later on. But if I have good number of automated

my feedback loop is really fast. I can make a change and know very quickly whether it's working or not. I could not have last responsible moment without fast feedback loops. And this is why things connect. All these are synergistic, right? The holistic things come together. You cannot just do one alone without having other capabilities. They're all interconnected. But this gives you the benefit because you can be

smarter tomorrow than you're today because you have more information tomorrow than you are you have today. So, there's a benefit to postponing. This also requires a bit of a courage on our part to take a deep breath and say, "I can wait on that. I don't need to decide that right now, so I can focus on what's imminent, what is important right now, and postpone this other

thing until a much later time." That's another benefit. One of my favorites is YAGNI. YAGNI stands for you aren't going to need it. I normally put a little Y at the end, I call it YAGNIY. The Y is something that I have added to it. The reason I also put yet is my programmers get very anxious. What do you mean I don't need it? You don't need

it yet. Okay. So, I can do it tomorrow, right? You keep saying it until we release it without it. So, YAGNI says don't bring anything in that is not essential. Why not? Because the more you bring in the harder it is to maintain the code in the long run. I often say code is like people on a crowded train. There are more people in the train, it's

hard for other people to get in. Same thing with the code. You got a lot of code, it becomes harder to add code. So, minimalism is a very important YAGNI allows us to ask, do I need that? Can I postpone it? Can I wait until later? What if I don't ever need it? every opportunity be critical of what you bring in. Remember what I said earlier? It's

always less expensive to add than to remove. So, if you don't add, it's easier to But here's the problem, right? I mentioned this earlier. The problem with who are programmers is double. We eat more than we should eat, and we write more than we should write. That's what we do all the time. But it takes courage to go in the opposite direction. It really takes courage. I'll

share with you one experience. This is what I appreciate when I when it happens. I had traveled international. I was starving. I was hungry. I went into a restaurant, sat down, and the restaurant waiter came to me and said, "What would you like?" And I'm like, I would eat the desk if I have to. I was that hungry, right? I said, "I want this, this, this, and

this." And the guy was very polite, and he looked at me and said, "So, you want these items?" Yep, that's what I want. And then he looked at me in a very nice way and said, "May I ask you how many other people are joining you?" And I said, "Why? I'm I'm here alone." And he said, "And you're alone and you want all that food?" I'm like,

"Dude, I'm paying for the food. What's the problem?" And he said, "All right, let's try something different. Why don't you order half the food, and if you finish that food, the other half will be served to you at no charge to you." I said, "I like you already. Let's do it." And he served me half the food. I managed to eat half of that. He said, "Can

I bring you the other part at no charge?" I'm like, "No, thank you for, you know, being wise and and and making me realize what I was doing." That is courage. He could have said, "You know what? This fool wants to order the food. He's going to pay me. I'm going to dump all that food on his table. Why do I care?" But he was a professional

on that day. And that you gain respect for people when they do it. That's my responsibility as a programmer. I should not write any code that is not necessary. Because code is a liability. See? That's what happens when you write a lot It's biting them. They're struggling. You hear this every time. You can hear this. Scary. Don't go that side. That's legacy code. They're maintaining them, right?

So, the point really is you don't want to write any more code than you need to write. That's YAGNI. You're not going to need it. Don't write it. But, this requires being alert, constantly asking, do I need it? And to avoid writing code that's not needed. What about extensibility, you say? Don't they want to make this code do all these beautiful things? extensibility is a slippery slope.

We often write code for the sake of extensibility. And in doing so, we have made things more complex than it should be. So, how do we then consider extensibility if we don't do My recommendation for extensibility is to wait a little bit to truly understand what that extensibility really is. If a change is needed and a similar change is needed in the future, but then make it

extensible, but not too early. Not too prematurely. I I had somebody teach me this wisdom. And he said to me, he said, "Venkat, I learned something," He said, "If I had an interface and a bunch of classes, I'm stuck with it. It's very difficult for me to remove But if I only write a class and then I realize I need another class and now I extract the

commonality into an interface. This is something I grew based on real evidence rather than perceived extensibility. And he said, "At this point the structure is minimum. Whereas when I did it ahead of time, it is massive." And that is the lesson I carried forward hearing this. It's like you can always incrementally rather than doing it ahead of time. There is another problem that we need to When

you hear all these things in lectures like this or books you read, articles you read, sometimes we'll miss on the context. We don't think about the context. I've been writing about 40 years. When I started writing code, a lot of people in the room probably are young. You're thinking, "Gosh, what does that mean?" 40 years ago we did not have IDEs. There was no IDE. There was

no Eclipse. IntelliJ. There was no VS code. There was no Visual Source Safe. No, I'm sorry. Source Source What does VS stand for? Studio, right? Thank you. Visual Studio. Not VS code. This is VS without the code. Visual Studio, right? None of that exist. And how do you do your stuff? You go to the command line. Oh, there was no notepad. There was no Windows. Why notepad,

right? So, literally, you had a terminal in front of you. And you open a terminal and you did everything in the terminal. And when you do this, how do you edit files? By opening one file at a time. And imagine this, if I have to make a change that affects 30 files, you got to sit there and open 30 files and make changes to it. The cost

of change was enormous. Today, you're sitting in front of your IDE and you gently right click. Okay, maybe not right click. Shift F6. If you're using shortcut on the keyboard, right? And then you change it. And it says, "Would you like for me to go find everywhere this is used and change it?" Yes, please. Before you can blink your eyes, it's done. Old guys like me are

in tears. Because what you just did took us an entire day. And still we got it wrong. has come down drastically. So, now if I tell you, "Oh, you got to make all these things now because it's expensive to change later." You're like, "No, it's not. It's not really that expensive as time goes on." So, you need to think about that as So, to me, focus on

parsimony. Parsimony stands for minimalism. So, do as little as you can do now and do more when you know more. And that can help you to create an that is easier to evolve and easier to maintain as time goes on. So, this is something you can do deliberately So, you can think about this. Any fool can write a lot. But, it takes wisdom. And I will end

this word with one thing. This is something I've been thinking quite a bit We all are so eager to gain knowledge. Which is good. But, knowledge in the absence of wisdom is dangerous. I would never hire anyone who is knowledgeable but doesn't have the wisdom. Because knowledge shows you what you can do. Wisdom tells you what you shouldn't. And that's extremely important for what And so, I

hope a few pointers that you can take back and think about how you can evolve the architecture as well. Thank you for your time. >> [music]