As a senior technical director at Primitive Logic, I have the happy privilege of working with a large variety of technologies. While I am still very hands-on, I almost always have people on my project teams who who are deeper on the specific vendor platform on whom I rely to keep me honest when working with clients to set project expectations.
I have lead multiple initiatives involving Salesforce (I have reached the level of Ranger on Trailhead in my spare time) so the skepticism of my lead developer when the sponsor of a recent project asked us to implement a Salesforce community with no custom code matched my expectations, too. Neither of us had ever been on a project where there was not a serious amount of custom development using Apex and JavaScript, frequently with the need for custom HTML for the UI.
Still, it was an interesting challenge and we assured the client that we would make every effort to fulfill requirements with as little custom development as possible.
A good chunk of my career has been devoted to working with flexible platforms like Salesforce; i.e., vendor products and services that provide a set of out-of-the-box features coupled with APIs for extending functionality with custom development. I have learned that the amount of custom development necessary to meet business requirements is influenced by more factors than what the product provides by default.
Project timelines combined with abbreviated training can result in functionality being custom-built because it is often faster for a developer to figure out to build the feature than to learn how to use the provided solution. In some cases, it is still faster to use the out-of-the-box approach, but the vendor-specific nomenclature makes it difficult for the deadline-harried developer to find the standard answer where Google and Stack Overflow search synonyms will find the custom solution faster with the more generic phrases used by developers in general.
In organizations with a mature platform relationship where the developers know the standard capabilities very well, it can still sometimes be more expedient to build a custom solution. Platforms are designed to serve a broad spectrum of use cases and sometimes a well-designed API that is intended to provide support for a variety of use cases can still become unwieldly to use. I see this happen more often in the APIs that expose functionality for use outside of the platform, though it does still apply to internal feature configurations.
Product understanding and complexity aside, there are still the cases of unchallenged assumptions factoring in. Developers experienced with other platforms may be convinced that they can build it faster or better without even considering the default option. Another source of build before implement by assumption is when what is available in the standard offering is slightly different than the business specification. Far less often than should be the case, the delivery team will assume the requirements are completely inviolable and never present an alternative to business that may miss one or two minor features but take weeks less to build and are as close to maintenance free as can be expected using the platform-included solution.
I also find that developers who will campaign elaborately for what they think to be the best solution within a technical group will not take the extra step to challenge the business on whether being able to provide some specific behavior is worth the thousands of dollars it will take to build and maintain when the difference provided by the freely available option is minimal. I certainly don’t advocate for pushing hard for the path of least resistance in development. What I do think is often a miss is to argue technical the differences between approaches with business when there is a clear business choice involved in the decision; i.e., what is the ROI of the feature that requires customization?
In this particular case business had challenged the technology team with doing as little custom development as possible by making it a success criterion of the project. The other criteria were:
- Topic-based navigation in the community
- Gamification of community participation
- One-click publishing of knowledge articles to the community
- Validated service request form
- Role-based views for internal users
- Transparency of the request-to-completion service process
- Automated status notifications
- Automated process reminders
- Automated, role-based approval process
Because we had been tasked with using as little code as possible, we were motivated to dig a bit deeper into documentation than is normally done when concerned about time constraints. The result was that we were able to deliver all of the above without writing a single line of code.
And yes, there is a very small “but” that goes along with that. The requirement of service process transparency was fulfilled, but the balance between usability and data security made for a less-than great user experience for external (community) users involved in a large number of service requests. We agreed that we all would like to enhance the list view with a custom component. Still, considering we did not think that a code-free community cold be created in the first place, this is a very trivial exception.