Why Developers Hate "Clean Code"?

[@Grumpicles]

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.

[@T___Brown]

Id say many dont actually implement Agile Scrum properly. Where I at we just put tasks for "do work" quite pathetic

[@MrJSplash]

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.

[@padiau78]

@@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.

[@catsgotmytongue]

@@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.

[@nitrovent]

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.

[@evanboltsis]

Let's have a Retro about it Nick

[@aaronkoller8811]

I think we need to have an intervention here.

[@damianrodriguez9553]

First, let's have a planning for this interview. Do I prepare the poker planning dashboard?

[@amnesia3490]

can I get a task for this ?

[@TheMightyOgg]

I need a spike for this sprint, what shall we remove for this 20 point item?

[@ivandamyanov]

How about we do backlog grooming first boys? How about some refinement? A 2 hour meeting should be enough.

[@rjanBergProfile]

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.

[@EricKing]

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.

[@rjanBergProfile]

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.

[@EricKing]

@@rjanBergProfile Agreed! We should work together lol

[@tuckertcs]

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.

[@Crazycorn2]

Most poor developers hate it, just like bad plummers, mechanics etc hate having to do things properly.

[@Anonymous-un2nj]

Based on what I see in my project, Clean Code never existed...

[@scooterjackal]

You’re not alone 😂

[@GaryFrancis-q3r]

🤣

[@johnnyblue4799]

I washed all my code yesterday! It's squeaky clean now!

[@Anonymous-un2nj]

@@johnnyblue4799 Unfortinatly not easily done with tight coupling, low cohesion and no documentation in million lines of code.

[@JulioKawai]

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.

[@Jabroni24601]

I’m all for the Scrum rant. Give the people what they want!

[@henningerhenningstone691]

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.

[@ThugLifeModafocah]

Agree with the firts half, disagree with the last half.

[@henningerhenningstone691]

@@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 :/

[@tarquin161234]

@@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.

[@krss6256]

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.

[@kylekeenan3485]

This somes it up nicely, thanks.

[@mikicerise6250]

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. 😛

[@TizzyT455]

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.

[@Zolem-i7o]

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.

[@DanteDeRuwe]

Pleaaaase make the scrum video. It seems like I'm the only one on my team passionately hating scrum, and it drives me insane!

[@phirus646]

really? I have the feeling everybody in my team hates scrum and I'm the only one who likes it.

[@volan4ik.]

You both need to swap, guys 😂

[@trader548]

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.

[@ghaf222]

Scrum is exactly one of those things. I got sent on a course, got a certificate, the end!

[@Bill-s6j2w]

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?

[@nexxxuno]

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.

[@qj0n]

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

[@gaborpinter4523]

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

[@TheCameltotem]

"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"

[@thebitterbeginning]

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.

[@edgeofsanitysevensix]

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

[@ghaf222]

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.

[@Bill-s6j2w]

Exactly this! SRP should be the guide for classes, methods, and functions, certainly not line-count!

[@InverseBasement]

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

[@Briezar]

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.

[@mambocollective]

@@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!

[@tarquin161234]

I disagree with "No method should be longer than 7 lines of code."

[@Tobi-bx8kt]

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..

[@LaCinturaDiOrione]

The hard part of Development Management is to know When and How recover the Technical Dept of the early stages of a product.

[@Misteribel]

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.

[@mambocollective]

Exactly!

[@leaderyt1318]

Its maybe not about the clean code its maybe the way is implemented it self

[@clixmods]

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.

[@joancomasfdz]

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.

[@mrBjarneLP]

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.

[@Bill-s6j2w]

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.

[@sealsharp]

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".

[@curtis6919]

​@sealsharp cope and seethe oop dork. Go write some boilerplate code

[@reikooters]

Sounds like Molly Rocket's video

[@antongorov5275]

@@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.

[@christopherwalton7736]

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.

[@dekryptid]

Give us an ATDD video 😎

[@SergeiFedorov77]

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.

