Summary
Despite the Java noisy noise about attracting Visual Basic-type developers, I retain the impression that many of us Java folks don’t get it. Either we can’t define this audience or we secretly don’t believe in its value. But there is value here, value loftier than merely growing product revenue and stealing corporate developers away from .NET.

The VB-type clamor from our pointy-headed friends in product marketing includes the following: There are more than twice as many VB developers as there are Java developers in the world and it’s an obvious place to try to grow a Java product business; Java and J2EE in particular suffers from a complexity so deeply ingrained that it surfaces when realizing even the simplest of application use cases; typical JSR expert groups (the folks who write the Java standards, groups comprised of vendors and academicians rather than corporate app developers) have a historical tendency to believe that complexity should be hidden by tools instead of resolved by the application model – a view that seems to have lost traction within even Sun (see Project Rave); tools for aspect-oriented and generative approaches to business process creation and integration are chief among vendor hopes for finding new value-add in the largely-commoditized J2EE platform stack.

All of this is true, but it may miss the core value of the VB-type audience, as that value premise has little to do with Java and enterprise contexts per se.

So here’s the premise that many of the Java elite sadly do not seem to believe, as it vaguely seems to suggest a deterioration or “dumbing-down” of their craft (in much the same way that mainstream adoption of the web broke the hearts of Internet elitists years ago):

It should be possible for a halfway intelligent person with no programming expertise to develop, test, and deploy dynamic, data-driven, service-oriented web applications very quickly and very safely. This non-programmer might be a power user in Accounting or HR who is completely uninformed about classic computer science issues but knows a thing or two about Excel pivot tables and rules governing workflow; or this non-programmer might have once been a true programmer, say she’s familiar with C/C++, and simply wishes no longer to deal with the artifacts of systems and languages (at least within the scope of her current use cases and/or professional context).

The value here is not so much in attracting Visual Basic developers to Java, and the ideal tactics aren’t those which call for Java to mimic VB or C#, or for JSP (and JSF) to mimic ASP.NET. The real value is in giving non-Java developers and those who are not going to learn any programming language the power to create applications and services through simple tag and script-based development models and highly-customizable components and services that can be imported, integrated, and managed within simple lightweight tools (as opposed to full enterprise IDEs). The fact that we refer to this as “going after VB-types” is saddening, as these folks – you know, the people in the world who aren’t geeks like you and me – ought to have a better baseline option than Visual Basic and VS.NET.

Building application models and tools for these folks is not the same as making Java easier for existing developers. Simplifying the development of EJBs and SOAP endpoints is an important thing, but if the solution requires understanding of transaction attributes or of namespaces in an XML Schema, or if it requires use of computer science-y cool topics such as aspects or generative programming, then it is simplification and elegance for you and me, not something for VB-types.

Giving non-programmers the components, models, and tools they need to develop applications and services is a good thing for us to do because it decentralizes and democratizes the creation of new technology and new technical solutions, distributing the power to innovate and create to a broader array of people. This is a good thing for all of us the world over, it’s good for the various Java platforms, and it should not threaten current hardcore systems architects any more than the mainstream adoption of HTML threatened web application developers.

As you can tell, I do buy the premise. Though I am skeptical that current leading J2EE vendors can deliver on such a thing (do giants like IBM, Oracle and Sun, full of experts a world apart from the classic VB developer, see primarily a broad marketing opportunity or do they really get the importance of ease of use in app models and tools?), I’m nevertheless glad to see these leaders addressing the issue. Someone – perhaps a new player, perhaps an open source initiative backed with decent marketing – in the Java community needs to make this happen, or all VB-types will be forced to use… well, VB.

Talk Back!

Have an opinion? Readers have already posted 7 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Sean Neville adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Sean Neville is a software architect at Macromedia where he is focused on creating the Flex platform. His previous projects include the JRun application server and Flash-related products for J2EE and .NET. His experiences include membership in the JCP Executive Committee and numerous JSR expert groups; authoring articles, contributing to books, and speaking on enterprise topics; financial services app consulting; building doomed yet fun web startups; maintaining open source projects; and half-decent fiddling of Irish jigs and reels.