K Cartlidge

DotNet, Golang, Node, JavaScript, Ruby, Python, PHP.

Never have a dynamically derived status flag.

An obscure title for a very niche topic? Possibly.

It is, however, the cause of subtle errors and inconsistencies in many systems I've had the 'pleasure' of working on in the past.

The situation.

Imagine if you will a billing application. There are various values that can change over time, all of which contribute towards determining the current account status:

And there are many more variables that could apply.

The problem.

So now the following happens:

This is convoluted logic, existing in several places, possibly written in different languages (eg Go or C# for the app and SQL for the BI tool).

Some of the possible outcomes:

So now you're left with uncertainty and possible differences that lead to customer complaints when one system says the status is one thing and another behaves as if it is something different.

The solution.

Systems change state when actions occur whether that be (for example) a chargeback being input, a payment going through, an order being placed, a complaint raised, or a credit applied.

Therefore:

This gives the most important thing a conglomeration of interacting systems and processes can have - predictability.

Summary.

There are other benefits. And there are 'reasons' why you may be tempted to work out some kind of status based on an easy combination of known values.

No matter how easy it seems to have something derived on the fly - for instance a quick little public property with it's own internal logic, or a disinclination to add state-setting code for every action - do not be tempted.

A single source of truth, consistent across all systems, is a kind of holy grail. Avoiding dynamic status logic can help hugely.

Never have a dynamically derived status flag.