[@michaelrarela5734]

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.

[@SergeiFedorov77]

@@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..

[@sebastianszafran5221]

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...

[@HannesBiribauer]

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.

[@SlackwareNVM]

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".

[@keigezellig]

Not necessarily a problem of scrum itself but more of the underlying company processes.

[@jfftck]

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.

[@MarvijoSoftware]

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

[@lil_nach]

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

[@TrOgaN_]

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.

[@BillyBraga]

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.

[@ruekkart]

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.

[@helleyequeue]

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

[@softwaretechnologyengineering]

Scrum is the most efficient way to introduce technical debt into a product.

[@qj0n]

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

[@GabrielAlva]

The shade on poor F# 💀

[@ivank6486]

Somewhere is the world one F# developer cried.

[@MrEnvisioner]

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.

[@fsharplove]

@@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.

[@dave7038]

@@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?

[@GunslingerP]

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

[@kibria8680]

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

[@Gd2Ph]

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.

[@Hereson]

I only write instant legacy code..

[@naughtiousmaximus7853]

Java?

[@mikicerise6250]

@@naughtiousmaximus7853 😂

[@TheoPoufinas]

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'...

[@qj0n]

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

[@CarstenFuehrmann]

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!

[@GameDevNerd]

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.

[@mikicerise6250]

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.

[@IreneSmith]

I was in a situation a couple of years ago where I was on a team of developers who were each working on their own unrelated projects. We were developing code examples for other developers using multiple languages. Most of the time my report at scrum really had nothing to do with what anyone else was doing. I dreaded daily scrum meetings because the only real use for scrum was so that the manager could keep track of what you were doing, a topic that should have been discussed at the manager one-on-one. I felt that it was the biggest waste of time on my calendar.

[@sergeynosov8180]

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.

[@CHE6yp]

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

[@carlinhos10002]

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

[@JollyGiant19]

I can’t tell if this is satire or serious because it’s basically on the line 😂

[@ooijaz6063]

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.

[@mikicerise6250]

Where is this mythical large Clean Code project? 😅

[@mattbristo6933]

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.

[@tarquin161234]

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.

[@ripahoratiu]

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.

[@davorloncarevic5128]

This is one of the best, honest, real life situation videos I have seen for a long time. You could probably make 24h video on this subject and it would not be enough, these 15 minutes are pure gold.

[@alexthebassist23]

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!

[@ErazerPT]

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...

[@georgepagotelis]

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 :)

[@alexthebassist23]

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.

[@ErazerPT]

@@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.

[@georgepagotelis]

@@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!

[@maflex24code10]

When I started work, and building API, I tried to do code most universal as is possible, like universal actions for removing entity, and inherit from models. Then I started go get new requirements from clients and PMs. "Change this, add that, change the logic how this working" etc. Then universal started to be trouble, because we need some exceptions, more and more. Finally repeated code started to be better. When I needed to change something in some module - I just did it, not thinking how it can affect to other pieces of code in another module. Theory and scheme is one think - practical, and changing requirements other

[@vitorbarleta4457]

"I fear no man, but that thing... (inheritance and polymorphism). It scares me"

[@xlerb2286]

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. :)

[@asagiai4965]

Inheritance shouldn't be too deep.

[@JollyGiant19]

@@asagiai4965I’ve seen class inheritance hierarchies that would make the Hapsburgs blush

[@asagiai4965]

@JollyGiant19 I think that's the point, because most people inherits so deeply, it's bad. That's why I said ...

[@jongeduard]

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.

[@travisabrahamson8864]

