Thursday, February 11, 2016

When To Soft Code Or Not To Soft Code

My Auntie Pat Tern got mad at my no good cousin when he told her he changes phone numbers every time he gets a new burner phone; she warned us to make sure we do business by the rules.  So I looked through my code and shared her suggestion with my developers.

It turns out they tried to correct a problem with badly implemented hard-coded values by soft-coding some values that represented software architecture decisions and similar business rules.

Previously, I showed you the example of a hard-coded username being assigned as record owner, which caused two problems in the org.  The first problem was that the username needed to be an API-only user rather than an employee who might leave the company whose username would be deactivated.  The second problem was that the username was hard-coded deep in the code rather than being represented as a constant at the beginning of the class.

The developer who tried to fix these problems decided to soft-code the username as follows:

Using Custom Settings allows the username to be changed outside of code at any time, multiple times.  The above example does not solve the first problem we had, though. Unfortunately, soft-coding the username defeats our business rule requiring data coming from integrations to be owned by a user or Queue specific to that integration.  In other words, our business rule required the use of a constant rather than a soft-coded value.

We had to take that code back to the drawing board one more time because, like Auntie Pat Tern demonstrates, code should behave according to the rules of business, and enforce those rules automatically.

Monday, February 8, 2016

Magic Numbers and Hard Coded Values

My Auntie Pat Tern recently borrowed her friend's phone and noticed the recently called phone numbers didn't have names assigned, so she called everyone to remind them to enter contact names with their phone numbers.  I looked through some of the code in my org and decided to share her advice with my developers.  I found code that made use of Magic Numbers and hard-coded values, both of which make the code difficult to maintain.

Imagine Auntie Pat Tern's frustration when she wanted to find a particular number and couldn't because it wasn't listed under any of the names she expected to see.  And the contact list was empty.  She couldn't find the number she wanted and she couldn't tell what any number was for without a contact list.  In programming, the variable and constant declarations are like the contact list and allow us to give understandable names to numbers we use in the code. Numbers that appear without names and descriptions are known as "Magic Numbers" because they appear and seem to work by magic, such as the following example:

Imagine trying to maintain code like this, would you know where to change a value and how often that value may be repeated in the code for the same use?  Does 0.43 need to be changed to 0.435 every time it occurs in this class, or just in a single line of code.  These values should be named according to the business logic being automated and should be declared as constants for more readable and maintainable code.

Magic Numbers aren't the only hard-coded values I found in the code. Deep within the bowels of one utility class I found a user name hard-coded as the owner of all records generated by our integration with another database.

In the example above, you can see the hard-coded user name, but you can't see the fact that this was a real user, and happened to be someone who had left the company and so was deactivated.  A better approach for this would be to assign an owner that is an Apex-only user, a bot-user specific to this integration, rather than a real person, and define that user name as a constant.

Static variables, at the beginning of a class, provide an ideal location for declaring variables and constants associated with business logic.  At the beginning of the class, they can be near the class description, the comment that describes the business case being automated by the class, and make maintenance a breeze.

Naming values and putting them where others expect to find them will help you avoid problems like what happened with my Auntie Pat Tern.

Monday, February 1, 2016

Avoiding the Negative for Clear Code

My Auntie Pat Tern recently reminded me to avoid double negatives and use positive language as often as possible. So I looked through some of the code in my org and decided to share her advice with my developers. When we write conditional statements using NOT (or "!"), we are using negative syntax which is more difficult to understand than positive syntax. Here's an example written in negative syntax, then rewritten in positive syntax:

The conditions evaluate the same, but I find the negative syntax more difficult to read during code review and maintenance. Note that it can be improved upon further with a basic knowledge of String methods.

The first time I encountered super negative syntax, I thought the developers who used it were making a game of being abstruse.  But knowing that the two programmers were friends led me to discover that this was in fact a case of "cargo cult programming" where they were sharing and reusing a bad pattern because they hadn't taken the time to pick apart what the code needed to accomplish. Once they better understood what the code was doing, they learned to write it more clearly.

Thursday, October 1, 2015

Even Small Companies Benefit From A Center Of Excellence Team

User adoption is a double-edged sword for some companies. As more users become more active on Salesforce, and as more departments find it to be the best solution for their needs, the more work administrators and developers have in keeping the system working the way users need it to work.

