Automation 201: Processes and Frameworks

We need more [better] processes to make this operation repeatable!

Working in a corporate IT development environment, I hear that statement a lot. Every time something goes wrong with a deployment, a project is running late or over budget, a team is not meeting its objectives, the root cause meeting always ends with this conclusion. Well, at least it seems to be!

Do I disagree with this conclusion? Not necessarily!
I think there are better ways of handling these issues through tools, automation and organizational structure, but processes do have a critical role to play in a stable production environment.

Now there is nothing wrong with processes. However, processes are not free! While they make operations repeatable, they are not reusable.

Repeatability adds consistency to an operation, reusability makes it faster.

I came to a revelation recently that contrary to popular belief, processes do not add reusability. They only add repeatability and predictability.
Think about it, a checklist to deploy an application is repeatable and provides consistency of the output (as long as the checklist is complete). However, it's not reusable! Every new person executing the checklist for the first time suffers from the same learning curve and pitfalls. Even on the millionth time, the time taken to follow the process is still the same.

Processes are repeatable, frameworks are reusable.

And the main reason behind that is that a process aims to replace the human intellect by "documenting" all tasks that need to be accomplished for repeatability, whereas frameworks insist on automation based on conventions that need to be followed.

Take for an example, memory management "best practices" in C programming language.
One way to address memory saftey is by mandating memory-management be a line item on a code review checklist. This is a linear complexity operation. More memory operations in the code, more time it will take to verify during the code review.
Conversley, you can come up with a memory management convention, like Objective-C's memory management guidelines.
Now during the code review you only need to make sure the guidelines around memory allocation/deallocation have been followed or not; no matter the size of the application. Infact, Apple was able to take these conventions and codify them as ARC, completely automating the memory safety reviews.

Process is a set of tasks to complete, framework is a convention to follow.

And, this is the key difference. Next time you have a problem to solve, see if you can build a convention-based framework, instead of a task-based process.