I need to study this to understand how you could classify the dependency graph of a proliferated legacy architecture. Networks have in recent years emerged as an invaluable tool for describing and quantifying complex systems in many branches of science (1–3). Recent studies suggest that networks often exhibit hierarchical organization, where vertices divide into groups that further subdivide into groups of groups, and so forth over multiple scales. In many cases these groups are found to correspond to known functional units, such as ecological niches in food webs, modules in biochemical networks (protein interaction networks, metabolic networks, or genetic regulatory networks), or communities in social networks (4–7). Here we present a general technique for inferring hierarchical structure from network data and demonstrate that the existence of hierarchy can simultaneously explain and quantitatively reproduce many commonly observed topological properties of networks, such as right-skewed degree distributions, high clustering coefficients, and short path lengths. We further show that knowledge of hierarchical structure can be used to predict missing connections in partially known networks with high accuracy, and for more general networkstructures than competing techniques (8). Taken together, our results suggest that hierarchy is a central organizing principle of complex networks, capable of offering insight into many network phenomena. www-personal.umich.edu

Interesting thoughts: Callbacks are essentially a permission to change the implementation of a method, usually without defining exactly where they are called. In an API, you can not guarantee anymore the postconditions of your callback enhanced method, since the observer is allowed to change the observed component.

Interview with Donald Knuth: I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. [...] I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the "Titanium" approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.

Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading.

The whole OSGi movement is highly interesting. I recently investigated more into Component Orientation, reading an old book by Clemens Szyperski. Before I can understand SOA, first I must understand their basis: components. Feature driven approaches always deny the use of modularization. They argue that the cost to develop reusable components beat the long-term benefit of reuse. Therefore you should develop only the features you need in an agile manner, without caring for later reuse. That's great in the first iterations. Without de-composing your architecture the maintainance costs will explode in the following years. What you have to do is to plan your dependencies, your boundaries and gather similar functionalies at one place. So feature driven may turn out a legend. In the end you need to turn your code into components.

UPDATE: "the problem with java is that is has no modularity". Word! it-republik.de

They nearly convinced me just by their super-slick presentation style. Yummi!