Co-Worker pushing for a scary and smelly software solution, need help!

Question

A coder w/ a lot of clout in my office wants to go down a path I feel is instinctively wrong. We need a business rules framework for a set of web services we have for accepting certain types of xml infosets in a WCF based POX service.

In the previous version we used a homebrewed rules framework that would trigger off certain data points and if those triggers were satisfied, actions associated w/ the particular rule would be taken against the xml infoset (modifications, appending, etc).

Now this is a relatively large project w/ a lot of moving parts and we used the previous framework in various places all throughout the solution. I'd like to push for us to use a commercial and stable rules framework such as WWF or something similar but this guy has another idea and it seems really smelly to me even though I don't have a great argument against it.

Basically, he wants to have an admin that uses CodeGen to generate scripts. This code will be stored in the DB and retrieved as necessary. The code will the be compiled into an assembly in memory and executed. When I pointed out that you can't unload an assembly in memory once it's there, he stated he doesn't care about that point. When a change is made to an existing script, he'll create a new hash to act as a new namespace and load that script as an assembly. Each script (there could be on average a hundred active) will be it's own assembly he'll load into memory dynamically. Each day he'll have IIS recycle the process to get rid of out of date assemblies.

Is this really bad an idea as I think it will be and why?

Answer 1

Does this sound like a bad idea? Maybe.

If you are creating something where the rules can change on a day to day basis, he "might" be going down a right path, you can get around the fact that you cannot unload assemblies, by creating a separate appdomain.

However, without knowing more intimate details of your implementation goals, it will be hard to say.

Answer 2

Proof of Concept!! I can't say it loud enough, but this is a prime example of where a proof of concept would help prove which approach is going to make more sense for your organization.

It could turn out that he can build the system you described and have it humming in a few days, where it would take you several weeks to get up to speed on WWF. Or conversely (and I think this is what you're assuming) his POC will be buggy and lacking in features where your WWF POC will be done much faster and be much more robust.

But you'll never know unless you try it out ... until then, if he has the clout, I guess he wins :-P

Answer 3

It's a bad idea because they're not using existing tools to solve a problem, they're reinventing the wheel with a proprietary technology that does what WWF does, only less cleanly. It smells because it's code at the wrong level of generality.

I can offer little advice on how to convince them of this, other than to point out that there are more elegant solutions available. Management may be swayed by the fact that you can hire perfectly good WWF coders off the rack, while nobody can be expected to know how to work with this smelly solution on day one.

Good luck.