A Tale of Two Systems: Design and Reality - Mandeep Singh

This talk, titled 'A Tale of Two Systems: Design and Reality', covers the discrepancies that often arise between a designed system and its actual implementation, a phenomenon known as architecture drift. The speaker, Mandep Singh, a software engineer and author, highlights critical reasoning behind these inconsistencies, including technical debt, changing requirements, and assumptions made during the design phase. He discusses the importance of maintaining clarity in system requirements and emphasizes the need for peer reviews to avoid treatable mistakes. Furthermore, the talk introduces the concepts of two-way door decisions and the use of AI for productive software development. The session provides strategies for overcoming these design challenges while ensuring the architecture remains aligned with reality.

The title of the discussion is a tale of two systems design and reality. Uh many a times it happens that the system you design okay it is not being reflected in the reality. We also call it architecture drift. Okay. So we will be talking about some of the reasons uh why it could happen or why it could be introduced in your system and some of the ways

you can come out of it. But if you didn't attend my last uh previous session, I will quickly introduce myself uh just to add on what uh I was introduced earlier. So I'm Mandep Singh. I'm a software engineer. I'm author of this awesome book called Systems on AWS. It teaches you system concepts along with how you build systems. and I also manage a YouTube channel called Amaz

Singh. So back to our session design versus reality. Okay, we have something in design and then the reality is totally different. We'll start with some of the uh uh uh architecture diagram per se, right? So let's say uh you build something. Okay, this is how it looks like. Uh in the design phase, you have clearer components. You know uh these are the different services I have. I

have a database, I have cache and all those things. It's a pretty clear clear picture. But if you see right now on the other side right uh if I ask you what that is and if I ask you to compare uh how that uh is being reflected in the reality that's a total mesh right uh people also call it big ball of mud so over the time

it could happen that how you built your system or how you implemented our system or probably I mean there could be lot of reasons for why it happened but due to those reasons we end up ended up like that okay so we have to try that we don't do something like that. Instead, we keep our system clean. Okay. So, we will start with software development life cycle.

Okay. This is how every uh uh software starts, right? Uh and these are like four stages which are shown here. But uh I mean depending on company or depending on organization, depending on team, these could vary. But at a higher level, there are four stages. The first phase is design phase where you do architecture uh or like let's say requirement gathering. what is my system is expected

to do? Uh what is my system not expected to do? All kind of those kind of things, right? Then you uh come up with certain uh architecture, right? Uh that these are the different components which are there in my system. This is how they will interact and all those things. Okay? Once you finalize on the architecture, then you plan accordingly, right? This is how my system will

be implemented. Probably you divided the system into multiple phases. Okay? There could be a lot of things. So you do that in the first phase. uh once you did all that you built the architecture you uh created a laid out a plan for it then you do the implementation you are building that solution as per the architecture which you created that the second phase and once you

implement the solution then you come to testing uh we build something so we have to test it out right uh we don't just give directly to the customers uh we test that out uh that okay my system is working as per what I expect it to be okay and there could be bugs as well like uh there are always bugs Right. So we uh run out some

fixes. Uh we probably come back to implementation phase again and then we test it out again and finally once we are sure that okay uh everything is working as per our expectations then we finally go to the launch phase in which we go uh do the deployment and go live. So these are the general stages right and depending on then it can be a complete feedback loop

cycle that uh depending on like I mean you gathered some feedback or you probably monitor some metrics and all you can again come back to design and implementation and today what we are doing is we are focusing on these two phases design and uh launch. So something bad happened between these two phases implementation testing and all that the launch doesn't look like what it was supposed to

be. Okay. Uh we planned for something else but we ended up delivering something else. Okay. So let's start with our design phase first. Okay. So what do we want in a design? Okay. Uh let's say you are a king, right? You want to build a castle. So how well you want to build that castle? You want that castle to be perfect. Uh see look look at this

