Managing complexity with OSGi - In bundles and between bundles

2010-04-22 Software-Engineering OSGi Thoughts

Right now the Brandvis SelectPortal system is based on Microsoft .NET and we constantly improve it and add features. While we do this we also constantly refactor the system to eliminate complexity to make it easier to maintain/extend.

Triggered by this work and triggered by a talk on reuse of OSGi bundles that I attended a couple of years ago, I started to think about complexity again. The main conclusion of that thought process is that there is probably an optimal (means minimal) complexity for any given system.

To get to that optimal level of complexity you constantly refactor the system (because there is no chance in hell that you will get it right the first time around by thinking about it and then implementing it) and change the granularity/size of your reusable software artifacts (classes, bundles, services).

Getting the granularity/size (and the responsibilities) of a reusable software artifact right, is probably the holy-grail of software engineering and there is no easy answer, because if you cut it too small and build the system from a lot of very simple, small software artifacts the complexity and dependencies and relationships between the artifacts get out of hand. Going the other way you can try to reduce the complexity of the system, by building it from larger software artifacts, but then these artifacts itself will become more complex.

That means that in any case you need to build your system on a software platform that allows you to iterate on getting the granularity of the software artifacts right. I believe OSGi is such a platform.