I recently watched Diving Into the Developer Console so you don’t have to, and it got me thinking about the direction of the force.com platform. I spend quite a bit of time with force.com, so I’m always eager to get a glimpse into how things are improving for developers.

Developer Console

The first thing that’s very clear is that salesforce is continuing to invest heavily in development in the cloud. Some people call this Development As A Service. It’s really an IDE in your browser, which is what the Developer Console is all about.

Over the past year or two, it has grown from a simple System Log (which always functioned intermittently) to a fairly advanced developer Swiss Army knife. Some of the newer features are:

• performance analysis
• execution tracing/debugging
• taking and analyzing heap dumps (even in production)
• development in the console with syntax highlighting and rudimentary auto-completion

On the roadmap for the Developer Console are task-based perspectives, schema building, testing and deployment. Basically salesforce wants developers to develop in the console.

The current incarnation of the Developer Console is not without its issues, such as choking on large logs and the odd glitch here and there. But this is a quickly moving space. The browser vendors are improving performance almost daily and salesforce clearly believes in developing in the cloud. So, expect more big things in the future from the Developer Console.

You may be thinking “hey, what about the force.com IDE?” or, “you’ll have to rip my text editor from my cold, dead hands,” or, “how do I version control files in the cloud?” Wait, those are just the voices in my head. Remember Bespin? It didn’t exactly revolutionize the developer world as some predicted. It did, however, function more as an instructive research project that Cloud9 and others are doing interesting things with.

More importantly, one could imagine that when you develop code in the same environment in which it runs, some fairly amazing tooling is possible. And apparently there are no plans for a local execution engine for force.com, so it appears that eventually all phases of the development lifecycle will live in the cloud.

And speaking of the force.com IDE, it’s not dead yet. In fact, it just may get a fresh breath of life in the form of a major rewrite. Salesforce is working on a “Tooling” API that will expose a standardized interface for toolmakers, including salesforce themselves, to build tooling against. The current plan for the force.com IDE is to simply keep it current with the metadata API, then release a complete rewrite based on the Tooling API, once it is available. They also plan to open source the rewritten IDE so the community can do its thing. There’s been a lot of clamoring for the code to be open sourced due to persistent bugs, so perhaps we’ll see an improvement in this area.

Performance and Governor Limits

Apex has always seemed snappy for simple controllers and triggers. But certain tasks can expose some speed issues. Running tests for a medium-sized app, for example, can take 30 minutes – an order of magnitude slower than what it should be. VisualForce apps in general have had a history of performance issues. The AppExchange was noticeably slow when it was relaunched as a VisualForce app. It’s hard to say if the Apex runtime is the culprit, or something I/O related, such as creation/teardown of database test fixtures. In any case, improving performance is an ongoing initiative, and the latest release, Spring ’12, is supposed to benefit.

More importantly, as the runtime becomes more efficient, salesforce can continue to progressively relax the governor limits. And that’s what they plan to do with what is colloquially being called “Limits 3.0″. As with the limits overhaul a year or so ago, this iteration will loosen things up by reducing and simplifying the metrics. The idea is that instead of measuring very detailed things such as number of statements executed, the resulting impact of the execution will be measured, such as CPU time and heap size. Simpler is better, and this should help developers spend less time being governor limit engineers and more time solving business problems.

An Apex Renaissance

Another exciting improvement is the addition of reflection to Apex. Apex currently has minimal reflection abilities, which makes lots of tasks impossible with a static language like Apex. Granted, reflection is a somewhat advanced feature that simple VF controllers and triggers don’t need, but the possibilities that open up for larger apps are pretty exciting. For example, a big pain point is not being able to use mocks and stubs for testing. Another is a whole swath of design patterns that are difficult or impossible in Apex, such as Abstract Factory and Dependency Injection.

Salesforce is also talking about building more libraries into the platform. The JSON parsing library is an example of a library they’ve already baked in. apex-lang is slated for Summer ’12. I imagine we’ll see others, perhaps in the areas of OAuth, pre-built integrations with social networks, and improved support for consuming Web Services. What I’d really like to see is for a language like Java to be allowed so developers can leverage vast wealth of open source code libraries available. That would cut back on all the wheel reinvention going on.

Last, but not least, is refactoring. When you’re building on force.com, the concrete sets quickly. Resistance to refactoring is endemic to the entire platform and is a serious problem, especially for ISVs. Doing  simple renaming of classes, objects or fields require Herculean effort. The current state of the art would likely involve emptying the org, externally modifying metadata XML, and reloading the org. Even the most basic refactoring support could not arrive soon enough. Fortunately, platform-level support for refactoring could arrive in some form as soon as Winter ’13.

What, no namespaces?

Salesforce is slowly shifting focus to “professional development” (their words). I’m not quite sure what means, but I do know that in order to create well-designed, maintainable applications on force.com, Apex must get namespaces – namespaces, packages, modules, whatever you want to call them. Creating and maintaining a large application with a language that lacks namespaces is simply insane.

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.