As someone who has worked in development teams, I take it for granted that not everyone on the team has the same needs and interests. A twenty-something Java developer, fresh out of college, is interested in questions like, "Which emerging framework might be worth learning?" The architect on the team may be interested in the same frameworks, but for entirely different reasons. Unlike the rank-and-file developer, the architect has decision-making power over which framework to adopt. The architect bears responsibility for the long-term consequences of this decision, while the rank-and-file developer is primarily concerned about delivering components written for whatever framework the team selects. Meanwhile, the development manager has to oversee the work of both the developer and architect, ensuring that, collectively, the developers and architects and testers and everyone else deliver their work product on time, at an acceptable level of quality.

Different roles, different questions — not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, take a look at the chart in this earlier blog post, which shows the sources of information and advice to which developers and architects turn.)

"Follow The Money"
Still, people can confuse the needs of these different roles. Case in point: The yearly Oracle OpenWorld conference, which now includes JavaOne since Oracle's acquisition of Sun. In a recent blog post, Tim Bray cites an unnamed Oracle employee who hinted at the end of JavaOne as a developer-focused event. Bray says that the following is not an exact quote, but his best effort at reproducing what the mystery Oraclonian said:

“You don’t get it. The central relationship between Oracle and its customers is a business relationship, between an Oracle business expert and a customer business leader. The issues that come up in their conversations are business issues.

“The concerns of developers are just not material at the level of that conversation; in fact, they’re apt to be dangerous distractions. ‘Developer mindshare’… what’s that, and why would Oracle care?”

It's easy to rebut this assertion. Just take a look at the Oracle Technology Network (OTN), which is chock full of content for developers. Of course, we're talking about developer support for the Oracle platform, which may or may not resemble what Oracle ultimately does with the new Java wing of the site that replaces Javasoft.com. (Side note: Oracle does seem to have over-branded the new site.) For now, it's worth noting how much effort Oracle has already put into supporting developers: for example, the company was a pioneer of making commercial software free to developers, through OTN, to evaluate and learn.

Oracle OpenWorld is an entirely different matter. Pitched to development managers, IT executives, and other people above the rank-and-file developer in the org chart, OpenWorld presented the same smorgasbord of technology in the Oracle platform, but not at the level of detail that OTN provided. For example, when Oracle first launched its grid initiative, it was signaling to decision-makers in IT departments and ISVs that Oracle was committing itself to providing a new kind of deployment architecture. You did not see an Oracle executive install and configure the necessary middleware, nor did the intended audience need that kind of presentation.

Oracle might be committing a grave mistake, if it were to impose the OpenWorld model on JavaOne. It's not inconceivable, but I'd be surprised if they did. As enthusiastic attendees of earlier JavaOne conferences, a lot of influential Oracle employees themselves would protest if the event mutated into something unrecognizable and unhelpful. 

"If You're Going To Hype It, Hype It With The Facts"
Unfortunately, one possible source of confusion is self-imposed. Stereotypes ignore diversity, and a common stereotype overlooks the diversity of roles within development teams.

Deep within the subculture of software development, there is a strain of distrust of anyone beyond the paradigmatic developer. We all know the stereotype: brilliant problem solver, technically hyper-proficient, working through the wee hours, solving problems in ways that people won't understand but eventually will appreciate…If that sounds a little narcissistic, well, perhaps it is. Other relevant adjectives include histrionic and unrealistic. 

Here's an example of the histrionic aspect: At the Agile conference last month, I heard a couple of Easy Rider-ish comments about how the presence of Wipro and IBM meant that The Suits were going to ruin the event. Instead of applauding the fact that Agile had gone mainstream to the point where Big Honkin' Vendors like IBM, Microsoft, CA, and Wipro were incorporating it into their product and service strategies, these individuals were worried that The Man was taking over.

Here's an example of the narcissistic part: Read the comments following this blog post about Microsoft KittyHawk, a RAD tool designed to bring business users into the software development process. Business users may not understand Java binding or unit testing, but they do know quite a lot about the business problems that applications are supposed to address. So, reading the responses to the KittyHawk announcement, why the nasty, condescending comments from developers, such as "People are 'non-programmers' for a reason," followed by "And most are also 'non-thinkers' for the same reason"? So much for business/IT collaboration, I guess.

Maybe it's time to put down the Neal Stephenson novels, take a deep breath, and consider that, in the real world, software development requires a diverse set of roles and responsibilities, such as engineers, architects, development managers, and product managers. If someone designs a conference, a community, or any resource to support one part of the development team, it may not be ideal for everyone else. While nothing stops a company from making stupid decisions, there's no obvious incentive for Oracle to alienate the Java community, in all its diversity.