I'm running a fever and have given up all hope of concentrating on anything work wise today so it's time to cruise through the blogosphere, catching up on my tech favs. Of course, what might seem genius to me now could be crap when I'm lucid again.
Keeping that in mind ...
I recommend taking a thorough read through this post on Java memory problems. It might be seemingly obvious to many that have been in the Java game for awhile, so it's all the more reason to give it some attention. We tend to gloss over what is 'obvious' and then are surprised when we're tripped up by it. And we invariably are.
Here's an interesting white paper on rolling out agile to large enterprise. It's a good overview of large scale organizational and process structure. Of course, read it with a realistic attitude. We all know there is never an end-all be-all anything and this goes in particular for things of an organizational nature. Organizations are comprised of people and those pesky carbon-based water bags are always the biggest wild card, no matter how much we might want to make analogies with inanimate objects (it's an apples-to-carburetor comparison, which isn't very useful). The kinda folks that live by these analogies are of course human themselves (well, most of them are, most of the time). Which means that they inevitably end up demonstrating the fallacy of their own position, to others, anyway, if not to themselves.
A certain executive standard bearer for the periodic table very recently compared software developers to automated dishwashers during a discussion. Ironically, this was in a meeting whose primary goal involved quantifying the monetary value of agile. He had a valid point (there is not a 'bad' and 'good', binary with people - it's a scale) but the analogy used to make it was bogus (and the scale off - it's not a linear scale by any stretch).
But I digress, check out the white paper. All other things being equal, you have to organize such that your software boundaries align to the extent they can with your organizational boundaries so that you minimize cross org communications requirements (that's overhead not directly related to the value prop) and at the same time can better instill a sense of ownership and pride within the team by delivering deploy able, usable software.
But maybe that's just the fever talking ...
Hey good news for those of us who are EHCache users and have a stake in its continued success and growth but who are also fans of (or at least have seen some exciting potential in) Terracotta. Terracotta has hired on EHCache maintainer Greg Luck and will now be distributing and supporting the EHCache code base. They be gearing up to be gunning for Cameron and Oracle Coherence, so says Eric in not-so-many words.