> > What exactly is officially to be considered a 'corporate developer'? > Honestly, for I don't know. The common VB guy who neither cares > nor even knows much apart from 'point-and-click and it's done, > obviously'? >
A corporate developer is more known by what she or he knows, than by what tools they use (although VB will certainly be common). In general, the corporate developers that we (the Creator team) focused on are those that have one or more of the following characteristics: * Are primarily engaged in some knowledge worker task, and are not professional software developers. * Would typically first go to an internal IT department for an application to access the company's internal databases, often to be frustrated by how long the backlog typically is in such organizations. * Is willing to learn a little bit about visual development and/or scripting; is not (usually) willing to understand more esoteric things lke object oriented programming. * Likes to build by cut-n-paste-n-edit from starting point examples, rather than creating designs from scratch. * Can "consume" things like database schemas and simple web services that provide lists of data back; typically less capable of "creating" such architectures. * Work product is more typically used at the departmental level than at the enterprise level (so scalability and performance are not typically the highest ranked priorities). Before I joined Sun, I worked for a company that provided information services to the long haul trucking industry. When I left, there were about 350 employees; 20 software engineers (building the products we sold and provided services through -- in Java), 10 in IT running the internal customer and billing systems (mostly a combination of a GUI scripting language plus third party COTS software), and about 200 knowledge workers in various fields (typically using MS Access and MS Excel to retrieve data from the corporate database) in various fields. Many of those knowledge workers found it necessary to build some of their own data retrieval tools, because there was no way the IT group could get around to meeting everyone's needs, and became corporate developers. I expect that this kind of ratio between folks who know and love Java, and those who are just trying to get their job done, is not unusual. I also see it as a *huge* opportunity for Java as a platform, if we can just make it easier for them to use. This doesn't require sacrificing all our up-to-the-second passionate debates about MVC, IoC, SoA, persistence tiers, AOP, design patterns, or any of that. It does require recognizing that not everyone in the world knows, or ever wants to know, some of the things we O-O folks tend to care about. > -- Chris. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
