Where I work we have around 10 VS projects in a solution which are identical in functionality (with some different different rules in a few methods) and share many exact methods. They share the same namespace and the classes are called with if else's individually.

I believe it would be better and more succinct to have an interface and an abstract class with protected methods which are common among all the children.

The methods which take one of these classes can then take an Interface rather than have 10 different methods which take one and run the same method on each class.

The public methods all have the same signature and return the same thing.

Future implementations of the class will have a clear guideline on how to implement it (other than copy pasting and editing a previous version) and it is more maintainable. The reason I am considering this is because I am adding an extra version and unhappy with the idea of copying and pasting a lot of mess and changing all the bits I need to change (just in 2-3 long methods of ~20 methods)

I am having difficulty expressing my reasons to why I should be allowed to make these changes (would probably not take more than a day and changes no logic so minimal testing is required). I know intuitively it is better but that is not good enough!

How do I explain to the lead dev when DRY is a good thing? Or is he right that we should just keep copy and pasting things because we "inherited the code this way"?

  • 3
    "How to convince X?" is usually not a great question, since part of it requires knowing the person and their motivations which we obviously don't. What we can answer is when DRY is a good thing and why it is a good thing (so I'd suggest editing your question to focus on that). The short version: if I have to change this piece of code, either I change it in just one place for all apps, or I have to change it in 10 places, which means a good chance I either break one of them or miss one of them, or even if I get it right it still takes ten times as long. – Ixrec Jan 18 '16 at 0:19
  • 1
    If the project is in product and working, don't touch it. Otherwise, provide a simple example showing the real (not the theoretical) benefit of making your change. Change only when there is a real need for the change. This is my opinion. – NoChance Jan 18 '16 at 1:03
  • 1
    You've got two problems. The first one is the repetition of code. The second persuading your co-workers to change. The first problem is the easiest to fix, and as other posters have suggested, I can't see any reason why you can't just start making these changes. It'll take time but when people see what you've done and the start you've made it then they'll come round. At the moment it seems there is very understandable tendency for people to say 'if it ain't broke don't fix it.' – Daniel Hollinrake Jan 18 '16 at 9:13

DRY is one of my favorite principles, and I often have a similar issue to yours. How do I convince my co-workers (who are often very opinionated) that the way the code is now could be improved?

In my personal experience, if it means a lot to me I "just do it" on my own time in a branch. When I'm happy with it, I bring it up with my colleague and show him what I mean rather than just talk about it. My coworkers often don't like talking about doing things because "doing it is too much work". If I show them something that's already done then they take to it a little more kindly :).

This question also looks close to yours, so it is probably worth reading.

| improve this answer | |
  • 1
    +1, most people who talk about something mean "you do it, now I've done all the hard work of thinking about it". Doing it first means your serious about it, and not a manager (or worse, an "ideas man") – gbjbaanb Jan 18 '16 at 8:50

It sounds like you're using inheritance to share behavior between classes. You should favor 'object composition' over 'class inheritance'. This is not cut and dry and context matters, but you should give thought to whether you need your abstract class.

As far as the interface goes, it sounds like a good idea, branching often is a sign that code could be better designed. I would however do this as Boy Scout refactoring. Basically, leave the code tidier than you found it, but keep refactoring within the context of the task that led you to that code. Next time you visit that branching method maybe create an interface, do some trivial renaming and send it to your colleagues for code review. Your change and it's justifications will be a lot more concrete at that point.

Don't try and fix the world at once and don't try to set the standard for "Future implementations" all at once. Improvement should be be in small bites, yet continuous.

| improve this answer | |

Start by telling (reminding) that cost to maintain software is exponential with its size (source this book).

Then your arguments look solid. Avoid clashing with their resist to change (because it's most likely just that) and gently guide them to a DRY version.

| improve this answer | |
  • +1. you also find a description here: en.m.wikipedia.org/wiki/Don%27t_repeat_yourself from where you may take your own conclusions. In general: double code, double work, double costs. Also, risk to forget to do Bugfixes in every copy, can reach from unhappy customer to angry customer to penalty charge to "used to be a customer". Even worse if you don't know the numbers and places of copies of faulty code. – Tobias Knauss Jan 18 '16 at 16:13

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