There are some features within the Force.com platform, that upon first glance, look interesting, but as you become more familiar with developing apps, you wonder how you ever lived without them. One of these features is dependency management. (you must be logged into your dev account to view this link)

Dependency Management alone is great. For example, if an admin attempts to change a field type, which is referenced by a Visualforce page, or an Apex class, the app displays an error indicating the dependency. Proactively stopping changes which will break code, is critical to long term management of an application, but as a best practice I try to leverage the feature for something more: to promote collaborative development.

During the implementation phase of a project, roles are typically divided between functional: changes which can be completed by an admin, and development: customization activities such as Apex, Triggers, and Visualforce pages completed by platform developers. By leveraging the dependency management support provided by the Force.com platform, admins and developers must communicate regularly and collaborate during implementation (and beyond). This type of collaboration was encouraged in other development languages, but never really enforced. 

Take an example of a project I am currently working on. We had created a nightly integration with the customers internal system. One of the fields being returned was intended to populate a picklist. Upon further analysis, it was agreed that a string field may be more appropriate. Unfortunately I had already built an Apex class for lead scoring, which assumed this field would be a picklist. Within my code I  split the string returned. Changing the field type from picklist to string would break my code.

 In a traditional environment, this change may not have been picked up until runtime. The downstream result has the potential of unhappy customers, and costly maintenance to debug, and resolve the problem.

But we are developing on the platform, so dependency management is enforced. When the admin on the project attempted to make the change, they were informed of the dependency, and were unable to continue. 30 seconds later my IM buzzed, and the admin and I exchanged messages until we collaboratively agreed on the best approach for handling the customer's requirements. I had instant visibility into functional changes which impacted my development.

In the end the build never broke, the platform pinpointed the dependencies, and the development never missed a beat. You can't beat that for a best practice! 

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS