SuiteScript Process - Enablement, not Enfeeblement
Created: November 19, 2020
A timely quote today from author James Clear, who much more clearly and succinctly communicates my message from yesterday:
Many people work hard, but few people work on the highest and best thing. Usually, it takes no more effort to work on high leverage tasks than it does to work on low leverage ones. It's just a matter of directing your energy.
James Clear, author Atomic Habits
Now onward to Process day! One of the most common objections I hear to adding standards and processes to a SuiteScript team is:
We're moving too fast for processes!
The highest profile software teams in the world - think teams at Google, Amazon, SFDC - are able to deploy standardized, reviewed, tested code to Production on a daily basis - or even faster - without being disruptive to users or operations. I can assure you they're not able to do that successfully because they have no processes in place.
They're not "moving too fast for process"; they're moving so fast because they have disciplined and mature processes.
My college roommate and best friend is a senior software engineer at Amazon. When I asked him, "How often does your team deploy code into Production?", he said:
"Couple times a day. We have automated pipelines for testing, deploying, monitoring, and rolling back if monitors detect issues."
Do they have some advantages we don't here in the SuiteScript world? You bet. For starters, they're not billing anyone by the hour, so they're highly incentivized to be hyper-efficient in their development cycles.
But even these teams didn't just magically start out with these capabilities. Coupled with sound software design, they've consistently invested in designing, defining, and refining their standards, processes, and automations over months and years, sharpening them to a fine point to where they can nearly implicitly trust them.
Will you be automatically deploying new code to Production multiple times a day? No, and I'd probably advise you don't do that anyway. But you can absolutely get to a place of faster, more consistent, higher confidence, better-tested deployments - though it can't happen if you never get started.