Nelz's Blog

Mah blogginess

Project Granularity in an Enterprise Setting

What is the "correct" granularity for projects (or modules) in an enterprise environment?

I don’t have a perfect answer for this one yet…

In general, I have been advocating smaller projects, for just about anything that can be pulled out.

One possible complaint about this option is that the number of individual JARs grows, increasing the difficulty in the JAR-space. I think that if you are using some type of Dependency Management system (like Maven), this is all but negated since most of the JAR wranglin’ is done declaratively.

The second complaint has to do with Eclipse and its refactoring capabilities. If you have lots of smaller libraries and you change something in one library, Eclipse doesn’t seem to have the ability to perpetuate that change across to all the associated client code. (This seems to be because the projects are all associated via binary dependencies, rather than associating as code dependencies.)

However, maybe the purposeful upgrade to client code is a good thing. I definitely think having small, modular components it better than having one monolithic project… But do we achieve this at the expense of developer productivity?

Maybe I just need to look at this issue as a trade-off. Which is costlier? Less modularity (which has long-reaching effects) or less-functional refactorings (which are shorter-termed, preferably infrequent, and arguably a benefit)?

I’m gonna need to think on this one for a bit… (Though it sounds like I may have already made up my mind…)