image. This is a a generated image by the way. So look at this image. I asked gave it the prompt that okay generate me a beautiful castle. Okay. So if you see the lighting is perfect, the gardens are great. Uh the tombs and structuring and all everything is great. Right? So this is we want uh this is what what we want in our system. I mean uh

if we are building a castle, right? So this is what we want in our building right? But uh we are not civil engineers. Uh we are software engineers. So if I talk about the design software design what do we want in our system is that first thing is we have good clarity on system requirement uh the design phase which we talked about earlier that I have I

know what my system is supposed to do I know what my system is not supposed to do I have clear boundaries I have clear tenets right so that's the first thing you do and once you do that you come up with certain architecture we don't want to generate that big ball of mud right uh we have a a clearer uh uh architecture right how the components are

interacting how your code is written and all those things and you also want to ensure some sort of non-functional requirement charact characteristics of the function uh system as well that my system should be scalable as in like when there is new traffic that came in okay spiky workloads or my system should be able to scale well or I should not be able uh spending too much time

on the on call my system should be maintainable right so all those things and finally you should have a clear implementation path that I did the hard work Now I will build the solution. Okay, this is what we expect in the design phase. But let's come to the reality now. Okay, we were building castle earlier, right? So let's say the architect who was uh designing this castle

uh some other king hired that architect to build his castle. Okay, or this king was killed or probably the workers who were there uh they left in between. There could be a lot of reasons. Okay, and in reality it turned out to be something else. If you see this castle, there are a lot of patches which are there. Uh it's broken at places. The garden is torn

out. Okay. So it is not what we supposed to be. Okay. And if you compare this with a software architecture, so in the software terms, uh you might have introduced lot of techs. Okay. We saw lot of patches in that building, right? So let's say you introduced quick fixes and workarounds uh due to maybe probably a lot of reasons. We will be discussing that in further slides.

But yeah, you introduce technical debt in your system. some lastm minute must have features came in your project manager came okay this is the most important feature that we have to build right now I mean I have faced this situation you might have also faced this situation that this is the must-h have feature we have to integrate it whether it was uh thought of in the design

or not okay so that is one of the thing the next thing is company prioritizations also change probably let's say you are working on some project and some government regulation came in you all know probably cases of dream 11 or all these things, right? So, prioritizations change. So, due to that, uh it might be possible that engineers were shifted to some other project and all those things,

right? So, that can also uh happen in reality. And the next thing is dependency hell. Okay. Now, when I say dependency hell, it basically means uh I mean whenever we deploy a system or like whenever we create a system, uh a single system doesn't do everything, right? you depend on some other systems, you depend on some libraries or or what all right but if you don't have

clarity on why something is used okay if you don't you are just adding dependencies all over and again so it will become hard to manage right so that sometimes happen in reality as well and the final point is u you might have faced this okay uh let's say you say that okay it was working yesterday I don't know what happened today uh it's it's broken okay or

you might say that it's working on my machine but it's not working in that particular environment. Right? So all these scenarios can happen in reality uh which we might not think in the design phase. Okay. [snorts] why this happens? This happened we know that we thought of something uh we ended up with something else. So why this happened? Okay. So the first thing is design assumptions doesn't

hold true. you uh created the design with some sort of assumptions but when you are building the system those assumptions didn't hold true or like they completely changed. So I will uh take an example from my personal life. I was working on one project okay uh and it the project required state machine management. When I say state machine if you compare it with let's say e-commerce website.

So whenever you place a order there are different states through which this shipment transitions let's say first of all the order is placed right whenever you place a order then it's in processing as in the shipment is being packaged uh then it moves to intransit that it is being delivered I mean it is in path to your location and finally it is delivered canceled or let's say

returned back all those things scenarios can happen so we had a similar use case that we have to manage states right so we have to have some kind of structure or some kind of quoting pattern or whatever you call it uh we have to design that managing of state machine in our codebase. Okay. And uh in our parallel team okay with some other manager uh we had

