Alright welcome to the session on Core Design Principles for Software Developers. My name is Venkat Subramaniam. We're gonna talk about some of the things we need to think about when it comes to designing software. So I'm gonna be talking quite a bit about what are some of the principles we can consider when it comes to writing code on a daily basis. These are principles we can consider when writing codes on a daily basis These are principles that I have personally benefited from a great deal Almost every single day when I write code I think of a lot of these principles these have been extremely valuable for developing software which I consider to be a better software So I want to talk about some of these principles the way I'm going to structure this is I'm going to talk for about an hour and twenty minutes give or take and then we'll take a fifteen minute break and then we'll come back for the remaining half of the session and finish up the rest of the part I really appreciate questions if you do have a question I certainly welcome them But I have a problem of not being able to see through the blinding lights so if you do have a question Speak up raise your voice, draw my attention I'll be more than happy to listen to you and then participate in your discussions questions comments just about anything so with that said let's get started the first question I want to start by asking is, what do we consider as good design that's the very first thing I want to consider well I once worked with a guy who had a really interesting way to define a good design He said the design is good because I created it well I think we need a better way of defining than that So how do we really be objective in defining good design that's the next question to ask Well I'm going to say a design is good if the cost of changing the design is minimum So I'm going say this design is really good because when I wanted to change it I didn't have to spend way too much time and effort changing it Well while that could be a good definition there is one big problem with that definition And the problem is when it comes time to change the design you realize that this is horrible and that's way too late to say oh gosh we messed up So we need to be able to proactively say that we are creating a better design rather than after the fact Say well that was after all not a good design So again how do we really define a good design then So clearly a good design is a design that is easier to change So maybe one thing we can do is maybe we can start subjecting the design to change along the way and see how the design stands up and if it doesn't we can after all keep evolving it and getting it towards something that's easier to change Well the very first I wanna start out by saying is this is something that I I am really beginning to realize more and more is Almost and I'm not going to say almost impossible to get it right the first time and this is something we need to keep in mind because a good design is almost impossible to get it right the first time This is insane in my opinion because programmers wanna sit down write code once and say I am done but if you really think about a lot of human activities We never seem to do things in one time we take several iterations to get things done If you look at the evidence of some really famous artists for example the greatest of painters Greatest of sculpters the masterpieces they created, they never created those masterpieces in one sitting There is evidence of several prototypes having been created and that eventually led towards creating this masterpiece And we come to work and think we can sit and get the coding done in one day and be done with it So the very first thing I think we should come to realize as developers is we definitely have to give time to really create the better quality software and we have to really improve on what we do rather than just creating it once and be done with it Because I firmly begin to believe now that software is a never actually written it is always rewritten So we definitely have to provide ourselves the opprotunity to rewrite software As much as we can and why should we really care about it? Because a software has to constantly evolve if somebody comes to you and tells you they wrote the software once and they never had to change it again what they are telling you is that their project got canceled because any software that is relevant has to change and we have to be constantly changing and evolving software that is extremely important So, as a result, we should really afford for the change, that becomes very important to make it possible But how do we evaluate the quality of design? Well, thankfully there are some really good ways to evalate quality of design and we are gonna talk about some of those things And how do we create good design? I want to say, if we want to create a really good design there is one first step I think this is not easy but we should try, the first and foremost To create a good design, the first step, this is the hardest step actually is: 'Let go of the ego" So, this is really hard for a lot of us, right? Because, it's MY design, I created it Well, at some point we got to realize, you know, we can not be perfect By definition we are human, that means, it rules us out, we cannot be perfect and we have really to let go of the ego, and work towards creating better design and the minute we let go of the ego in us, I think we get better and I want to say a little bit about ego, I don't think we want to really have no ego at all that is important, because if we don't have any ego at all, we wouldn't have pride we wouldn't have passion in what we do, so ego is kind of like cholesterol: you want good parts but not the bad parts so you want to make sure you that you have the right amount of ego to really get motivated to do stuff but not enough to [ ... ] our progress.
So, let go of that and the second thing I would say in this case in creating better design is: Be unemotional. You know, when it comes to creating design, we often get really emotional You may look at this and say: gosh, this guy is talking about non-technical stuff Well, I think that's really the first step, because this non-technical things really makes it hard for us to develop better software So we really need to be unemotional about it. So, when we become unemotional we are not attached to the solution and what we are really attached to is solving the problem we have So, one thing we could say is.. I would like to, as much as I can, say: "Here is an idea, I want you to either do this or come up with something better than this" And when it comes to people, I think it's important to have people who can challenge each other, that's very important And I want to say this because this is really something that I am looking for and I am gonna say, per se, this is something critical to think about When you have people working with, there are two kinds of people that are dangerous to work with. So, who are those? So, one, who can't follow instructions; these people are really dangerous Two: who can only follow instructions; these are also very dangerous So, folks who cannot follow instructions, you tell them what to do you come back from lunch, they are still sitting there I told you exactly what to do, why wouldn't you do it? The other group is even more dangerous, right: you tell them what to do and they literally did that And they are like, instead to, you found there is a better way here, why didn't you do it? "Because you didn't tell me to do that", right, and that's really dangerous also So, I think it is important to empower people, so that people will have the courage, the confidence to deviate from your plan and that's one of the times when you want people to come back and challenge I remember this one time, I had a person walking with me and he said How do you do this? I said: I know exactly how to do it but I won't tell you! And I want you to go find the answer for this.
Here are some ideas I want you to come back and tell me what you find, but here's a little direction About two hours later he said: by the way, thanks for the tip, I figured it out and I have implemented it. So, show me what you have. And he shows me what he has
