I come across a lot of people who proudly claim that “I am a process person” and say processes are nothing but practices that are standardised. With more and more people coming into software management after a 3 day course to claim themselves as a master in managing software development, the more cargo cult processes come to dominate the industry.

Processes are necessary and they bring a predictable output for a given set of static conditions. It is useful for working on predictable items like visa applications, pasteurising milk, preserving food, approving loans etc on a scale. Practices on the other hand deal with dynamic systems, it is like the race drivers going for a track sighting before the race or the chefs using only simple english to talk to their cooks. Practices are negotiable, it is backed with a value and intent and requires discipline to get it followed while processes are non negotiable and usually enforced through a compliance mechanism.

Processes are helpful as an abstraction, when the person following the process does not worry about what they are doing as long as they are compliant. A good example in the cooking space is the difference between a cook in a fast food chain’s kitchen vs a cook in a fine dining restaurant. The fast food chain cook will always set the oil temperature to the exact specified temperature, fry the pre cut potatoes (which were cut to certain specifications) for the exact amount of seconds prescribed and put it out on the plate. This can be done by cooks with zero knowledge of cooking (easy to train and staff), if something goes wrong or any step in the process has been missed, then you have run into a mess. If the potatoes are of a different cultivar, the production stops. There is no resilience but it is incredibly efficient.

On the contrary a cook in the fine dining restaurant may have a set of practices like waiting for the oil to come to near smoke point, test frying a piece of potato for tasting it, then adjusting the cut sizes if required to perfect the fry before serving the meal. There is so much of resilience but it is inefficient compared to the fast food chain. You also need very capable and knowledgeable people.

Both processes and practices have their respective places, it is trouble when people use it interchangeably in software development. Majority of the development related tasks need sound practices based by value and intent in place. If a practice is not feasible, replace with another which will help realise the value. If clean code has to be ensured, a process person will put a detailed code review process in place with hierarchy of responsibilities and often keep code under lock and key. A person who is keen on the intent and value of code reviews will come up with many different practices like integrating lint and static checks in IDE, pre commit and pre push hooks to catch obvious guideline deviations early, mob reviews once in a while and spot refactoring etc. Each of the practices are negotiable and interchangeable as long as the value and intent remains the same.

The fast food chain approach does not work for all aspects of software development. Processes expect many things to be static and developers need not know the big picture. Processes require work that can be broken down, carried without knowledge from other parts and can be assembled later. Instead in reality there is so much of interaction between broken down work and you need developers who are well skilled in both communication and technology to get the job done in a dynamic landscape, along with the big picture. Practices are not processes.