Take the 2-minute tour ×

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?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

Some thoughts:

  1. Upper management very likely doesn't know or care what MEF is. If asked, they'd likely want to know that it will get them a solution sooner and cheaper than otherwise. That's a tough promise to keep if you are still learning the framework.
  2. Do you really want to be learning a new framework at the same time you're implementing Y with "an aggressive deadline"?
  3. Regarding Z in a year - what if "definitely coming" turns into "maybe someday?" or "never"?

My recommendation would be to implement your choice (2)(a) - give the folks who sign your paycheck what they ask for. Copy X into Y and revise. Naturally, this isn't an ongoing pattern.

Learn MEF on the side with no specific deadline. That way you're not risking your deadlines and you can afford to make mistakes as you climb the learning curve.

If/when Z becomes a real project, you'll be in a good position to implement it with 'known technology' and probably refactor the other two into a more general solution.

share|improve this answer
Thanks for the reassurance. I would much rather structure this "next generation" application without the pressure of a deadline so that any mistakes don't cost us the job. –  Russell Apr 4 '13 at 11:48

Using MEF does not magically turn your application into a collection of composable components.

The code first has to be structured to have sufficiently loose coupling between the different parts, which probably requires quite a bit of refactoring. Sometimes it's almost a rewrite if you didn't care for loose coupling before.

Once your codebase is structured to support composing features, the technology you use for composing does not have that much impact. It's only there to create objects and wire them up to each other. MEF isn't necessarily the only choice for composing "components". A dependency injection container like Autofac also does that (with better features for composition of "components" within a single codebase, but no dynamic loading of plugins).

So i'd suggest to learn about the requirements for composability on your codebase first (i think Dependency Injection in .NET is a good book on that - it also covers MEF), pay special attention to them while creating new features and slowly refactor exisiting features. Once you can compose the most important parts you can pick a technology for doing so.

share|improve this answer

Your Answer