a similar use case not the exactly same states but they had a similar use case of managing the states. So we interacted with them and they mentioned that okay they are using this particular opensource library and it is working pretty great for them. Okay. uh and it is offering them lot of abstractions and all those things. So we also thought of as in like it is already

used by those people right uh so why not we use it ourselves as well right this is what we generally do we ask people okay this worked for you or probably you did some blogs you ask jp or I mean whatever resources you follow uh you take help from folks right and then you think that okay it worked for them so it will probably work for us

as well okay that's what we thought and we implemented the solution and then we uh moved ahead with the testing and But what we observed was uh it introduced and we actually implemented that first. Okay. Then we observed that it uh unnecessarily introduced some abstractions which we really don't need. We were trying to fit into those abstractions just to make our code work, right? And it was

unnecessarily making the coding like you want to easily understand that code base, right? So you can uh say that okay it was all beautiful and all but it was not making sense for our use case. we just introduce abstractions just for the sake of it. So instead we pivoted and then we removed that library altogether from our codebase and we implemented the simple state machine on our

own. Okay. So this was one of the use case around uh we took some assumptions and then we pivoted uh to a different approach during the implementation phase. Now these things can happen with you as well right? uh so how do you handle those inconsistencies on your system if these things do happen how do you handle those so the first thing is figuring out right tool for

the job and you can do that by doing some sort of proof of concepts PC's right uh the idea is that if you do a P for use case uh then you will know that okay this is what I need really okay uh if you are dependent on some other team's inputs and all uh and remember that it can definitely It will take some time but it's

always better that to uh spend that uh that much time into implementation and then come back completely revert and then uh think of your s own solution okay so it's tradeoffs you can say right so if you do early PC's you are able to figure out right tool for the job you might have heard the phrase uh if you just have hammer everything will look like screw

to you right but that is a wrong approach right uh you should you should be able to figure out a right tool uh for the right job and one related strategy is uh two-way door decision-m so during my uh time at Amazon I was part of Amazon earlier so I was introduced to this concept of two-way door what it basically means is that uh if you did

something okay and it didn't work as expected okay you took some assumptions uh you did uh did that approach so it's easier to come back or like take a different approach altogether if you compare it with the oneway door decisions uh they are kind of irreversible. So it's one direction only, right? So you should always be able to like you should always try to take two-way door

decisions as long as possible. But let's say you took a particular decision. Okay? What if that go uh goes wrong, right? That happened in our use case. So what you do, you communicate and pivot. Uh let me uh take one example. So let's say uh you are all excited about this session and you want to travel to GS location right and you uh searched on the Google

maps that uh I want to travel to uh GS location and Google map show this 18 minutes of clear path uh I mean you might be thinking if if it's really true in Bangalore traffic but uh we are talking about assumptions so why not right so let's say uh it was showing 18 minutes But let's come back to the reality now. Uh since we are talking about

Bangalore, it can really happen that you find a road closer, right? So let's say uh you find a road closer. So what you will do there? There are three options there. Basically the first thing is you stop there and wait that uh this road will be opened and then I will travel. Okay, that's the first option. The second option could be that you go back home that

I'm not attending the session, I'm going back home. But the better approach would be you ask Google maps that find a new path for me. Okay, that's communicate and pivot and it really applies to our lives as well, right? Uh I mean if something is not working for us then we take a different approach altogether. That's pivoting. The state machine approach didn't work for us. So we

perted to building our own state machine. Okay. So this is all about design assumptions doesn't hold true. U the example and how we can uh solve those inconsistencies. There are two points next which we will be discussing. First thing is wipe coding. uh w coding essentially means uh AI assisted coding. Okay. So you use some uh sort of AI tools to write software right another thing which

is related to this is no expertise to implement the architecture as in you are just coding based on wipes you don't know or you don't have expertise to actually write that software but since you have the AI tools at disposal you are using them to create that software if we talk about wipe coding uh you might have seen lot of posts or news on LinkedIn on social

