Today, we concluded another successful Salesforce.org Open Source Commons Community Sprint. It’s no surprise that these events are important to me. They’ve been one locus of my personal/professional growth over many years, including beginning to dabble in “developer” tools like Github, VS Code, sfdx, the programming language YAML, and the CumulusCI suite.
The maintainers of the Data Generation Toolkit project (maintainers = fancy word for project leaders) have established some fantastically useful workstreams and work outputs!
- A repository of community-vetted recipes for fake datasets across a variety of products (NPSP, EDA, Outbound Funds Module, Program Management Module, regular Sales Cloud, etc)
- A set of instructions for building scratch orgs with certain settings that are most similar to our real Salesforce orgs
- New “providers” for generating fake data types that fall outside the scope of the main one. Examples include, Foundation names, Academic Department names, Nonprofit names, Nonbinary human names
- Offered many community presentations and publications about the benefits (necessity?) of accurate-seeming fake data
- Feature requests as Snowfakery (the tool) continues to improve
- Reviews of third-party apps that have the capability to seed sandboxes
- A culture of learning and welcomingness
- And I’m sure more stuff!
Difficult to learn, easy to use
One of the quandaries of learning Snowfakery (and its parent tool, CumulusCI) is that it takes an average of 6-10 hours for someone with little/no experience with command line tools to download the appropriate packages and learn how to do (relatively) simple things like access the right folder (aka repository), find the right files, make a new Salesforce org with the right metadata, and conceptually grasp “version control.”
These are not Snowfakery problems, they are bridging the gap between administrator-to-developer problems. From this perspective, it is very difficult to determine the difference between Snowfakery issues and computer environmental issues. Also, it is easy to think that an application like VS Code is for Snowfakery, instead of for many types of code, and which Snowfakery runs “in” as a sort of user interface.
Once all of the programs are installed and the person is in the right repository, *actually running* Snowfakery is simple and successful for pretty much everyone. Learning how to change a recipe file and ask for approval on these revisions is relatively easy, too.
Snowfakery requires significant activation energy and few capacity leaps one you can connect the main ideas and functions. The documentation is great and there are lots of examples that you can copy from. So, how do we get people over the hump?
Two (?) paths
It seems that there are two paths to explore in response to this conundrum.
- Somehow use technology to make CumulusCI easier to install
- Substantially improve training and expectation-setting to reduce frustration during the lengthy set up steps
I don’t have the knowledge to address issue 1…
… but as for issue two, I have some ideas.
- Don’t learn CCI alone! When you get frustrated, it’s so helpful to have a buddy to reach out to, whether they are at the same confidence level as you or more of a mentor figure.
- Expect that it will be hard, but rewarding. This is not the same as learning a new Salesforce feature/function but a new way of working
- Separate the concepts that are generic developer concepts (like continuous integration, version control, Github style of collaboration) from CumulusCI fundamentals (like executing a task, flow, or snowfakery recipe run)
- Learn by doing – don’t just do the Trailhead, but rather, get the technology set up and get to work on a real world problem, an “issue” in Github, or a personal goal
BTW, I still think a one-click install is the way to go 😉 Not much gained by banging my head against the install-wall, but also, I don’t want ease of use to overshadow personal/technical growth.
What are we enabling learners to do?
I have been focused for the past couple of years on BEING a learner and giving back to the community as a project leader.
Today, a collaborator asked a very provocative and compelling question: How much can we reduce the time for someone to run a Snowfakery recipe right away in a target org of their choice?
As much as I appreciate this question and I have asked it myself many (!) times, my reaction today surprised me a bit. I immediately thought, “What’s the hurry? Enjoy the ride!”
What?!
After years of wanting to throw my computer out the window, now I’m thinking nostalgically about all of that frustration. I don’t want to deny anyone the pleasure…
But on a deeper level, I also realize that the times when a recipe in our repository will match what someone needs 100% and be ready to go are extremely rare, bordering on impossible.
The glory of Salesforce is customization! So why would someone run one of our zero-customization recipes and be satisfied? I suppose it could happen, but it seems like not the most useful premise.
If we aren’t preparing people to simply run recipes, but rather to revise them, then the degree of prep increases exponentially. Furthermore, if, on top of that, we want to equip people to share their recipes, then we have yet another layer of complexity. These processes take some developer-y-elbow-grease. Should everyone involved in the project strive to “develop” these skills?
Depending on the day, I could argue on both sides of this.
Rethinking personas
It seems to me that there is a tension between simplicity and complexity, standardization and customization, investment and return on investment. How much technical knowledge does someone need to use a tool like Snowfakery?
Early in the project, we established “personas” as in, different stock characters who are likely to intersect with the project. We came up with 3: administrator, developer, consultant.
I wonder now if we can turn these personas into more functional archetypes:
- Recipe requesters (ie “I need fake data to show…”)
- Recipe runners (ie “I know how to run a recipe that already exists…”)
- Recipe writers (ie “I know how to write a recipe from scratch using a variety of Snowfakery features”)
- Tool enablers (ie “I know how to add features to Snowfakery”)
Many of these functional personas cut across traditional career paths like admin/dev/consultant. Which I think is really cool!
Of course I, we, want everyone (!!!) to be able to use these tools, but I think we also need to be honest that they are not “plug and play” (now, or possibly ever?).
So my question is, what do you want to be able to do? Then, we’ll figure out a plan to get there!
This blog has long been a place for provisional thoughts that I am grappling with. Today, that thought is, “should we make hard things easy/er?” Yes, to increase adoption and accessibility, but hopefully not to the extent that we lose the thrill of learning, joy of collaboration, and eagerness to solve deliberately hard problems.