Cloud Zone is brought to you in partnership with:

Ben Kepes is an analyst, and entrepreneur, an commentator, and a business adviser. His interests include a diverse range of industries from manufacturing to property technology. As a commentator he has a broad presence both in the traditional media and as an extensive blogger. He sits on the boards of a number of organizations, both commercial and not-for-profit. Ben is a DZone MVB and is not an employee of DZone and has posted 197 posts at DZone. You can read more from them at their website. View Full User Profile

Force.com and the Uber-Democratization of Programming

01.07.2013
| 3137 views |
  • submit to reddit

In the last few weeks I’ve started to riff on James Govenor’s meme, that of developers becoming the new kingmakers. I recently wrote a post discussing what I saw happening with Salesforce – how the combination of force.com and Heroku was creating a real gravity pull for developers and that Salesforce was primed to be at the epicenter of this development. A number of people pushed back on that theme, in particular questioning how force.com – a business centric PaaS that is admittedly highly proprietary, can constitute anything compelling for developers.

Not being a developer – my comments come from a business perspective. That might be anathema to most developer purists, but I sense that what we’re seeing with high level PaaS’ like force.com (and, for that matter, the other SaaS-based highly flexible platforms, is an uber-democratization of development that will prove even more revolutionary for developers and business than IaaS has been for operational teams within an IT organization. That’s the reason I started differentiating application PaaS (aPaaS) from infrastructure PaaS (iPaaS)

Let’s see how that works. With cloud, organizations no longer need to think about procuring, racking and stacking servers. Rather they obtain their server needs on a utility basis from a cloud provider (in the case of the public cloud at least). CapEx is removed, the need for large operational teams goes, and all of a sudden the ability to acquire server time moves from central IT, down to tech teams within a business unit. All fine and good so far, but let’s get to the next stage, PaaS.

In the old days, a business that wanted to, for instance, create a custom application that integrated with its ERP or CRM, would have needed to engage a developer with a deep understanding of both development languages and the hooks into the software package being integrated with. With aPaaS that is no longer the case. The platform itself is built upon the application and hence is already integrated with the core data the organization is trying to use. The language is easy enough for most business people to use and hence they do, creating applications at will.

This concept, of aPaaS being the catalyst for massive democratization, was well articulated in a recent post that went out on a significant limb by saying that “Force.com is the next Visual Basic”. Rather than an insult however, the author stresses that reactions to force.com replay many of the those that went alongside the introduction of VB a couple of decades ago:

  • Most professional C++ programmers dismissed it. VB was a “toy language” or a “glue language” for components – not for serious software development.
  • Increasing number of software engineers embraced the language because, to put it simply, when it came to desktop applications you could be an order of magnitude more productive in VB than in C++. It may not have had the stature and features of a “real” professional language, but it sure was profitable to work in it.
  • VB was easy enough for anyone to use, so everyone did. Doctors, lawyers, students – millions of VB developers sprang up out of nowhere and wrote a lot of code. Much of it was very bad code, but that’s what happens when a bunch of amateurs get in the game. Entire book, magazine and training industries grew up to help them get better, and many of them did and built entire careers around the platform.

The very reason VB was productive is important to remember in light of the rise of PaaS generally and these high level aPaaS’ in particular. The original post detailed the traits that force.com shows that were so starkly on display at this year’s DreamForce:

  • A web based GUI environment that provides a high level of abstraction for developing real applications that seamlessly integrate core features like database, email, reporting, the web, chat and mobile.
  • An environment that lets you do a great deal without code, but provides the language and “hooks” that allow serious programmers to go much farther.
  • A flood of non-programmers who are using the environment to solve real problems, and who are stumbling into actual programming.
  • Lots of truly awful code being written, so there’s a huge need for training and a thirst for knowledge on how to do things correctly.
  • A language and platform that doesn’t seem to get much respect from the “real” programmers doing Java, C# or other languages, even though the demand (and pay) for Force.com and Apex programmers is huge.

It is true that, just like VB being under powered for some applications and needing a product like .NET to fill the gaps for particular needs, so too does force.com have its limitations. We’re always going to see “real” developers do the complex stuff – just look at the amazing number of applications being built of Heroku, AppFog, EngineYard et al – but that’s not the key point here. The key point is that the number of people globally who are now developing applications is ballooning, while the number of so called “professional” developers remains fairly stagnant. The thing that allows this to occur is a democratization, an increasing utility and, yes, a return to the simplicity of the Visual Basic days. It may not be a “real” development tool, but it’s one that is changing the very essence of what development is.

Published at DZone with permission of Ben Kepes, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)