media everywhere right that uh CEOs claiming that this is the percentage of code which is written by AI right uh you will see uh lot of people claiming that these are some of the screenshots which I took uh but you will see this all around uh all around the internet but with everything there is never 100% upsides like uh I mean any decision you take there are

some pros there are some uh cons right there are some positives there are some negatives so with swipe coding as well there are some downsides the first thing is uh blackbox code. What do I mean from this is that you wrote uh you wrote the code but you really don't understand what it is doing right. Uh you don't understand how it is working. You can't explain uh

what is going inside there. So it's sort of a black box for you and it introduces a sort of kind of hidden complexity to you. If I ask you like why these 10 abstractions are implemented in your code, can you explain that? Okay. If you're able to explain it then why coding is great. If you're not then it's a downside right. So it's a hidden complexity which

get introduced and in the beginning you might say that okay this is very clean extensible and all those things. If you attended the first keynote, uh there was a discussion around extensibility, right? So we should I mean extensibility only sounds good until and unless you actually need to extend that software, right? So if there is a hidden complexity, uh it's a big downside and it also introduces

missing edge cases. If you don't really understand what you are doing, there could be lot of edge cases. Okay. Uh let's say you have some sort of dependency in your software. Now if that particular dependency is down can you handle that? Is there some graceful way through which you can handle that? Okay. Uh so missing edge cases a big problem but as I said uh everything has

negatives and positives. Okay. So it's great tool right I mean how many of you are using AI tools to write software? See including me everyone is using it. So it's a great tool right? It helps you to move faster. So the first thing is if you want to build MVPs and this is really helpful even if you're non- tech person right uh you can easily build MVP

so you don't have to reach out to engineers you don't have to seek their bandwidths you can build a MVP and then seek feedback from customers really right it's easier to do that okay the next thing is it helps you to move faster in software engineering now when I say software engineering you don't have to spend too much time on research probably right let's say earlier you

want to create some sort of architecture that this is the problem I head and I want to research about it right so AI tools can really help you there and not just wipe coding term uh AI tools we are talking about right so it will really help you to move faster in software engineering like I was working on a legacy uh codebase right now so it's hard

to get understanding of that but if you use some uh sort uh this AI tool it can give you some head start that what is actually happening inside that legacy code once you have that head start you can again I mean iterate over that or your understanding that okay this is what is really happening and it is really great if it's paired with human right so I

was as I'm saying right I'm trying to understand this legacy code now I'm paired with it as in I'm also trying to understand what is happening so I can actually make those improvements if I see that okay these are some bottlenecks which which are there in my current code then I can improve upon them so paired with a human uh AI tools can really work great and

the final thing is if you understand why along the Okay. So if you remove that blackbox code thing, okay, if you remove that hidden complexity and you know that what is really happening in your software, okay, then it's a great thing. Let me uh take you back uh to the uh pre AI era. Okay, let's say you faced certain problem. You are developing a solution, you face

certain problem. What will you do? You will do a Google search, right? You will find couple of answers. Stack Overflow most there are couple of stack overflow links which you will find. uh you will go to a particular link okay this link is making sense then you will read all the answers you will read all the comments which are there and from all those solutions what you

will do you will figure out what is the solution that is working for me right so that's what you have to do in the case of AI tools as well okay AI tool provided a suggestion to you but you validate against your business context you validate against your business use case that okay this is what is really making sense to me so if you're doing that then

AI tool AI assisted coding or V coding they are really great. Okay. So we discussed three points till now. Let's move the to the next one which can contribute to why design is not being reflected in the reality. Technical debt. Uh we pinpointed this point in the beginning that in reality technical debt can lead to uh the uh uh drift in the architecture. Right? So when I

say technical debt, what are some of the things that technical debt can introduce in your things uh in your uh software? The first thing is suboptimal solution. Okay. So let's say there are multiple solutions to a problem. Okay. It always happens that particular problem can be solved with multiple options, right? So because of some of the reasons you took a sub-optimal solution, a solution which is not

