As some of you may know, I'm the author of the book Clean Apex Code.
In that book, I discussed many core software engineering principles and how they apply to Apex code. But I spent very little time explaining how they apply at the macro level: to an entire Salesforce org, and to non-code metadata types such as Flows, Validation Rules, and even Fields.
More importantly, it's entirely possible to work with clean code in a dirty org.
What's a dirty org?
You know you've worked in a dirty org if you've ever experienced any of the following emotions
or
and the most common one
In a dirty org, nothing is simple.
Every small change from the business becomes a 2-sprint project. Every time you fix something, something else breaks. There are tons of metadata that is no longer used but no one dares to delete it.
Every "Do you have 5 min for a quick change?" Slack message gives you anxiety.
Every time you get a new requirement, you spend an entire day trying to figure out where it should be created (i.e, is there an existing Flow you can extend? or do you start from scratch).
Over time, I want this blog to help people answers to questions such as (aside from providing updates on HappySoup):
- How do you know when two Flows should be combined into one, or when splitting one into smaller ones causes more harm than good?
- How do you tackle low cohesion when “clicks not code” creates solutions spread across multiple metadata types?
- How do you clean up the org from unused fields, record types and permission sets?
- What technical debt really is and how you can use it to your advantage, and when it becomes a problem
- How do you decide if data validation belongs in Validation Rules, Flow conditions, or Apex?
What's a clean org
Here's the simplest definition of a clean org:
A clean org is easy to work with and evolve. You know where to make changes. There are no surprises. Changes in one area never break functionality somewhere else.
This may be aspirational, but I hope that with this blog, we can move in that direction together.