Thanks for sharing. Although it isn't my application domain, their considerations were nevertheless interesting.
On a general note, this bullet under "Lessons Learned" circa 48:00 hits home:
> A rationale for each rule educates developers and gets their buy-in
It's been my experience that standards which embody this philosophy are the most pleasurable to work with. On the flip side, I've dealt with "updated" standards which have directly perpetuated technical debt as a consequence of rules defined to address temporal issues that were relevant at the time but passed over in subsequent revisions due to lost tribal knowledge...it's always a challenge addressing this class of rule, even if just trying explain to a new developer on the team without making that person feel like a complete tool.
On a general note, this bullet under "Lessons Learned" circa 48:00 hits home:
> A rationale for each rule educates developers and gets their buy-in
It's been my experience that standards which embody this philosophy are the most pleasurable to work with. On the flip side, I've dealt with "updated" standards which have directly perpetuated technical debt as a consequence of rules defined to address temporal issues that were relevant at the time but passed over in subsequent revisions due to lost tribal knowledge...it's always a challenge addressing this class of rule, even if just trying explain to a new developer on the team without making that person feel like a complete tool.