Salesforce offers many powerful declarative (point and click) tools that let you build no-code solutions to your organization’s problems. While you should often prefer declarative solutions, there are indeed many situations in which they are not appropriate.
An even more common occurrence is that problems that were originally simple evolve and outgrow their original solution. Raise your hand if your org has a Process Builder that no one actually understands anymore.
As your use of the Salesforce platform matures, you will eventually need to add custom code to your Salesforce org. Declarative tools give you a guarantee of quality, but the quality and longevity of your custom code are all due to vendor selection and budget prioritization.
Types of development skills
There are two kinds of software development skills: problem-solving and longevity. Problem-solving is just what it sounds like; it’s about creating solutions for the here and now. Longevity is not concerned with solving the problem—its focus is on structuring the solution so that it may evolve with the rest of your code.
While all Salesforce consultants or companies must possess problem-solving skills, longevity skills are surprisingly rare. Longevity problems typically occur several months after development begins. By then, the developer and the client have established a history of success with their current process.
Inevitably, however, longevity problems will start to occur. As the code base grows, it becomes more complex and each new feature makes the system harder to troubleshoot. Features used to fly out the door, but now they creep. New features create bugs in existing features. Costs and schedules start to expand ever outward. Rinse, lather, repeat.
As the code grinds toward gridlock, your team may start to discuss replacing features, instead of expanding them. The extended feedback cycle of longevity problems obscures the cause. With such a disconnect, many reasonably assume these challenges are inevitable and that software naturally has a life span.
Even the smartest and most conscientious developers often end up on this path because it is a natural function of complexity. Problem-solving skills and longevity skills are separate disciplines – think about the difference between a handyperson tasked with fixing a leaking sink versus a kitchen designer who thinks in a holistic manner and with a long-term strategy in mind.
Benefits and costs of longevity skills
The most obvious benefit to longevity is cost. Replacing features is expensive and it is much cheaper to expand them responsibly. The other primary benefit is that the code becomes more flexible.
Code that does not have longevity resists change, and the more you change it, the harder it becomes with each subsequent change. Code with longevity gets increasingly flexible with each change making it easier and easier to change, rather than the inverse. With each feature added, the next, and the next after that, become easier.
Put another way, instead of complexity growing with the size of the codebase, it tends to stay very stable. The codebase can grow and grow without getting crushed by complexity.
Building for longevity is harder than just building to solve problems. As mentioned above, it’s a separate discipline that can be hard to find and staff. It also requires a more ordered approach that increases per-feature development cost. Instead of just throwing new code on top of old code, you are continually refactoring the code to control the complexity.
Setting yourself up for success: prioritization
Prioritize ruthlessly and spend where it matters most. Be honest about what you really need right now and what you can add later. Developing quality software is initially more expensive, though not radically so. It naturally follows that the larger the scope, the more dramatic the difference between the “quality” version and the “budget” version.
We get it. It’s tempting to choose the lower-priced bid or the bid with all the goodies. Much like cheap toys from the drug store, you will get what you pay for. A cheaper bid is not a bargain if you must replace components or when it causes follow-on work to balloon.
Where quality matters, limit the scope to constrain your costs. Save your non-core features for a follow-on project by which point you will know your vendor and the project requirements far better and expectations will be much more realistic.
Setting yourself up for success: choose the right vendor
Vendor selection is key, but unless you are lucky enough to already have staff with longevity experience, it will be extremely difficult to discern business development/marketing sweet talk from actual capabilities.
Salesforce certifications are a good indicator of platform knowledge, but they give no indication of longevity skills. Salesforce training and evaluations are focused on technical details, not the architectural decisions that lead to longevity.
Here are a few ways to start sniffing out vendors that understand longevity and high-quality code.
- Choose vendors that focus on long-term partnerships, rather than contracts. Winning bids and making margin on a contract is about solving today’s problem cheaply, often at the cost of long term strategy.
- Ask about the age of their oldest client relationships. Find out how much work they have that is retainer-based (though for vendors working with nonprofit and grant-based organizations, that will be less useful).
- Prefer vendors that recommend reducing scope, instead of promising you everything. Skepticism is borne from a preference for quality. Over-optimism is borne from a preference for money.
- Look to established network. If you have another trusted technical vendor, consider asking them to help you evaluate the vendor, or even help you manage the initial project.
- Ask for referrals. Query existing customers of the vendor under consideration specific questions about longevity. Did progress slow down or increase over time? Did the system have features or components that needed to be replaced as requirements evolved? Is their system easy to change or do minor requests require outsized investments?