Dreamforce is rapidly approaching and the excitement among the salesforce.com faithful is palpable. I’m not as excited as I am anxious about potential announcements that could move the needle in the force.com development space. So I thought I’d jot out a few things I’d like to see.

I’ll stick to evolutionary ideas for this post, and I’m assuming that the proprietary Apex and VisualForce stack is here to stay. I’ll save the idea of tossing it for another day.

• Local cloud – This would allow developers to edit and compile code and run tests locally without server round trips. This is the general model used by Amazon Web Services, CloudBees, CloundFoundry, and salesforce.com’s Heroku service. Ideally this would alleviate much of the latency associated with compiling and running tests, enabling certain agile practices that are nearly impossible today with Apex, such as test-driven development.
• Apex packages – Apex currently has no analogue to Java’s package or C#’s namespace. Since there is effectively one package (global), there is a single name collision domain and a single unit of reuse. What’s worse is that this “global” namespace applies to the entire org, not the various logical apps or packaged apps that may be installed. So the app you’re building now, the app that you build six months from now, and the packaged apps you install along the way all share the global namespace. This is currently the most fundamental and serious shortcoming in Apex and it puts severe downward pressure on the size of apps that can be built with a respectable level of quality and maintainability.
• Testing improvements – The current testing framework is lacking a few important features. Formal support for setup/teardown would result in more reusable and less fragile tests. Mocking would allow true unit testing (95% of unit tests I see are actually full-blown integration tests) without the need to code exclusively against interfaces look up dependencies.
• Improved managed package upgrades – The concrete sets when one releases a managed package. The latitude for refactoring, removing deprecated components and editing existing components is drastically inhibited. After a couple of releases, an app can really start to wear its history on its sleeves. There’s gotta be a better way. Also, patch orgs are a clunky and manual solution to publishing minor changes to an app. They should be eliminated and the notion of minor updates should be folded into the original developer org.
• “Project Coin” for Apex – Inspired by Project Coin, there are a bunch of small changes that could breathe some life into a stagnating Apex. Here are just a few: A real and defined object root, reflection, improved collections library, string formatting, ability to throw instances of built-in exception classes. Ok, so some of these aren’t small. Still.
• Make System Log work reliably – The “new” System Log has a lot of fancy moving parts, but the fundamental problem that it has always had still persists: it often does not receive logging data. Sadly, many developers simply don’t use it because of this.
• Some love for the Eclipse plugin – The vast majority of force.com developers use the Eclipse plugin. The plugin is promulgated by salesforce.com, which is what makes it so puzzling that it is often several versions behind in its support for Apex and VisualForce. And its most frustrating bugs are years old. How about some love for the plugin?
• A better SOAP stack for Apex – I’m not referring to the venerable salesforce.com SOAP API here (which embodies some of the best work salesforce.com has ever done). I’m talking about Apex code consuming third-party services. The SOAP client is broken and limited in numerous ways. It can only handle the simplest WSDLs. Many force.com projects ultimately ditch it in favor of rolling their own SOAP messages. REST (or plain XML over HTTP usually) has become more popular with the kids, but for better or worse, SOAP is here to stay and better support is much needed.