0

I recently joined a company where I was tasked with building a system for one of their clients. The work I've done is so far working well, but the most senior developer on the team who's been with the company for many years is having trouble understanding my code. He says it's hard to follow.

I tried conducting a training session for him and another developer where I explained the design patterns used in this program. The system is written in Ruby on Rails and I used a design pattern called the "Clean Architecture" to better modularize all the functionality. During my presentation, the senior developer scoffed at some of the concepts. He feels that the Clean Architecture introduces a lot of unnecessary complexity because it involves so many layers of abstraction and objects.

The developers on my team don't seem to unit test as thoroughly as I do, and don't see the need to learn a new conceptual framework. However, I've worked at other organizations running large applications that run into scalability problems when using the default problem solving approaches popular in Ruby on Rails. Seeing how those teams solved such problems and made their codebase more maintainable using SOLID and Clean Architecture is why I think it's a great way approach to the program I'm building at my current employer. None of my coworkers at this company had exposure to anything like that yet. Neither of them ever heard of SOLID.

My concern is that the other developers on my team will eventually push back on the design patterns I'm using and try to micromanage my work. Maybe I'm not great at articulating the advantages of the way I code - I just go by what I know works from past experiences. It is especially troubling to me that one of my coworkers finds my code to be "hard". What do you think is the best way of handling this situation?

closed as primarily opinion-based by gnat, Robert Harvey, Laiv, Greg Burghardt, Robbie Dee Nov 2 '18 at 15:27

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • How large is this company? Is the product you are working on likely to run into scaling issues like the one your prior products did? What is the typical experience level of programmers at this company? It is possible that your previous job needed more complex, scalable systems than your new company does, and trying to import all of these ideas as is to your new position is simply overkill and over-engineering. At the least, that is likely what your coworker thinks, and you will need to show your way of coding solves practical problems that your current company actually encounters. – Nathanael Nov 1 '18 at 19:43
  • 2
    Unfortunately, you have only three options here: 1) keep trying convincing them, might send them some webinars to believe that you are talking seriously. 2) you go their way. 3) just leave them and get rid of their insanity... Umm. May be you have a fourth option, just push the ass of that out-dated senior and lead the team your self! – IWIH Nov 1 '18 at 19:51
  • 6
    Do you have any concrete, actionable reasons or examples that demonstrate why SOLID and Clean Architecture actually produce better programs? My experience so far with SOLID and Clean principles is that they provide excellent guidance and have significant educational value, but on the whole, I find that (at least for inexperienced developers) they create more confusion than illumination. I'd much rather work with people who know what they are doing and have the capacity to create well-crafted programs than those who blindly follow SOLID without fully understanding it. – Robert Harvey Nov 1 '18 at 20:29
  • 3
    So if you're going to hang your hat on SOLID, you must be able to demonstrate how specifically SOLID principles will fix their Ruby on Rails woes. Personally, I have my doubts. More than one company has started out with Ruby on Rails and eventually ran into scaling issues. Their solution was not to bring in SOLID principles; it was to replace Ruby on Rails with some other technology that scales better. – Robert Harvey Nov 1 '18 at 20:35
  • @Nathanael The company is small - 3 other Ruby devs on our team. I'm not sure whether this program will hit scalability issues, but it's job is to do some complex data transformation and access multiple APIs. SOLID/Clean Architecture may seem like overkill now, but I'm anticipating this program to grow in complexity with new requirements as it has already. I think it's proving its value right now by working, which is better than using a less robust design which would later force admitting whoops there's a lot of technical debt to refactor. – Greenspud Coder Nov 2 '18 at 1:36
9

You know, this:

Convincing a development team to use a better design pattern

Is a fair bit different from this:

I recently joined a company where I was tasked with building a system for one of their clients. The work I've done is so far working well, but the most senior developer on the team who's been with the company for many years is having trouble understanding my code. He says it's hard to follow.

In your title you sound like you're one of those guys full of book learning, ideals, and little experience who blames every difficulty with the existing code base on the teams outdated ideas.

In your opening paragraph though you're working on a green field project and are only having trouble with a peer review.

These are wildly different situations. Old code bases will always be full of old ideas. When we make changes in them we tend to fall into their framework and perpetuate the old ideas. It's expensive not to. We work to modernize them but somehow something from the past always hangs on. They effect even the way we think.

