IT SIMPLY WORKS! … UNTIL IT BREAKS. STANDARDS, BEST PRACTICE AND ENTERPRISE PATTERNS FOR DECLARATIVE SOFTWARE DEVELOPMENT (Tahoe dreamin 2018)

Editor's Notes

• #4: Guide towards the topic. Inquire, who works within a guided process Ask for bad expience etc.
• #6: Hands up who knows this. And hands up who pushed something like that to prod It’s not about fingerpointing - we all did (and do) that in emergencies or when in hurry. But we have to do better and clean up as soon as possible
• #9: What do we mean by enterprise patterns? It basically describes a process that reduces random or unpredictable results and therefore reduces risk for the org’s health and data integrity. Enterprise patterns basically means: Establish a workflow, make steps compliant and follow best practice in terms of quality, engineering and security standards. Then adhere to it and track that you’re following this process. Take the standards that you expect from enterprise grade software development and use them in your declarative customizations
• #10: The most important pattern is establishing a routine for handling changes. This starts with the way you collect change requests: Let users give you some explanation - commonly refered to as a “user story” (As <role> I need <feature> so that <task/problem to solve>. The more crucial part we want to stress here is the way HOW you do changes. While Salesforce gives you the ability to change almost everything straight in production, this doesn’t mean you should work that way. If you look a little closer, Salesforce even warns you to make any changes directly in production. You might have heard this already, but a core principle to reduce or avoid an unpredictable state of your org and logic, and therefore a number one advice if you decided to treat declarative changes in the same way you treat enterprise software development: Don’t develop in your production org (except reports, dashboards and list views), don’t have even have more than a few people with the permission to bring in changes. Establish a role for this job, take care to select experienced people for this role and make sure they understand that they are the keepers of your org.
• #11: It’s not about being perfect right from the beginning. If you didn’t document right from the beginning, you will have a hard time to “fretro-document” everything. Yet it is overly important that you keep your knowledge about the org somewhere accessible. Have you ever “inherited” an org? <Ask the audience> Did you find at least some documentation? In an ideal world, you will create an index of all object and all logic, that explains - most importabnt - the ideas and rationale - THE WHY - behind customizations. The world is not ideal - we know that. Make a humble start: Try to write down - at least for your new customization - why you did it and what you did. Whenever you touch something, make it a habit to write this kind of documentation for something that’s already there. You will see that very soon, a nice compendium to refer to will be around.
• #29: Its important to know that everything is in a good shape before you start. There, run all local Apex Unit Tests before you start developing. Choose running local tests so that everything that run everything that i’s what creates your test coverage. No use running all unit tests because these include managed package tests - you can’t resolve errors and salesforce doesnt count them into your test coverage. If tests fail - keep a log. It’s not good and you should seek to resolve test failures. But a lok will help you and your team to identify the person / team to fix the issue. Expect these failures to happen upon your deployment too.
• #30: Its important to know that everything is in a good shape before you start. There, run all local Apex Unit Tests before you start developing. Choose running local tests so that everything that run everything that i’s what creates your test coverage. No use running all unit tests because these include managed package tests - you can’t resolve errors and salesforce doesnt count them into your test coverage. If tests fail - keep a log. It’s not good and you should seek to resolve test failures. But a lok will help you and your team to identify the person / team to fix the issue. Expect these failures to happen upon your deployment too.
• #41: Not so fast. T
• #43: It’s time to complete your documentation. Does your solution match the requirements? Does is satisfy acceptance criteria?
• #46: Does the logic work as described? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #47: Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #48: Does the logic work as described? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #49: Does the logic work as described? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #52: Deployment
• #53: Deployment
• #54: Deployment
• #55: Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #56: Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #57: Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #58: Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #59: Does the logic work as descibed? (you did document the design, right?) Are all acceptance criteria satisfied? (you did write that down, too, right?) Does the logic affect you when you’re doing unrelated things? (well, too bad then. start over and build better entry criteria)
• #60: Relevant Salesforce Help / Documentation