> Surely, you have a process that you follow in your own work though?

Personally, no. I have spent enough time at enough organizations to simply adapt to whatever they do. But if I want to write some code I just do that. I might toss in testing or whatever for bigger projects, but it’s all ad hock.

Processes are about repeatability, but for personal projects you can customize based on more specific goals. If I want speed, accuracy, or whatever I am going do made different choices. I am even going to change things up based on whatever mood I am in at the time.

The moment your personal project becomes an open source project with you as the maintainer, there will be process. Manually making releases without any process gets real tiring, real fast.

> There are formal codified processes and there are informal tribal ones

True but misleading. A lot of the time the difference is simply doing a bunch of process activities versus not doing them. E.g. imagine team A develops software in a more-or-less sensible way, and team B spends 80% of their time doing the same things that team A does and 20% of their time estimating how long those things are going to take. It seems fair to say that team B has not just different processes from team A or less formal processes than team A, but actually has more process than team A.

> Processes mitigate risk. Just because that risk isn’t important to you doesn’t mean that risk isn’t important to someone.

Processes can be a mechanism for mitigating risk. They can also be entirely devoid of value.

I'm not saying all process is worthless, but someone who wants you to follow a process should be able to tell you who that process benefits and how. If the only reason you're following the process is because it's the process, it's probably a waste of time.

I’m not sure we’re talking about the same thing. What you’re talking about is the difference between value-added processes vs busy work disguised as risk mitigation. Both are processes but of differing value.

Pointing out bad processes does not refute the point that processes exist and they exist because somebody is trying to mitigate a risk. It’s just a comment about the effectiveness of the process design.

In that case your claim is completely unfalsifiable. I might equally well claim that processes exist because they're works of art, and the fact that some processes are not aesthetically pleasing doesn't refute that.

How is “the intent of a process is to mitigate a risk” completely unfalsifiable? Is your claim they exist simply because they exist and have no underlying purpose? You can evaluate the risk, as well as evaluate the effectiveness of the process at managing the risk. You falsify the intent by describing the relevant risk severity/probability reduced by the process.

You not agreeing with the risk assessment is not the same as denying the intent. It’s also not the same as saying it’s effective at managing the risk.

If there’s a required review, you may think it adds no value. But you may also be ignorant of the downstream risks it mitigates. “You” may not care, but somebody downstream does. “Your” ignorance of the situation doesn’t invalidate the process, although it may speak to poor leadership in terms of making sure people understand why the process exists. You can, however, invalidate the process by interrogating the intent. E.g., maybe the downstream interaction has changed and the review is no longer necessary. Maybe the probability has dropped enough to become a negligible risk because of a design change. The process can be falsified in terms of meeting the intent because the risk would no longer exist.

Re-reading this, I realize it’s needlessly wordy. To condense my point, you can simply ask, “what risk is this process trying to mitigate?”

If the answer is “none”, it validates your point that the process is needless and the claim about risk is proved false. But most responses will be able to articulate what the risk is, whether it’s relevant to your position or to someone else.

> But most responses will be able to articulate what the risk is, whether it’s relevant to your position or to someone else.

Not my experience at all. Most responses to the question as phrased would be "huh?"

I would claim that most processes are not born of an intent to mitigate risk; in my experience there's rarely an intent at all, people cargo-cult the idea that they should have processes without understanding why or even conceptualising that there should be a why.

I think I may understand why we’re slightly talking past each other on this.

I’ve certainly worked in organizations that continued processes out of sheer inertia of “this is the way we’ve always done it.” While someone may have inherited a process and continued using it without understanding why, if you reach back to the initiator they will have a risk they were trying to mitigate. Even if their predecessors are oblivious. Again, I would chalk this up to a failure of leadership to explain the “why” when passing it off rather than a failure of process.

Even in instances where people copy processes just because they are emulating a different org, that original organization had a risk they were mitigating. Blindly following suit like an automaton says more about the person pushing it than the validity of the original intent.

A process can certainly outgrow its intent. If I am prescribed medicine and blindly continue taking that medicine after I’m well, it doesn’t mean the there was no original, valid intent. The risk profile changed; the process did not update keep inline with that changed risk profile.

I've worked with many organisations that had processes, that placed a lot of value on process. At most one of them would have described their processes as being about risk mitigation. For all I know it may be true, as a kind of etymological curiosity, that the concept of process originated as a means of originating risk, but that's certainly not a useful perspective for understanding how and why most organisations that adopt processes today do so.

>Processes mitigate risk.

Processes mitigate risk of repeating a mistake, but they don't prevent new ones, unless you have very wise people building them, and keeping them current.

Processes can be thought of as an institutional form of OCD. There are costs, and they shouldn't outweigh the benefits.

>Processes mitigate risk of repeating a mistake, but they don't prevent new ones

I’m not sure I fully agree. Reactive processes prevent recurring mistakes, because they layer on a requirement to close a gap. I think people can go overboard, particularly when they are myopically focused on a single risk in their wheelhouse and miss the big picture.

Better processes can be more proactive. For example, a process requiring a failure-modes-effect-analysis can identify potential faults that have never been experienced. Developers may feel like they don’t need to work on an FMEA because they “know what they’re doing” and miss latent failure modes