However, you're working on a new project. No old code to tie you to the past. You're problem isn't convincing a team to use a better design pattern. It's convincing them that they can understand one you've used.

I tried conducting a training session for him and another developer where I explained the design patterns used in this program. The system is written in Ruby on Rails and I used a design pattern called the "Clean Architecture" to better modularize all the functionality. During my presentation, the senior developer scoffed at some of the concepts. He feels that the Clean Architecture introduces a lot of unnecessary complexity because it involves so many layers of abstraction and objects.

If what you're writing is a one-off he's right. Clean Architecture doesn't minimize complexity, abstraction, or object count. It minimizes the impact of change. That's only valuable once you move past one-off thinking to how this thing is maintained over time.

The developers on my team don't seem to unit test as thoroughly as I do, and don't see the need to learn a new conceptual framework. However, I've worked at other organizations running large applications that run into scalability problems when using the default problem solving approaches popular in Ruby on Rails. Seeing how those teams solved such problems and made their codebase more maintainable using SOLID and Clean Architecture is why I think it's a great way approach to the program I'm building at my current employer. None of my coworkers at this company had exposure to anything like that yet. Neither of them ever heard of SOLID.

That means what you're doing is nearly as bad as coming in and programming in a language none of them has ever heard of.

My concern is that the other developers on my team will eventually push back on the design patterns I'm using and try to micromanage my work. Maybe I'm not great at articulating the advantages of the way I code - I just go by what I know works from past experiences. It is especially troubling to me that one of my coworkers finds my code to be "hard". What do you think is the best way of handling this situation?

You're focused on the one guy who finds your code to be "hard". What about the others? Always be willing to accept the idea that, despite following Clean Architecture, your code might suck. You need someone, besides you, to tell you when it's understandable. Don't hide behind ideological differences. Only once you've gotten someone to admit they can understand your code should you push your ideological detractors.

The way to push them is to evangelize. Don't force them. Convince them. If you're not Uncle Bob don't try to be Uncle bob. Giving long winded, one way presentations is not how I'd go about it. Ask questions. Learn what they do believe in. What concerns they have. What problems keep cropping up. Be willing to admit Clean Architecture doesn't solve every problem. Show them what it does solve. Show them how you can react to unforeseen change. Get them interested. Then you can explain why you don't solve everything with one object.

  • I have been bad at selling this idea, but your last paragraph is helpful. Thanks. Maybe my code does suck, but despite the criticism the disagreeable dev hasn't given specific enough criticism to make adjustments. Maybe I need to emphasize more on how all the abstractions built allow for very granular unit testing. Prior to my arrival this team has done primarily one-off projects, so its understandable why clean architecture seems intimidating. As for the other team members they've been focused on other projects and haven't taken interest my code. – Greenspud Coder Nov 2 '18 at 13:21
  • 2
    Get as many eyes on your code as you can. It will fix problems and give you power. – candied_orange Nov 2 '18 at 15:35
  • Giving this answer the green checkmark because it points out the distinction in this case of persuading a team to change a design pattern in an existing project vs using a new design pattern in a brand new project. The message is very similar to Jimmy's answer in that more close collaboration may be needed to demonstrate the benefits to the team from bottom-up rather than to preach a new set of ambiguous high level concepts to them. – Greenspud Coder Nov 2 '18 at 16:36
17

This is probably more suitable for careers but joining a company and immediately telling them to change the way they do things is a really going to be tough. It's unlikely anyone is going to listen to you until you have proven yourself. And this is for good reason. What if you don't know what you are talking about? They know what they've done works. They don't know about you and your way.

What I would suggest is to immediately stop with trying to teach them. It strikes me as a little condescending and arrogant or at least that's how it's probably perceived. It's unlikely to get the results you want.

