I get asked this question a lot.

Let me paint pictures of two companies, Process.ly and Princip.io, which have two common goals:

• Maintenance
• Security

Process.ly achieves their objectives through process.

Princip.io achieves their objectives through principles.

Process.ly - Maintenance

I pulled the following text from Process.ly's onboarding documentation.

Process For Decommissioning a Service

1. Identify and contact the code owner to get their approval documented in our Service Decommissioning Template. [Oh. By the way. They recently migrated their documentation from Notion to Jira. If you encounter any dead links, please follow their process for updating documentation.]
2. Submit a support ticket to the Observability Team to monitor access to the service for a minimum of 14 days.
3. If there is still activity on the service, create a spreadsheet with each consuming service and that service's code owner. Attain their acknowledgment and approval.
4. Submit a support ticket to the Platform/Infrastructure Team. [Oh. By the way. You'll learn that the Platform/Infrastructure Team was rebranded to the DevOps team and Alice, the listed point of contact, isn't with the company anymore.]
5. ...

Web Service Security Lifecycle Process

Security is our #1 priority and the following process ensures that all private and public facing services adhere to the standards that our customers trust.

1. Phase 1 applications are considered in-development, cannot be shared internally or externally, and may only be deployed inside a VPC with no internet gateway.
2. To promote a Phase 1 application to Phase 2, submit a ticket to the Application Security Team. [This links to Zendesk, which you don't have access to. After getting access, you find out that the App Security Team no longer monitors Zendesk. You have to reach them on Slack.]
3. Phase 2 applications are Phase 1 applications which have passed our Baseline Security Review process.
4. Phase 2 applications can be shared as internal tools.
5. To promote a Phase 2 application to Phase 3...
6. ...

You probably jumped to this line without reading all of that. Your eyes probably glazed over.

Contrast that with the principles-based approach of Princip.io below.

Princip.io - Maintenance

• Clean Up After Yourself

Don't start new work if you've identified something that is no longer in use.

Seriously. When it comes time for performance review, removing a dead service is twice as valuable as introducing a new service.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

- Antoine de Saint-Exupéry, Airman's Odyssey

• Security Takes Priority

Security is the big red button on our factory floor that brings the whole system to a halt.

Everyone has the authority to stop any non-security activity to address any security concern.

Security is the hill we choose for our final stand.

If customers don't want to pay,
if investors won't fund,
then we will go out of business.

But as long as the name Princip.io lives, do not sacrifice security.

But Eric...

Isn't this a bit of a straw man? Your comments portray Process.ly as a company that doesn't keep their process documentation up-to-date. Any company that doesn't keep their documentation up-to-date is going to have issues.

Yeah. Ok. You're going to have problems with anything if it's not kept up-to-date. That's not a "principles vs. process" problem. Maybe both can work and I'm unfairly including a comparison to an organizational problem with Process.ly.

But here's the thing: process changes way faster and way more often than principles.

Process changes when tools change. Process changes when teams change. When responsibilities change. When services change.

When you encounter a not-applicable step in a process, it's difficult to resolve. You're following a rules-based system and all of a sudden there is no rule.

Principles change slowly and rarely.

When you're working towards a principle and encounter an ambiguity, you're better equipped to proceed because there are no rules.

Don't flinch at that. Lack of rules doesn't necessarily lead to chaos. Principles provide order.

But Eric...

What about safety-critical systems, like aviation. They have process and it's led to one of the safest forms of travel.

Yes. True. And I'm not saying that process doesn't work.

I'm saying it's wickedly expensive; especially when the environment changes quickly and often.

How often and by how much do you think a pre-flight checklist changes for a typical passenger airplane?

How often do your deployment and smoke-test checklists change?

What's the cost of letting a passenger airplane's checklist go stale vs. the cost of letting a deployment checklist go stale?

The process of a typical tech company changes rapidly and the cost of stale documentation is a slow bleed rather than a firey crash.

But Eric... aren't you just repeating the Agile Manifesto?

https://agilemanifesto.org/

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Yeah. This isn't new. It's just a reminder.

References

The Impact of Prior Knowledge on Searching in Software Documentation

Write clearly »