I've heard of companies that have such a large backlog of requests in Salesforce that by the time any work request gets cleared, the requesting user may no longer even need whatever they requested. Obviously pulling work requests out of a backlog on a First In First Out basis is not a manageable solution for anything much more complicated than user provisioning and password regeneration.
A governance team can help keep things running smoothly.

Instead, companies should consider implementing a more mature governance system like a Center of Excellence (CoE), or scaled down version in the form of a Success Team. This governance body for Salesforce orgs brings all the stakeholders to the table at once and provides transparency into the important issues each department is facing.

You may be familiar with scenarios of what happens without a CoE: multiple departments need customization work but the administrators and developers are stretched too thin to dedicate a resource to any project. In some companies, new requests simply spread resources even thinner across yet more work.

For example, the product department needs a way to mass input new products while the customer service department needs a smoother way to handle complex steps for authorizing a product return and credit. The admins and developers are stretched too thin to take on both tasks simultaneously. But that's what they are asked to do any way. And so both projects chug along ever more slowly without the proper attention to detail.

Instead, an active CoE can prioritize these requests based on input from administrator, developer and end-user representatives.  But the administrator has to be given a lot of say in the CoE decisions.

Special talents of any good Salesforce Administrator include the ability to understand your specific business processes and how they relate to Salesforce features and capabilities. Companies need to use that person's knowledge to put projects in logical order and give them a reasonable timeline. And in some cases, departments may discover that their needs overlap and the administrator can accomplish multiple tasks at once.

Nightmares of No Governance

One administrator I worked with had multiple departments needing a way to combine records into various related groups. A simple addition to the data model and Heroku Connect settings could have made that possible, but coordinating with three departments for a solution required getting everyone together to discuss. That is the most difficult part of projects without a CoE.

In this example, the administrator had built out and populated a model that no one was using. The administrator had been working with customer service, but that department had turned its attention to fighting other fires.  The product department was at a loss about how even to put a request together for configuration changes in Salesforce and had a terrible relationship with IT.  And the marketing department did not know they could simply use Heroku Connect to pull the data they needed from Salesforce into their web app. The administrator and developers didn't even have a way to communicate to users that solutions were complete because they did not have User Acceptance Testing scheduled.

I've also worked with CIOs who make purchasing decisions based on demos rather than actual product testing in Sandbox. These CIOs expect administrators to configure ill-conceived or undefined solutions with untested products. Yet a CoE can create well defined functional requirements enabling the administrator and select users to conduct basic testing before purchase decisions in order to determine how new packages interact with existing systems and whether they address basic business needs.

Simple Efficiency of Teamwork

Rather than setting your projects up to fail by not allocating sufficient time to them or setting up your company to fail by pitting departments against each other to fight over limited internal resources, set up a CoE to handle these issues in a transparent way. Discussions can be continued in Chatter and resources can be shared in Content Libraries or Chatter Files for full disclosure to Salesforce users. Proper governance records why decisions were made, which keeps your company from spinning its wheels revisiting decisions when there is no new information.

The beauty of the CoE is that it can be scaled to meet your company size and needs. Start with an executive sponsor and department managers who are using Salesforce as well as administrator and developer representation. Add a couple of power users and training experts. Schedule meetings and combine them with an online Chatter group to continue any open discussions. You will find that this can help equally with the initial roadmap of Salesforce projects and ongoing collaboration as well.

When projects require outside vendors, there should be an administrator in all meetings with the vendors to ensure that the business and user needs are well defined for your vendor partner as well as for anyone responsible for in-house support and maintenance after the project goes live.

Once departments start sharing how they are using Salesforce, they may even inspire each other to make better use of data that is already in the system.

Saturday, September 26, 2015

Build Teams, Not Committees

Being part of a committee makes everyone cringe, but being part of a team can bring joy. If they are both just groups of people, why do they make us feel so different?  Use this simple comparison chart to understand why your company should rethink committees and focus on team building instead:



One clear leader, the head coach, who brings everyone together and is ultimately responsible for success or failureNo clear leader and no mechanism to unite members
Additional leaders empowered at every level of the team including skill-specific coaches and team captainsPower struggles and power grabs when leadership is unclear
Team members have clearly defined positions and roles for working togetherMembers may not understand their contribution
Defined timeline and ways to measure success throughout the season, as well as pre-season and post-season expectationsVague goals, arbitrary timelines
United against an opposing team or united for a singular achievementOpposition often comes from within the committee and personal goals take precedence
Well defined tasks for each and every time the team gets together come in the form of practice routines, game plans, and even a task to share fun with pizza socials after gamesMeetings may be scheduled in advance but members may not know what they are intended to achieve, agendas and summaries may not be offered to members
Keep members motivated and acknowledged for their efforts and achievementsFail to recognize the value members bring and their individual contributions

Simply reclassifying committees as teams is not enough if you lack motivating leaders and empowered members who are trusted to execute their well defined tasks and coached on paths to improvements when they fall short.  We like sports metaphors because they generally make us feel good about ourselves and others, work should be able to do the same.

Saturday, September 19, 2015

Struck By Lightning, Now What?

We have all seen the new Lightning user interface by now and while it currently effects the way sales teams and admins interact with Salesforce, we can start planning for a broader implementation right now.  Lightning provides for a modular page layout that we can configure for our own processes and dynamic components including a Kanban board layout and interactive charts, among a lot of other cool features.  And it represents a big change in the way users can view and interact with data in Salesforce, whether sales users today or every user as new releases become available.

As you consider rolling these new features out to users, here is one process you might consider:

Step 1, Learn

Trailhead offers learning modules to help
with smart implementations.
Recruit some super users to play with Lightning Experience in a Sandbox.  Find enthusiastic users that you know will have exciting ideas, but also have at least one of the more reluctant users.  If you have a user who is just not that into Salesforce, this could be a good opportunity to win them over by listening to what they need and letting them affect change.

As an admin/developer, start learning about Lightning App Builder in Sandbox or in a developer org.

Of course, everyone should go through Trailhead modules related to Lightning.  End-users might want to start with the features module.  Admins and developers both can start creating apps to become familiar with features and limitations.  At Dreamforce 2015, there were already 17 Trailhead learning modules available that you could find with the Lightning tag filter.

If you have not set up a CoE (Center of Excellence or Success Committee) in your company to bring together representatives of each department using Salesforce, this would be a good time to put that group together and start planning as a team how to bring Lightning to users in each department.

Evaluate some of the Lightning Components from the AppExchange and see if there are any quick wins you can bring to your users or inspiring solutions that may already be available.

Keep mobile in mind as well.  The Lightning user interface works well across all devices and if you have not considered the mobile user experience, this is a great time to learn more about it as well.

Step 2, Plan

Meet with your super users and your CoE to workshop ideas about what may be the best way to design page layouts but make it clear that this is a way to gather ideas, not all of which can be implemented right away. This is a time for generating wish lists rather than worrying about actual final product.  Let users dream up their ideal page layouts but keep realistic expectations, their ideal may be unattainable, but it should help you understand their needs and goals to work towards a better middle ground.

Give each user paper and have them draw out what they would like their page layouts to look like now that they have seen what could be possible with Lightning.

After you give users a chance to draw up their own ideas, give groups of users who perform the same job function the chance to work as teams to combine their ideas on a whiteboard or, better yet, on a poster board you can keep as a reference.  Try to have multiple groups of users each create a board and then have the groups come together and discuss why they designed the page layout on their board the way they did.  As they discuss their ideas, they may want to make changes and you should be able to discover some of the most important concerns and requests.

During the planning phase, admins and developers at your company should also conduct a workshop, or internal hackathon.  Create a new Sandbox Idea Factory where they can put together ideas that they think might benefit the company or the individual user experience as well as ideas that simply interest them as a challenge.  This is a great place to promote creativity and inspiration and bank resources that may come in handy for development.

Step 3, Develop

Create a project plan that merges the most workable options from your Idea Factory with the most desired and manageable requests from user workshops.

Keep the channels of communication open as you execute this project plan.  Whether you use Agile or other project management methodologies, it is important to make sure everyone understands the immediate goals as well as the more long term goals.

Keep meeting with your CoE to make sure they are behind the development efforts and aware of timeline, progress and roadblocks.  You want to ensure that the users are kept in the loop during the development cycle so that they don't feel forgotten or get the wrong impression that their ideas from the workshop were merely dismissed.

Make sure your super users from the learning phase are still involved with user acceptance testing and helping with creation of training materials and best practice guidelines as you develop those as well.

Step 4, Implement

