Looking for advice in managing code in related applications (long)
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
I seriously worked at a company that had the same issues, with 6 clients. We brought our concerns to the biggest of them to help come up with a solution. They bought the other five companies (they were all competitors) and us. Needless to say, we merged the codebase. ;) Sorry this doesn't help much, but it was as though I was reading a part of my history there...
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
Just a thought, I have never done this myself, but have you considered macros and/or include files? You may be able to create separate libraries for each customer, using your common source. Then they could not "access" whatever you did not want them to see because it is not even in their library. Dave.
-
Just a thought, I have never done this myself, but have you considered macros and/or include files? You may be able to create separate libraries for each customer, using your common source. Then they could not "access" whatever you did not want them to see because it is not even in their library. Dave.
If functionality exists in the project but you use flags to exclude it based on the release settings, that could work (much like debug vs prod).
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
I have done this in the past by having the core code into a base project or projects and custom code in the customer central project. I then use the primary project to dynamically load the dll's for the customer centeric project so the main application is driven from the core code. If two clients request two identical features the core code gets moved to the core application and the customer centric portion gets placed into the customer centric project. This helps to prevent divergence of the code base. For each customer, you deploy the base code and the customer centric dll's. Everyone is happy and it works well, albeit it can be tough to debug at times.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
I seriously worked at a company that had the same issues, with 6 clients. We brought our concerns to the biggest of them to help come up with a solution. They bought the other five companies (they were all competitors) and us. Needless to say, we merged the codebase. ;) Sorry this doesn't help much, but it was as though I was reading a part of my history there...
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
Since 1991, I have used a data profiling/historian product from OSISoft. When the application was used on an OpenVMS system, each site was given a build specific to them, and, there was a 'build manager' responsible for adding the products each client licensed. When they moved to a Windows NT environment, all customers were given the base application, but subsequent pieces were licensed individually. So... my 'vision' would be: modularize as much as possible each 'version'/'client site' gets an include file that ONLY has their pieces included if the call is never included, it can't be reverse engineered to 'add'/'hack' this functionality I hope only the best for you. If possible, keep us informed. Tim
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
Dan Neely wrote:
The third is related to the second. For security reasons if customer X can't have feature Y, then X's application cannot have methods to implement Y in the common library even if X's application doesn't have any way to call the method because if they were clever enough they could do reverse engineering write their own front end that sits on top of the common library.
This, is a large part of what plugins are intended for. If they don't get the plugin, they can't load it, so there can be no reverse engineering. The bad news here, is that your company is going to have to take the financial hit for changes to the codebase.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Just a thought, I have never done this myself, but have you considered macros and/or include files? You may be able to create separate libraries for each customer, using your common source. Then they could not "access" whatever you did not want them to see because it is not even in their library. Dave.
Macros might work in theory but one of our deliverables is source code to A1 (who in sells the system our app's part of to the other users); trying to explain that the IFDEF's mean that even though an item we can't give to the end user is in the source isn't in the executable is somewhere we don't even want to think about going. Even if we crossed that bridge new developers not having NDA access to what we did for old customers would be a show stopper. Include files are out because it's a C# app; not C/++.
3x12=36 2x12=24 1x12=12 0x12=18
-
I have done this in the past by having the core code into a base project or projects and custom code in the customer central project. I then use the primary project to dynamically load the dll's for the customer centeric project so the main application is driven from the core code. If two clients request two identical features the core code gets moved to the core application and the customer centric portion gets placed into the customer centric project. This helps to prevent divergence of the code base. For each customer, you deploy the base code and the customer centric dll's. Everyone is happy and it works well, albeit it can be tough to debug at times.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
I see this ending badly... In my experience, simple is always better than complex. I vote for one skin-able app with options that can be turned on/off. I'd explain at length but that would be complex and simple is always... well, you understand. ;)
Can't be done. Between NDAs and non-technical people having a copy of the source to look for "forbidden" terms the customer specific stuff must be kept out of the shared material regardless of what pain it may cause elsewhere.
3x12=36 2x12=24 1x12=12 0x12=18
-
Ennis Ray Lynch, Jr. wrote:
albeit it can be tough to debug at times.
What sort of problems did you encounter doing it this way?
3x12=36 2x12=24 1x12=12 0x12=18
Sometimes the debugger does not like to step into a dynamically loaded assembly. Most of the time it works I just mention it so you know it may exist in certain configurations. Otherwise, I am very happy with the approach. Can also be used to offer tiered feature-sets without the risk of someone just "enabling" a feature.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Dan Neely wrote:
The third is related to the second. For security reasons if customer X can't have feature Y, then X's application cannot have methods to implement Y in the common library even if X's application doesn't have any way to call the method because if they were clever enough they could do reverse engineering write their own front end that sits on top of the common library.
This, is a large part of what plugins are intended for. If they don't get the plugin, they can't load it, so there can be no reverse engineering. The bad news here, is that your company is going to have to take the financial hit for changes to the codebase.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete O'Hanlon wrote:
The bad news here, is that your company is going to have to take the financial hit for changes to the codebase.
The way our bean counting works the hit'd be primarily born by whomever was the first customer to get a version refactored this way; with other existing customers being hit if they wanted an update. My (uneducated) get feeling is though that if more elegant this would be significantly more expensive than my thoughts about sub-classing, and since the extra money that got spent on the redesign would mean less customer visible stuff for their money this could be a problem.
3x12=36 2x12=24 1x12=12 0x12=18
-
Can't be done. Between NDAs and non-technical people having a copy of the source to look for "forbidden" terms the customer specific stuff must be kept out of the shared material regardless of what pain it may cause elsewhere.
3x12=36 2x12=24 1x12=12 0x12=18
-
I see this ending badly... In my experience, simple is always better than complex. I vote for one skin-able app with options that can be turned on/off. I'd explain at length but that would be complex and simple is always... well, you understand. ;)
Every book on coding theory and design I've ever read always says to avoid complexity. However, I am finding more and more that reading coding theory is like watching Microsoft demo a new technology: the examples are chosen to look great, to work perfectly, and to bear little resemlance to the challenges you meet in the trenches. Sometimes things (and when I mean "things" I mean "business rules dictated by competing or potentially conflicting needs") are just plain complex.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I've been working on a series of applications with related functionality with each app being delivered for a different customer. The apps have significant amounts of functionality in common but there are some features unique to each customers requirements which cannot be provided to any of the others. Because all the versions belonging to our customers (A1, B2, A3) so far were funded and developed separately and in sequence in each case we simply took a snapshot of the prior customers source put it in a new SVN repository and started making changes from there. We've managed OK so far but with more customers expected in the future and plans in place to roll some of the improvements from customer A3's application back into a new version for A1 our current setup isn't going to remain manageable with our current process. What I'm looking for is information about how this sort of thing has been done elsewhere and what would be the best way for us to proceed. I'll describe my thoughts on how we proceed along with concerns I have about it and am looking for feedback on it. We envision our customers being split into two main groups based on some high level capability differences. My prefixing our customer IDs with A and B reflects this; A1 and A3's versions of the software have significantly more in common than B2's. At present we don't expect there to be a C category to be added but can't rule out that changing several years from now. Our basic idea is to split the common parts of functionality (both backend and win form classes) into common core libraries for A and B type customers; and to then inherit the common classes and implement customer specific functionality for each version in a separate solution. We might also have a top level common library for things shared with both A and B although there're enough differences between A and B that I'm concerned we'd end up overriding enough of the methods that it ends up only adding complexity to the situation. The reason I think I need to put each customers application into a separate solution instead of having a single solution and just selecting which customers app to run is severalfold: The first is that due to customer specific NDA's we're likely going to have new developers who won't be allowed access to apps done previously because without their being tasked to work on customer X's application they can't meet the externally imposed need to know requirement for NDA approval. The second is that because we're working directly on a specific customers
I can't offer anything anyone else hasn't already said, but can I ask that you please post your solution? This is a good, chewy one.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
I can't offer anything anyone else hasn't already said, but can I ask that you please post your solution? This is a good, chewy one.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Since 1991, I have used a data profiling/historian product from OSISoft. When the application was used on an OpenVMS system, each site was given a build specific to them, and, there was a 'build manager' responsible for adding the products each client licensed. When they moved to a Windows NT environment, all customers were given the base application, but subsequent pieces were licensed individually. So... my 'vision' would be: modularize as much as possible each 'version'/'client site' gets an include file that ONLY has their pieces included if the call is never included, it can't be reverse engineered to 'add'/'hack' this functionality I hope only the best for you. If possible, keep us informed. Tim
Tim Carmichael wrote:
OpenVMS
:thumbsup: My only experience with a proper version control system is OpenVMS' CMS... and after reading (most of) the Subversion manual I believe CMS is superior at this sort of thing. The company I worked for at that time looked into Visual Source Safe as a replacement and decided that it just didn't have the required features. The thing is (as far as I can tell anyway) is that there is a whole different way of dealing with source code that the lesser systems enforce. It comes down to the operating sytem -- OpenVMS just does file handling way better than desktop operating sytems. When I finally got around to starting to write my own version control system a year ago, I took CMS' approach.
-
Every book on coding theory and design I've ever read always says to avoid complexity. However, I am finding more and more that reading coding theory is like watching Microsoft demo a new technology: the examples are chosen to look great, to work perfectly, and to bear little resemlance to the challenges you meet in the trenches. Sometimes things (and when I mean "things" I mean "business rules dictated by competing or potentially conflicting needs") are just plain complex.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Avoiding complexity is easy. As long as you only ever deliver hello world.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.