Hopefully, this question is not too open-ended...
I have been tasked with taking a 3 year old application (.NET 4.0, WPF, WCF, EF 4, SQL 2008) that was designed for a very specific market X and "re-purposing" it for a another very specific market Y.
To further complicate things, the company has also mentioned a third market Z, but that may be a year+ down the road. But it’s definitely coming.
The deadline for getting the application Y ready for market is aggressive. It might be negotiable, but just assume it’s a matter of 2-3 months.
I have been working at the company for a while, and I was very intimately involved with the initial creation of application X, and I am still involved with the maintenance.
The new “application” Y is interesting because there is some “overlap” between the features required for X and Y.
For example, let A, B, C, D, and E be features and let ‘ (prime) denote an enhancement to a feature. All of the following scenarios are valid:
---X---|---Y--- … ---Z--- (down the road) A | A B | B’ C’ | C | D E |
Some features can be merged from X to Y as-is (A). Some features from X must be enhanced before they can be merged into Y (B). Some features in X will not be in Y at all (E), and Y will contain features that are not in X (D). You get the idea.
Here are my questions:
(1) In the eyes of upper management, they ultimately see 3 different applications - one for each market: X, Y, Z. Moreover, they see 3 different copies of the same feature A that will need to go into each application. As discussed, there may be some enhancements that will make it to select products, but at the core, they are nearly identical.
Sometimes I'm guilty for finding excuses to use the latest programming trends, BUT I think there's a strong business case here for utilizing the Managed Extensibility Framework (MEF). Why have 3 different physical applications (and hence 3 code bases) when it could really be one “next generation” application with plug-able features through something like MEF? There are several benefits that something like MEF could bring to the table.
Does an extensibility solution like MEF seem valid in a case like this?
(2) Given the limited time to get application Y to market...
(a) Should I go with a conservative approach and simply give management what they’re asking for, i.e. make a deep copy of X and modify it for Y? Perhaps there will be time after Y goes to market to develop a more ideal and extensible solution? My past experience with this company has seen demos become fully-fledged products within no time – if you get my drift ;)
It could very well be more difficult to modify X code to make it work for Y rather than it would be to create Y from scratch and import X features.
(b) Leaving X alone for now, should I create Y with MEF in mind. Features from X can easily be imported into Y. If this is done properly, Z should be easy to implement. It will probably be a risky undertaking to go back and address X to fit into this framework since it's so widely used, but it could be done on the side with no specific deadline.
I have to pitch this to upper management. Any advice or thoughts?