Tim, This video is arguably one of the most important and best videos you've ever published. As I was listening to you I could actually see and remember so many occasions over the years that your words were exactly correct. If you're a junior developer and learning your way in, save this video and repeat it once every 6 months. Thanks Tim.
Great timing. I just implemented clean architecture in an app I am working on and while I was doing it I really questioned myself if was worth all the complexity. You are the only one saying this . Thanks!
I built a web app for my college a few years ago using clean architecture. It's now an absolute maintenance nightmare and I want to rewrite it as soon as I get a chance. Currently leaning towards vertical slice architecture, based solely on the fact that with the current version of the app, if I want to change something on one screen, I have to modify around 20 files spread over 4 projects. I undoubtedly got a lot wrong while building the application (I'm learning as I go) but using clean architecture was definitely the wrong way to go for the level of complexity of the app.
“Write Simple Code” Tim say it again for the people in the back lol 😂 I remember a previous job where we would design something and go back and ask. Is this simple enough! Great video!
You always exceed my expectations when dealing with these obscure & kinda unclear questions Literally man you are my hero! Landed a great job, just because of you. Thank you so much!!
This is gold. Made me feel a lot better about some of the more simplistic projects I’ve developed. They do what they need to do without conforming to whatever the latest fashion is.
My main take away here is: - Junior Dev: Write simple code to solve simple problem. - Mid Dev: Make everything looked as complex as it could get to solve the complex problem. (Stuck here) - Senior Dev: Every complex problem can be solved by writing simple code. (I wonder when am I going to get here)
That's amazing advice! I think the highest praise you can receive as a developer is if smart developers that look at your code eventually start writing code the way you do. I've always felt my code looked stupid but I felt that was one of the best parts of my code 😀 Over the years, I've realized that it's very hard to break stupid code and it's also very easy to maintain because you can immediately identify the object and the method that you need to modify and usually it's about as simple as updating this comment.
Well explained. Thank you Tim for eye opening explanations for developers. Not to screw up applications by adding unwanted things without understanding.
So far I have used many of your c# lessons for myself without really thanking you for it. I would like to take this opportunity to thank you personally for everything you have taught us developers or even beginners about #coding so far. Thank you for all your great videos and that you will stay with us for a very long time!😉
Great One Tim. I have a dream to built a startup using C#, or sold my Application to Indonesian Conglomerates/VC. Now i spare my 4% income beside investment for learning from you. Hope my earning or stock options or application usage increases.
I work on a project now where a former employee of the company was neither, junior, mid-level nor senior. He mentioned to achieve write complex code for simple issues. Those type of developers really should go back to school or redo a course with an actual teacher because those type of developers eliminates the fun of programming for other developers.
Well said Tim! I however think that the DRY (don't repeat yourself) principle should not be violated under any circumstance. Having duplicated code doing the same thing is a maintenance/reliability nightmare. If the code/logic needs to change, there is a high tendency of forgetting to update the duplicated code. This causes issues in production.
If you ever find yourself having a rule that cannot be violated under any circumstances, you've probably made a significant error. I cannot think of any principle or pattern that is inviolate. Here is a quick example for DRY. In the JavaScript world, there is not a built-in way to pad a string on the left side (so "123" becomes "00123", etc.) So, one person in the open-source community created an npm package called left-pad. It was 11 lines of code that efficiently added padding to the left of any string using any character as the padding character. Other developers decided not to repeat that same code, so they took a dependency on that npm package. Then, the original author deleted the package. That broke thousands of sites and services around the globe. That's just one way DRY can go bad. You might say that the issue here is a dependency, not DRY itself. While I disagree, let's shrink this a bit. Imagine you decided to write a bit of code like left-pad for your company. Maybe it is C# code. So, you create it once and then reference it in every application your company uses. Now imagine you did that with a .NET Framework dll. It would work because, at the time, all of your applications were .NET Framework. Along comes .NET Core. Now what? You can't upgrade your library until you are ready to upgrade all of your applications as well. And you cannot upgrade your applications until you upgrade your library. All of the sudden, every application that your company makes is tied together into one big ball. The typical solution? Not upgrade. Just keep everything at the working version. All because you decided DRY was paramount. That's the trap of absolutes. The key with DRY is to evaluate both sides. Yes, duplicate code means changing something in multiple places. However, it also means that those places can change independently of each other. With DRY, you only need to change things in one place, but those multiple places are all tied to each other. You've created coupling. There are ways around this, and there are solutions to make things less drastic (.NET Standard could have been a solution for my original C# example), but DRY is not without downsides.
I like to tell young developers that it's easy to write complicated code and very difficult to write simple code. I see this in my current project. For example, they're storing the connection strings in app settings with placeholders for username and password. At runtime, grabbing the username and password from key vault and substituting the values in. Just store the entire connection string in key vault and be done with it.🤦♂ Be wary of unnecessary complexity.
Thanks for a very useful video. What are your thoughts on the use on implementing business logic within stored procedures. I don't mean validation logic to prevent invalid or inconsistent values being inserted, but rather the stored procedures implementing business logic so that the application code is nothing more than a link between the UI and the db. I've seen solutions architectured this way. My opinion is that unless there is a significant performance expense, business logic should be implemented in the application code and the SPs only used for db specific operations.
I like to keep application logic in the application and database logic in the database. Let each system do what it does best. That means I don't typically put business logic in the database.
This makes a lot of sense. I have been studying design patterns for the past few years. Adhering to dependency inversion seems like a commitment that has to be had from the start. I wonder how it’s balanced with this general approach of add complexity only when needed. Regardless thank you Tim for what you do
This is where experience comes in. You will have a general idea of the scope of your application. With DI especially, your application won't need to be that big to get value out of it (especially since it also helps you test your code more easily). So you would look ahead at your application and say "based upon my experience, an app of this size will benefit from these patterns". The key is to not just always apply those patterns. Evaluate the complexity of each app to determine what it needs.
@@IAmTimCorey Perform an initial assessment of complexity and go with patterns that seem appropriate then add patterns as the complexity grows due to additional features or poor initial assessment. I got it that makes a lot of sense. Thank you for the response and God bless.
So the message is: Make the architecture as simple as possible, and apply patterns & principles only if they outweigh the cost. Sounds good and reasonable, BUT: I reality most of us are expected to get the structure right in the first approach. For two reasons: - Management usually expects that the code is "done" at some point and doesn't want to "pay" for the refactoring when the code gets more complex. - Often some other person of the team continues with the code you started, and most of the time this other person does not want the apply architectural changes to "someone else's" code. So for production grade code most of us need to have some kind of structure right in the beginning, expecting things to get more complex in future. Even if that structure seems to be over the top at the moment.
That's the hard part, and why companies often want work experience when hiring for any position. Experience tells you how complex an application is going to get. That allows you to make some initial design decisions when it comes to patterns to apply globally. That's why, for example, ASP.NET Core web applications start with dependency injection and logging built right in. The team at Microsoft knows that almost any web application will need these two concepts. Even choosing to build an MVC project is an up-front decision on the complexity of your web application. So, you make the decision on when to implement something based upon your planning of the application's complexity. The other thing to consider, though, is that not all patterns are application-wide. There are some things that can be chosen on a smaller scale. Those things should be applied when it becomes obvious and not before. Finally, when in doubt about when to apply a pattern, it is often better to NOT apply the pattern and regret it/refactor it later rather than applying it and regretting it later.
@8:25 Design Pattern Bingo! 😀 You should coin that phrase! It also applies to writing code as well, not just structuring it. If the code isn't easily understood in a quick scan, then the architect/developer has to explain how writing that code in a more complex fashion benefited the application. I think it also applies to writing code conventions as well. Clear and concise code with named functions is a lot easier to understand than a whole page of anonymous lambda expressions that in some case may require a manual to explain what's going on which I see a lot more of nowadays.
It's great advice you give in this video, it always depends. But it would have been nice to have some examples, like "if you're building this thing, then I'd go this way and structure it this way. If you're building this other thing, then I'd rather go this way instead.". Like your console over-engineering project, which was great, because it was a simple goal, easy to understand, but with some more complex concepts thrown at it. I'm building a WPF app that takes a spreadsheet file (csv, excel etc) of product data and ultimately insert/updates the products via an API into a specific store in a POS platform with some login credentials. Tha app validates the file against some business rules (some columns is required, but the column names each have some aliases, because files is coming from multiple sources and can be structured a bit differently) and loads it into a datagrid. There are some textboxes, checkboxes and dropdowns that control if we should prefix the productnumber, what product group the products should belong to, whether to update existing products and such other uploading behavioural stuff. I have the API data access repository in a seperate project, but the app itself,, as simple as it seems, is a bit more complex than can be handled in the UI code behinds. And as you so eloquently mentioned, it's not the recommended way. I just have a bit of a hard time structuring this app. I'm also following Milan Jovanovic and his demonstrations into DDD and I really like it. He makes things look pretty simple. But going from his videos to my unstructured app is a bit hard. Any recommendations is welcomed.
You shared some very profound knowledge here Tim! But I think to really know when and where to apply each design you’ll have to be a really experienced developer. I think it is very very difficult for a junior dev to understand which patterns he or she really wants to use and how he or she is going to structure his program.
Absolutely. That's why I don't recommend that junior developers focus on design patterns. They actually make it harder for those developers to write good code. You need to be experienced in what the code is doing and its complexities before you can work to simplify it.
Does anyone really know when to apply each design properly? I think if you get it right 60% of the time, you're probably one of the best architects in the world especially if you apply them at the start of the project. Who even knows all the patterns? I think a lot of developers invent their own version of the pattern as they are building the application and they realize the need to resolve a problem that they run into. Coding is similar to filmmaking - a director like Spielberg may not know everything about making a movie - he usually applies what has worked for him in the past or finds one new thing to add.
I really don't agree about the DRY one you(and others) expose : when just two parts of the (initially exact) same code evolves thier own way..., you arrive at a point where you even are not able to know that this COMMON part exists, things become entangled/mixed up, and then : even if you take this long time... to try to extract common things (which should have been done since long ago) you're gonna take risks getting afraid to touch things..., and lose quite more time that the necessary one if things had been done (DRY) initially. Things/algorithms that have a NAME should be framed at one (correct) place, and reusable as such. And there we come to documentation/communication.
I like your approach, you try to make things simple. in clean architecture they make so many separations that I think its too much. however, your examples are sometime too simple sometimes ancient.
