For many many years the Java world has popularised frameworks for developers. Most developers understand that frameworks sit on top of stacks and typically act as a way of simplifying the interaction with the complexities that exist within. Experienced developers have long been able to build complex systems without frameworks but it has often been at the expense of time and reliability (some definition of efficiency). The best frameworks are extremely prescriptive, taking the plethora of configurable options which are presented to the developer by the combination of software components that make up the stack and narrowing them down to a very specific subset. They take the complexity and flexibility and condense it down to something which more than 80% of developers will find useful or easy to get to grips with.

Now that's not to suggest that this complexity and flexibility is bad. Far from it: one size rarely fits all and whilst one developer may not understand why it's even necessary to have an option to tweak Widget XYZ, another developer would find it impossible for that to not be available. Component developers have always tried to provide 1001 options for the wide range of users they can perceive and that's the right thing for them to do. However, many component developers are unable to consider how their implementations may be best tailored for the majority: in fact it may be anathema to them to do so. In some ways I speak from experience with our experiences around Arjuna! It's only in recent years, with the STM implementation, that I think we've managed to provide a framework that hits most of the user needs.

But I digress. This is not meant to pit framework developers (or users) against component/stack developers (or users). As software developers we need them both. However, in some areas, and it seems specifically in the Java space, we often hear about the frameworks more than the software entities upon which they rely. I suppose it's similar to movies: we hear more about the actors on screen than the plethora of people behind the camera who actually make the films possible. Another analogy might be the iceberg, where the majority lies below the ocean surface! This is a problem I've run into many times over the years and written about a few times. I'd put myself more firmly into the component/stack category of developers, though I've tried to learn from some of the more successful framework implementations and developers when coming up with the Narayana STM solution. Having many of those framework developers on my staff has helped, so it's probably an unfair advantage I have over others! However, my main point in writing this entry isn't about me or what I've done, it's about how frameworks and components/stacks exist in a symbiotic relationship: frameworks need the stacks on which they are deployed, or they have nothing to make them work, and likewise the stacks need frameworks if their capabilities are to be made readily available to a wider range or developers.

What "gets my goat", as we're used to saying in the UK, is that some framework developers are often less than up front with the fact that their offerings are critically dependant on the stacks "below". Don't get me wrong: I'm not making any judgement about the relative importance of the framework versus the stack in the final solution. However, I do believe in credit where credit is due. Now the users of frameworks are excused from knowing too much about what is happening under the covers: it's like driving a performance car and not knowing the details of who designed and built the engine; but at some point you do need to know that what makes a car perform is at least as important as how it looks! Despite the fact I work for Red Hat and am JBoss CTO I'm trying to be objective here. We've made some really good frameworks that build on our stacks. We've also been less than successful on others. Likewise some of our partners or competitors have made some great frameworks that also rely on JBoss components. The right framework can make you incredibly productive. But the right framework also needs the right support from the components and stack upon which it is deployed. If you don't have a good framework but do have a good stack then a good developer can still be productive but not necessarily efficient. If you have a good framework but a poor stack (e.g., not reliable or scalable) then a good developer is going to realise quickly that all that glisters is not gold!

OK so you may well ask what's the conclusion? First of all I'm not sure there's just one conclusion. If you're a developer then of course you're going to look for the framework that makes you the most productive (definition: get done what's needed in the shortest period of time, but ensuring when you move on to your next company or project you don't leave a steaming pile of poop for someone else to pick up). These days we're a wider Java community that focusses a lot on the implementation language and the framework, since they typically go hand in hand. Projects often have tight deadlines and aggressive milestones making it easy to justify selecting your approach based on the experiences of others who may also have been subject to tight deadlines. But ultimately we need to take the time to investigate the entire solution not just the framework because one really can't succeed without the other.