3

The problem

C# project consisting of WCF services used by a Flex application.

A customer may request a functionality change that requires me to alter code to work just for them. It could be a single line of code in a method or maybe a method acts in a totally different way for customer x.

My Ideas

  1. Use branches for customers that have a customization. When a release is ready, merge to customer branches and try not to break / forget what their customization was for. We use SVN. I'm not a huge fan of this as the code base is very large.

  2. Use inversion of control, dependency injection, and MEF. Create an interface for the class/s that needs to be modified. Create a new class library project (that is, customerabc), add a new class that implements the class just created, override method/s as needed for customer changes. Add a MEF export. I then place this in a customization folder and point MEF there. If it finds a DLL file in the folder, it uses that instead of the export from the executing assembly.

I like option 2.

Pros :

  1. Easy - normal deployment install, then drop in their DLL file.
  2. Obvious - it might not be overly clear wether or not a customer is running code from their branch. With this option I could just look at the customization folder.
  3. Clean - only the files that need to be customized exist. There isn't any need for a full copy of trunk. d. It promotes better SOLID for future development and refactoring (this project has little OOP).

Cons:

  1. It will be harder to manage changes in trunk out to the customer projects.
  2. It doesn't necessarily solve my problem with database changes or changes on the Flex side.
  3. If the change is a single line of code in a 500 line method, I don't see any other option than to override that method, copy paste the code to the customer override and make the one line change. This isn't good use of DRY to me, but is there a good way around this?
  4. OK, so better use of OOP and SOLID principles could mitigate some of this, but it also means that to implement a simple customer request, I have to do some major refactoring to the whole class... potentially many classes.

What should I do?

  • Are there plans on expanding the number of customers with customizations? – JeffO Jan 21 '14 at 22:45
  • Yes. I expect there could be a dozen or more to manage. – Paul Wade Jan 24 '14 at 16:47
  • Any chance this question could help: programmers.stackexchange.com/questions/130741/… – JeffO Jan 24 '14 at 22:12
  • Not really unfortunately, thanks though. – Paul Wade Feb 28 '14 at 2:15
4

Option #1 is reasonable, but it represents a big hassle.

Option #2 should be the dictionary definition of overengineering.

Option #3: consider this:

Instead of multiple disjoint sets of requirements, (one for each client,) suppose that you have a single set of requirements, covering all customers, with the additional requirement that any given installation of your application should cater to a single customer, which is specified in configuration.

True, this means that specific customer concerns will be scattered throughout the codebase, and that every customer will be receiving inactive features, possibly even unused database tables and columns, but do they need to know? And if they do need to know, do they care? Do they mind? Would they please mind their own business and let you do your job in whatever way is more productive for you?

My car engine has some hooks on it. I have no use for these hooks, but they are there because they made it much easier to install the engine in the factory, and much safer for the workers there, so the presence of these hooks has actually lowered the end price that I paid for my car. So, I am perfectly fine with these otherwise useless hooks.

  • 1
    I do exactly this way (option #3). I've many parameters in a database table, specifying if in that form that button is visible or not, if this column is present or not, if the algorithm used in that part of the code is A or B or C... Maybe some parameters are related (you can check easily for possible inconsistencies before committing their new value) but it doesn't really metters. Every time a client ask me "can I have this?" I create a new parameter (or little set of parameters) to describe the addition/customization. So I can activate easily for someone else or remove for something better. – Fil Jan 21 '16 at 14:29
  • we are basically talking about a feature toggle for #3? I agree this seems to be the best way. I would think this could get tricky for QA though. turning on and off any combination of features. – Paul Wade Jan 22 '16 at 22:54
  • 1
    Yes, I was essentially talking about a feature toggle. But each set of feature toggle states is controlled by the "current customer", so the QA only has to test for each different customer. Which they would have to do anyway, under any option that you might consider. – Mike Nakis Jan 23 '16 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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