current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite
1

I recently became lead developer of a project at my first non-internship programming position. I've been there for 8 months since I've graduated in December. The project is a web service we offer that is used to track inventory, provide reporting features, and other administration services. The project was originally created for a single client, but has started to become a general project that can be customized for each client. So as each new client signs on, we copy the code from the most recent project and start fresh again customizing the site for the new client.

The Customization can be fairly dramatic in some areas of the site, or in some cases very little customization is needed. The problem I see is when we make improvements to the core functionality of the site, that all clients would benefit from, we would have to copy this new feature into every client's site. This seems very cumbersome to me, even with my limited amount of experience and feel there has to be a better way. And to be honest, it usually isn't copied over at all. Same for bug fixes. They'll go client by client, fixing the same bugs as they go in each site. Right now we use Microsoft's Team Foundation Server as our code repository, so a new project for each client is created and added.

It may help to mention that it is a smaller company with about 40 employees. Of which 9 are programmer's. I feel like this could be a chance to prove my worth and figure out a better solution. If anyone here has had experience with a similar situation any input would be appreciated.

Update:
Some questions that have been asked that I have added in here.

Q. Describe what the application looks like. Is this a web application? Does the application on it's own look to have three (or more) tiers? Is the code a mess?

A. Yeah this is a web application that has a fairly extensive database, and is FDA regulated. It is used by Pharmaceutical companies to track pharmaceutical drug samples distributed by their representatives. The code isn't horrible, but it can definitely be improved. Which is something I have been trying to do. It was developed with ASP.Net and C#.

Q. Tell me about the database. Is there a common database that all instances of the application interact with?

A. No shared database, each client has their own database instance. When a new client signs on we take a copy of the most recent client's database to be used. The database is written in a fairly generic way. Some business logic needs to be tweaked depending on the client, but it usually isn't too extensive and doesn't require modifying table structures or anything like that.

And finally, most of the customization that has to be done involves business logic. We don't really change the UI per client or anything like that. Just acquire a copy of the Company's logo and smack it the default spot. Some of the more extensive changes had to do with the companies structure and involved the database/ BL. Most of the time though it is more minor changes.

share|improve this question

closed as unclear what you're asking by Jim G., gnat, Bart van Ingen Schenau, BЈовић, MichaelT Aug 5 '13 at 1:02

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
    
Describe what the application looks like. Is this a web application? Does the application on it's own look to have three (or more) tiers? Is the code a mess? –  Tombatron Aug 3 '13 at 19:02
    
Yeah this is a web application that has a fairly extensive database, and is FDA regulated. It is used by Pharmaceutical companies to track pharmaceutical drug samples distributed by their representatives. The code isn't horrible, but it can definitely be improved. Which is something I have been trying to do. It was developed with ASP.Net and C#. –  Singularity222 Aug 3 '13 at 19:11
    
Tell me about the database. Is there a common database that all instances of the application interact with? –  Tombatron Aug 3 '13 at 19:30
    
No shared database, each client has their own database instance. When a new client signs on we take a copy of the most recent client's database to be used. The database is written in a fairly generic way. Some business logic needs to be tweaked depending on the client, but it usually isn't too extensive and doesn't require modifying table structures or anything like that. –  Singularity222 Aug 3 '13 at 19:43
    
Have you thought about the option of a separate "branch" (whatever TFS calls this) per client instead of a separate project? –  Martin Ba Aug 3 '13 at 20:10

2 Answers 2

up vote 1 down vote

So I've been giving the overall question a bit of thought. I'm going to try and put myself in your shoes and go over what I might do "in a perfect world".

Core Application Logic

A common library of application logic that is shared across all client application instances needs to be designed and implemented.

Make no mistake this is a huge task, which will involve analysis of all client applications. At this point, if your application is using the App_Code folder for storing common classes and what not, that'll need to stop.

A good starting place for developing this common library is with the original version of the application. Since each instance of the application may have a varying degree of customization, this process may require a bit of iteration to get right. The end result here is a library the encompasses all of the common functionality shared across all instances of the application.

Custom Application Logic

In your question you mentioned that some client's application instances require extensive customization and some clients require very little customization at all. This where careful design of your common library will pay off. For clients that require any customization you'd simply inherit from and extend the common library.

Base Site Layout

You'll need to isolate the basic templates (or master pages) for your application and scrub them to look as generic as possible.

The process of extracting a base site layout will be similar to creating the common library.

Here are some things to consider when working on this:

  • All page styling handled in an external style sheet.
  • Commonly customized template functionality is isolated in partial templates.
  • JavaScript should also be isolated away from the templates (no inline scripting). This will allow for fixing and extending JavaScript on all instances of the application.

Custom Site Layout

Doing a custom layout for a client could be as simple as adding a few images and a custom style sheet.

Database

Instead of continually copying the latest copy of the database for use by the next client, you'll need to consider scripting the creation of all of the database objects and seed data into a base script.

This will serve to allow you to easily track differences between different clients versions of the application database.

Source Control

Team Foundation Server allows you to create branches, you should use this to your advantage.

Once you have a base application isolated that will serve as your application Main repository, and each client's version of the application would have a branch off of Main. This will allow you to easily pull a bug fix in the Main repository into all of the different custom branches.

Another benefit to this source control strategy will be that it will allow you to easily identify the differences between the different implementations of the application.

share|improve this answer
    
One that I have done is added a SQL Server Data Tools project. So the project contains scripts for all the database structures and when the site is deployed to QA or Production, the scripts are run on the target database and everything is updated. Before they would use a tool like Red Gate SQL Compare and do it manually. If you are familiar with SSDT, you can create a post deployment script that will create the database structures and insert seed data. So when I have time I have been identifying all the seed data and creating some merge statements to be run. –  Singularity222 Aug 4 '13 at 21:11
    
I'll respond to more of what you proposed when I have a little more time. But thank you for your response. –  Singularity222 Aug 4 '13 at 21:12
    
@Singularity222 Awesome, based on your feedback I'll refine my suggestions. –  Tombatron Aug 4 '13 at 21:16
up vote 0 down vote

You should definitely start moving common code to separate projects and compile it with separate dll's. To follow the DRY principle is in the blood if a true it-developer.

Though, you need to "sell" this idea to the team. I think it can be easily done by referring to the subversion system. Tell them to imagine, what they will do if there is no TFS or other subversion system invented. After that, tell them that you now use pretty same "inventing wheel" approach, besides, your wheel seems to be squared and hard to work with.

EDITED:

Codewise, you should separate it in separate projects, but allow to extend classes in inherited code (by actually inheriting from base classes, handling events of base class, assigning own strategies to the base class, etc).

share|improve this answer

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