Process should amplify good engineering judgement, not attempt to replace it

2026-06-23T08:30:00.000Z

I’ve worked in a number of organisations—particularly those with a strong manufacturing background—where there’s a belief that if you define the software process in enough detail, good outcomes will follow.

It’s an understandable idea.

In manufacturing, repeatability does lead to quality. But software doesn’t behave the same way.

At its core, software engineering is still partly a craft. It relies on judgement, trade-offs, and learning as you go.

That doesn’t mean “no process”—far from it.

A good software process should clearly answer questions like:

• How are requirements captured and tracked?
• What level of design is expected, and how is it linked to requirements?
• What standards and testing approaches are applied?
• How does CI/CD fit into the picture?
• How are tests, defects, and day-to-day work managed?
• What tooling underpins all of this?

But it should stop there.

I’ve been on the receiving end of many external audits over the years, and the good assessors always seemed to focus on two things:

• Are you doing what you say you’re doing? Show me.
• Are there any obvious gaps in your overall approach?

If your process is clear and explainable in a few minutes, both of those become straightforward.

When it isn’t:

• It turns into a checklist exercise
• It creates a false sense of control
• Engineers optimise for compliance, not outcomes

I’ve seen release processes where the focus shifts to “have we followed every step?” rather than “is this actually ready?”

That’s the tipping point.

The best processes I’ve seen are:

• Short
• Principle-driven
• Easy to internalise

They provide guardrails, not scripts.

Because ultimately:

Process should amplify good engineering judgement, not attempt to replace it.