When we were building BrightChecker’s synchronisation system, we discovered something that is easy to overlook.
A synchronisation process can be working perfectly and still be almost invisible.
Information goes into a queue.
The queue sends it to the server.
The server confirms receipt.
Everything is fine.
But what happens if something isn’t fine?
Building the synchronisation queue
The synchronisation system took around two months to build.
During development, we needed to know exactly what was happening to every individual item.
Had it uploaded?
Had it failed?
Was it waiting?
Was the connection unavailable?
So we created a synchronisation screen inside the field section.
We could filter it by job and see which items had succeeded and which had not.
That was extremely useful while we were building and testing the system.
Then we had a decision to make
Once the system was working reliably, we could have simply hidden all of this.
After all, most inspectors don’t want to manage a synchronisation queue.
They want to carry out an inspection.
And that is still the right default.
The normal user doesn’t need to think about the queue.
But we didn’t want to pretend that software never encounters an edge case.
Because it does.
What if?
What if the connection disappears halfway through something?
What if the signal is extremely poor?
What if something unusual happens during synchronisation?
What if a particular item doesn’t behave as expected?
The right answer isn’t to tell people:
“That can never happen.”
Real systems don’t work like that.
So we made it configurable
The synchronisation screen can be exposed through the organisation’s settings.
That means a business can choose to make it available when needed.
If a user encounters a problem, they can see what is happening, capture the information and provide it to us.
Because BrightChecker is browser-based, fixes can also be pushed out without requiring everyone to install a completely new version of a native application.
That gives us another way of responding to unusual cases.
Edge cases are part of good design
We don’t build software assuming everything will always go perfectly.
We test the normal path.
Then we test the awkward path.
Then we ask what happens if something even less likely occurs.
That doesn’t mean exposing every technical detail to every user.
Quite the opposite.
Good design can hide complexity while still making that complexity accessible when it is genuinely needed.
The synchronisation queue is a good example.
Most people should never need to think about it.
But if you do need it, it is there.