What's the biggest scam in software development?
2024 ж. 24 Сәу.
18 800 Рет қаралды
What's the biggest scam in tech that is deemed acceptable? Best practices. Everything has trade-offs, and your context matters. Let me give various examples to get out of this dogma about best practices.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via KZhead
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo...
0:00 Intro
0:51 Principles
4:04 Example
6:10 Context is King
#softwarearchitecture #softwaredesign #softwaredevelopment
Probably one of the most important things to understand is WHY something is a best practice. Many people learn guidelines (aka best practices) and then indiscriminately apply them turning them into rules without the understanding behind them. If you understand the whys, then you can better apply the guidelines appropriately.
Yeah for sure. Some people get too religious about "best practices" even if they don't make sense in a certain context.
”Only mediocre businesses follows best practices” is my favorite quote from last year. The argument being that if you follow best practices you don’t experiment and innovate and without these you cannot excel.
You cannot Excel but you can spread the Word :D
This is complete nonsense. You as a developer want to develop use cases, best practices are frameworks that help you get faster. The fact that software development is one big piece of garbage is due to such missionary bullshit talkers who regularly serve up new buzzwords to managers. While - of course - new approaches are completely incompatible with old approaches, you have to start from scratch every time. Ideally with best practices, otherwise you have no framework and just pile old and new shit as high as the "Tower of Babel".
100%. If I get asked for the "best practices" on any one topic, I almost shut down completely. It's a lazy question and they want a lazy response. Another variation of this is the so-called "Senior Engineer" with "10 years of experience" where they haven't learned anything new in 9 years, and call what they did originally "The Best Practice".
We call those developers with 1yoe repeated 10 times
I have seen this in developers with "20 years of experience"
10 years of repeating himself 😂
I guess the flip side of this is labeling something an "anti-pattern"
Yes! I totally wanted to mention "anti-patterns" but forgot.
I couldn't agree more. I've seen so many developers justifying decisions being "best practices" not really seeing the tradeoffs. I think the worst of it is how it kills the conversation with some people that bought too hard on this. Also when it comes to infrastructure I feel providers push to advertise for "best practices" too much on their favor trying to oversell things
Rather than pile on, I'll defend best practices. They may not be your practices, but they became a best practice for a reason. The challenge, as Derek points out, is context. Dogma and cargo-culting can turn a best practice into a costly practice. - Learn from best practices - Know what you are doing and why - Do what's best for your use case/team/company
"Everything has trade-offs". That's the message. That's one of THE most important things we can be repeating for folks! Thanks for this! 💪 People need to understand *why* these are "best practices" and not assume "best practice" means "you must always".
So true! The most valuable knowledge in software engineering is to know that “it depends”. Always
One of Context-Driven Testing principles: "There are no best practices. There are good practices in context"
The software testing community has the same problem in fact it was so bad that a whole separate School of testing called the context-driven school emerged that literally has an axiom that there is no such thing as best practices there is honey good practices within certain context
I understand the point, but as a skipper sailing student I cannot agree that best practices are the biggest scam because sailors have best practices that makes sailing safe and effective. The question would be, who is saying that X is the best practice?
Ya that's an interesting point of "who is saying X". In our lovely software world, over time many different concepts lose their intent or the primary driver for the "best practice" isn't known and it just becomes a "we do this because that's what the industry does now" without any idea of why.
@@CodeOpinion I guess that's the difficulty of working with abstractions versus something like sailing in this example. It's easy to lose track of "up" when you're under a sea of abstractions.
I think in your case it also tends to differ a bit since there are probably centralized institutions which determine what is a "best practice" and give out ISO's or at least recommendations given by seasoned professionals. Software is probably moving too fast to have something like a centralized institution for best practice yet. You might have e.g. ECMA and the likes, but it's far from a top-down style in which recommendations are handed out. That's how I would see it at least.
The difference is that software engineering is less engineering and more software. Which means, unlike engineering or sailing, who are strictly bounded and defined by the laws of reality, software is much less constrained. Especially when software describes processes and interactions that involve humans. I believe a need for software engineers to explore and shape those constraints is what makes it so beautiful.
Ultimately, you have to get shit done. Use what works for your team given your circumstances.
Good stuff. This sort've aligns with the previous video on "design patterns." I think early on it was easier for me as a developer to want to know the "right way" to do something, trying to learn all the techniques for solving problems, naively thinking that if I just built up the right amount of knowledge I'd be a skilled programmer. What I've found, and what was even communicated to me at the time but I just didn't have the experience to understand, is that skill comes from practice, experience, and encountering different types of problems. You develop ways of thinking that is a conglomerate of your past experiences, and you're learning along the way. Hopefully though, if you're focused on continually learning and improving, never thinking you know it all, then that skill becomes something very valuable and likely becomes the mark of someone with lots of "tools" to solve problems. I think I've seen plenty of programmers who have "followed the best practices" of X technology/organization for years -- but they never really grow because they're comfortable following the rules laid out by other people. They become less valuable and, although good people, not very good teammates who often bring little to the table. I don't want to be that person.
Context matters for minimal APIs: Pro: lets you show off how few lines of code it takes to write hello world in your language Con: anything more complicated than hello world becomes a complete mess, so you need to split it up into methods, at which point you may as well have just used a Startup class, which already has a well known structure that is easy to test.
I wouldn't paint "best practices" as being a scam with a broad brush. I think reading about them and understanding the context which they were proposed under is key. There are many ways of solving problems in software development and we should be cognizant of lessons learned by previous developers and avoid making the same mistakes. The name "best practices" might be wrong, but I generally think of them as "guidelines under some context".
As soon as you pull in the context to consider, it stops being a best practice by definition and it becomes a practice within a context. Also a lot of the time context isn't even provided. Especially in online tutorials. You are missing the point IMO
We agree about "guidelines under some context". However that's not always the case. Hence the video because of the # of comments I get in various videos, my blog, twitter, email, etc about "you're not applying X principle".
@@TheHegi My point was about not throwing away what we have learned in the past from previous developers. They may have packaged their learnings as "best practices" but, like I said, I think of them as "guidelines under some context". To me, it's important to know the context, or find out what it is. Obviously this is not something that can be learned from a simple tutorial.
@@CodeOpinion I agree that they have been taken as prescriptions by most, but learning from previous developers mistakes is valuable. Systems are evolving and development practices are changing and some of those may have been "good" ideas at the time for solving a particular problem. Like you said, context is King!
@@dimpho.ngache congrats, you are immune to the problem. Most people don't think like this so they aren't. Hence by stating this as a best practice is the perfect approach. You spot the problem with his post? Great it means it wasn't made for you and move on. If you don't then take it into consideration and start thinking. Either way win / win.
Yip, 100% on tiny software teams getting carried away on what Netflix do and replicating.
It is common for developers to point out "principles" - like "You should add an interface to follow this SOLID principle". It is so annoying. Do they strictly follow principles in real-life? I doubt it. Principles are not rules to be strictly followed. They are conventions for dealing with known issues. They often have to be applied in a pragmatic way. And often they think they apply principles but really just apply some coding pattern - completely missing the point and not reaping any benefits from the "principle".
I found the second one to be better, because you're just starting the application. It's simple and clean. Regarding the single responsibility principle, it does do two things, configuring and running the application, but like you mentioned, if that only needs to be done in one place, that's not really an issue. The moment that isn't the case anymore, you simply rewrite that part of the code so it's reusable elsewhere.
Any concise lists of pros and cons for diff architectural patterns? (hexagonal, clean, layered, vertical slice, microservices, CQRS, etc) It's really hard for me to identify trade offs right now since I'm still wrapping my mind around what each pattern really means. Also sorry if repetitive. I think I left a comment yesterday, and it seems to have disappeared.
It's crucial to balance applying best practices with the project's and the organisation's needs. Sometimes, deviating from best practices to meet a specific goal or deadline may be appropriate. However, weighing the potential trade-offs and risks associated with doing so is essential because context matters the most.
Thanks for this. I have been having a constant stream of "it's a recommendation" from another dev lately. I guess I'm gonna make them watch this vid.
100% Agree. Everything is on a spectrum of different contexts. IT DEPENDS! And the default initial starting point should be to KEEP IT SIMPLE AND AVOID UNNECESSARY ABSTRACTIONS AND BLOAT! That's why I love python and rust because you tend to (in the python/rust community as a whole) start small and abstract only when it makes sense to... C#/Java tend to have these big heavy frameworks... they can be good in some cases to have all of the batteries included. But it DEPENDS ON THE CONTEXT
I have been saying this for years now. Thank you for these great examples, now I can let you articulate this for me,
Glad it was helpful!
DRY, Don't Repeat Yourself, probably the single biggest driver of high coupling and low cohesion in the IT-business... with REST being a a very close contender of course.
Around Christmas I asked a question on your video "I NEED data from another service!" about central configuration service. Do you plan to make a video on that maybe soon perhaps? :)
I'll add it to my topics list!
Context Practices!
Over time I've come of the opinion that many design best practices were developed in environments not all that similar to the ones I work in. As such I think a lot of them have relatively little applicability. My biggest concern is there seems to be little concern for the cost of abstractions, only the value of them.
Agree. I did a video about the cost of abstraction and indirection. kzhead.info/sun/d7KjdL5ofGh9iKs/bejne.html
Great video!
100% agree. I think this applies to the everything needs to be DDD and mediator crew.
Here's MY best practice: Don't go looking for solutions if you haven't run into a problem yet.
A true scam is something that costs you a lot more money than it is actually worth ... like TDD when you already have a great test automation engineer and very few bugs ever reported.
🤦
I'd still use TDD personally. It's the most effective way I've found to write code. Just setup your requirements in the tests and then make them pass. Simple as.
@@MrC0MPUT3R I’ve never seen it applied anywhere where it gave them a true benefit. Went for an interview at one place where the interviewer was so dogmatic I turned the job down. Can’t work with people like that. The firm went bust 1 year later because all their products were shit and kept crashing so they lost all their customers.
@@MiningForPies That's why I said I'd still personally use it. I encourage others on my team to use TDD, but I absolutely am not dogmatic about it. Being too dogmatic about testing leads to bad tests. You see the same issue with requiring a certain amount of code coverage. Developers end up writing tests that satisfy the requirement instead of actually test the code. For context, at my company, we don't have test engineers. The developers write all the tests.
Is this your polite way of saying "don't be a puppet, use your brain"? 😂
Pretty much. Everything has trade-offs and what makes most sense depends on your context.
What about "you shouldn't test private methods"? I often want to test some private methods to make sure their individual bits work properly, but people at work tell me I should only test the encompassing public method
Not testing private methods is a value proposition. I think if you are feeling like you need to test a private method, there may be an issue with the design. Generally, a non-trivial private method should only be called within the context of a specific public method. Because that context should always be the same there is little value in putting in the effort to test it outside of that context. If you have sufficient tests for the public method then you will have sufficient tests for the private method. Any test written for the private method would be redundant. If you have a case of a non-trivial private method being used by multiple public methods, then either it likely should be extracted out into its own class, or it is a case of code that looks the same but really isn't because the public methods may want it to change in different ways in the future. There are always exceptions, but the exceptions should not be very common. So there may be times where you feel like a private method needs tested, but it shouldn't be often. If it is often you might need to rethink how you are doing things.
@@evancombs5159 Thanks for your reply, very interesting. I think I understand now 👍
Calling things "best practices" is definitely a pet peeve of mine. Usually people understand the nuance, but they still say "the best practice", as if there's just one best for everything.
Do whatever you want. If you're doing something weird, come up with a good excuse about the context and how everything is a tradeoff. You can always find a good excuse, rest assured. Or... just forget about that nonsense and apply the best practices. If you don't, then make it clear which rule you are breaking and why, by providing the tradeoff you had to compose with. Expose the pros and cons and make sure the decision is not based on laziness or just trying to be a smart ass. Everyone has an opinion - good or bad. Best practices are based on errors already made by others, so it's always good to fall into this trap yourself, then you learn. But most of the time, you often come back then to applying best practices.
Right. Best practice at one time was to write all data access logic in stored procedures.
@@CodeOpinion True! Best practices evolve, because they benefit from many experiences over time. One more great thing that our own judgement on things doesn't embed.
"It Depends" :)
Agreed
100% agree....amazon does it mentality
Coding book worms do my head in. Had one guy religious apply SRP in a project once, a maze of classes to derive the business logic. Literally a line per function in around 10 or so cases. It was crazy. It was a whole exercise to refactor and reduce around literally 50% of the classes this generated, it's crazy. Sometimes I don't know what's worse, a developer who doesn't care at all and writes sloppy code or one that cares too much and uses every pattern under the sun to overcomplicate something.
Sounds more like a lack of understanding SRP than a religious following of it. I try to follow it religiously, but it doesn't result in an absurd amount of classes or methods.
Too strict linter rules are also crap. Like must have blank lines before any block or between any variable declaration and a statement. Worst case they aren't enforced by the linter but are law and people don't look for anything else in pull requests...
I like these rules because of consistency and readability, but only if they can be enforced with automatic code formatting. Code style rules should be applied automatically without manual intervention. Manually formatting code is dumb in my opinion. Logic rules linting might require manual intervention, but depending on the tool and complexity some might also be auto fixed by the linter being used. I only have experience with ESLint (JavaScript) so I'm talking from that perspective.
@@rand0mtv660 We have eslint/tslint for frontend and multiple tools for c# in the backend. I agree, what cannot be enforced/automatically fixed is crap.
The biggest scam in software development is actually KZheadrs calling on well-established cultures to be scams to make themselves stand out for their own benefit. Some KZheadrs do that.😀
Sorry you feel that way. That's not the intent. Look at the rest of my channel/videos and see if you feel the same way.
"well-established cultures" doesn't mean they don't have to be challenged and questioned from time to time. If people didn't challenge previous "well established" practices, we wouldn't have all the advancements we do have.
At the end of the day, nobody cares how you write the code. What matters is that it can be modified easily without breaking things, it performs acceptable for the task at hand, and that it works correctly and that it is secure. That's all. There are a ton of ways to make this happen. Best practices might help you along the way, but they are often contradictory, and you need to know when to follow them, and when to ignore them.
It sounds like you're saying that in certain circumstances there are BETTER practices, which means there are still best practices, but they are contextual. So best practices exist, but they are not categorical imperatives. So categorical imperatives are the problem, not best practices, and people are confusing the two.
Absolutely contextual.
If put that way - what is the best practice?
@@viktorshinkevich3169 The questions about event sourcing seem to be an extension of the single responsibility principle, i think you have said before. So a Create should not return a new id, if i understand your other video properly. I think the issue is that as engineers we must always speak in the context of number ranges. So we must estimate required throughputs over time. We don't get to operate in the realm of "pure math" speaking in ranges of infinities. Whether a CQRS system, or logging or message queues (and please forgive me if i am using ill-fitting terms in this area of your expertise), requires application of single responsibility by not returning a new id is a question of long range planning, foreseeable scaling, and expected integrations balanced with the difficulty of upgrading later. In such a case, premature optimization should be avoided. So, in the template example, one or two bullet points could be put in the code comments estimating where the procedural code might need to be improved.
Today's Best Practice is Tomorrow's Legacy....
Thank you. If I hear another comment about SOLID or SRP, I'm going to lose it.
Best practices exist in accounting, engineering, and many other disciplines. Saying "best practices don't exist" is akin to saying "there is no possibility of a rational moral code and every judgement must be made up fresh on the spot". This is the theory of pragmatism, and it's incoherent because it invalidates itself if it's used as a principle. It's the principle that there are no principles. People tend to get to that point because they tried to apply best practices without regard to context, like using 1/x but forgetting to say "except where x=0"
As someone who inherited a very badly written code base that did not follow any "best practice" I can tell you they are not a scam. If you religiously follow without reason then of course you will shoot yourself in the foot but that's not what best practices are for and calling them a scam because some people are dogmatic over them is like calling seatbelts a scam because someone decides to hold their new TV with a seatbelt in the passenger seat for safety. They are practises not law.
OOP? DDD?
Haven't seen the full video but as soon as you called Best Practices a scam, I knew you were going down the clickbait route. As a junior dev, where coding practices need to be shaped, Best Practices help. As a senior dev entering a new programming language eco-system, Best Practices help. But once you've gained some mastery or have better opinions, then by all means, deviate and form your own Best Practices and starting spreading the word.
I disagree. So called "best practices" dull juniors, and it's a lot of work pulling them out of that mindset. Anything labeled best practice w/o context is outright harmful. This video wasn't click bait at all.
The best practices your being taught as a junior are from someone that deemed them be appropriate in... wait for it... your context. Those same "best practices" may or may not apply in another situation. You have to understand the trade-offs being made to understand that. Rather instead of being taught the "best practice" alone, it should be included what the trade-offs were, including alternatives, in the given context for that decision to be made.
@@CodeOpinion if they ask, the smart ones will, then we can go into the history of the Best Practice. But given time limitations, and not boring the person to death, just follow these Best Practices, and adapt to the environment that others before you have created before you take the reins.
@@FahadShafique You shouldn't follow practices that are innapropriate for your context just because some dev before you did so. It does nothing but make the problem worse. Nothing worse than devs that blindly follow others
@@hellsregect I question when needed. And if the junior dev asks, I answer as needed. But Best Practices, whether project specific, or language-ecosystem specific, are generally not "scams".
and my juniors watching videos like this and priding themselves they know better.... 4 portrait screens long per API route, nested 5+ deep scope with if-else, using, try-catch.... how's about you let them make their own decisions instead of trying to clout ride molly rocket? whats next? linters are bad?
I've read your comment a dozen times and I still don't understand it.
@@CodeOpinion i'm suppose to believe you never seen molly rocket's talk about why programs are slow? atleast he makes a valid point for breaking common standards, Speed and Measure. Whereas you're just making a vid just to tell ppl to use discretion. I'm pissed because i have to deal with someone's legacy code.
Yes, that's exactly what the video is. Use discretion. I'm glad I got the simple point across. 😂
Well, if a junior dev can justify his 5+ deep scope with if-else - why not?
@@viktorshinkevich3169 It's tightly coupled with multiple refs and what not. I couldn't care less what they wrote if my manager didnt assign me in the morning to fix their code before noon.