Convincing a development team to use a better design pattern [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Improve this question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.