How Salesforce Developers Collaborate

This week I am happy to have Matt Lacey a Force.com blogger join me on ButtonClick Admin for a look at how we as admins can take a page from the Developers and learn to collaborate more. Matt is from Melbourne Australia and has the privilege of being ButtonClick Admin’s first international guest blogger. He is a Salesforce.com Certified Administrator, Certified Advanced Administrator, and Certified Developer.  Currently he is leading the charge on the StackExchange to get a Salesforce Q&A site set up. You can read more about Matt on his blog by clicking here.

—
Salesforce Developers and ButtonClick Admins tend to be pretty distinct, sure there’s some crossover here and there, and some of us have learned to try and do some of the clicky parts before reaching for Apex (or codey parts after the clicky parts), but on the whole the two jobs are different. Of course variety is a good thing, and any company who wants to maximise their use of Salesforce, or the force.com platform generally, could do with having experts who work in both areas. But that’s not the end of the story — for a team to work efficiently, and without friction, the members must be able to collaborate effectively. Collaboration is the key to successfully leverage the full extent of Salesforce and the force.com platform, from sales team members working on deals to administrators and developers helping those users realise their full potential by providing the correct tools. Collaboration doesn’t end within an organisation either, the Salesforce community excels when it comes to demonstrating the power of us all helping each other, you only need to look as far as the #askforce Twitter hashtag to see the wheels in motion. Even if you’ve only been working with Salesforce for a short while, you’ll undoubtedly be aware of them leading the charge towards the social enterprise, helping business become more efficient through innovations such as Chatter, which unsurprisingly, focuses on collaboration.

How Salesforce Developers Collaborate

Having thrown the word around considerably so far, you’ve no doubt guessed the theme of this article, though what I want to discuss in particular is how developers collaborate; I don’t want to get too deep and technical, but hopefully this will help provide some insight into the mindset of developers and explain how we can effectively work together. The stereotypical view of programmers / hackers / coders / software engineers / what-have-you is that they’re not particularly sociable, even within their own. I believe this stems from the notion of being in the zone; frankly when you’re elbows-deep in code and concentrating hard on tracking some complex logic, or debugging a needle-in-a-haystack kind of bug, even the slightest distraction can cost a considerable amount of lost time. Such an intrusion can de-rail your thought process with astonishing speed, and if you’ve spent the best part of an hour reaching your current state, you’re unlikely to be particularly happy about being yanked from it, as it’ll no doubt take another hour to get back there. So if you approach a developer (you being a person in ANY role, fellow developers included) frowning at some code (likely with headphones on), then try to catch their attention to show your need to interact without straight-up interruption; wait until they’re ready to come to you: chances are they’ll be considerably more amicable.

• So take away #1: Salesforce developers are social, and the best recognize the need to communicate effectively.

Developers collaborate with other developers in an infinite number of ways, and across a broad spectrum. Towards one end of the spectrum, collaboration can be simply in the form of well-commented code, providing hints for future maintainers, while towards the far end there are huge open source projects with people spread around across the surface of the planet. Day to day, things are a little different for most developers; for the most part my interactions with fellow team members take on the form of phone calls, Skype chats and face to face discussions. We collaborate on code by being careful not to work on the same areas of force.com orgs at the same time, and to protect us when we do we leverage the power of version control. Being a big fan of Twitter means that I read a lot of news and information regarding what other developers are working on or towards, and Twitter is also a useful resource for a quick answer to a problem. Other resources online for collaborative help include websites such as StackOverflow (which is rapidly becoming a default go-to place for development issues) as well as technical blogs which aim to share knowledge, and generic (as well as platform specific) forums and communities.

Collaborating with system administrators and our consultants takes on a different form; here things are far less technical and instead we’re all trying to interpret both instructions and intentions, verifying that the former will successfully lead to a result satisfying the latter. My personal experience has shown there tend to be two areas of difficulty with the communication of specifications, the first being that the end user doesn’t know precisely what they want; I’m sure most Button Click Admins have had first hand experience of this.

• So point #2: talk to the user, ideally with a developer, and if their requirements seem vague then try to lead them through potential solutions, help them work out what they actually need.

The second area of difficulty for those working with developers is when they encoutner a developer so focussed on writing code that they won’t ask questions, often not considering what the end-goal (or business context) may be. It’s all too easy to see a list of specifications, tune out distractions and hack something out. What is required when communicating specifications is a discussion, not an IM, not an email or voicemail, but a bona-fide, real-time talk. It’s up to both parties to make sure they know what goes in, what should come out, the business context, and which bad things going in will make which kind of explosion. Once we’re all in our happy place (the place where everybody involved knows everything involved) THEN it’s time for the developer(s) to start cutting code.

• Developer collaboration rule #3: TALK!

Finally, collaboration is defined as the action of working together to produce something, and that does not necessarily mean that two people have to be working on the same thing in order to assist one another: oftentimes somebody working in a completely unrelated field and business will have solved a problem that you are currently facing, and so the power of the community comes into play. Salesforce provide various ways of getting help and support, though they tend to be segregated somewhat, geared towards specific roles rather than catering for the masses with a holistic approach; an approach where questions can be asked and answered with input from both sides of the fence, maintaining the discussion necessary for a complete and functional solution. I’ve already mentioned the Twitter hastag #askforce, and some LinkedIn groups are another area where the community really comes together effectively. . The aforementioned StackOverflow is great for developers on all platforms, but that was just the starting point for the Stack Exchange network, which now includes sites for photography, sport, cycling and many other areas, with the Stack Exchange community moderation Q&A models efficacy being proven time and time again. The next site could be for Salesforce: for admins, for developers, for consultants and end-users. The Salesforce Stack Exchange proposal has been put forward with the intention of creating a site where the whole community can work together. Though it is hard to communicate the strength of this model I have attempted to communicate the benefits before (link), and the proposal has gained much support so far. We still need more people to commit to the proposal which is the next step in getting it launched as a live site, so please get on board and help us all help each other.

So to conclude, the three main points again:

1. The stereotype is just that, and they’re often wrong. Developers are social, and any developer worth his salt understands the need for communication and team work.
2. Work with developers when gathering specs, everybody brings something different, but equally important, to the table. Working together is how we benefit the users the most.
3. Talk. Chat. Chatter.