I don't think it is dead in the sense that the one of the responsibilities of developers is to have code that is easy to maintain by the team, not just the individual. I have also seen things extracted out to far for the applications purposes, so just like the 'Odd Couple' there is the extremes of Messy but works hard to maintain and So clean it is hard to understand but it works. As developers we need to advocate for the code. I do believe understanding the concepts of both CC and SOLID can make you better at avoiding pitfalls. I'm a fan of TDD because so often developers start coding a solution and add extra or get distracted by "features" not yet needed or discussed. I see it as a focus tool as well as a way to define when done with this coding session. As for Scrum and Agile my main issue is too often these are sapping time away from teams and at times the ceremonies seem more to justify a position in the company vs actually helping teams succeed. Worse is when I see a team of 10+ and they try to keep a standup to 15 minutes, that is insane and would drive anyone crazy.

[@viophile]

I agree 100% with you about scrum and agile. What a waste of time and effort.

[@domi_dreams]

we have an ol' sayin in Poland: "those who work with the scrum - they don't laugh in the circus"

[@secretagent5209]

😂

[@daniil7750]

it seems to be the same in many EE countries, in Russia we say exactly the same 😄

[@qj0n]

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)

[@anonimzwx]

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.

[@FelipeV3444]

Fr, like if the team has no standards, creating some will definitely be an improvement!

[@Gentlehag]

Exactly what you mention at 09:30 . Trying and learning TDD, SOLID Principles and so makes code better by default even when nocht epxlicitly applying those principles. There are so many easy ways to change coding style without effort to avoid race conditions, unnecessary states, reducing complexity and so on without heavily relying on tdd, just by slidly changing the way I write intuitivly code

[@pdurchev]

I absolutely agree with you. Using all these principles as a guide line without strictly following is the most effective way of developing applications. For the entirety of my career so far (almost 20 years) one thing is constant - time is limited. It would be great to spend months refactoring, upgrading technologies and improving implementation but there's always very limited time for these things, because the customers are waiting on the newly requested features.

[@Bill-s6j2w]

@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.

[@keyser456]

Focus more on the task, and less on ceremony. It will get you much further in software development.

[@NickSteffen]

