What a great book, which Lars wrote even before the AI hit stage. I’m saying that because while the book is really good, it could be also blog post only, so I really admire how Lars have been able to extend the text and repeat it in several different ways that it doesn’t really look like a repetition 🙂
Jokes aside, the book is extremely important as it shows the patterns you might consider to be ok-ish and don’t foresee their whole impact.
Anti-pattern is a pattern that occurs in unsuccessful sofrware systems or projects that can look superficially like a good solution but in practice gets you into trouble.
I really loved a lot of them:
- Heroes don’t scale
- Be careful about suggesting big bang delivery approaches as it very frequently occurs where the digital transformation lacks strong leadership, so it will all fail at the end – spectacularly
- Just Do It!
- Stovepipe – respect the organization and as it is currently siloed and do nothing about it
- Intense coupling which results on waiting time for the other system(s)
- (Ungoverned) Org Proliferation where multiple partners implement their own small part of your overall instance. Great question on the CTA board, which probably never goes properly in depth
- Data export for further processing and ultimately their loss – you should aim to use compliance as a tool to become more secure and more security-aware, not as a way to get security out of the way because you’ve ticket all the boxes
- Declarative Is Always Safe! Still it might not mean that it is safe solution. I didn’t know for example that if user has access to All Flows list (and now with the Automation App it is way more common than before) they can run any of them – are you ready for that? Check great (and long) article by Aaron Costello on this topic
- Spaghetti Sharing Model – sharing can get super complicated in big orgs and I would say you really need to use Roles (or Territory Management) to help you with setting the security not in a way how the company works internally
- Use Custom Objects when possible – wrong! Overuse „Hero objects“ (the oldest of oldest such as Account, Contact, Lead, Opportunity) might be wrong as well
- Ignoring ecosystem and building where buying would be better – personally seen in and saved a lot of money to customer when I proposed the document generation solution instead of hardcoding tens or hundreds of VisualForce pages. Also building only for you means no additional development unless you will pay for it and come with the ideas
- License-based solutioning, shadow objects, etc – still there sometimes, the price push is being stronger and stronger with every price increase. But it is also about using external sites and pushing data across when it would be better to just use Experience Cloud
- Assumption-driven customization where you don’t have access to the „right“ stakeholders and depends on just part of them
- Golden Hammer (love the name!) – saw it way too often especially with junior admins who learnt something and then used it again and again for all use-cases. Also are you looking for problems you can solve with your tech stack or you start with the problem and then try to find the solution?
- Don’t depend on POCs as they are easy to get right but they are typically very limited and hard to switch for real business use case
- MINO (Middleware In Name Only) where you basically map APIs 1:1. I would say the whole integration anti-patterns are lighter in their better approach than the rest of the book and I really wonder how some of the example solve in a better way
- Enormous interface which basically can do everything but is hard to extend due to its size and complexity
- Chatty Integration which just triggers so often the other system is not able to handle it. I really love the idea of proactively asking the other system about its performance and intentionally add delay on SF side to not overload it
- Integration pattern monomania is one of the patterns where I would love to see more details about better solution. I know all the different integration patterns, but seeing it applied to the example in the book would be just awesome
- Groundhog day anti-pattern is when you just repeat yourself a lot because you don’t really try to find the underlying reason of the question. And you might not have the right communication strategy for the right audience – highly visual and engaging material might be great for workshop with general audience but for technical audience you need to have the precise and technically correct materials in a format they understand and typically use
Don’t postpone decisions beyond the latest point it makes sense to take them, even if making a decision is hard.
Two great links with additional anti-patterns – C2 and DevIQ.
While highly repetitive it is great at the same time as it shines the light on the topics from different angles and I would highly recommend the book for your library (and reading) just to be aware of all those moments when it felt like a good decision but long term probably isn’t that great.
Napiš komentář, díky!