Instead, try asking them what they would do it differently. I would strongly recommend going along with what they suggest, at least initially. You might learn something and you build some trust. Start small with your ideas to improve things. Once you have some working systems under your belt and established rapport, you will have a better chance of having your ideas given consideration.

  • I get what you're saying and my reason for writing this post is that I'm concerned about coming across as arrogant in this situation but don't intend to. As far as doing things differently, my coworker believes in less abstractions. If I do that, I may not be able to unit test as thoroughly. When they brought me on they gave me full jurisdiction over this part of the system as it needed to be done and they didn't have the capacity, so I delivered a system that works great. Only problem is my design choices are a little mystic to the existing senior dev. – Greenspud Coder Nov 2 '18 at 2:06
  • 2
    @GreenspudCoder What I would do is take a piece of functionality that has tests and work with the senior on implementing them in a way that is acceptable. Then ask for help on how to make the tests work. Hopefully it's not a question of whether tests are worthwhile. Either there's a way to do it or you will demonstrate why you did it the way you did. I'll be frank though, some of the patterns that are commonly used to allow for ease of testing do, IMO, make the design overly complex. I think languages need to be improved to better support testing, personally. – JimmyJames Nov 2 '18 at 14:25
  • I agree with you there on testing limitations. Rails does so much behind the scenes that sometimes it's hard to mock simple test scenarios. I like abstractions because it breaks the system down to paths where you can test pure inputs and outputs without framework-specific setup. For example I wrapped all the calls to an API-related gem into a repository class, which allows better handling of the gem's inconsistencies in handling certain API error conditions. The other dev says I should just use this gem's methods directly, but that would mean you'd have to rescue Error in more places. – Greenspud Coder Nov 2 '18 at 14:47
  • 2
    @GreenspudCoder Even just saying something like "this layer makes things a little harder to follow but it solves problem X" can help to start building some trust. The main fear that I have when new developers start introducing things to the code that I'm not familiar with is that they don't really understand why they are doing this and that they just doing cargo cult stuff. It seems maybe that you explained what you were doing top down. Try coming at it from the bottom up too. – JimmyJames Nov 2 '18 at 15:03
  • As you suggest, more collaboration to get the other dev's input would probably be most effective. Maybe the design choices I made will seem more understandable when he's asked to suggest alternatives. My style is to lean on more complexity for more effective testing, but that can clash with someone who doesn't mind using big factories to set up relatively simple test cases, or chooses to write fewer unit tests overall. – Greenspud Coder Nov 2 '18 at 15:06
6

Your past experiences with other companies may indeed tell you what works to solve the kinds of problems that those companies experienced, but does the company you've joined suffer those same problems and if so, are they severe enough to warrant any big changes?

Some of the practices you mention are extremely valuable for some projects which happen to have a lot of complex, ever-evolving requirements, or suffer a lot of 'pain' for someone maintaining the code, but that doesn't mean those practices are appropriate in all scenarios.

It can often be the case that in software projects which, maybe even despite their size, may actually have requirements and components which are generally simple and stable enough that they don't really undergo enough significant changes in their lifetime for there to be any serious tangible benefits to putting in a lot of effort into maintainability.

For example, you could have a component in a system which by most peoples' judgement might be considered completely un-maintainable, full of wretched "code smells", and plain ugly to read; but if the component has been sat in its production environment working away happily with no problems and nobody has changed a single requirement for the system in years or raised anything more than the very rare/occasional defect, then who really cares how bad the code is?

Without drawing any conclusions about who is right or wrong, it sounds to me like you may not have been at the company for long enough yet to know what their real problems are.

If you want to convince someone to adopt your solution, then it needs to be predicated upon having first identified a specific real problem (e.g. pain points, things which are high-risk and frequently go wrong, or are unbearably difficult/time-consuming); then you can explain to them what the problem is, and try to engage them in a discussion about ways of solving it - the problem discussion really needs to happen before jumping to the solution however.

Keep in mind that there may be other solutions that your team would prefer instead of the one you're suggesting, or they may simply decide that the problem doesn't really exist or that it exists but it's severity and impact on the team is low, and not worth fixing.

Otherwise, (and without jumping to any conclusions - consider this more of a "devils advocate" position if you will..) if you can't identify a real tangible problem which is worth the fixing, then perhaps the solution you're suggesting isn't necessary.

  • I know it does sound like I've introduced a solution before a problem exists. As I mention in the posts above what's made me uncomfortable about the situation is that the rest of the team is very hands off on this part of the system I built, but yet there's criticism about the choices I made in getting there. Maybe this won't turn out to be a major point of conflict so long as I stay the only one working on this project. It's just that the criticism regarding my design choices is concerning to me because I don't want the rest of the team to get frustrated or resentful over it. – Greenspud Coder Nov 2 '18 at 2:15
  • But the conundrum is balancing the feelings of the other team members vs making design choices which I think are the best when given an assignment to work on independently. Nobody else suggested anything better so I went with what I think will work and so far we have a very good piece of software that I've been able to update quickly and upper management seems happy with the outcome. – Greenspud Coder Nov 2 '18 at 2:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.