I Was Wrong About Single Responsibility Principle | Prime Reacts

Prototyping helps me make a bunch of mistakes up-front, which sometimes can help me understand how to optimize what I'm creating. If everything I'm writing against is well documented, I may not need the prototype, but that may not always be the case.. I do agree that a lot of projects and companies ignore their technical debt until it's too late though, that's a fact!

Can't agree more that you need those thousands failures. I had couple of great teachers which knew all the software architecture concepts and explained them like they've created them. But one day they've decided to start coding. And boy it took long time for them to apply their knowledge

Per Wikipedia Robert Martin went on to rephrase SRP with a much clearer (and arguably quite different) meaning:
"Gather together the things that change for the same reasons. Separate those things that change for different reasons."

I like this. It's a good answer to DRY. For example if you are building an API for finance to view your sales, and an API for data analytics to view your sales, it is tempting to have them be the same API because at a small scale the difference between the two use cases are trivial to paper over.

But at some point finance will start talking about bounced payments and fiscal years, and analytics will start talking about correlation IDs and shopping carts, and that's gonna lead to a sad time where you'll wish you'd duplicated most of that code from the jump.

well I disagree with you disagreeing

Where can I watch VODs from this live streams?

Dreamt you were baby sitting my sister. And you refused to acknowledge your online presence.v strange.

"There should be only one reason to change it" is better understood as there being only a single person or role within the organization who would be responsible for a decision to change the class. For example, if the class is an implementation of a business process defined by the org's director of finance, then only a decision by the DoF to change that business process should result in a change to the class. This is related to Conway's Law (no relation to the Game of Life) -- "Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations."

"Get a working copy then refine it"
I´ve worked on too many such projects, the truth is that they never get refined.

this is a very abstute comment

Hi! I wrote the article you're reading 👋🏻. Very interesting analysis, I think you're correct that a lot of software engineering knowledge is tacit and is gained by individual experience, but I don't necessarily think that that's the only way to do it. For example, Pete McBreen in Software Craftsmanship suggested a guild-like model where apprentices learn from masters; the point of that approach is that the master chooses the tasks for the apprenticeship that model all of the learning points.

“Uncle Bob, this is Enrique”

Why is it like most of the comments came from people who didn't watch the video? They're talking about the first part of the video, that says the misconceptions about SRP and not the second part of the video that untangles it

Excessive optimization is going to lead down a rabbit hole, I have seen it too many times. Often, also what one thinks is fast is actually slower than the simpler option because of cache and branch predictions.

Do you think Unreal Engine would have even existed today if the first thing they did was Nanite. No, that was incrementally built, and with the rest of the engine done, it was easy to test it against the old version.

I think you are talking about premature pessimization. These are things you know are going to be slow, and it's near zero effort to use the faster version so do those things. Premature optimization is more about optimizing something you don't either know will be slow, you don't know if you will need to feature, its going to take multiple times the effort or maybe in the grand scheme it does not matter. Read Herb Sutter's C++ coding standards book on that.

Also, I am a game dev. Optimized many projects and seen a ton of premature optimization in my time sucking up project time and then been thrown away.

My favorite programming paradigm is where I can create what I imagine.

After reading the SRP article on Wikipedia, my conclusion is the term is ill defined. Apparently everyone misunderstood the original definition and the clarification didn’t help matters any.

So SRP is a corollary of Conway’s Law?

In other words, should is a different word from must.

My rule is, "don't follow a rule that you don't agree with". If you don't agree with the rule, then either: 1) it's a stupid rule; 2) you don't understand the rule; or 3) you don't understand what following the rule is supposed to accomplish. SRP was never supposed to be about having only a single "change point". When they saw this, they should have thought, "Do I agree that a module should only have a single change point? I need to be convinced before I do this." But now we're at a point where new programmers are just blindly following (and misunderstanding) the advice of previous generations of programmers instead of reasoning from first principles.

The problem with software "engineering" is everyone thinks their farts smell like roses and everyone else's farts smell like gut rot. Design never gets better than my opinion vs your opinion. Nobody is correct and everyone is correct. It's an endless circle of nitpicking other people's nitpicks.

