Join us to learn about Top 10 Salesforce Anti-Patterns. Lars Malmqvist did a great session in Apex hours on Salesforce Anti-Patterns. He cover the common mistakes made by Salesforce architectures on the platform.
What are anti-patterns?
An anti-pattern is a decision that seems like a good idea at the time the decision is made, but reliably leads to bad outcomes.
Top 10 Salesforce Anti-Patterns Video
Top 10 Salesforce Anti-Patterns
10: Stovepipe
A stovepipe is a system that is built with no attention to standards or common abstractions, leading to a system that may work but is hard to maintain, extend, or interoperate with.
Problem
How do you implement an IT system in an organization where departments are siloed, power is distributed into individual fiefdoms, technical teams work independently of each other, and there is no strong central authority on architecture or technical standards? The answer, in general, is the stovepipe anti-pattern. Given the prevalence of these organizational characteristics, stovepipe is one of the most common anti-patterns you are likely to encounter as an architect.
Solution
Fundamentally, a stovepipe proposes to solve the coordination problems inherent in many organizations by building a solution in splendid isolation, not taking into account any wider concerns or requirements, using whatever tooling and standards the implementing team prefers. That way, you can simply go ahead while short-circuiting corporate bureaucracy in the process.
Result
- An increasing difficulty in understanding the code base, especially for new parties working with the system
- Inconsistent architectural design and implementation patterns in different areas of the system
- A diminishing user experience and user value due to the increasing inconsistency and inflexibility of the system
- Great difficulty whenever new requirements have to be implemented
- The system is hard to integrate with other systems in the landscape
- The system is hard to incorporate into global processes, for example, a consolidated DevOps pipeline
- Increasing error rates
- A higher and higher cost of change due to all these factors
Better Solution
While this is a complex problem here are some tips to avoiding the Stovepipe-anti-pattern. Define clear architectural patterns and practices that can be used between teams to create common abstractions. Put in place conventions for how different things are to be implemented, both at the macro level, for example, when to use flows and when to use triggers, and micro level, such as a coding guideline.
Adopt standards for all technical areas, such as reporting and BI or data governance, in order to ensure consistency. Have strong guidance for creating stable interfaces for cross-system integration, as well as integration patterns for different use cases. Put in place a common methodology for implementation across Salesforce projects to ensure consistency. Adopt consistent tooling for all elements of the development life cycle to enable cross-team and cross-system understanding. Enforce these standards and practices vigorously.
9: Cognitive overload
Cognitive overload happens when the amount of information presented becomes overwhelming to the recipient to the extent that it impairs action.
Problem
Cognitive overload is a general term from psychology for situations where our brains are overloaded with information. This especially happens when we convey information to non-technical audiences. For technical audiences, we can to a large extent rely on an understanding of diagram formats, standard ways of doing things, good practice, architecture patterns, and similar.
That reduces the cognitive complexity for such an audience, although complex architectures can still be hard to follow even for experienced practitioners.
However, when you are trying to convey this information to a general audience, you cannot rely on these supports, and therefore the task of conveying key trade-offs and many moving parts can be extremely difficult.
Solution
My personal belief is that a large number of talented architects fall into this anti-pattern because of a sense of intellectual honesty. They have considered many options and are aware of many arguments and counterarguments for and against the solution they are proposing.
Therefore, they feel dishonest in simply doubling down on a highly simplified version of the option they have chosen to recommend. In scenarios where business stakeholders are the ultimate decisionmakers, which is often the case even for seemingly architectural decisions, that almost inevitably leads to cognitive overload.
Result
The obvious result is a failure of communication. Your main recommendation and supporting points are lost in a quagmire of information that your audience is unable to process.
Better Solution
Effective communication is not something that can be taught in a few sentences. But your takeaway should be that it is important to simplify a complex message sufficiently for it to be understandable for your audience.
8: Assumption-driven customization
Letting the assumptions of a small, unrepresentative group stand in for the needs of the wider user base.
Problem
The thing with assumption-driven customization is that it’s less about the problem it’s trying to solve—that could theoretically be anything—and more about the way you are trying to solve it. With assumption-driven customization, you are trying to solve a problem as defined by your product management, product owners, or developers.
Only, it turns out that the actual problem you need to solve was something else entirely. The problem with assumption-driven customization, in other words, is that
you are unwittingly trying to solve the wrong problem.
Solution
The proposed solution of assumption-driven customization is to let a group of experts stand in for the wider user base in order to facilitate rapid delivery of the solution being built. This is a perfectly reasonable approach. We let experts guide us in most things, and generally, it works quite well.
This only goes wrong if, for some reason, your representative experts turn out to have systematic biases relative to your real user base—for instance, someone who used to work in a function but now is out of touch with day-to-day reality or someone who has made the transition to an IT career some time ago and has now adopted an IT perspective on things.
Result
- At one end of the scale, you have a set of basically benign misunderstandings that can be fixed with goodwill, training, and a set of workarounds.
- If that is insufficient, you may have to add or rework a limited number of features in order to get the users to a place where they are happy to work with the new system. This is still relatively manageable.
- However, sometimes you get to a point where users flat-out refuse to adopt a new system, even with substantial modifications.
- At this point, you have two options: either you force it through and deal with the backlash from the user base or you scrap the tool and go back to the old way of doing things.
Better Solution
This is a difficult pattern to guard against because it occurs when the people we trust to be the voice of our user base fail in some significant ways to represent those users. It can be deeply uncomfortable having to raise these kinds of issues with Product Managers or Product Owners who are convinced about their own position, and in fairness, most of the time they will be right.
However, there are some mechanisms that can help with this: Broader consultation with the user base—for instance, via larger events or a common online forum. Earlier feedback from the broader user base. Roadshows, demo videos, and webinars are good options here. Sprint-by-sprint acceptance testing from a larger user group. If you are looking to create deep change, plan for it, and include the necessary change management. Never try to sneak in a major change.
7: Groundhog day
The groundhog day anti-pattern happens when people endlessly ask the same questions, even after multiple repeated explanations.
Problem
Sometimes, people just don’t seem to understand what you’re saying. No matter how hard you try to explain a point or how many times you explain it, there doesn’t seem to be any getting your point across.
Solution
When you engage in the groundhog day anti-pattern, you respond to the situation of having seemingly never-ending queries about the same issues by repeating yourself a lot. You may repeat yourself in different languages or in different modalities, but you are reiterating the same message.
Result
- First of all, you get nowhere with the message you are trying to communicate, which usually needs to be accepted by the audience to which you are communicating
- That leaves you frustrated as you ponder how to better communicate your message to the audience and continuously fail
- It leaves the people you are communicating with frustrated as they don’t feel you are listening to their real concerns
- The project, in the meanwhile, usually stalls, and progress on key areas can be blocked due to the communication impasse.
Better Solution
The first step is to recognize that the problem exists and is not about you finding a better way of saying the same thing. Once you begin hearing the same questions over and over again in slightly different variations, pause and take a step back. Engage with stakeholders and allies to figure out what are the real reasons behind the resistance that you are facing.
If you find that there are reasons that lie behind the consistent questioning that go beyond just comprehension, work actively to find an alternative approach without compromising your core goals. Then, apply good change management practices to help drive the needed transformation.
6: Spaghetti Sharing Model
A Spaghetti Sharing Model does to the security of a Salesforce organization what spaghetti code does to the maintainability of an application.
Problem
In classical software applications, there is a well-known concept called spaghetti code. It happens when programmers work without design, practices, or the necessary experience to implement a system. Happily, on Salesforce, we rarely see spaghetti code to this extent. It can occur, but in my experience, it is quite rare.
What does occur frequently are Spaghetti Sharing Models – that is to say, sharing models that are so complicated that even their designers can’t reliably tell in a specific case why someone has or hasn’t got access to a given record.
Solution
The Spaghetti Sharing Model anti-pattern suggests that you address sharing
requirements in an incremental, iterative way, seeking as closely as possible to meet the business need but not enforcing any technical standards or overall design.
Result
- Records are shared with some users without anyone fully understanding why
- Record access is missing from some users without anyone fully understanding why
- Pinpointing access issues is extremely difficult
- Making changes to the sharing model is either considered entirely off limits due to complexity
- Changes to sharing often lead to new issues that are difficult to understand and fix.
Better Solution
At the risk of provoking severe retaliation from agile fundamentalists, I will suggest that if you find yourself in an organization where there are highly complex sharing requirements, you need to stop, take a step back, and put in place an upfront design for the sharing architecture along with governance mechanisms to enforce it over time. For instance, you might introduce a principle that it is best to be parsimonious in using sharing mechanisms and make the adoption of new types of sharing subject to approval by an architecture review board or design authority.
5: Pieism
Pieism fails to contend with key architectural trade-offs, insisting instead that you can have your pie and eat it too.
Problem
Pieism is an anti-pattern that has its root cause in an aspiration to avoid having to make difficult trade-offs when implementing a system. That may be because of political difficulties or weak project leadership, but it always involves a failure to acknowledge a key trade-off that needs a decision.
In a sense, most engineering problems in software architecture and in general are about balancing a set of trade-offs. However, those trade-offs are often uncomfortable and will involve not pleasing all stakeholders.
Solution
Pieism suggests as a solution to one or more important trade-offs in your solution that the trade-off is not real, that you don’t really have to compromise, and that you can in fact have your pie and eat it too. Sometimes this is done by ignoring the trade-off or sweeping it under the rug; sometimes it is acknowledged but special pleading is deployed to suggest that this case is somehow special and therefore the trade-off does not apply.
Result
The result of Pieism is the resurgence of the trade-off you’ve tried to ignore. Murphy’s law being what it is, that will probably happen at the most inconvenient point in your project life cycle and cause major damage to your project.
Of course, the specific damage will depend on the trade-off you have been ignoring.
Better Solution
The way to a less pieist future lies in openly acknowledging the trade-offs to be made and engaging constructively with stakeholders about the options. Often, there are ways of giving stakeholders more of what they all want, but it may come at an additional cost or a longer timeline.
4: Automation bonanza
Automation bonanza is what happens when you fail to govern how automations are used on your key objects.
Problem
The problem that automation bonanza tries to resolve is how to accommodate different architectural styles or preferences when creating automations on Salesforce. That occurs almost inevitably when you have multiple teams working on the same objects as part of different projects and often coming from different implementation partners.
There are many ways to automate business processes in Salesforce, and different teams will have different takes on the best way for their particular requirements.
That is fine if you have just one team working on its own objects but gets messy when you have more.
Solution
Automation bonanza responds to the multiplicity of automation options and the commensurate multiplicity of automation approaches by allowing for diversity. This reduces coordination requirements between the teams and usually doesn’t result in short-term issues.
Therefore, it can be quite difficult to spot that you have a problem or are generating a problem before things have already gone wrong.
Result
- Slowing performance on key record pages—sometimes, saves can take a long time to complete.
- Failures in integration call-ins, especially where these update records in batches or in a bulk fashion.
- Failures in batch jobs or import jobs
- Strange, unpredictable errors occurring in the UI, typically associated with a save or update event.
- Difficulties in debugging issues occurring on the platform as interaction effects from automations overshadow the general picture.
Better Solution
The key to avoiding the automation bonanza anti-pattern is good architecture governance around your core objects and their automations. Some things to keep in mind in order to do this include the following: You should start by defining which types of automation you want to use in your org and for which use cases. Ideally, you want a number as close to one as possible for each object.
Choose either flows or triggers as your go-to automation type and stick to it. It is possible to mix Apex and flows safely, but it requires careful planning and a good framework. If using flows as your principal mechanism, make callouts to Apex via Actions rather than by creating triggers unless forced to do so for performance reasons.
3: The Golden Hammer
The Golden Hammer makes the fundamental error of mistaking a tool that is a good solution for some use cases for a tool that is a good solution for all use cases.
Problem
The Golden Hammer solves any problems—that is the nature of the Golden Hammer. Once you have found the Golden Hammer, every problem you encounter is a fit. There is no evaluation of fitness for purpose because the Golden Hammer is obviously the right solution.
The tech industry, in general, is very prone to Golden Hammers. We are always looking for the next cool technology to solve our problems. Salesforce with its
aggressive sales approach and Kool-Aid drinking community is perhaps even more prone to this anti-pattern than most platforms in the technology space.
Solution
The solution proposed by the Golden Hammer is the Golden Hammer. That is to say, whatever the problem, whatever the parameters of the problem, they will somehow be twisted into something the Golden Hammer could conceivably deliver, or alternately, the Golden Hammer will be twisted into something that delivers a solution to the problem.
If you have to pick, it’s better to mold the problem to a bad-fitting tool than to use a tool for a problem that it is definitely unsuitable for. However, it goes without saying
that neither of these options is particularly good.
Result
- At a minimum, you will end up with a gap versus the requirements that you were meant to fulfill as there will be areas the Golden Hammer didn’t really manage to solve because it’s not the thing it was meant to solve
- Higher cost and more customization work as you increasingly stretch the Golden Hammer beyond its capabilities.
- Additional maintenance work and resulting cost as a result of the overstretched solution that has been created.
- Reduced faith in the real capabilities of the Golden Hammer within the organization, even where it is genuinely a good fit.
- A need to maintain a specialist skillset across different areas in your business that will persist even when the hammer is no longer popular or trending.
Better Solution
In the Salesforce ecosystem, we are constantly bombarded with new features, new toolsets, and new ways of doing things. While that is great, changing an approach that has worked for you in the past and that continues to deliver value to your organization should only be done after careful consideration and definitely not because Salesforce has just launched a shiny new toy.
Instead, take a gradual, incremental approach where you try out new toolsets of smaller features and projects that do not have a business-critical impact. Don’t just do prototypes or proofs of concept (POCs) as these are easy to get right but use them for real but limited business use cases. Get the learnings, then scale it across your estate if it genuinely delivers value. If it doesn’t deliver value to your organization, leave it alone, even if it’s very cool.
2: Big Ball of Mud
A Big Ball of Mud is a system that has lost all internal structure and coherence and can only be partially understood by its original creator(s) and not at all by anyone else.
Problem
A Big Ball of Mud is what happens when all internal structure within a system collapses and what you are left with is a big ball of undifferentiated mud that is impossible to understand or change. You might be able to keep it running with enough firefighting, but you’ll never make it work well or significantly change it.
It is a response to a system that has such great pressure to deliver functionality in several areas, that going along with any idea that seems to deliver the functionality in question seems to be a good idea.
Solution
The solution proposed by a Big Ball of Mud, in general, is to put your trust in some team or person to just get something done with no regard for the consequences. It is often attractive in pressured situations because it gives you a seemingly good way out of your predicament without having to pay the costs of disciplined development or implementation.
Result
A Big Ball of Mud is an end state for a system. Once the system reaches a state of total internal disorganization, the only way to keep it running is to have the one or two people who still partially understand how it works continuously firefighting to keep it going. You will neither be able to make changes that are anything other than trivial nor will it be realistic to refactor the system into a reasonable state. It would be cheaper to rebuild the key modules, which is what tends to eventually happen with these kinds of systems.
Better Solution
The Big Ball of Mud scenario reveals a profound lack of technical discipline and respect for craftsmanship within the executing organization. If your technical culture does not value good practice, architecture, well-structured code, and abstractions, but instead values cowboys just getting something up and running, no matter how quick and dirty, then you will be prone to end up with Big Balls of Mud.
To be sure, there are situations where quick and dirty is good enough. If you’re writing code for an ephemeral marketing campaign, a research project, or a throwaway prototype, then you don’t have to care so much about whether the system you create can evolve. However, for most of us, most of the time, this is not the case.
1: Hero
A Hero Anti-pattern is when an urgent delivery problem is solved by one or few people stepping up and putting all of the work on their shoulders – instead of spreading it out.
Problem
The Hero anti-pattern generally purports to fix an urgent delivery problem that has occurred either in a project context or during normal operations. When it occurs in normal operational mode, this is often in a context where firefighting issues with the system have become a run-of-the-mill occurrence.
Solution
The Hero anti-pattern proposes to solve the problem described in the preceding section by allowing an individual or a small group to take too much responsibility for resolving it effectively by working as much as is required, even at some cost to themselves, to get things done.
Result
- The Hero will start to feel the pressure.
- Heroes don’t scale.
- Heroes aren’t replicable.
- Heroes can accumulate serious technical debt.
- Heroes don’t have time to explain how things were
implemented- - The rest of the team may feel overlooked.
Better Solution
The fundamental problem with the Hero anti-pattern is that you are relying on specific individuals, with often hidden knowledge, working hard – usually too hard – to get things done rather than on repeatable, transparent, and manageable processes that will allow you to continue to deliver, even as the context and the people involved change.
The primary way to get away from the Hero anti-pattern is therefore to work on your processes and spread skills and knowledge systematically across the team.
Summary
Thanks Lars Malmqvist for a great session. Please check our friend Lars Malmqvist book to learn more.
