If the Process Isn’t Clear, Software Won’t Work Miracles

There’s a common expectation in project discussions:

“Once we have the system, everything will fall into place.”

I’m cautious about that idea.

Because software doesn’t create a process.

It simply turns what already exists — good or bad — into a system.

If it isn’t clear who does what, when decisions are made, or who handles exceptions, no interface can fill that gap.

It may simply move the problem somewhere else.

Software reflects the process

A good system usually keeps three things clear:

• who is responsible for what
• what each status actually means
• which steps can be reversed and which ones cannot

These things don’t necessarily have to be documented formally. But at the very least, the team needs to understand them in the same way.

Otherwise, every new button creates a new argument:

“What does this status mean?”

“Who is allowed to change it?”

“Why did the system allow this?”

The problem isn’t the technology.

The problem is an unclear and unagreed way of working.

Automation can speed up confusion too

When you automate a well-defined process, work becomes easier.

When you automate a messy process, mistakes simply spread faster.

For example:

• the same order appears as “ready” in two different places
• a payment is recorded in one system, but the corresponding status isn’t updated somewhere else
• one employee knows how to handle an exception, while another follows the system and gets a different result

In situations like these, people often blame the software.

But in reality, the system is exposing a reality that the team never fully agreed on.

These are the questions I ask first

Before writing code, I usually ask:

• How does this actually work today — not ideally, but in reality?
• Where does the process most often get stuck or break down?
• Which decisions should be made by a person, and which ones should be handled by the system?
• Who owns the exceptions, and how are they recorded?
• When someone says “ready”, does everyone mean the same thing?

If the answers are short, inconsistent, or contradictory, we fix the process first.

Then we build the software.

The takeaway

Software isn’t magic.

It makes a clear set of rules faster and more repeatable.

If the rules aren’t clear, define them first — on paper, in a conversation, in a diagram. The format doesn’t matter.

Because if you put something unclear into a system, you may end up with a more expensive version of the same confusion.