optimal. Okay? So you took a suboptimal solution. So it could be a tech it would be a technical debt for you. Okay, because uh there would have been more better approach which which you should have taken but you took a suboptimal approach. So it's a technical debt and it could happen due to multiple reasons such as tight deadlines. Again your project manager came in that it's a

a really important feature we have to introduce and uh uh we don't have much time. It's a very important ask and we have to survive in the business right uh I mean even if introducing technical debt gets there get gets you there uh we do it okay so this can introduce a technical debt okay and tight deadlines is one of the reason the other reason could be

that team lacks expertise now when I say team lacks expertise uh let's say you are working on a software and people don't have expertise to build it now even if you don't know that you are introducing that debt in your code you introduced it because you do you lack expertise around it. So that could be one of the reason that uh the uh software has technical debt.

Another reason could be departing engineers. Uh departing engineers uh it happens with a legacy code bases uh mostly that there was some software architecture and uh it was [snorts] a software code or a system or a microser it was managed by one person and that person actually left. Right? This this this is what happens right junior is asking where is the documentation and team lead is saying

I am the documentation I I I have the power of it everything right so if that is what is happening and if this engineer leaves then that is the technical debt which get introduced in your codebase right but we have to manage it somehow right uh if it gets introduced we have to manage it if there is a problem we have to figure out a solution so

if you talk about some of the ways the first thing is uh if you took some shortcuts let's say you took a sub-optimal path you should really understand it why you took it. It could could be your tight deadlines. It could be earlier that team lacks expertise. Okay, whatever reason is if you understand why it is there in the first place then probably you can manage it

well. So it's the first thing. The next thing is you treat debt as business priority. Okay. Uh you never say I mean you never assume that you are solving this technical debt because you will feel good about it. Okay. uh in the end we are in the business of making money right uh we are not in the business of feeling good okay so we have to treat

that technical debt as business priority now if I have to explain this problem to a business person everything all right yeah uh okay so you have to treat everything as a business priority now if you have to explain that to a business person okay you might say that okay if I uh inter if I resolve this technical debt uh my new feature release will be reduced by

four weeks. Okay, that could be one of the reason. Other reason could be that since I earlier took a suboptimal solution, if I improve it right now, my latency will be dropped by 90%. Okay, these are the reasons where business will prioritize. Okay, the reasons which you say that okay, the software architecture will be this and this. Business people don't care about that. So depending on the

stakeholder you are talking to, your decisions will change. I mean the words you convey will change and that's what really you have to do and the final thing is you have to track and manage there are lot of ways through which people do it you can just create jira tickets and put them in the backlog but you have to really pick them up right so I have

seen lot of ways uh in my experience that like how people do it one of the way is that uh during the on call cycles if there's some time is left there are no incidents there was a happy week so that engineer will work on some the techn technical debts which were introduced the some of the backlog items other approach which I have seen companies taking is

uh for a quarterly planning okay you are doing some sort of planning so I will dedicate uh 70% to new feature release to a product feature enhancements and other 30% I will give up to my uh removing these uh engineering complexities okay so these are the four points we discussed till now the next point is designer's mindset uh when I say designer it's basically the person who

is designing the software okay it could be architect it could be senior engineer it could be anyone it could be you I mean any person who is designing that software so what goes inside the person's mindset that it leads to the uh difference in design and reality the first thing is if that person acts as a source of truth okay and the person behaves as if I

have designed the system. It doesn't require any reviews. Okay. So the peer-to-peer reviews are missing. If those re uh these reviews are missing, then there are lot of edge cases which could be missed. Okay. This is one of the thing. Uh it could really happen that uh I mean if you brainstorm on a solution, there are a lot of things that come in. Okay. Uh there might

be some bottlenecks in the approach which was already took. So if that can be solved then it removes that problem. So this is one of the thing if architects behaves as source of a truth uh it is a problem and it happens mostly because there is missing collaboration between designers and stakeholders. Okay. Uh designer is working in silo that okay I came up with this architecture now

