I am working as a software engineer. I have colleagues that believe in a set of things: SOLID, TDD etc. These are a set of practices that are very commonly known as "best practices". I don't automatically adhere to those principle and I think that sometimes they are harmful in some way. When I talk about my disagreement, I fail to persuade anyone unfortunately even when I provide arguments. I think the main reason is that my communication is somewhat violent. It's like criticising someone's religion. It's inherently violent.

Is there any books, podcasts, whatever that could be helpful in such a situation? I prefer resources that expose conversations and comment them rather than bullet points of tips but I appreciate any suggestion.

PS: I have already read nonviolent communication by Rosenberg.

  • 3
    An honest question: is English your native language, and are these communications happening in English? Oct 10, 2021 at 12:09
  • 2
    No I am not a native english speaker and those communications are happening in french (my native language). Oct 10, 2021 at 13:09
  • 1
    Somewhat related
    – mustaccio
    Oct 10, 2021 at 14:08
  • 3
    Why do need to persuade them? Never mind you not agreeing with the "best practices" of your workplace, do you follow them? Not following different rules than everybody else will make you very difficult to work with.
    – Helena
    Oct 10, 2021 at 14:17
  • 3
    PS: What is actually your goal? Come across as a nice person, convince people not to do one specific aspect SOLID and TDD, get away with not following SOLID and TDD?
    – Helena
    Oct 10, 2021 at 15:38

4 Answers 4


Check out How to Win Friends and Influence People by Dale Carnegie. It's remained one of the most popular self help books for over 80 years--and with good reason.

Simply from the way you phrase your question, I can tell you're approaching this from completely the wrong angle. If people feel they're being attacked, you've already lost. Don't "provide arguments." Don't try to convince them you're right and they're wrong--you're all on the same and team working toward the same goal. Instead, ask questions and propose statements that they can agree to without feeling attacked. Lead them to the conclusion you want. (If your proposal is truly better than what they believe in, this shouldn't be all that difficult.) If they have a strong attachment to ABC, DEF, or even XYZ, don't make the conversation about these acronyms.

When they've reached the "correct" conclusion, let them think it was their idea. Again, the goal is not to win an argument but to influence behavior and the best way to do that is take our natural egoistic responses out of the equation. If you approach it from the perspective of winning an argument, you'll be met with resistance at every turn and even if you eventually win this particular argument, you still will have lost in the long term as they will come to resent you and the next time there's a disagreement, they will push back even harder.

  • 1
    this would've been my answer.
    – Tiger Guy
    Oct 11, 2021 at 18:50
  • "let them think it was their idea." - THIS Is the key. Every rancher knows that the secret to getting 100 animals that are all 6-10 times bigger than you are to do what you want is to get the animals to think it was their idea in the first place. Oct 19, 2021 at 16:38

You write of the standard way of doing things that "sometimes they are harmful in some way". You may well be right, but they are also extremely helpful in general. I'm getting hints that you might be looking for freedom to abandon SOLID and TDD completely on the grounds that they are "sometimes harmful". I doubt that the percentage of times SOLID is harmful rises as high as 10%, probably much less. Are you writing 90% of your code according to SOLID? If you made sure you always followed SOLID in the times it was preferable you would have more credibility when you wanted to not use it.

You also have to remember that a big part of writing good code is to make it understandable by the people who have to maintain it. That means that they see the kind of code they expect. It's why we have coding standards and patterns. If you use a different pattern from normal there has to be a *really * good reason for it - not just some minor potential benefit.

The other way to not come across as "violent" is to make sure you acknowledge the places where other people are right. Make it clear to them that you do think that SOLID works in 95% of cases. Write code like you think that. If you get in a debate make sure it is about one of the 5% of cases where it is questionable.

EDIT: If you believe you have a decomposition method that is superior to what is currently being used (remembering that SOLID is not itself a demposition, just a set of rules of thumb for evaluating decompositions) then I would suggest asking if you can present this methodology to your colleagues. Be prepared for bringing about change to take a long time. People are understandably reluctant to replace a known working system with an unknown one unless they are presented very convincing evidence, usually over a long time.

  • Sorry, I don't think that SOLID is 90% useful. Take a look at "The philosophy of software design" book, you may change your mind. Oct 10, 2021 at 20:35
  • 1
    If you think SOLID is generally wrong then you have an uphill battle. Even Ousterhout has come up with a better system that doesn't make SOLID wrong. It's been used very successfully for decades, and people aren't going to abandon it without being presented with something convincingly and substantially superior. Sometimes "the best is the enemy of the good". Oct 10, 2021 at 23:39
  • Well, here's what Ousterhout says about R. Martin refactoring code into a set of functions doing each one thing: groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/… Oct 10, 2021 at 23:53
  • 1
    @PhilippeLafourcade Those links are not public for everyone to read.
    – David R
    Oct 11, 2021 at 13:55
  • 3
    @PhilippeLafourcade: The fact that you seem to reduce a conversation about how to approach your workplace interaction down to a concrete argumentation of why your opinion is right is a reasonable indicator of precisely what is going wrong in your workplace interactions. If you're eager to argue points when briefly touched upon and sidestep the actual conversational focus, this is going to rub people the wrong way. This answer's focus was not on establishing precisely how useful SOLID is, yet that is what you specifically responded to.
    – Flater
    Oct 11, 2021 at 15:14

Generally if you want to have productive conversations then you pick topics that people want to talk about.

If you already know that they don't want to discuss something and you don't want to antagonise them or have a confrontation then don't bring it up unless asked your position or opinion on a matter.


Convincing a team of seasoned developers who work well together to abandon core practices like SOLID is probably never going to happen, regardless of how you tailor you communication style. They've experienced tangible benefits, and any downsides your seeing are worth it to the team.

Taking your specific example, I think you're best chance at a compromise will be attempting a shift of how you define 'Single'.

While your team may expect a REPL to have classes similar to this:

  • CommandReader
  • CommandEvaluator
  • CommandPrinter

Each obviously only does one thing, but you can also just write a class similar to this:

  • REPLRunner

It's 'single' responsibility would be driving the Read-Evaluate-Print loop.

  • The second solution will be rejected. I tried but in the code review I am always asked to divide things :/ Oct 10, 2021 at 18:45
  • And what would be your reason for not dividing it? Oct 10, 2021 at 19:34
  • The reason is that by devising things up we ended up with lots and lots of classes each with its proper interface and abstraction. The complexity of the system increase, it becomes harder to understand, harder to maintain, less-performant etc. Oct 10, 2021 at 20:32
  • It becomes harder - for you - to understand. The contrary is true for the rest of the team. They see code that fits their mental map of how code should be and thus is easier to understand and maintain. My sense is that you don't fit this company and would be happier elsewhere - someplace where you are the main person having to maintain the same piece of code for several years.
    – David R
    Oct 11, 2021 at 14:00
  • I am aware that it become harder for me which is not the case for the others. At the same time, I am the one that is obliged to adhere to things I don't believe in ! It would be ok if my colleagues apply SOLID because they believe it's helpful and they let me NOT to apply it. It's not the case I am forced to adhere to those things. Oct 11, 2021 at 15:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .