Skip to end of metadata
Go to start of metadata

The Cost of reuse versus duplication

See The Cost of reuse versus duplication for details of how and when to aim for reuse.

Enterprise Maven Infrastructure to facilitate reuse

There will always be overhead with additional projects that have their own release cycles, but this overhead can be minimized with Maven Infrastructure. When set up, releasing an extra project is trivial, and working with multiple projects becomes manageable/easy enough.

The problem with 3 and 4 is that effort is put in before we know if it is actually needed. And, worse, if it is not needed at all, we have wasted valuable resources. If we could defer the work we might need until we actually need it done, the last two costs would be minimized.

So why don't we? As a long as we follow good practices and write maintainable code, we are not forced to do more QA or write the code more generic than we need at the moment. If we should is another matter which will be discussed elsewhere.

What is a helper project?

We use the term helper project to denote code that is non-trivial and which is not part of the primary responsibility of a component. Typical examples are support for transport (JMS, JMX-RPC, Webservice) or storage (SQL, File). The keywords here being non_trivial and support. We want to encapsulate such complexity in separate components. Encapsulation makes them easier to write and easier to test. It also makes them easier to reuse, but this is a bonus, because the other benefits alone makes separation worth while.

Another reason why these helper projects are valuable is that they are a means to centralize functionality. Often the problem is not too little use, but too much. That is, the same functionality is written many, many times, instead of reused.

TODO: Are descriptions of the responsibilities of such helpers necessary to understand the concept?

Labels:
tactic tactic Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 23, 2008

    By way of Anders Norås, I found something that looks abit like critisism of this practice: http://codebetter.com/blogs/jeremy.miller/archive/2008/09/30/separate-assemblies-loose-coupling.aspx (lots of discussion in the comments, mind).

    Any thoughts on that?

    1. Oct 23, 2008

      First, it is true that separate projects gives some extra development hassle, but this hassle is made virtually zero by [Enterprise Maven Infrastructure]. The argument should thus be considered invalid in enterprise java environments.

      To me it seems he writes about helper libs as a means of decoupling. I can be, but it doesn't need to be, as it seems to me he illustrates very well with his physical and logical decoupling descriptions. There are only minor issues in his post I don't agree with. So perhaps this page needs some more work?

      Any suggestions to which questions this page need to answer to make the concept easier to understand and more explicit?

  2. Oct 23, 2008

    Should the discussion about reuse be moved to separate page?

  3. Oct 23, 2008

    more on reuse: @jhannes thanks... #reuse - I think we probably should: indicate counter-measurement strategies and selection criterias next