go build. Okay. So there is separate architecture team there is separate engineering team which is implemented that implementing that architecture. So if that goes inside the mindset or if that's the culture of a company then that can become a problem and that's the reason when the drift happens. It's one of the thing I have seen this firsthand that if a person if a designer is too focused

on exploring new things uh rumdriven development you can call it promotiondriven development you can call it anything you call it if the person is focused too much on that it can really create a problem right if you are using a solution which is not really needed okay then it will create problem if you're just introducing these tools even if you there is no requirement for it then

that's a problem right Because the ideally what we want to achieve is uh we are not seeking a perfect design right we are seeking a solution which solves this one quote which I really uh find useful that 90% of functionality delivered now is better than 100% of it delivered never okay so if you're trying to build a perfect solution if that goes inside the designer's mindset then

that becomes a problem instead you should uh follow it approach that okay I've built the 90% functionality or 50% functionality then I will move ahead and iterate over it. So what should be the ideal role? If I talk about designers ideal role the first thing is they should not act as gatekeepers of perfection. They should instead act as enablers of smart decisions. Okay. What do I mean

from this is they should be able to guide the teams on trade-offs. Okay. Why this particular decision is being made? And I will share one example. I was talking to a developer uh why I mean why they are doing this. Okay, they were exploring a new database. I mean they were trying to integrate a database into their system which was a managed offering and I asked the

developer why they are using it and he gave me a really silly reason. Okay, he said that because architect told him so. So it it happens. Okay, even if you have not observed it, I have seen it that it happens that most of the time due to this missing collaboration and all uh people are just doing things because they are told to do. Okay, so that's one

of the problem and the ideal role would be that the architect or the designer should be able to guide teams on trade-offs. The next point is keep the architecture aligned with reality. Okay. So as I said earlier right, we are not trying to build a perfect uh perfect solution. We are trying to solve a business use case. We are trying to solve a business context customer problem

per se. So okay. So we have to keep the architecture aligned with the reality. Okay. It could be dependent on lot of factors. Uh for one person let's say I just have 10k to manage my software. So I have to manage through that. if some other person has 100k. So that is one of the what is the cost I have or then the next next point could

be uh what is the customer traffic I have. Okay. Uh so depending on all these factors your design can vary. So you have to keep that architecture aligned with the reality. So what we should instead do we do a smart design moving fast without sacrificing future. So the first thing could be since AI is a great accelerator, we talked about some of the pros, some of the

benefits of AI, right? So you can take help of AI tools for research. We're trying to move fast without sacrificing future. So this is one of the good things uh which is there right now in the industry which you can leverage to move faster. The next thing is doing PC's rapid prototyping plus validation. So it becomes a constant feedback loop. You follow an iterative kind of design

uh pattern. Okay. the design which is on day zero will not be same as day n. Okay. So you design and iterate. Uh and let's say you are trying to build a perfect solution on day end it will be really hard to map because you really don't know what you will actually uh uh need right. Uh if you try to remember the example of uh the Twitter

use case which we are talking about in the first session right so the idea was they tried to build something else but later on they pivoted to something else right. So the idea would always be design and iterate the day at zero and dayn will never be the same and let's say on day end your system is not able to scale. Now you will have resources to

do the architecture again. Okay. So that's the uh most uh I mean the basic idea that you can follow to have a smart design. Final thing uh I mean it's the thing which most people hate but the idea is that you document your decisions why you took a particular decision okay uh you don't have to create a fancy design you don't have to follow the English structure

or like all those things if you just you can add simple comments to your code base if there is some analysis which you did you just mark it down that why you took that particular decision okay in the future that decision might took might not make sense but at this particular point of time this decision is making sense. So why that's why I took it. Okay, moving