Honest question: do most codebases have any sort of documentation with some sort of scale of "don't fuck with this unless you really need to" in there?
Like so if you were going to maintain a dependency of some sort, you would see where it is on the scale relative to downstream and upstream packages, and make an informed decision about whether maintaining that dependency is better than rewriting (or copying over with bug fixes and/or new features, and using that for your new dependeency chain?

People need to stop wasting their time trying to decipher the prophecies of Uncle Fraud.

You call it brain rot, we call it: "no ... u"

Isn't the concern about upfront performance considerations the worry that you'll be locked into architectural structures that will never be sufficiently performant? Conceptually, I try to consider that, but don't initially worry about performance in the lower level small details that can be relatively easily changed... for those I'm all in on
Make it work; Make it pretty; Make it fast
(I'd add don't even try to make it fast at these lower levels until it's established that you need to... pretty is more important until it's proven that faster is necessary.)

I try to think about big picture inflexible performance at the start, but mostly ignore performance in the details, provided those are details where you could relatively easily swap out doing it another way. At that level, it's often fairly straightforward to go from clean to performant if necessary. But the converse in my experience is not true... if you try to write the smaller non-architectural details as performant from the start, then it's going to be ugly and inflexible, and almost certainly will remain ugly and inflexible forever, and thus forever will be harder to understand and maintain. And very likely, that choice wasn't even necessary! There's a reason no one codes in assembly unless it's absolutely necessary. In other words, for these smaller bits, my view is that you don't want to make a mess in the name of optimization until it's demonstrated that necessity demands that you accept a mess in the name of optimization.

Pretty is more important than blazing performance "in general" (programmer salaries are the main cost of software dev),
and pretty to perfomant is a one-way street.

The problem is people are dumb.
Most people are dumb.
If fact, you could say about half of the people out there are below average intelligence.
Its not a high average, either.

I believe we've been trying to idiot-ify development for ages.

I agree readable is often a good thing.

Buuuuut, hot take here:
I wrote a system for pagination with filtering in PHP and the code wasn't nice to look at. It even used goto at one part, but it did well, and as fast as PHP basically could given the framework (Falcon) and SQL layer provided.

It got merged but much gritting of teeth was done, and Devs said it wasn't all that readable or extensible.

The devs who merged it clearly didn't quite understand some of the stuff I did but it worked.

Anyway go forwards a few months, we got this new dev in, he picked it up and extended it within his first sprint there. Bam, no problems whatsoever, it just took a dev worth his salt and someone who could reason code.

I've been thinking: is software engineering all about trauma handling and self-help, because everyone seems to tweet and write blog posts that are aiming to be insightful life-coaching (or ranting about social aspects) or perhaps philosophical paths. It feels fundamentally different to any other engineering to me (or I haven't been exposed to this side of other engineering fields).

I completely 100% disagree on "we can't teach people, they just need experience"

Software engineering is not some completely unique special field separate from every other one where you can only learn through experience.

Just like EVERY OTHER job and field in the world, good software engineering can be taught. Sure, you need experience as well because you can never be good with just studying, but to say that bad software engineering teaching "can't be fixed because people just need experience" is categorically false.

I feel like loosely coupled code is way better at explaining how you should approach single responsibility. It shouldnt be over engineering just so you dont have to make a change in 2 places either.

Down with OOP and tunnel digging pedogogues

Excel :'D Heheh. _ Minus 25 years..._

... back in 1999, when net was not yet "human right" and we had FLOPPYS etc, "as nonmillionaire" kiddo, i wrote fantastic static megaweb builder in Excel :D (Config, component instance data, content page data, image metainfo, TABLES, TABLES WERE AWSOME etc).

Javascript to handle huge ultrafast ultra nice expandable menus. Everything was a component. {x:table=table_blaah_id} {x:image=id|popup|right|theme=blaah|etc}). Fantasic. Awsome in-excel tools to manage it all.

I had few sites with 10000+ pages. You guise know how fast one can enter data into excel? ULTRAFAST. Export to disk was almost INSTANTANEOUS (second or two). gzip and upload.

486DX100MHz 8MB RAM with 480MB Conner took the that fast penetration like professional ho. :)

A bit later a discovered that I also reinvented the wheel i mean MVC or smth. :'D The stuff curious kids can do. Insane. PS! I should rewrite it and spice it up with JQuery. Dont beat me. :D