I think something that has changed is the life span of various parts of the software. I think software used to be around longer before it was deprecated or rewritten. This means that spending time on clean code has less value as you will be upgrading troubleshooting and refactoring each component for much less time and each component has less time accumulate the complexity that makes clean code more and more valuable. Nowadays it feels like software has a very short lifespan. I think part of that was the push to microservices (it's easier to rewrite a small component) even though in recent years we've moved backwards from that a bit. I think API standards have drastically improved to the point where it's easier to make another API that replicates the functionality of the original in new tech as well. Even in software that lasts longer, subcomponents change or are rewritten themselves more frequently.

[@adambickford8720]

Most devs aren't very good and 'clean code' is just more for them to botch. This isn't a theory.

[@jangohemmes352]

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.

[@paulkoopmans4620]

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.

[@mikicerise6250]

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.

[@DaminGamerMC]

the company I just started working at grew really really fast in the beggining and is still growing fast, so when they developed their system they basically just put all features in the system without following any standards and Clean Code. However, they now have so many developers that they have made a team, the one I am part of, that is only in charge of fixing the old code: refactoring, changing design and architercture, following standards, optimizing, etc. while the other developers adding new features now are following the same standards so eventually the system will be really "Clean".

[@metaltyphoon]

So this has nothing to do with clean code itself. More of “I’ve done this once and know where it can be improved so refactoring it will make it “cleaner””. Moral of the story? Just code shit and refactor when u need to because you don’t have a magic ball telling you everything you will need.

[@helleyequeue]

I have cases at work that my seniors did so much abstraction that sometimes when I need to do something simple I am going through base classes -> interfaces -> dependency injection -> classes that inherit the base classes with 5 constructors and reading all of those abstractions for simple things makes my head hurst. Looks like rocket science where on the end the class just connects to the sql db and pulls some data out from the table maps to an entity and that is it.

[@aushturm]

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.

[@tonyjoanes]

Nailed it as usual, the amount of places I have interviewed at that ask me about SOLID, I guess its a great interview question, the same as TDD. Rarely seen these principles followed

[@eerosalonen]

After company where I work adopted SAFE and Scrum I have gained understanding why people hate them and how they feel like extra obstacle instead of helping to get job done

[@Bill-s6j2w]

Again, it's people being dogmatic that is the problem, it's certainly not scrum. Scrum is ... chose the work for the next sprint. Work on it. At the end of the sprint reflect upon where improvements in the process can be made, make those improvements. Rinse and repeat. Tell me, how that can be a problem?

[@eerosalonen]

@@Bill-s6j2w In theory that is how it should work. But that is not what is seen in reality. In sprint plannings and program increment plannings situation is more often than not such that team plans time allocation for different type works, like how much support cases the most likely will be, how much time will be used for customer x and how much for customer y and how much time will be used to plan features that sales team has sold for customer z. Then team has to also allocate time for two legacy systems which needs to be supported until new system that is done team in another country is ready, but that transition is already been done for several years and there is again new delay. And end result is that nothing concrete was planned in those planning meetings, there is nothing that can be done to improve the process as that is not priority for company management as it is more important to get new sales in order to satisfy owners and whole process is just some strange pantomime where people pretend that they have things under control because there are jira ticket for time allocation for it, even though every one knows that time allocation ticket will be moved to another sprint or used to some other work.

[@stranger0152]

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.

[@keigezellig]

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.

[@Bujde69]

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.

[@All-in-on-GME]

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"

[@wpelfeta]

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.

[@metaltyphoon]

@@All-in-on-GME some bullshit numbers pulled out of the ass.

[@local9]

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.

[@Bujde69]

​@@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.

[@vincenzoriwu2998]

Great video as usual! We need your video on scrum now!😂

[@DeeKimber]

I think it's extremely important to be aware of these principals and concept and then build your own coding standards based upon what works best for your organisation / solution. Consistency within a team is the key, not necessarily following rules other people have prescribed.

[@urbanelemental3308]

The quiet part out-loud. Love it.

[@vorontsovru270895]

07:58 Unfortunately, this is a fairly understandable situation. The company simply weeds out people with the requirements of these practices, but they will not apply these practices. This is because senior managers are convinced that such practices slow down the development time of new functionality. Thus, they gain time in terms of implementing new functionality, but lose out in terms of performance/stability of work/time to implement new functionality (after a time when the project is more like a tangle of threads from dependencies). And the saddest thing is that these managers either don't understand this, or they don't care at all.

[@edgeofsanitysevensix]

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

[@dinov5347]

Sound observations and advice. My only criteria these days (I do like clean code, tdd, unit testing etc) is trying to get continuous delivery going. I think this trumps all since incremental changes and feedback are the most crucial part of delivering software. So in the end you must ask yourself "what are the roadblocks stopping you from doing CI/CD". Does it mean forgoing all good principles? Of course not. As you pointed out, you find a balance and hopefully you can deliver qualify as well.

[@tbddevelops]

I've long felt that being pragmatic about writing software, not trying to follow someone else's expectations about what the software should contain is the right way to develop. I feel the most important factors are can developers be productive (can they identify areas of change quickly, not repeat themselves and not worry about gotchas while moving the code base forward) in the code base on which they work. I think that every codebase, every team, every organization brings new challenges that mean it's not always practical to apply everything to, but it doesn't mean you shouldn't try and do some things.

[@mcxMakerx]

I would really push for clean code at the last company I was at because there was A TON of copying and pasting, horrible variable names, magic numbers, etc. Being a small company, these poor practices really slowed down development especially when I was pushed to get new features out the door extremely quickly. How was I supposed to know that the same code block was copied in 30 different places with only a slight change? I had to hunt things down all the time and replace them with a method. It really slows you down when you have to ask someone what a magic number is for/how they arrived at that number in the first place when there are no comments. If I fixed a bug in one place, I would have to search around the codebase to see where the same code was implemented again due to the poor practices. We followed SCRUM where I had to talk about what I was doing everyday which was mostly a waste of time.

[@TizzyT455]

Scrum is the worst thing I have to deal with at work, even worse than bad code.

[@Bill-s6j2w]

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.

[@TizzyT455]

@@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.

[@Bill-s6j2w]

@@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.

[@TizzyT455]

@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.

[@Bill-s6j2w]

@@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.

[@geestarrawify]

I would love a video on the bad things about scrum and its many downsides! 🤩 Your points mentioned are some of the ones I have had myself for a long time.

[@Omego2K]

I was obsessed with clean code and all the practices that come with it in one company where I stayed for a while. After I left I found the practice to be non-existent in other companies. I can also attest that some interviews have questions related to it, but the companies themselves don't practice it. I feel like architecture is more of a practice at businesses now. I also now feel like architecture is extremely important. As an example we are doing business with another company and they gave us are response time limit. To me that time limit it's mostly architecture that gives you those extra milliseconds or maybe even seconds. Sure the implementation is important, but as long as you don't use really crappy code then the implementation shouldn't cause a problem for any latency. And if there is then there is only a small amount of code that is responsible for the wait and see that you will have to change

[@ArtemShoobovych]

Great point, seen it in many places with established products: if something requires time and resources investment, but brings little value - business won't agree to that, since it is net loss. Roughly speaking, "if it works - don't touch it"

[@feefifofum6383]

Hey Nick. I've love you to do a deeper dive on what aspects of OOP you avoid and how you handle them these days.

[@DevMeloy]

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.

[@promant6458]

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.

[@invictuz4803]

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.

[@DevMeloy]

@@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).