to the next point. Uh so we discussed five points till now. The next point which can contribute to design not being reflected in the design uh reality is changing requirements. So you started out with something and then later on uh it pivoted to something else. So I will take example uh from my personal experiences the project I was working on. Okay. So I will try to uh

relate it if let's say if you want to do it. Okay. So let's say you are trying to book uh if you you are trying to uh create a payment kind of functionality uh to book or like to offer this functionality uh of uh accepting the uh payments right you are to you are creating this ticket and then you are accepting the payment for it. Okay. So

there could be multiple ways through which you accept payments. I just added two them for bank transfer. One is NFTT one is IMPS. If you don't know them, any is like not a real-time feature. Uh it takes somes time to transfer money from creditor to debittor or debittor to citor and in case of imps it's a instant payment transfer. Okay. Now once the payment is done let's

say you process the payment you have to figure out is the payment successful. Okay that's the thing which you expect that on the status page is this payment success is it fail it's still processing and all those things. So if I talk about what are the ways of it right you are generally let's say integrated with some payment partner. So what you will do you will ask

that payment uh partner what happened with this payment right. So generally they offer some sort of APIs inquiry APIs that you pass on this payment id and they will tell you that this is the current status of this payment. Okay this is one thing. Other thing could be you are uh integrated with their web hooks. So you exposed a public endpoint you gave to them and they

will publish callbacks to this endpoint. you will consume that call back and then you will know the status. So these are the two ways through which you can do it. Okay. And we are talking about managing this payment life cycle. So I will uh uh take example of NFT. Okay. So this is what we got in the requirements. So if you talk about payment life cycle for

NFT payments, it will start with initiated let's say. Okay. Uh then it goes to processing uh when the money is in the process state. And there are two states uh for success and failure. One is from the debittor end, one from the citor end because it's a not real-time payment. Okay. So if it's a debit failure then it's a terminal but if it's a debit success then

it can go to credit success or credit failure. But when we launched the system we realized we realized that there are some scenarios that the transaction can still go from deemed success to failure. Ideally want to treat success and failure as terminal states. Okay. So in some of the cases the credit success state is missing. Okay. That was one of the thing which we faced. Other thing

is there is a state where we observe that from success it can go to failure. Okay, it's really troublesome, right? So we never accounted this in the design. We never knew that this could happen. Okay, but this was the scenario we encountered and we have to solve for it. So we modified the design accordingly that we will uh introduce some kind of threshold in between that we

will wait once the transaction has uh went to success even because anyway the NFT is not real time. Okay. So you add some sort of threshold that once this is moved to success I will wait for some time and then I will sort the customer to the success. Okay. So this was the change we had to do. So requirements can always change which can contribute to uh

I mean what you actually build is separate from what you actually thought of earlier. Okay. So how do you how do you deal with it? Well you try to build for today and you again try to uh leave the room for tomorrow. Okay. requirements can always change. uh one thing the most I mean you also might have thought of this that you uh and we I think

we already covered this in this session uh uh itself that you build for the scale you are at currently with some headroom not so much with some headroom let's say you are have 100 customers so you'll try to build for thousand or 10,000 maybe okay you not try to build for 1 million okay 10 million per se so you build with some headroom and then you definitely

extension points for future growth if you compare it with Let's say I want to design a building. Okay, I want to create a building. Okay, so I earlier had a requirement for two stories and I left some extension points. So in future I can extend it to five stories. Okay, now let's say requirement came in to five 50 stories. Now okay now in that time you will

have resources to rearchitecture the system but earlier in the beginning if you have thought of that I will design the system for 50 stories and if that requirement might not there like very less chances that that requirement will come. So there is no point in spending too much resources in the beginning. So you take some headroom as in like for two stories it was needed you build

it for five stories. Okay, but not so much not for 50 or not 400 because premature optimization is root of all evil. Okay, this is a famous quote from Donald uh Donald N. Uh and it's very much true uh we should avoid it all cost. Okay. Now if you talk about how can you do it okay some of the things uh which I want to discuss around

