Why Developers Hate "Clean Code"?
Вставка
- Опубліковано 30 вер 2024
- Check out my courses at dometrain.com
Become a Patreon and get special perks: / nickchapsas
Hello, everybody. I'm Nick, and in this video, I want to talk about something I keep seeing over and over again and that's the rejection of clean code by modern developers.
Link to the Reddit post: / is_clean_code_dead
Workshops: bit.ly/nickwor...
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elf...
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
Purely based on your reaction to reading the word "Scrum", I want to see you talk about it Nick. That reaction was "real" enough to be felt on this side of the screen.
Id say many dont actually implement Agile Scrum properly. Where I at we just put tasks for "do work" quite pathetic
Forced adoption of scrum by an outside scrum group within the org with little to no consideration for what makes sense to that team given the circumstances is a common mistake I see. The original intent was that the team doing the work would decide for themselves what made sense.
@@MrJSplash Completely agree. And to make things worse, these agile coaches tent to only tell people what to do but not why. The result is a company and teams that just DO agile without ever actually developing a true agile mindset or understanding agile principles and values. Instead, they keep operating with a waterfall mindset in an agile framework - a recipe for disaster and very unhappy people.
@@T___Brown the problem is when people say 'agile scrum' in succession. Agile as per the original manifesto worked. SCRUM is stupid as applied by most teams using it today. The problem is when you take a good idea and try to apply it in ways it will never work. Agile is good as a concept when you don't try to systematize it and you stay close to the principles but it will never work if you try to force everyone and everything into a prescribed process, at which point it ceases to be agile anyway.
In our team we have managed to be largely happy with picking only some aspects of scrum like sprints but I agree that at least sometimes it indeed feels like mini waterfalls. The most important aspect we changed though is that we don't see the sprints as hard deadlines but rather as a point for feedback and where we can (re)evaluate the backlog and priorize (larger chunks of) work.
Let's have a Retro about it Nick
I think we need to have an intervention here.
First, let's have a planning for this interview. Do I prepare the poker planning dashboard?
can I get a task for this ?
I need a spike for this sprint, what shall we remove for this 20 point item?
How about we do backlog grooming first boys? How about some refinement? A 2 hour meeting should be enough.
Based on what I see in my project, Clean Code never existed...
You’re not alone 😂
🤣
I washed all my code yesterday! It's squeaky clean now!
@@johnnyblue4799 Unfortinatly not easily done with tight coupling, low cohesion and no documentation in million lines of code.
I agree that having it as part of development process is not good and can reduce productivity. It's just a bunch of tips to help improve readability and maintenance. I introduced code reviews in the company and part of clean code advices were helpful to make code more readable and simpler. First solve the problem and if it is an important peace of code that needs to be revisit often, than try to improve it. Most of code reviewed wasn't refactored.
I’m all for the Scrum rant. Give the people what they want!
If we consider the broad definition of clean code as "code that is easy to read, understand, and maintain," I find it difficult to understand why some developers would "hate" it.
The primary objective of clean code is to ensure that the next developer who works with your code can quickly understand it and easily extend, fix, and verify the changes. It is important to differentiate between the concept of clean code and the specific "rules" that are often associated with it. While these rules should certainly be discussed and critiqued, they should not be conflated with the overarching goal of writing clean code.
That definition of clean code is very subjective and can't possibly serve as a guide to new developers or to a team of developers. What might seem easy to read, understand, and maintain to one person ("this is a concise 30-line method where I only have to look in one spot to see what everything is doing") might not be so good for another ("that big block of code should be broken out into 5 smaller, well-named single-purpose methods"). The whole point of the Clean Code book was to lay out a series of rules for what constitutes "clean". The developers that hate it don't hate the generic concept that you mention, they hate the specific set of rules that appear in Uncle Bob's book.
As you point out, those specific rules may not work for every team. But I think it's still important that each team really decides for themselves what constitutes "clean" and come up with a set of guidelines that the team agrees to follow, even if not everyone on the team agrees with every single one of them.
Absolutely. It was not meant to be a guide on how to achieve clean code, but to underline the importance of the goal itself. How to get there should most definitely be open to discussion, innovation, and adaptation to fit modern development practices and team needs.
@@rjanBergProfile Agreed! We should work together lol
That's because there's a difference between clean code and Clean Code (TM). One is literally just readable, maintainable, and organized code, while the other is a set of guidelines, standards, principles, rules, etc. that bloat your codebase in order to achieve the above results in a specific way.
Most poor developers hate it, just like bad plummers, mechanics etc hate having to do things properly.
Pleaaaase make the scrum video. It seems like I'm the only one on my team passionately hating scrum, and it drives me insane!
really? I have the feeling everybody in my team hates scrum and I'm the only one who likes it.
You both need to swap, guys 😂
Majority of seasoned developers hate scrum, but if you say you dislike scrum, you will be gone...it's a religion in most large companies.
Scrum is exactly one of those things. I got sent on a course, got a certificate, the end!
I say "meh", scrum is an excellent framework, the problems come from certification, and "you have to do this" ... the whole idea behind it is the ability to adapt and change along with business needs. Daily stand ups are about keeping everyone on the team in sync, short sprints are about enabling directional change. Scrum is essentially, choose a bunch of things to work on that you can achieve within the given time-box, do the work, review what was good and what was bad during the sprint, make adjustments to your working patterns accordingly, show the stakeholders what you achieved, to give them the opportunity to guide the direction of the next piece(s) of work. Rinse and repeat.
What could possibly be wrong with that?
I think many developers take best practice guidelines too literally. For example on a course I went on they said a class should be no bigger than “2 screens” and methods should have no more than, I think, 7 lines of code. I get that they are trying to make you think about splitting up the code nicely etc. but some developers will split an 8 line method into two, which doesn’t necessarily always make sense.
Exactly this! SRP should be the guide for classes, methods, and functions, certainly not line-count!
I agree with this completely, a codebase is just like an app and coding within that codebase is just like UX, I write my code in a way that I feel good/comfortable using but also that my colleagues have no issue's picking off where I left without issues. Taking guidelines/practices as golden rules to never break is the best way to force a codebase to go bad as these limitations never scale properly with the application you are building
hard-limiting to 7 lines of code would just lead to 20 LINQ chains in 1 line which is impossible to follow lol. I'd say methods should be at most 1-screen long, while classes are at most 500 lines.
@@Bill-s6j2w Yep, line counting drives bad practice. Dev do stupid things, making code harder to read just to fit arbitary line counts. Crazy talk!
I disagree with "No method should be longer than 7 lines of code."
Give us an ATDD video 😎
Devs are sometimes such a drama queens... There is always a grain of truth in all of these principles. And as long as you are not dogmatic about them, but pragmatic they are great principles to know and use. Even scrum.
Clean Code is not dead. SOLID is not dead, DRY, KISS, YAGNI are not dead. Just don't be dogmatic about them.
The only thing that you should be dogmatic about is to keep to standards, conventions and concepts established by your team. And make sure you discuss with them any exceptions from the rules.
This somes it up nicely, thanks.
They're not dead and I do apply them. Obviously you want to make changes in one place, not ten. Obvious you want functions to be descriptive and do one thing well. But they're largely just common sense transformed into obnoxious sales acronyms. 😛
Clean code isn't dead, but people shouldn't rely on it as though its the gospel. Code is constantly changing. Your clean code today is potentially rewritten tomorrow. In fast pace settings just write code that's good enough, not bad but also not perfectly "clean". Sure if you had all the time in the world and what you're working on doesn't change often then go right ahead but if you are pumping out releases every month or even in some cases I've seen bi-weekly at times, clean code is the least of your concern (depending on the work ofc). Don't forget as a software developer/engineer it isn't always about just code. You have testing, validations with users, signoffs from product owners, handling the actual release, etc to worry about too. Deliverables and deadlines are usually more critical.
A-frickin-men! Coding for over 20 years, been saying it as far as I can remember... "STOP forcing process-dogma where it doesn't belong!" Each methodology, discipline, etc has pros/cons. I've never found any of the cookie-cutter methodologies to fit unaltered to any project I've worked on. ALWAYS adapt your methodology to the needs of your project/business/etc. NEVER follow blindly.
Yes. I have been doing it the same amount of time. My juniors get paralysed by dogmatic principles. I say to apply where it makes the most sense. Just write good code and make it testable. Write code for other developers not just the business
Well, I suppose it depends on the product. At my last company, they developed a massive and partly unmaintainable monolith that is practically killing the business. It has become too big to rewrite and too messy to extend and maintain efficiently.
Initially, shipping features quickly and cheaply was satisfying for the customers because they didn't follow any clean code principles. However, this short-term gain doesn't pay off in the long run if you plan to continue developing the product. Now, the company is basically wrecked because of this..
The hard part of Development Management is to know When and How recover the Technical Dept of the early stages of a product.
My experience in clean coding and agile:
- There is no requirement documentation anymore, only miro boards, so basically nobody knows what are we developing
- What we call MVP is a full featured application, because the customer cannot live without background color changing
- We create unit tests for each and every small method, integration tests with some test data, but the first run with real data will kill the application because the one thing everybody cares about is that all the tests must be green
- Devs are afraid to write code by themselves, instead they are just using libraries without deeper knowledge of the actual technology
"Devs are afraid to write code by themselves, instead they are just using libraries without deeper knowledge of the actual technology"
Have you ever played WoW? Have you heard the green little goblin who often says "Time is money"
I've come to a point where, when asked about CC and SOLID in an interview, my answer would be "do you want someone who's good at learning definitions by heart, or someone who writes good code? Show me some code and I'll tell you what's wrong with it". I can do the latter using common sense and a decade of experience, but have long forgotten what I had to learn by heart from books all those years ago.
It's good to freshen up on concepts every now and then, but writing 10 methods with 5 lines each, which are all only called once, is anything but clean. It disrupts the flow of reading and puts correct execution order at risk, especially when all data is stored and manipulated in member variables.
Agree with the firts half, disagree with the last half.
@@ThugLifeModafocah You are right, the second half is debatable. I would just prefer to keep that particular thing in a purely functionally oriented world where each of these functions takes something and produces something, without side-effects. Unfortunately I've often seen it mixed in with heavy object-orientation in huge classes, which was absolutely atrocious to read :/
@@ThugLifeModafocah People that enjoy breaking methods up into smaller methods often violate the rule that methods should be uncoupled and have no external dependency, which can cause problems if the methods are called by someone else in an unexpected way. For this reason, I think it's simpler and safer to keep all the code in one method.
Best companies I worked for used scrum effectively. When scrum doesn't work it's usually a hint about much bigger problems in the company, like not being able to commit to your short term planning (2 weeks) or not being able to plan at all.
Exactly. Teams who are efficient with scrum often work pretty well also before adopting it or after they changed it to something else. Scrum may or may not suit their needs and preferences, but it's not a gamechanger
Then, there are teams, which struggle with Scrum, but usually they adopted it to fix some problems which it didn't. And those problems also don't go away just by switching from Scrum to yet another method
Honestly, the principles and patterns are not dead. All very important. The problem is that at any given company you have, if you are lucky, a handful of devs who know them, care, and actually use them appropriately. Everyone else tries it once and it doesn't work out because they don't know what they are doing and don't have a mentor and then call it trash. This is typical developer behavior. Most devs are in it for the money. They don't care, they just do whatever is fast and easy. They write trash code and move on to the next company because they hate the code they wrote. Product/business awards these trash developers with promotions because stuff was done fast and now you have senior devs out there who know absolutely nothing and are 100% confident in their ignorance.
I only write instant legacy code..
Java?
@@naughtiousmaximus7853 😂
Scrum is the most efficient way to introduce technical debt into a product.
You either have culture of maintaining high quality or not. The way you manage your post-its on the board has little influence on that
So many projects have slowed down to a crawl, not being able to release new features, due to not having some semblance of clean code, a decent amount of tests, and frankly, just *readable* code. Being too rigid isn't good, being too loose is worse and causes spaghettification.
Exactly!
The shade on poor F# 💀
Somewhere is the world one F# developer cried.
I was really invested in F# and was using it for a few small things at work. Then over time I found that it was constantly lacking in feature equivalency with C# and was far too hamstrung by its own limited tooling compared to what is offered by C#. It really sucks cause I like functional programming, but the drawbacks of using F# just became too heavy, especially given how others on my team didn't want to learn the language. It's a real shame.
@@MrEnvisioner I am really invested in F#. I was not looking for feature equivalency with C# when I decided to learn F#. I wanted something different (really functional, not OO with functional features). So far I am very happy with my choice.
Whenever I can convert my C# imperative code to some succinct clean functional F# code I do it.
@@fsharplove I've been curious about using F# in my C# projects. Do you have any thoughts you'd care to share on how smooth the integration is?
I’m an F# developer, I’ve never encountered a situation where I wasn’t able to write code in C# that I wasn’t able to replicate in F#, using functional alternatives
I find Nicks argument that management doesn't care about clean code because "who cares about 10% improvement on speed" really bad. Conflating clean code with optimization of execution speed is so weird, it's not the point at all. Clean code is about optimizing development speed: maintainability / keeping cost of change low. Management dóés care about how long development takes for features in the years to come. So it ís important for them and bad code is still a problem.
Weird take from Nick.
Count yourself lucky if you work in a company and have a manager that accept you saying "I need two weeks" and getting that time allotted. I have to agree with Nick that many managers and companies care about the bottom line which is money. They rather have 2 features this week than 1 "clean" one. My personal experience is, and I have been literally asked like this; can it also be done in a week if you cut some corners? We can fix it later! That hacky piece of code will the there for years and years to come. It is not that I disagree with the fact that cleaner code has benefits in the future.
Another way of looking at it is that one could buy a 4 bedroom house or a 2 bedroom house, on the same plot for the same price? Many will choose size and visual appearance (like nice faucet and outlets) over the fact that "quality" brands, 5/8 drywall instead of 1/2 and a nice solid double layer subfloor is put in and will also be delivered earlier.
Management does not understand what any of this means, and how or why it may affect the cost of change is totally esoteric to them. Management is "we need this by Wednesday." If you set yourself up so that it's painless to get it in by Wednesday, you're okay. If not, you piss them off, no matter how clean your code is. And having that kind of agility is as much about anticipating what management / clients will likely need and ask for before they know it themselves than about any methodology.
BRB scrum meeting in 20 minutes. 😶
I know this was a video about clean code (which I have yet to see applied in a company), but my god do I eye roll _hard_ when I hear scrum. Don't you just love spending half a sprint in meetings and then getting asked why the feature isn't done on time as it was estimated. Oh and estimations are such a scam. They're a thinly veiled pact you sign with blood that ensures you'll deliver your feature on time no matter what happens. And somehow we always end up having to estimate in actual days, not relative terms. Sprints exist only in some far away fantasy; in actuallity, every piece of work ends up rolling on to the next sprint because of time spent on meetings and fixing urgent issues that have come up because you don't get enough time to test and who wants to spend money on QAs. And don't get me started on the mentality of "can we put more devs to work on this feature to deliver it faster".
Not necessarily a problem of scrum itself but more of the underlying company processes.
As always with coding, it's a balance. Don't be dogmatic but also not overly pragmatic. It's a thin line. I work with developers who are completely anal when it comes to clean code and others who don't give a shit. At the end of the day though the business wants working code
"I fear no man, but that thing... (inheritance and polymorphism). It scares me"
Not a big fan of either. To me the star of the show with OOP is encapsulation. You could take the other two away and I'd get along just fine. Don't get me wrong, I use them and they're handy in the right scenarios. But oh man have I seen code that overuses inheritance. :)
Inheritance shouldn't be too deep.
@@asagiai4965I’ve seen class inheritance hierarchies that would make the Hapsburgs blush
@JollyGiant19 I think that's the point, because most people inherits so deeply, it's bad. That's why I said ...
Polymorphism in a programming language is actually really great, but just based on interfaces / traits and generics, not on inherited logic implementations. Code should stay decoupled.
And that is the move that most modern languages have made these days, not just languages like Rust and Go, but in fact also just C# and Java, where everything is done by composition strategies as well.
Speaking about composition, that's also where OOP and functional programming perfectly work together. It's all about flexibly building logic in expressive ways, by builder style patterns and injected dependencies as objects or lambda expressions, which can compose new objects on the flow (which is in fact strongly related to the monad pattern). Just think about LINQ for example. And the entire dotnet DI and extensions system.
we have an ol' sayin in Poland: "those who work with the scrum - they don't laugh in the circus"
😂
it seems to be the same in many EE countries, in Russia we say exactly the same 😄
Interesting, personally I think Scrum is in much better shape in Poland than e.g. In usa. Sure, a lot of teams don't use it, but the trend of people learning Scrum on 2 days of training and becoming SM completely ignoring half of Scrum Guide was much smaller here. So currently, if someone from Poland says they work in Scrum, they usually do it by the book and it works for them, otherwise they would have already drop it
The biggest problem with scrum in West Europe and USA are companies which have been saying they do Scrum for years, effectively doing half-scrum half-waterfall, joining the worst parts of both with no opportunity to improve because team has nothing to say about how they work (which is first proof it's not Scrum)
The bigger issue is when you have a developer that writes over 200 lines of code in the controller including SQL commands. How is it then possible to quickly understand it, let alone safely change it at a later stage? I believe aiming for good separation of concerns and clean code is the optimal solution.
The problem with this style of breaking up methods into smaller ones is that many people end up creating interdependencies which can cause problems if the methods are not called in the expected way. Since I see this happen a lot, I think it's safer to go with big methods rather than lots of small ones.
Well, i definetly understand a 200 lines method better than moving between 200 interaces, classes and methods done just for the "cleaningless" of code. I'm kind of tired to see each and every class being exposed via an interface, endless properties to avoid inheritance and favour composition.
In cases where you never have a polymophic behavior, you never call modules of code from other places, and the existence of the object is actuslly, strictly bounded to the lifetime of the call.
I see too much of a code explosion, things that can be expressed in 50 line of clear code being split in a huge number of bits and pieces, just because "this is how it's done properly" with absolutely NO reason.
Is it more readable? No, because you're losing yourself beween abstrcations, dependencis and pretty often frameworks.
Not everything must be a DDD, my opinion is: use the simple and most direct way to get what you want. Sometimes (most often) you won't have to change it. If you reakize, at a later time that you have to break it an abstract it, it's quite a simple process.
I mostly agree with you. Some Clean Code concepts are fun to put a word on some good ways to organize code (like abstraction levels), but in general it's mostly common sense and not some kind of dogma.
There's a point, your "common sense" is not my "common sense." In general, it's pretty useful to have some base to know we're talking about the same thing.
Maybe we split the developer role in two. Logic writers and cleaners. :D One write the logic, the other goes and adds documentation and more abstraction. :D
From my experience of being a .NET developer in Poland, it's mostly true about those crazy requirements. They will firstly ask you about each of SOLID rules or some advanced SCRUM principles just so you can land in an old legacy project with waterfall like approach...
@Nick I think you are missing the point about "New developers joining..." he is talking about day one of development, not necessarily day one of joining the company. we all know that it takes roughly a week for a new (permanent) employee to be ready to start coding -contractor engagements are a different kettle of fish and usually it only takes a couple of days because, generally speaking, there is a lot less involved in the onboarding process.
Whenever I see someone hate on clean code I just assume they're not very good at their job, and a pain to work with. I've worked on clean solutions, and I've worked on wild west solutions. I have a clear preference.
I'm not talking about pure clean code, I don't think applying any principle to 100% is smart, but I'd rather work on code that is 70% "clean" than 30% "clean".
I'm assuming anyone that hates on clean code without giving it any merit is just an amateur that didn't get to see how hard working on a behemoth monolith can get if it's written like shit.
Genuine question -- can you give me an example in code that you'd classify as 70% clean and an example that is 30% clean? Having an example here would be extremely helpful as I have struggled to pin down firm definitions on what would/would not be classified as "clean"
Absolutely. As someone who has worked on projects with and without adherence to clean code standards, I prefer working on clean code every time. Without fail, the hacked together code is a mess where nobody understands how anything works.
@@Cam_all-in-on-GME some bullshit numbers pulled out of the ass.
Pretty much what the OP says here, in some of the behemoths I work on, I want it to least give me enough as to what it will be doing. How you name a function doesn't affect the performance, thats the core of all I care for. The simple concepts is good, doesn't need to be a religion.
@@Cam_all-in-on-GME it's hard to give an clear answer that is not up to debate but I'll do my best to explain. This is pretty much all up to interpretation (and the 70-30 are to be taken as a figure of speech) but here's a way to look at it. I'll extract 10 ideas from the book that are obvious in what they mean, and are not that hard to understand, or not that much up for interpretation.
1.Meaningful names(for methods, classes- describe what a method does)
2.One level of abstraction per function - don't mix low abstraction code with high level methods if it can be avoided
3.Do one thing per method(think of something like single responsability)
4.Don't repeat yourself, refactor
5.Only have comments where absolutely necessary, and try to find ways to avoid them. If you can rewrite in a way that doesn't need commenting, try that first.
6.Keep classes small
7.Pick a formatting/code writing style and have all the team adhere to it.
8.Set boundaries around third party code(encapsulate it, so that if you're using something - say, a nuget and it changes, you only have crashes in a single file, as opposed to all over your solution)
9.TDD - write tests that fail, write code that fixes them, rinse and repeat
10.Understand concurrency, and use thread safe contexts.
Let's say you apply 7 of those ideas. Maybe you think TDD is too much of a hassle, you don't want to stick to principle 3, as you want your methods to do more things, like saving data in the repo, broadcasting the change to listeners, and invalidating cache all in one method... you also have some humongous controller that handles way too many endpoints/entities.
Not idea, but I can work my way around that.
What if we only apply 3 of those ideas?
Say, collections are thread safe, meaningful names, and don't repeat yourself.
You're now using nugets all over your solution(god forbid they implement a new feature with a version that also adds breaking changes 1 year from today) you have no tests and no standards on class length, method length, formatting style, everyone's doing what they think is right. The methods mix high level calls with low level algorithms (say, some compression for image processing in a flow that validates user identity for a bank background check, and needs a valid ID) and are really tough to go around when the flow is encountering issues. If you're not familiar with the algos, best of luck.
And just imagine if you're new on that project.
In the end, what I mean is, most things in the clean code book do more good than harm, and aim to enforce a common context between all devs, and future devs. It doesn't hurt to have them, but it might cause a pain not having them. In the end, you're giving up convenience now, for convenience later... and I'd rather have more principles than less in the solution, but don't care for ticking every single box in the book.
Everyone hates clean coding until they have to fix the code written by someone else
Focus more on the task, and less on ceremony. It will get you much further in software development.
Let's breathe slowly and look at the bigger picture. Long-term development velocity is crucial _if_ (and that's a big "if") the software has a long life cycle. And Clean Code is a decent, though not perfect, way of maintaining long-term velocity. I work for a company that (among other things) still extends complex software that entered the market in the 90s. If you let a code base like that rot, it will kill you. Every "unclean" coding may improve your time to market for the first release cycle, and kill your time to market for all future features.
While it's good to question some technical details of Clean Code: If you work in a team that produces long-lived software and find it consists mostly of hacks - run!
I once saw a video where someone wanted to make an argument against Clean Code based solely on performance. He had a simple console application that calculated the area of geometric shapes. There was a class for each shape, function with good names and he used the formulas everyone knows from school. Someone who had no idea about the project could look at the code and know exactly what was going on.
Then he optimised for performance. He did some weird stuff with arrays and merged the different formulas for different shapes together. By the second iteration, I had already problems understanding how the code worked because it just seemed like a random array of floats. The resulting program was really fast, but unless you knew exactly how it worked, it was very hard to read.
The average desktop application does not need the last percentage of performance. But it needs to be finished, maintained, developed further, bugs need to be found and fixed. That's the main goal of Clean Code - or it should be.
Find the right mixture of performant and clean code based on what your project needs. Don't be religios about anything. Then you're good to go.
I personally believe that we can achieve both performant code and clean code in the same project/solution. Clean code does not mean "slow code": as you mentioned, it means code that is easy to read, understand, and extend, and it certainly does not preclude performant code.
Oh the "our benchmark is 99% method calls so method calls that are inlined are faster than virtual method calls"-tests. No shit.
My second favorite benchmark after "Language X is faster than Language Y by 10.000% and then one is a const expression while other does the calculation".
@sealsharp cope and seethe oop dork. Go write some boilerplate code
Sounds like Molly Rocket's video
@@reikooters Most likely.
OP appears to be missing the context that the video was a part of an advanced course (i.e. you need more than 4 brain cells to understand) focusing on performance. So they they thought that this was his only argument against clean code, when in reality, it is not.
In my experience as a software engineer over 20 years, companies will only employ people who can regurgitate SOLID, DDD, Agile and the latest fads. They are not interested in past experience and successes. It's sad to see the industry go this way, with a lot of experience being overlooked.
Commenter says "We had success with Clean Code and TTD".
Response is "Why Developers Hate "Clean Code"?
But maybe it was the TDD that made more of a difference to their success. That's my experience, anyway.
I had a colleague who was quite good at clean coding according to some principles. His code got so frustrating to follow and debug because there were so many chains of clean, single-purpose functions that you got lost in the depth of them when trying to understand what happened. The best, clean code is not only relatively "clean" but it should also be pedagogical and make sense. Sometimes it's better to not extract code to functions how contradictatory it may sound. Also, me working as a consultant in todays market where people switch jobs like underwear, it's also extremely useful to make comments in code more than maybe extracting functions to insanity because for some new, poor sob, that gets the ungrateful task of finding a bug in code he didn't build in a project where he is completely new there is no clean code that solely helps his work but making code that make sense to a human being and with some helpful comments are worth more than clean code according to all models etc.
Interesting. I see the phrase, “chains of single purpose functions.”
I agree, long chains of un-reusable code isn’t good.
In some situations, developers misapply the Clean Code Newspaper Metaphor, with very long call chains. For example, I’ve even see important business logic at the end of 6 method chain of calls-with all methods/functions not reusable. That code base was very hard to read!
What I think has gone awry when following software engineering principles, is following one or two principles to the exclusion of other software engineering principles.
All the principles must be applied together, to find a harmonious balanced fit within code. But when a developer applies a principle very narrowly, trouble lies ahead.
The challenge, of course, is developing the skills to know all the major principles, and apply them well. That takes years of experience and proactive discussion to get good at it.
@@michaelrarela5734 I appreciate your answer. Coding is, i.m.o, a form of art that is dependent very much on the experience of the developer, his/hers personalty and style, and the current environment in which the code/logic is to be applied, plus many other factors..
Clean Code isn't bad - people who take Clean Code to the extreme are bad
Most developers just start coding, no technical design and test are done before code, just because most developers are lazy.
Modern frameworks makes us too lazy because we can build things very quick like proof of concepts.
It is like doing hackathons every day.
And the code you write yourself is hard to test with these frameworks.
It only is truly implemented at companies where there is a top down effort and dedication to it. I’ve seen it done very well at 2/7 companies. The rest are just chaos. Honestly, I do like the order it brings to development, and work did go faster at both companies. Onboarding truly could be done in a few hours. But, the downside was you had very little agency and freedom in development or design processes. But, once leadership stopped being interested, it led to a lot of turnover and forcing out.
TDD, SOLID & Clean Code isn't about being productive day one. These are concepts that help development on mature projects. Eventually all development will go towards tech debt if good coding standards are not followed from the get go.
Technology evolves faster and faster with each year, so you're going to have tech debt anyway, even with all those meaningless acronyms. Nowadays, the real value is how quickly can you adapt new things into the app, and most often than not the so called 'Clean Code' actually makes it harder, as it requires too much fluff to make it work. That's the primary reason why small companies and startups don't use it, like, at all.
Yeah exactly, the article's main concern is about productivity on developing new features to satisfy stakeholders, not about minor optimizations or implementation details for the dev's sake. I feel like Nick's arguments are focused on startup projects instead of mature enterprise projects where tech debt from not following basics like clean architecture (or common sense) can slow new feature development down to a halt.
@@promant6458 This my be true in a startup mentality, but a long running application needs stability to maintain growth and performance. I've always worked on SaaS type applications where newer tech is heavily researched before being brought in.
Typically, by the time an application is truly outdated; a total or at least partial rewrite is required (think webforms to React).
@@invictuz4803 yup, stake holders generally don't care until you tell them it'll take exponentially longer to complete something then what it did previously. The trick is finding an extensible solution without making it overly complex.
I prefer DRY & KISS, abstractions are cool but can lead to an overly complex and fragile solution. Especially when most apps are poorly documented.
I agree 100% with you about scrum and agile. What a waste of time and effort.
It’s all about trade-offs. Clear concepts about SOLID principles, design patterns, OOP, programming paradigms, and TDD are necessary. However, striving for perfection in these areas can sometimes be unhealthy
Most devs aren't very good and 'clean code' is just more for them to botch. This isn't a theory.
In my experience working at a company that prioritizes clean code, I've found it extremely USEFUL during maintenance, bug fixing, and other tasks. Clean and well-documented code allows me to quickly find the information I need, reduces fatigue, and boosts my efficiency. However, I've also dealt with systems that weren't as clean, and on those "unclean" systems, it took significantly more time to improve, correct, and especially ANALYZE the implementation.
For those who don't value clean code, please consider the next developer who will work on your project; it's crucial.
The issue is what is the definition of clean code? If you mean the book and its set of rules, there are several articles and videos that bring some light in why some of the stuff is poorly coded in the book and why some concepts do not make that much sense anymore, since the evolution of the languages has brought new features and not functional programming is gaining traction.
if you talk about creating a code base that is easy to understand, and maintain and generates few bugs, that is what everyone is aiming for.
A nice property of the Clean Code methodology is that it is universally understood. You can come to a large Clean Code project and pretty much start working on it immediately.
The non-clean code (dirty code?), while not necessarily wrong, has potentially high, sometimes very high, barrier of entry for new developers on the project.
yeah, in theory. in practice clean code adepts over-abstract so much that finding actual code that does something feels like an striking gold at a garbage dump site
I've never been able to immediately start on any code base that was so called "clean code".
I have to spend at least an hour hopping from abstraction to abstraction to start understanding what a simple API call does
I can’t tell if this is satire or serious because it’s basically on the line 😂
From my exprience:
"Clean code" is a mess code in a long run because no one understand what's going on in the system. You can find abstractions by default and 20 methods for a simple piece of logic. You can't understand something that you don't know how works (definition of abstraction, you dont have to understand implementation, which is nearly alwasys false if it's not a library).
Clean code is usually simple code with few startegies and factories on top to make it really modular. Methods are usually small < 70 lines of code and split when there is a real need for that, not by default.
Where is this mythical large Clean Code project? 😅
Big fan of yours, but arent you twisting his words here. Imo, he is saying "Clean/TDD works great why is nobody using it anymore?". Besides, why so critical and insinuating that this is old and deprecated? Half the courses on Dometrain are about Clean Code, Clean Arch, SOLID and TDD
Yeah, I'm a bit disappointed in this video.
Nobody cares about clean code except developers who enjoy coding.
PS: Scrum is really good in a teams with bunch of junior/medior devs. When you become senior that can become annoying.
But I feel like that just comes with the territory of being senior. If you didn't do scrums, people are still going to come up to ask you questions all day anyway.
You are not wrong. We all hate scrum.
Because they do not understand the purpose of it.
To your point about startups not using CC - I think therein lies one big issue. When you don’t prioritize building the foundation of an app from the outset in an organized manner (whether that’s using CC/TDD or anything else), it becomes too expensive later on to refactor it. Or for example, I’ve been on teams that try bolting on CC concepts to an existing application and it just becomes a big mess of competing patterns
I think the root problem is that TDD is too dogmatic. You sort of nail it when talking about smaller companies and startups. Requirements might not be well defined, or the company is more interested in getting to MVP as fast as possible. TDD is fine, but without known requirements, what are we testing? If we miss half of the actual AC (because we didn't have it) was TDD worth the time?
Regardless of company size, I just think TDD is too idealistic. My current company pushes it but hardly any team truly uses it. I will always push to unit test code, and ideally once the system is of a size E2E testing as well in some capacity, but TDD often means to most people 100% coverage which one, is unrealistic, and two is horrible on ROI in terms of time investment. Once you start reaching for 100% coverage tests will almost always start testing implementation not intention.
I don't think TDD is dead, but I don't think it should be seen as a silver bullet, team guideline. Its far too easy to do it wrong and waste time, let alone lead to a potentially very rigid codebase.
I was hardcore into "clean code" for many years, but lately I've noticed what I'm doing counts as ... "something else" ... and I think "small code" probably describes it better. And I try to invert things where it makes stuff simpler, not only inverting if statements to early returns and less nesting but also larger concepts like an ID/GUID tracking system or something: rather than trying to build a huge, super class with data collections I'll just make a more centralized and flat buffer and make entries responsible for adding/removing themselves when created or destroyed and so forth. I want the smallest and fastest code possible that's easy to read (because there's not a lot of it) and easy to edit.
I've done it both ways, and I think there's a place for both. The huge, sprawling spider class might be good for nailing some really specific activity that needs to be expandable but in a very concrete way, like say reading, writing and interpreting new json files with who knows what structures. Stuff like GUID, better to keep simple.
Imho and also experience from working as a developer (currently tech lead) its more important to write testable and maintainable code then strictly follow OOP, TDD or clean code guidelines.
Its just a tool which helps you and gives you guidance f.e. how to structure projects, separate domain concerns from external dependencies, use IOC, ...very helpful for beginners for sure to not mess up already when starting ;) Have to say I am doing it much like Nick said at the end: Take what works well for you and your team, educate your team members to write testable code and mostly you are fine. Don't over-engineer (follow YAGNI). Also with experience you are doing a lot of useful things automatically which keeps your code maintainable.
Scrum is a different topic ;) - its way better then working in a chaotic way where no-one knows what even should be developed but same as with every "tool" - it can be miss/overused.
My favorite project was using elements of Agile and Kanban. No Scrum in sight, we would plan each quarter at a time, set a roadmap and start working on tasks. Sometimes we would deploy to Production up to 5-10 features in a week, sometimes we would have up to 2-3 weeks of no deployments depending on feature size. And it worked, everyone was happy, everyone was super productive because we never had to deal with stupid unrealistic deadlines.
On a different project I specifically asked: what if we finish this task before the deadline, can't we just deploy it?! why wait 3 more days? Management said 'because that's scrum'...
So your management had no idea about Scrum as no part of scrum guide forbids deploying before the end of sprint. Currently in my company we do Scrum and we deploy every day
That's it! I'm introducing the External Developer concept. Accelerate developer productivity by measuring how long it takes for a new, external developer to finish a simple, coding work item. Just like Internal/External Auditors do
As middle developer I have interest in knowing different practices but I value the best to have tech lead or similar role in my project who will actually enforce one of them or at least lead the discussions.
Every now and then a new "big thing" comes along that people hype up as the one thing that fixes all our problems. Clean Code is one of them, also scrum/ agile and microservices. Since everything in tech is just a tradeoff of things, the obvious problems with the "new big thing" come to light and everyone hates it. It is exceptionally ironic, when the people hyping it up (neglecting all criticism) are the same who hate it after. Imho I think every "good" engineer/ craftsman knows what to keep and what to discard pretty soon. If following a recipe to the T would bring guaranteed success, none of us would have a job, because a high schooler could do it in his/her summer break.
Imo it's a mistake to think that clean code starts and ends with Clean Code. What good clean code looks like has evolved. For instance a lot of us are finding the more functional approaches to be cleaner nowadays.
To write clean code is of course not dead. Should we go back to write bad spaghetti code again or what?
It seems we have some cult following some patented use of "Clean Code" meaning a bunch of almost religious directives, some of which are just bad and does not lead to clean code in the normal use of the words.
Writing good, clean, readable code for real is of course something everyone should strive for. But let go of that religious patented interpretation of Clean Code.
I don't hate Scrum. If your team is doing it their own way then all is usually pretty good. It's corporate agile that's the devil. SAFe... because we want corporate to not feel scared of people doing things their own way.
If Scrum isn’t driven by the developers, then it will just be micromanaged waterfall. I am currently working in a team that does the latter, but years ago, I was in one that the deadlines were given and we would have a large backlog of work, then the developers would work on the plan for completion of features - you want to know what happened, we completed two epics on-time and back-to-back, which the boss was surprised by and said that he hadn’t seen any team do that before and that most would miss deadlines. It isn’t the process that caused developers to hate Scrum, it’s how it is being used.
The biggest challenge is to tell management that they are to leave the developers alone and that they can and should see how to meet deadlines. That means that the stand ups are just a way to say that you need help later or that everything is tracking as expected, this is where you can just make it a simple thumbs up and move on to the next person who may have a problem and not talk in detail about what you are doing, that is a waste of time.
Just remember, Scrum is supposed to be a tool for developers to iterate the project and features based on requirements and not a management one.
Nobody hates clean code. Just bunch of content creators want to "sell" something else and differ from the mass. Things like endpoint pattern or specifications or whatever.
This isn't remotely true, you can just ask Uncle Bob himself about how many haters have debated Clean Code with him for decades at this point.
@@rectar the clean code as it was presented is just fine. the today transformation of clean code has nothing to do. people taking clean code and adapting it to their believes coming to what i have said. they just introduce pointless changes like endpoint etc. i laugh so hard when i see "do clean arch with endpoints , no controllers". Just let the people do whatever they want. using controllers or endpoints means nothing.
Even uncle Bob moved away from Oop and now is programming functional. The big problem is that proper OO often ruins locality of behaviour. You need to look at 20 files to understand a trivial thing.
No matter how much anyone tries there is no clean code ever!
great video, we had a senior come in recently who got a team lead role who tried to push clean code straight from the book on everyone. He ended up leaving in January after tanknig the performance of our performance critical application lots of simulations and calculations. My main issue was that it took the science out of everything, and that he replaced certain optimizations or even whole modules with code that was essentially 2008 Java (abstractions on abstractions on abstractions), causing a sub milisecond simulation to swell to 10 ms. His thought was to scale it more on AWS (this didn't work and cost us a fortune in extra compute required for our SLAs). Also, don't get me started on the ways I've seen scrum attempted in a couple of previous companies!
Yeah, they really don't grep the cost of excessive abstraction on performance critical sections. If you're dealing with more pragmatic people, you can just say "we'll put 'here be dragons' on that section and properly document it" and done, but if you're going against a "purist", good luck with that...
you've mistook "clean" code and confused it with SOLID. That's the difference.
clean code is about effectively cleaning business layers
What developers do is JAM in their rules and code and over time it that ONE function extends and extends so you end up with 10 rules inside foreach, no clear documentation about what is going on.
What you've described is C#/SOLID/OOP which is what your hard core developers did 2000-2010 - they got wiped out in SPA applications
So to me, in your example, there's a difference :)
Having one method that extends and extends so you end up with 10 rules inside foreach, with no clear documentation about what is going on is NOT performant, not reusable, not maintanable and not professional. I'm not advocating at all for that. Reuse, testabillity and maintainabillity are extremely important, and wherever possible should be used.
The underlying issue here was that in pursuit of following exactly what the clean coder book perscribed, to the letter. For example the layers of abstractions and simplifications degraded our performance critical solution to a point where we could be exploited by the market.
@@alexthebassist23 Don't think too much about it. As we say around here, our friend needs to put a bit more tobacco in it because it's hitting too hard...
There's a difference between a poorly expressed train of thought and loosely connected ramblings. The former sounds like an awkward translation, the later sounds like ChatGPT on acid.
@@alexthebassist23 yes understood that :) I understand your frustration, it's hard to deal with these guys ego's how "smart" they are. In future, possible use of BenchmarkDotNet for "critical paths" so any rewrites, .net upgrades, libraries can be called out straight away in PR's/POC, etc if they don't deliver more performance or blow out performance!
I have only 2.5 years of experience. I have never dealt with scrum and I didn't use SOLID, OOP, TDD stuff either. But I know that managing a big code base requires consistency and some amount of attention in giving names to the variables you create. When you do those 2 principles, you can manage big code bases easily and you can have fun while writing code.
I want to try out scrum, I want to use SOLID, OOP and TDD principles. But those are not things that define my coding skills. They shouldn't define yours as well. Don't be obsessed with writing the best code.
Best engineers are always those who can min max in any situation as best as they can. Don't forget that.
Coding skills are defined as writing code in such a way that another dev (or future you :) ) can understand and mantain the code without too much effort. Naming is one thing, but things like SOLID and other clean code practicrs can help you to achieve that goal. It's also being nice to your co developers. In my 20 years as dev i've seen of lot of big code bases with spaghetti code which could be somewhat prevented by using clean code principles.
12:20 “there’s no bigger trap than scrum and agile.. it’s such a stupid way of building software for 95% of everyone using it”
Great video as usual! We need your video on scrum now!😂
Also a lot of concepts are great on paper and in theory. However real life is never as simple and structured. People change their minds, requirements change, ideas change, motivations change.
I hated Scrum from the beginning. When it was introduced in our company around 15 years ago, the productivity dropped dramatically.
When people saw the productivity loss, they always argued, that's because we're are not fully 100% doing Scrum. Or other similar excuses, no one dares to question Scrum. I got a special agreement not have to do Scrum within the company.
My main critic point is, that no one is responsible for nothing. And everybody has a little knowledge about everything, but there are no experts any more. And the overhead of forced meetings of no real sense is enormous.
I would not choose a job position, where I would force to do Scrum.
The only advantage of Scrum is, that it doubles the job opertunities for computer science positions :-)
Interesting, Scrum says literally nothing about removing responsibility. It even says that team is allowed to split responsibilities within the team as they want
Also, I've never worked in a company, where meetings would take less than 15-20% of work time, no matter if they use Scrum or not
In our case, Scrum moved the responsibility from a single person to a team foreach part. In my experience the code quality decreased dramatically, because there was no longer a code ownership.
Yes, in any case there are often to much meetings. But in Scrum there are often forced meetings, where I counted the minutes until each meeting was over. Some people really like to talk about each pixel they moved.
@@juergenzhang9133 Scrum did not do that, people did that. It sounds like nobody where you work has grasped the concept. As pointed out above, scrum says nothing about nobody taking responsibility.
We do scrum-ish now, but there is still code responsibility. Actually they won't even let you open an issue without owning it first. For that matter, most people prefer it that way... nobody wants to debug someone else's stuff. ;) We do have the absurd meetings though.
What I'm noticing especially with some younger developers is their almost religious conviction to the fact that clean code = hexagonal architecture, unnecessary addons like mediatR and just overall over complication of what could be a simple, readable code. You go into such project and try to adjust something and you end up looking and thinking where do I put this new feature because it simply doesn't fit the general idea... Lookup feature folders, and try to follow common logic in your code, rather than taking something for granted. Clean code is when you can read it, not when you have to throw bunch of stuff at it to even begin.
In my experience, product managers actually become interested in code quality once it starts impacting the speed of feature delivery. But yeah, actual code quality has nothing to do with the “Clean Code”(c), SOLID, GRASP and all the other BS buzzwords. I’m happy that people started realising that this isn’t the unquestionable truth.
Scrum is the worst thing I have to deal with at work, even worse than bad code.
scrum is not the problem. Scrum is a means of time-boxing work effort, that's all. How can that be the problem? ... time to look and see what the problems actually are and adapt It could be that people are paying too much attention to "you've got to do it like this. This book says do this." That problem is not scrum, that is people.
@@Bill-s6j2w Easy, when there are things which cant be time-boxed into say 1 sprint. Or say allocating the correct amount of points. Or say requirements which aren't flushed out but are required. Scrum seems like it works on paper but in practice it only works in the minds of scrum leaders/masters.
Oh lets just keep fail over these stories, making the dev look bad even though they put in all the work they can but its just not enough and we can't put anything above a 5 pointer.
@@TizzyT455 "Scrum seems like it works on paper but in practice it only works in the minds of scrum leaders/masters."
That statement is complete poppy-cock.
It sounds to me like your experience has been tainted by not sufficiently making tasks small enough, admittedly it is something that only comes with practice, but large tasks can be broken down into smaller composite parts.
If requirements are not fleshed out, then they are not sprint ready, that is the point behind backlog grooming.
Also it should be noted that Scrum is not the best approach for every project, and there are alternatives whilst still working in an agile manner: Kanban for example; but Scrum itself is not bad and MANY organisations use it effectively.
@user-cs8ii8tw4y funny as you mention kanban as that's what we were kinda doing before this crap, and it worked fine enough. Also, if my requirements aren't sprint ready, and I'm not in control of the requirements, what do I just not have work? What I tend to do I make up some crap and then change it later when I have said requirements.
Also my statement isn't "poppy cock" what ever that is when you yourself admit that it isn't always best. I believe it isn't that companies need to use it effectively, but which projects can utilize it effectively. I've had scrum in my old job and it worked okay (still not perfect) but the thing im working on now, the entire team is always struggling to create proper tickets. Oh, we require a fix version, but we don't have a release for it yet. Oh, it needs an epic, but it doesn't fit anywhere... so either scrum works on paper and where I work is fucking it up royally or it doesn't work that well and everyone is making adjustments to it so that it works well for their team/project.
@@TizzyT455 you said that scrum
Only works in the minds … which is nonsense, it also works in practice. There are literally hundreds of organisations that use it effectively.
There are challenges, the same as with any framework, but the problems are people problems not with the framework itself.
As I mentioned before, deconstructing work into meaningful timeboxable (I made that word up) work items that deliver value takes practice to get right. It’s also a team effort, including the product owner: they tell the engineers what they want and the engineers tell them what they can deliver, how they can deliver it in an iterative manner. It’s only the engineers that are able to break a feature into deliverable parts since they are the ones who know how to build what is being asked for.
And in answer to your question about not doing any work if requirements are not sufficiently prepared, I would say that the work which can be done is getting those requirements sufficiently understood and broken down into tasks. You are right, you cannot start a sprint if the requirements are not sprint ready. Product owners need to understand this and the only way to make them understand is to not start a sprint and instead continue getting requirements properly fleshed out.
In my job i was able to teach some basic concepts of clean code and the code quality improved a lot, i think basic clean code can be followed for everyone and helps a lot to improve the quality.
Fr, like if the team has no standards, creating some will definitely be an improvement!
bruhhhh!!!!! im 100000% aggree with this entire video! the scrum part! (WATERFALL, with hard deadlines and death meetings!)
My 2cents (doesn't exist in Aus lol) from comments:
People are mistaking "clean" code and confusing it with SOLID. That's the difference.
clean code is about effectively cleaning business layers so NEXT developer can read your mess.
***What Developers do is JAM in their rules and code and over time it that ONE function extends and extends so you end up with 10 rules inside foreach, no clear documentation about what is going on. if only one developer does and understands (prototype way) that's great.
Refactor later? NEVER GOING TO HAPPEN! Totally disagree leave it to others. For one changing git history to put code in another file - good luck with that!
Organisations and every workflow type applications have this issue with clean code but what Nick isn't calling out, "long term developers" DO NOT WANT to change this (no documentation, mess) as it suits their needs of employment. You're just an annoying employee.
C#/SOLID/OOP which is what your hard core developers did 2000-2010 - they got wiped out in SPA applications. Lead to separation of concerns, move data, do calculations, ship data to UI.
Ps. agree lets get a "what is scrum"
Most interviews suck and are not on brand for the job. I've had an interview where they wanted me to recreate Netflix in like a week and they were like a car company or something stupid. I don't even remember. I've had companies fail me because I didn't write tests but they also didn't ask for tests and I only had like a day turnaround time.
Most of these interviews just ask for way two fucking much. Considering that I have a full-time job, I am not giving your task more than a few hours at best. If I cannot complete the task within four or less hours I'm simply not going to be completing it. I'm going to stub out shit and I'm going to be like well. This is the thing I would have done if I had more time but I have a real job and I have a family and suck it. If it's a good company, they will still understand what your code intended and they won't give a shit if it's a bad company that's doing this thing because they heard Google does it? You don't want to work there anyways
I hate Scrum from my soul..... I work for large company and in reality we have even Agile Coaches as some kind of supervisor.... it's creazy.....
I totally agree with you Nick. 30 years of software development and all of these buzzwords and practices have only ever slowed me down... Thankfully running my own software company now, we don't use scrum. Although I will say... it does help to keep you accountable for time...
Regarding SCRUM, I am SM with 12y of experience and I have NEVER worked with anyone who actually understand it. And in 90% of cases SCRUM became a NIGHTMARE way of working in micro-management-waterfall for nepo-babies-managers.
"Clean Code" is a meaningless Buzzword. It has always been. Either you as a developer have a good understanding of how appications should be build and architectured or you don't. You don't have to be TDD, you don't have to have a Codebase based on SOLID in order to have a well tested, well-maintainable applications.
Also, if you have a bad codebase, switching to TDD and SOLID etc won't fix anything.
Yes, these things have disappeared... They aren't buzzwords, or shouldn't be, they're just how it works... Small functions, clear inputs and outputs...
But with Teleriks and Avanades, it's more about the man month than the structure... I've seen code that was just as bad viewing the app as viewing the code...
But there is a big difference between APIs and web back ends... Web back-ends don't have child classes and you're always manipulating data, rather than say writing middleware where you need to work with the pipeline and not the data...
OMG, you said AGILE... That was a nightmare mostly because you can do all integration with something like Confluence or Jenkins rather than taking x hours out of every day...
Uch! I have seen Uncle bob clear it up time and time again when he gets those "dumb" questions in interviews. It should not be read/interpreted as "the only way". When he wrote these books or someone makes a DomeTrain course, the author relays a vision, design, rules, practices, that they believe in and relates to the subject but It is always opinionated. Now does that mean when Nick, Bob, Gui say or write something you have to take that as a 100% truth? No. As each author is covering a usually substantial subject they need to highlight all of the aspects and doing so slips in personal preference. 20% of your code tested vs. NOTHING, and 50% of it pretty clean by implementing just half of the "clean code" principles! These practices have their time and place. Your console helper that you run 3 times a year vs. your main/hot path in your main product. Certain fields will require 100% testing and coverage, like medical devices, FPGA design, MARS rover, etc.
If Nick writes "_logger" you can use "logger" if you want. If Bob says 5 lines per function you can do 10. If Bob says split up two for loops in 2 functions but you feel comfortable putting a double for loop in a single function... good!. If a car mechanic youtuber says torque this nut in six turns up to 50 foot pounds... if you do that in 7? fine. As long as you are in spec of the torque requirements.
also I heard Bob commenting on Agile, which he was involved in, that what we currently consider "Agile" is leaps and bounds from what THEY thought and meant at the time of creation.
If you take 10 devs,
8 of them will describe their code as clean,
half of them had never read any clean code book (or can name any principle followed or violated...)
and almost every dev will describe half of the other code as not clean, or readable...
What 'Clean Code' is, is very arbitrary and that's a shame.
Or TDD starting with production code... (and 30% coverage)
Or Agile without UnitTests and/or CI
Or waving the performance-flag, gaining 1ms in an GUI-interaction (and of course with zero performance-tests...)
tbc...
I always try to write the cleanest possible code with the highest meaningful code coverage (using TDD principles the way you describe it, writing code by default that IS testable) but, as we say in French, "not trying to be more catholic than the pope" and over-abusing the concept just to fit to what some guys decided was "clean" and "not clean".
About stupid questions in job interviews, when I was a junior, I've had an interview where the guy asked me "For the precompiler, what is better between a Dataset and a Datareader?" I couldn't answer (because, really, nobody cares) and his answer was "Are you sure you are a C# developer?"... I'm still a C# developer, not this guy and not because he had a promotion at his company...
About SCRUM, I must say that yes, it works, when it is implemented by the book. Often times (always?), the people making decisions just heard it talks about sprints, they think "sprint is fast, it's good, people will work faster and deliver faster". They then take some parts of the framework they accept to use but reject what would require them to change THEIR way of working (or controlling other people's work...), see after three months that developers didn't suddenly work 4X times faster and end up by saying "scrum is a joke, you're not sprinting, you're walking, it's useless, let's work like we've used to do since the 1980's"...
I've seen companies where Scrum works perfectly, people are happy to work there, they deliver features at a sustainable pace. They all have a common point : they implemented Scrum by the book, and the management agreed to let the realization teams have some kind of autonomy on their work to make it better.
Clean Code = Encapsulates everything in a Lib/Package and use it in a single line "under my rules, not yours". Simply as that. It`s not a bad thing, but turns into a standard "cake recipe". Why not build our own doing the same thing?
do every rules (clean code, SOLID, etc..) are applied on most IT projects => NO
Are most of the IT projects dying with the times because they are not readable anymore => YES
cause and consequences
"What I like ..." , "What I think ..." ,"What I prefer..." are things that can only work if all people are as smart as you "ο φίλος μου". In reality if you keep to basic "Clean Code" where you structure your code and name your classes and methods (albeit names can go really long , but for modern IDE its not a problem) properly - your code will be more maintainable... and in environment where "software eats the world",meaning you ll need a lot of workforce , and not all men being equal, you ll need to make a lot of concessions in terms of manpower quality , therefore maintainability is priority number one... its funny that this fact is poorly understood amongst smart developers , hence completely justifying the expression "too smart for your own good..."
The only place I see these - enter name here - methods working are when you are starting and are looking at a blank page. They help establish some level of "agreement" as you learn the actual functionality required. I work with supervisory process control applications for manufacturing and the vast majority is legacy code as the physical equipment is many years old. Attempting to apply new practices when revising old complex code is just asking for failure (either in functionality or delivery dates) Understanding the SOLID principals help when making decisions on laying code -- but should not be the rule.
I lived through the the initial structured programing technique of GOTO-less programing -- use one and you failed (or were fired). Based on this absolute rule -- I had to work on functions that had over a dozen or more nested "if"s -- record was 18 -- why -- gotos were bad said the original developer - sound familiar? ...
My focus -- code for maintenance -- expect your code to live 10+ years!
Scrum... yeah we need your rant Nick!
My take: Scrum rhymes with scum and scam.
Scrum = micromanagement = wall of green = speed delusion = dust (mountains) under the rug = reward for quick and dirty devs.
Comes deployment time and poof vaporware.
LOL. This thing could be 50 ms faster. Yeah nobody ever complains about 50 ms faster. If you work somewhere where performance is critical, like video games development, you're more likely to hear about 0.5 ms faster. 0.1 ms can make the difference between your game running at 60 fps or not. High-speed trading has even stricter requirements.
Neither Clean Code nor TDD are micro-optimizations, they're practices and you don't need to follow them by the book (literally) in order to gain value from them as long as you have a clear idea of how you want to write code and how it should look like to be maintainable while delivering value to clients/customers. With regards to TDD, I've just refactored a piece of code that didn't have any (valuable) unit tests and just by writing some important test cases before making changes to the code, I found several issues with the code and these issues would not have come to light without writing those tests, they also would never have existed had TDD been applied in the first place.
A note about scrum based on personal experience working with different teams: The Agile Manifesto declares "people over processes" (actually "Individuals and interactions over processes and tools"), but most teams or companies that do Scrum actually do this in reverse by putting "processes over people", which is where everything falls apart.
Clean code, OOP, ... Imo people that use it are just pedantic about everything that is according them not following some principle, that just doesn't really matter, why in reality the code is very good, and follows basically all good principles. Also automatic code checkers are mostly just pedantic and make your code worse. They don't focus on what's actually good and bad. The code they write themselves and according them follows all principles is bad, extremely overly complex and doesn't work. It's fine to 'hack' something, as long as it is the correct hack, which imo means it's not a hack. A simple problem should have a simple and 100% correct solution and the problem is not the 'hacks' but the wrong hacks that are implemented to try to solve a problem that makes things difficult.
...and then juniors use web application builder, dependency injection, event driven architecture and don't recognize patterns and principles. You use it daily and don't see it? Really? Regarding unit tests, I usually see missing tests, indicating non-TDD approach, at first glance. These tests are really missing, it is just hardly visible because tests fits nicely implementation, which if written slightly different would introduce defect even though coverage is fine. People don't use TDD because it is difficult and requires experience, but when learned it really speeds up development and shortens feedback loop. Bottom line is, you can write clean code without sacrificing delivery.
The way I see it, coding is a tool. You don't code for the sake of coding, you code to create something. Fixating on conventions, rules and practices will narrow your horizons. It's good to know and be proficient with them but that's about it.
If you expect every company to follow rules that you put on yourself, you'll fall into exactly this mental abyss and will have hard time finding work. One could even say, you're no longer a team player.
Ooooh also on the topic of Scrum, during my 7-year carreer I haven't met anyone working in proper scrum product team. It's always a complete mess that doesn't work with people that couldn't care less about some agile bullshit.
Bro is still thinking that someone cares about all this practices and he is living in world of pure programming. Real life is a little bit different. You use the approach chosen by your lead + business. That's all. Your lead likes ddd - you will write a shitty version of ddd (let's call it DDD that can fit in deadlines). Language is also usually chosen by leads (if it's not legacy). Company pay you to make more money. People who hire you don't care about language, technology, framework, principles and so on. Developers are the same people as guys adding flour to the bowl in the bread factory or guy who is installing brakes on the car. Welcome to real life )))
Amazingly, all of the devs I've been interviewing amazingly not only know how to spell SOLID (I'm a dotnet dev) they can regurgitate single responsibility, open for extension, ect.
Then you look at their code... 😢
I think that most clean code efforts have to be driven by the dev team (I, for example, as the team lead for my company's product, enforce TDD coverage for all new changes, and I can be brutal in my PR reviews). People outside of dev don't care because it "doesn't move the needle." So at the end of day, in my opinion, it's a matter of how much garbage you want to wade through just to update the code.
I hate "Clean Code" arch because the value it has is...at best, minimal, and, at worst, negative due to all the abstractions and hoops you have to jump through to follow something.
For instance, why wrap a dbContext in a repository when I know that SQL Server isn't gonna change as a dep in the next 10 years? Or, why are writing mappers between domain and db entities all over the place?
I've never seen CC *not* overcomplicate the code base, even if I can see some value in a couple of its principles.