For the past year I have been working on the Salesforce.com Force.com platform as a service (paas) and thought I would give an overview as to how it has held up in my experience as a platform for agile development methodologies (most notably Scrum). This will be mostly from a developer and scrum master’s perspective, but I will try to include views from other roles where possible.
Rapid Application Development
To start developing on the Force.com platform, you simply signup for a free development org (which is an instance of their software in the cloud) and you are good to go. I generally attach Eclipse to my org using the plugin that Salesforce provide (you can download this bundled and redistributed as a standalone IDE but I play with other languages so like to be able to use one tool for the many tasks) but through the web interface there is a built in code editor.
Firstly, as you can imagine, this is an extremely quick and easy system to get setup and started on; I can have this all setup and be creating my first objects (analogous to tables in an RDBMS) for use in under 10 minutes – something that I think you will find hard to better elsewhere. This is the first plus point for Salesforce in terms of agile – it is extremely quick and easy so you can get started right away. Often teams tend to have a series of other admin tasks that they have to perform in order to get working, but with Salesforce, your effective “admin” time is zero. If you fancy seeing something amusing for 4 minutes look here. It sums the speed of Salesforce better than I ever could.
Testing, Testing, 1, 2…
As a developer who likes to use agile practices, I try to work in a test (or sometimes behaviour) driven way to ensure that I am testing my code as I go. Another benefit of the platform is that in order to publish/package or use some code in production, it must have at least 1% test coverage and the entire code base must average at least 75% coverage! I have worked with a lot of developers before that seem to think (incorrectly) that testing is not an integral part of development, but on the Force.com platform you must do some unit testing. I have sadly seen cases where people have merely “exercised” their code by ensuring it is called in a test method, but as a general principal it serves to try and enforce the correct practices. (At the end of the day my 2 pence is that if you are going to have to write some test methods to cover the code, why not get it to do something useful and add an assert or two? Go on, you will thank me for it later. If you haven’t got proper unit tests you can never do any refactoring, only go changing code blindly.)
Continuous Integration
In a previous life doing .Net development I had the pleasure of setting up a continuous integration system. Now I am actually not being sarcastic when I call it a “pleasure” because it was both a great learning exercise and also a magical tool. We could work on a copy of some work in .Net, ensure all our tests and code worked properly locally, then push them to our source control system where it would compile the entire system, run all the unit tests and other tests we had built around it (selenium etc.) and tell us either that everything was all good or that we had messed up somewhere and needed to fix it. This was all done really quickly and speedily and gave great instant feedback on what your code was doing to your overall code base and whether or not your product was always ready for deploying out to a customer (from a purely “it compiles and the code in there works” point of view, some functionality may not have been fully linked together just yet).
When working with the Force.com platform, if you are working on your own the “local copy” you are working on is actually just a copy of the files that are on and running on the cloud somewhere. If developing solo, this is fine as you can have your own source control system where you can deploy your changes from to a fresh org if you want to tests it is all okay. When working in a team it starts to become a little more tricky. Firstly you can’t always work in a single development org (I have worked in groups of 5 or so in a single org and you can nearly guarantee that you will either blow the request limit for a 24 hour period or that someone will be waiting relying upon changes from someone else etc.). The maximum number of developers that can sensibly work in an org is about 3 or 4 if they are working on mutually exclusive tasks, otherwise it becomes a bit more complicated. Often it is easier to work in separate development environments, then merge your changes into a single source control system together. My preferred method is to have the developers agree to deploy the package with the latest code after having committed code to the system. They just simply take a build token to signify nobody should make changes and the job is easy. It is also work setting up a nightly build where the latest code is deployed and tested (through both unit testing and selenium testing). Salesforce provide a great metadata tool to do the deployment and some simple ant scripting gets it all going nicely.
Release Early, Release Often
One of the basic principals of any agile development setup is that at the end of an iteration a release with as few a number of bugs as possible (see testing above!) should be available. Again Salesforce have got this covered by allowing you to create packages and now change sets that allow you to make releases available after each iteration. The ideal situation for a team developing a project on the Force.com platform would be to create a beta managed package at the end of each iteration which can be used for user testing, demos and also as a snapshot of where the system is. I have worked with teams and seen situations where development is still on-going on the last day of an iteration, and there is no visible release made internally (or even made at all) in the code base. By having the pressure (for want of a better word) or creating a managed package (75% code coverage and all) you focus on finishing stories/tasks/work and make sure that it is properly done. If you fail to make the cut you have failed to do the work properly. It is a very hard lesson to have to enforce (“but we were so close, honestly it is only an hour or so away from being finished…..”) but if enforced properly you will find your team getting more done of higher quality because the right system is in place. Continuous integration (as discussed above) helps to make this happen. This way you can also ensure that when you tell someone that a release is going to be on a certain date, you can make sure it is.
Logical Separation
Salesforce enforces an MVC architecture when using Visualforce (its page mark-up language) and Apex in a controller. There are also triggers which handle work done on or with an object before and after update/insert/delete (validation, creation of related objects etc.) There are also components that can be created by a developer in order to reuse pieces of work. More recently as the Salesforce governor limits have started to be relaxed further and further, more traditional design patterns (such as those by the GOF or Martin Fowler) can be implemented alongside the newer patterns that have been developed for working on the platform. These combine to make it very easy and logical to separate out your code into correctly structured layers and provide yourself with patterns for use in the future. There is even dynamic apex to help further this extensibility in providing correct layer structure for your code. Add onto this you don’t have to do anything with a database (as it is already there and provides you with a large portion of your object structures) then correct layering and code practices are hard not to do.
Summary
Hopefully this somewhat brief and not fully comprehensive post has helped you to see some of the awesome features that Salesforce have setup in order to help you become a better developer and help you develop in an agile manner. Please feel free to post comments or suggestions for additions and I may either add them or create an entire new post to entail all those things I forgot.