Component Costs
I don't like adding new components (e.g. a C++ or C# DLL) to my overall enterprise application, unless that component truly pays for itself.  For example, I won't create a component that contains one lonely extension method.  I'd rather have the extension method be a Visual Studio "code snippet."  And even if I had a hundred such tiny utilities, and was tempted to put them into a new component 'B', I would still ask about the **coupling** I will create between component 'A', upon component 'B', just so 'A' can access one of those hundred utilities.  Those of you who are component architects know what I am talking about.

Beyond this, I think about the cost a new component levies against a project.  I think of components like babies.  They are free to make, but costly to maintain (i.e. managing dependencies with other components, ensuring proper build dynamics for localization, branding, handling (or mis-handling) in install scripts, etc, etc).

But here is my problem.  I want a better way to explain this to project managers, or anyone who is not a component architect.  I want to have a book, or research data, that converts the type and quantity of components (perhaps with CCD metrics too) into an overall component maintenance cost.  This would help educate developers to be more thoughtful about why and when they choose to create a new component.

Certainly I could spend the next two years attempting my own analysis, preceding my own publication, but I'd rather leverage someone else's work.  Any suggestions out there?

Component Costs
===

I don't like adding new components (e.g. a C++ or C# DLL) to my overall enterprise application, unless that component truly pays for itself.  For example, I won't create a component that contains one lonely extension method.  I'd rather have the extension method be a Visual Studio "code snippet."  And even if I had a hundred such tiny utilities, and was tempted to put them into a new component 'B', I would still ask about the **coupling** I will create between component 'A', upon component 'B', just so 'A' can access one of those hundred utilities.  Those of you who are component architects know what I am talking about.

Beyond this, I think about the cost a new component levies against a project.  I think of components like babies.  They are free to make, but costly to maintain (i.e. managing dependencies with other components, ensuring proper build dynamics for localization, branding, handling (or mis-handling) in install scripts, etc, etc).

But here is my problem.  I want a better way to explain this to project managers, or anyone who is not a component architect.  I want to have a book, or research data, that converts the type and quantity of components (perhaps with CCD metrics too) into an overall component maintenance cost.  This would help educate developers to be more thoughtful about why and when they choose to create a new component.

Certainly I could spend the next two years attempting my own analysis, preceding my own publication, but I'd rather leverage someone else's work.  Any suggestions out there?
