Manager: This code you wrote violates the single responsibility principle!!

Dev: How so?

Manager: You have one function that you call in *MULTIPLE* places. That’s too much responsibility for one function! Functions should only have one responsibility!! Creeping the scope of a function beyond that is a TERRIBLE way to write code!

Dev: But why spin up multiple functions that all perform the same thing?

Manager: Well if a function has a bug in it and you use that function multiple places then that bug exists everywhere you use that function. If a function only has one responsibility then if it has a bug that bug will only exist in the single place it is called! You really should think first before asking questions like that.

Dev: …

What. This is literally the opposite of single responsibility principle...

a functions responsibility isn't measured by the source of the call, but by the actions it performs on the system

that's like saying that because 5 managers want you to implement Feature F in project P you have more responsibility as if they all asked 1 different person... You don't really, you're doing one and the same thing and it's gonna be done when it's done...

Now if even 1 Manager asks you to do 5 things, then that's higher responsibility, as you're not responsible for 5 things...

the whole idea of single resp principle is to create functions that do exactly one thing, and do it well.

Don't have your "getUser()" function also log last login time or whatever.

And you most definitely don't want 5 functions doing the same thing. That's the exact opposite of what you want in a codebase.

@domfoo sadly I know "seniors" too like that.

Don't understand object oriented programming, still thinks GOTO is a thing, brag about how he knows COBOL and that COBOL is the best.

How very DRY of your manager.

I suggest you hide the problem by wrapping that function in a dpendency library, and use that instead!

How can this be? People are really this stupid?

Edit: I take it back. I had a manager interpret a company rule is an asinine way like this once.

@lambda123 I disagree. OOP is great as long as you're not an idiot with it.

I take a hybrid approach to it. Classes are single responsibly, and usually describe important contexts within the application.

Once I have a context, libraries are developed that help maintain those classes either as stand-alone or in a symbiotic relationship.

These are the shared libraries that are the core of why the app exists, the classes are only used to manage state and i/o at that point.

Ruby on rails has a fantastic ecosystem that proves this system works, I only wish more OOP langues/frameworks would leverage their own spin on it.

@domfoo I wish. He reneged on his position on this after I refactored the PR to create a separate function definition for each call for the diff in question and he said it wasn’t very DRY. After I pointed to his comment on the PR that was what prompted me to do this he got offended and wouldn’t talk to me the rest of the day and I reverted the commit and moved onto another ticket.

This doesn't sound real... is it?

@lambda123 I am not sure this is that

I think either your boss has no idea of OOP or you didn't understand him.

From a textbook point of view:

There is a justifiable reason to have the same code written twice if they are used by different stakeholders and have different reasons for change, it is possible that they look the same at that moment in time but since the reason they exist is different they just look the same. This follows the single responsibility idea which talks about code with different reasons for change should not be shared.

This is something I would do in an application layer rather than domain as domain is a single source of truth and consistency.

I might choose not to follow this if the functionality is well understood and very specific.

@lambda123

It's more important to deeply understand the pros AND cons, than to follow the rules blindly.

For example, there are cases where SRP works for you, and there are cases where it works against you. Same for DRY.

Both duplications and abstractions have their costs, and there's some tension between various "clean code" wisdoms.

The most difficult case is that of "multiple personas" -- An takeout delivery app has restaurants, delivery drivers and customers -- Where processes can have overlapping requirements, but still come with differences. Would you build 3 invoicing services, or 1?

Anyway, there's:

Devs who don't understand rules/paradigms, and just hack things together until the tech debt kills the company

Devs who interpret rules randomly for their own arguments.

Devs who have read all the architecture bibles, and are extremely pedantic about it blindly applying it.

They're all horrible to work with.

@lambda123

It seems weird for an exact science, but I try to follow my intuition more these days.

How will I feel about this code in 2 years?

Is my code written in such a way that I could trust another developer to make a change and not introduce a bug? Could a junior understand this code on their first day?

Answering questions like that usually leads to clean, DRY, SRP, composition-over-inheritance, modular, domain driven (<fill in more architectural hypewords>, etc) code.

Not by being absolute about rules, but by following your gut.

+++ New NFTs from Bored Ape Yacht Club founders led to Ethereum gas prices touching the moon +++ Manager knowing nothing about coding discovered +++ Rice bag fallen over near Yancheng +++ Zero day remote code execution found in Cisco security appliance +++ Bronze League hero walls off against terran +++

@lambda123

As a developer who wrote Haskell for his career for ~5 years, I fully agree.

OOP purism is overrated.
Although, FP purism is overrated as well.

In most cases, pragmatism is the best paradigm.

@lambda123 the argument that OOP is always shit hits home a bit because most devs are shit. It's not surprising that a group of people that are too lazy to pick up a book but will spend weeks poking and prodding their code until it "works" are unable to progress and understand the concepts which can be confusing and sometimes seem contradictory (DRY vs SR). I have yet to see a good OOP code base in the production tbh. Which is frustrating to me.

Are FP code bases mostly good in the wild? I don't have experience but I would guess they're just as shit as everything else.

@lambda123 I think huge inheritance trees makes for incredibly hard time to work on a new project. And for some reason people do that.

@Hazarth it is not literally the opposite of the single responsibility principle. But it is the dumbest interpretation I've ever heard, don't think anyone here doesn't know that.
The opposite would be to cram everything in a single function have a huge list of parameters to switch the outcome.

@boombodies what the hell is wrong with this excuse of a manager? If they keep on doing stupid shit, then that's it!

When time's right, send them this thread, where we publicly harass their passive ass decision. Being called out like this will be just desserts for them.

@Grumm did that guy spoke Classic Greek or Sanskrit in college? or maybe Sumerian? Old-ass languages had their time. and were replaced for a reason.

This manager is breaking the single responsibility principle. His/her job is to make sure people under him/her have everything they need to function properly...

@JsonBoa He had probably Latin.

It is just frustrating to see people like him in action as he claims to be 'IT responsible'.

Then you end up like @boombodies...

@hjk101 True, your example is the correct opposite :D I got carried away

Yeah no, I know people know, I just explained it because OPs original post didn't show any opposition towards the manager. So I just explained it for the sake of any newbies that might read the rant for info

i hope your next response was "firstly, that's absolutely not what the single responsibility principle means. secondly, your rationale is absolutely stupid. thirdly, keep to what you understand, if such a thing even exists."

You always have the option to not fix.. you may get into a heated conversation, but that is what retro is for. I suggest you bring the pr up in retro, and discus this together with the team. That way everyone can speak up and correct your senior who is obviously thinking about single responsibility wrong.

For fucks sake, LEAVE!

I wonder if these people are for real. I sounds to me that they're bitter and checking out how much stupidity they can muster before getting caught.

This is the Contained Resource Availability Pattern (CRAP) - "Every single resource must be used the minimum amount of times, if possible just once".

It's a mash up of "Curly's Law" with "Single Responsibility", mixed with a twisted version of "Don't Repeat Yourself", and a fucked up sprinkle of "Keep It Simple Stupid".