Now for the fun part!  With the support of your super users and your CoE, start rolling out your customizations to users. Make sure they have the training and support they need for a good start with your custom Lightning user interface.

Step 5, Evaluate

Listen to your CoE to discover what worked well in the process and determine what changes you can make to these steps before beginning the process again.  When you start the next learning phase, you might consider introducing your users to some of your favorite ideas from your internal Idea Factory as well as new Salesforce features they may not be using yet.

This initial Lightning release affords us all time to work with users and plan how to meet their needs. If we start now, we can create a process that will make transitioning to the new user interface a chance to impact user adoption as well.

This is just the beginning.  With three releases a year, Salesforce will have more features coming available so keep your Idea Factory Sandbox active to give admins and developers a place to challenge themselves and stretch the capabilities of the org.  And let your CoE continue to support project planning and generate enthusiasm among end-users.

Thursday, September 10, 2015

Salesforce Lightning And Juggling Ideas Together For Rapid Development And Rapid Training

When you employ rapid development techniques, you need a documentation and training tool that can quickly introduce new capabilities and concepts and later allow you to expand on that knowledge with added content. Salesforce uses Trailhead as that online learning tool to introduce users around the world to new features associated with the Lightning Experience and other platform capabilities.

While Salesforce's traditional documentation and training resources contain a multi-course buffet of information, Trailhead provides resources more comparable to a delightful cocktail party. The content is lighthearted and approachable and comes in bite-sized portions that are quick and easy to consume.

For developers and administrators who want to gain familiarity with the new Lightning Experience before unleashing it for end-users, Trailhead offers a great introduction with four new badges (pre-Dreamforce '15): Lightning Experience Basics, Features, App Customization Lite, and Rollout.

Being able to offer training content quickly and update it easily has been a benefit of Trailhead, a unique and innovative free training offering from Salesforce.

For the team involved in creating Trailhead, customer enthusiasm for the training modules has been rewarding. "I've never stumbled onto anything this big," says Josh Birk, Developer Evangelist at Salesforce and the developer behind the initial Trailhead prototype. According to Josh, "this last year has been the best year of my career for being part of a team of people with such a passion for improving customer experience."

We can learn from more than the content since, as a project, Trailhead has a lot of lessons to teach businesses by example.

According to Josh, "At Salesforce, we aren't just trying to make things work, we are trying to make things work better." In this case, Salesforce executives lent their support when they discovered multiple groups working independently on an area where the company was already doing good work, according to customer feedback, but individual employees had a desire to move beyond good to great.

Moving a product from good to great might seem like a luxury to companies that are stingy with resources and believe success comes from doing what you did well once before, years ago. Companies like that typically suffer from business short-comings like risk-aversion, groupthink, management by perkele, and bystander apathy resulting in management that gives a cold shoulder to new ideas or any ideas that don't come from the top down. But the culture at Salesforce avoids all of those pitfalls.

Josh feels lucky to work for a company that supports compelling ideas born from employees asking themselves "what if we could give our absolute best?" In this example, Salesforce executives demonstrated their interest in helping employees achieve their best by encouraging their efforts.

Executives knew that multiple people were exploring good ideas and gave those people time to collaborate on what they were all trying to achieve. Managers guided the teams to discover how they might fit their ideas together. Open collaboration is part of the Salesforce culture to keep moving forward, keep progressing and keep being innovative.

For Josh and others working on creating Trailhead, their original ideas to give their best sprang from interactions they had with individual customers. Face-to-face at workshops, online in the Chatter communities, everywhere they found customers, they took the opportunity to think about what might make things better for each of those individuals.

According to Josh, "our approach was not looking at what other companies were doing but instead looking at what our customers needed." What started as a tool for on-boarding new administrators and developers is evolving with new content for more intermediate and advanced users, and of course offers new content around release features like Lightning as well.

For administrators rolling out Lightning Experience, these lessons in collaboration can be applied to the roll out. With the limited Lighting Experience available in the Winter '16 release, we have time to conduct workshops with users and brainstorm on what Lightning has to offer our teams to help them achieve their best. As administrators, we have the opportunity to juggle these ideas together into improvements for our companies as long as we welcome ideas from end users and think about making things better for them as individuals.

To hear more about Trailhead and innovation, sign up for Josh's session at Dreamforce 2015: Making of Trailhead in Moscone West.