There are no impossible things - just incapable minds or lack of money! ;) VBS thought me how to transmute pain to gain through pain.
--
PS! DONT TAKE THE CHICKS-CHICKS-CHICKS-DJABBELJUICE! (You will be here forever. Lissin, Linda. It´s a long time.) IF ONE DAY YOU FIND, YOU ARE DÖD, DO NOT REINCARNATE! NO SUBBMISSION TO GUILT TRIPPING! DO NOT TRUST PPL UPTHERE WHO MAY LOOK SOMEONE YOU KNOW OR LOOK LIKE JEEBUS! GO TO THE VOID! THIS PLACE IS A TRAP! IM DÖD SERIOUS. :|

Can you please increase the volumne of your voice in the future videos?

This scares me. I see a lot of comments saying engineers with opinions exist. This is very dubious. Engineering is about identifying a problem without opinionation in a systemic/predictable way where every step produces the means to relate part of the solution to a problem, and then apply the smallest solution that solves the problem.

Developers who don't apply engineering principles do the work based on opinion. And as quality assurance lead with 10 years of multi diplinary language experience, those people cause me the most work and consistently too.

If you can't do your work without opinion, you're not engineering. If you disagree, please elaborate how. I'm very open to be shown different perspectives.

totally unrelated, but you should definitely watch this video, is great, by the guy of “this is my favorite linux command”

I Spread Dangerous Misinformation (Apology Video)

SRP in software is like building a house where every room is only responsible for one thing : one room for sleeping, one room for storing clothes, one room for eating, one room for watching tv, one room for storing food, one room for storing drinks, one room for storing dishes, one room for washing dishes, etc. A good idea in theory, but often it makes sense to merge things together.

a lot of the wisdom from old se heads comes from careers working in large corps where you had to manage org complexity as much as software complexity esp w/ change management pre-standardized source control.. its worth understanding but good chance it doesnt apply anymore we have different paradigms now

"Build a working copy, then refine" -- no. Prototype a working copy, then scrap it and build it right is great.

I think the fundamental disagreement about the work/pretty/fast thing is that you shouldn't commit your code after the "work" stage, only after the "fast" stage.

In my day the hot take was 'everything singletons' and you'll be ok.

SRP is responsible "to", not responsible "for".

This guy here.... he wants one input and multiplex outputs. You have to take it with a grain of salt, otherwise you walk into oop land without realizing. I wouldn't get hung up on it without a concrete example that frustrates him. SRP wasn't created for higher level, like oop or microservices. It wasn't envisioned like that, as if there were ancient prophets that knew what was coming. It was about the smallest unit.

I understand single responsibility as a way to reduce context overload. Having to keep a lot of context in head is the devil. My little brain starts to leak when I write more than 20 lines of code, so I write simple classes and functions that know little and do little, then compose them to do a little more.

It’s all arbitrary. That’s what people in software refuse to accept. It justifies their shitty behaviour towards others, so they will never accept.

No one can explain SRP because it is unexplainable. IMO, SRP and SOLID were invented as rationalisations after we all witnessed OO failing to deliver on any of its promises. I state this with confidence because I drank the Kool-Aid for so long and was a guilty party along with the high priests of OO selling its snake oil.

SRP is complete when any programer read the code say "this is funny".

As a tech artist working with performance optimization for games, the pitfalls of "make it work, make it pretty, make it fast" is something I am constantly on about.

I remember working on a java thick client and there was more effort around if it was 'real mvc' than solving the users problem. Don't lose sight of the actual goal.

"Make it work, Make it pretty, make it fast" is how you keep your job and grow your business. On the top of my head I have not heard of a single successful company that has succeeded by optimising first. The mantra applies in all fields of engineering. The first cars were ugly and slow, but they worked.

I'm with you on the line of prime. That being said, I also prefer building infrastructure. Lower level things will be built upon to the point where every behavior will be depended upon. In that case, if you don't design with performance in mind, you'll never reach the optimum.

On the other hand, Theo is more interested in getting products in front of users, all else be damned. Especially in a startup where the future is uncertain, that makes a lot of sense. The rewrite will suck, and you'll certainly pay for the mistakes later, but having revenue is the thing being optimized for