[@DevMeloy]

@@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.

[@IzaacB89]

We’re using some form of a scrum-amalgamation that works really well for us in our current project. We’re close to release, and then we’ll see how we’ll work on our next project. For some context, we’re a dev team in a government agency, developing internal systems, and when the product is feature-complete we’re not really involved anymore, and gets assigned another project.

[@invictuz4803]

Great article topic to review, keep these kind of videos coming! Hard to tell when you're switching between reading the article and voicing your own opinion though. Maybe, add a pause before the switch?

[@graybot8064]

When I think about clean code, I like the analogy of a chefs kitchen. The restaurant is not paying the chef to keep the kitchen clean, so why do they do it? It makes the next meal prep safer and faster. If you only care about delivering the current piece of work, your next piece of work will be impacted.

[@WileeRunner42]

Agile is take and use what works for your team. Similarly to all these concepts, they are good to know the reasoning so you have more tools in the toolbox to use. Just don't take your only tool the hammer to caulk in the window. I once told a new programmer on team about design patterns that 1: our customer doesn't care, 2: I can describe my code as following any design pattern, and 3: they are useful to know so that you have various tools and ways of doing and understanding things.

[@hichaeretaqua]

Over the last decade, I have tried to delve deeper and deeper into the topic of clean code. But the more I've looked into it, the harder it is to find a reasonable definition for clean code. It somehow seems like a magical creature. Almost every developer thinks they have seen the creature from a distance. But when you get up close and try to define criteria for what exactly clean code is, it usually ends up being an exchange of opinions, having little to do with facts and more to do with personal preferences. In the end, I avoid these discussions now. If someone makes suggestions to improve "readability" and I can't see anything obviously bad, then I accept the suggestions, even if I disagree. In the end, I believe that my time is worth more than the potential outcome of such a discussion.

[@Esgarpen]

Clean Code isn't bad - people who take Clean Code to the extreme are bad

[@justindoyle8091]

My experience of Scrum and Agile is exactly the same. Waterfall with artificial deadlines and daily standups. Anything that isn't finished by the deadline gets 'rolled over to the next sprint'. So why even bother?! A lot of managers looked at Agile and all they saw was, ooh, daily meetings and frequent deadlines so I can make sure my devs are working hard! The rest was ignored because they really don't want devs making any decisions about order or priority. That's their job!

[@tamaslencse3468]

You absolutely MUST make a video about scrum and agile! I would love to see it!

[@dave_s_vids]