it. So the first thing is the balancing act. Okay. Uh how can you balance it? Now if I say uh uh the balancing part right the important thing would be that you are able to prioritize and plan well okay uh you know what needs to be done now what are the things that are critical for me right now okay and what are the things which I can

leave what what can wait when you are building that story when you are trying to build that uh building uh there are few things which needs to be built right now okay but there are few things which can wait okay in a building as well there are a lot of things probably In the interior you can left out some point as left some of the things in

the beginning but later on you can develop that. Okay. And one famous way of handling this is Eisenhower matrix. If you have not heard about this Eisenhower matrix what it says is uh you identify the task into four categories. Okay. Uh there are four quadrants which you see and then you divide each like whatever you are doing into category of important and urgent. So if you see

the first one it says do okay the task is urgent and important okay the task is really important uh the task has to be done now if you don't do it there are consequences associated to it there are deadlines it has to be prioritized right now so that is the first thing you do it right away the next thing the next quadrant which says is it's important

but it's not urgent if it isn't uh important and not urgent what you can do is uh you can schedule it for later okay uh there are no deadlines to it. So probably when you are doing the quarterly planning you can say that okay I'm not working on it right now. What I will do instead is I will work on this in the next quarter because it's

important but it's not urgent at this moment of time. Oh give me a moment. Uh yeah so the next quadrant says urgent and not important. Okay it's urgent but it's not important for you. Okay. So you can do the delegation. Okay. It doesn't require your skill set. It can be done by someone else. So you can leverage your skill set to do the task which is important

and urgent both. If it's not important for you, so it can be done by really uh it can be done by someone else. Okay? So task that must be done but it doesn't require your specific uh skill set. And the final thing if you don't need something then eliminate it altogether. You delete it, you remove it. Right? So the task which is not important not urgent uh

basically some distractions or unwanted features you just introduce you can remove them all together. All right so this is really important when you are trying to balance in your software. Okay you identify what needs to be done now and what can wait in your architecture. The next thing is that lashian method. I mean if I talk about uh yeah so if I talk about the next method

or like next uh thing which we want to do is um focusing on the developer experience. Okay. Now it's not just about a developer like in any role you are in. Maybe you are engineer, maybe you are a product designer, maybe you are UX designer. So any employee per se if there is some friction. Okay, if there is some friction which get introduced in your uh I

mean in your work in your day-to-day work you should remove it and it's uh atlashian basically calls this developer joy I I read on their blog so that's why I added atlashian method but the idea is if there is some friction okay whatever the people are doing then it should be uh they should be able to remove that friction let's say there are some process improvements which

are needed okay so you do those process improvements okay uh if some let's Say if you are trying to deploy that same software to 15 regions okay and you are manually doing that can you improve that process of uh instead of manually testing and deploying to a CIC CI/CD pipeline probably okay do introduce functional testing so all those things if you're able to balance that out if

you are able to introduce that in your life cycle then you are essentially making your employees happy okay there is friction which is being reduced or removed from their uh day-to-day work and The next thing is the final thing uh which is speed and good architecture aren't enemies bad trade-offs are. So we discussed that there should be trade-off analysis which we do at every point of time.

Now but we sometime think that if you are trying to build a good architecture it will take so much time okay or if we say that okay if a good architecture will build be built then it will take lot of time or if you are moving fast then the architecture will never be good. Okay. But the idea is that no architecture is good, right? No architecture is

perfect. It definitely depends on the business context. That's what we are talking about from the beginning, right? So if you're good uh in the trade-off analysis, if you're trying to do that proper trade-off analysis depending on what context you have, okay, what problem you are trying to solve, then you are good to go. So speed and architecture uh speed and good architecture aren't enemies, bad trade-offs are.

So this is all I wanted to talk about. Uh I think we wrapped up much before time but uh thank you so much and if you want to connect with me uh these are some of the QR codes which I can which you can scan and yeah uh if there are any questions happy to take >> [music] >> Heat.