"it's not about you, it's about them". That's a wake-up call we should all try to remember when getting stuck into a fun and satisfying refactoring exercise!

[@juergenzhang9133]

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 :-)

[@qj0n]

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

[@juergenzhang9133]

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.

[@Bill-s6j2w]

@@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.

[@mikicerise6250]

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.

[@takisback]

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.

[@LordSuprachris]

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.

[@DaT0nkee]

Actually uncle Bob explained why he created agile, clean code and solid. At the time the number of developers doubled every 9 months. Which means 80% of the developers on the market had less than 3 years experience, and you had to develop products with them. Obviously, seniors exacly know how to do things, so they dont need leashes like solid, they are working fine by themselfs.

[@jewersp]

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.

[@nyhronr88]

Nick, what elements of functional programming do you use when coding in C#?

[@Robert-yw5ms]

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.

[@matthewbymaster5057]

You need to make a video on Scrum and what works for your team(s). I think of scrum like a very dangerous tool that requires users to read the manual beforehand BUT no one ever does. The Clean Code, OOP, SOLID, DRY, TDD, etc concepts are good to know so that devs can be pragmatic about writing their code (like you said). I just spent the whole morning rewriting tests for a new scenario because our contractors didn't set anything up to be extensible/reusable.

[@richardbeyea8840]

Scrum: What went well in the last sprint? Bob really took charge and was able to do an amazing job adding the 8 point feature. Way to go Bob!

[@emilfrick6770]

I would love to see a video on which aspects that are good to adopt regarding these conventions that are wrapped in a acronym. Maybe a video series, I dont know :D

[@amnetik2596]

As a junior developer who has only known SCRUM/AGILE, I am very curious about what alternatives you would suggest. I'd be quite interested if you made a video on the topic.

[@mikicerise6250]

Anarchy! 😅

[@vipero07]

I've been at a number of start-ups as one of the very early if not first developers, and at all of them we started with clean + TDD and devolved into hackathon projects / rapid feature iteration. It's been my experience that, unless management has a background in code, "it's fine if some bugs and tech debt are introduced so long as we add new features quickly." While personally I disagree, since its generally faster to have TDD and clean code (especially if you plan to refactor) it's just never been my experience with the pace management demands. Especially with the moving goal posts of early startups and their release schedules. As for why this happens at larger companies, I suspect its similar, management has expectations and "I'd rather release known bugs and meet deadlines than miss deadlines" becomes the standard. Consider this "hey bob isn't writing any unit tests" "well george is holding up my PR for this new feature". Management doesn't care about clean code, essentially.

[@vipero07]

I also love the description of scrum... 100% how it's been done at every company I've ever worked for once non technical management got involved. Waterfall but with shorter deadlines and zero documentation or thought of how some new "probably small" but actually huge feature would be done.

[@Rajeshsingh-ws5th]

Hi Nick, what do you think about, stay connected with handson coding or leave it and get into project management and work like postman to grow in career?

[@TheMightyOgg]

You and I literally said the same exact thing, the exact same way when the *Scrum Leader* at my company scheduled a call with me -- I feel how you feel in my bones. Can't we just write good code, release on time, and just do what we CAN do to make our quality as good as possible and still maintain some velocity? Everything really is "good/fast/cheap" pick 2.

[@troncek]

Ah scrum and sprints ... always a joy on meetings twice a week where I take that time to actually do work and code, while "listening" for my name to finally be called so I can say what I'm working on in 5 seconds.

[@tore28]

TDD can be extrapolated into extremes. Some developers are fanatics about code coverage and want to cover every line in their code. Sometimes you must go for the middle ground, where your code should be testable, especially your central code. But often there is not enough money to add as much tests as you desire. Sadly, many in middle management also lack the understanding why tests are important. Tests are important, but one must be pragmatic. Clean code should be grounded on accepted standards. You could enforce code style via .editorconfig in Visual Studio for instance. But it can be off putting to some developers with too strict a regime.