Every business now runs on small programs doing jobs in the background. They copy files, check websites, send reports and tidy things up. Each one tells you how it went: a green tick, a "done", a red warning. Most of the time we take that message at face value.
At Balay ni Bruno & Co. we learned to stop doing that. Over a few days of ordinary work on a website we look after and on our own internal checks, three separate tools reported one thing and did another. Each one had already led someone to a wrong conclusion before we caught it.
The Three Ways It Happened
A small program removed one line of code from a set of web pages. On Windows it also quietly changed the invisible character at the end of every line, so every file it touched grew. The homepage got bigger while losing a line.
A sync between computers printed FAILURE while it had in fact succeeded. Separately, a health check was started with a broken file location. It ran nothing at all, and still reported success.
A status check written for one computer was run on another where those systems were never installed. It showed several red alerts and warnings. Every single one was a false alarm.
Case One: The Difference That Was Not There
The first case shows how a small, invisible change turns into a real cost. Later on, someone compared the live homepage with our own copy, saw that the sizes did not match, and wrote down that part of the live page existed nowhere in our files. That note went onto a status board as a blocker. It held up a simple two-line menu update for days.
There was no missing content. The words were identical. The only difference was the invisible line endings the earlier program had changed.
What we concluded at first
- The live page and our copy are different sizes
- So something on the live page is missing from our files
- So the update is blocked until we find it
What was actually true
- The words on both pages were the same
- A rewrite had changed only the invisible line endings
- Nothing needed finding, and the update was safe
The fix was a small setting that tells the program to leave line endings exactly as it found them. The lasting lesson is bigger: any program that opens a file, edits it and saves it back must keep the line endings as they were, or it will change every line of every file it touches. And before deciding two files really differ, make the line endings match and compare again.
A file size is not evidence on its own. Two files can differ in size and say exactly the same thing.
Case Two: A Green Light Is Not Proof
The second case came in two parts. A sync printed FAILURE, yet when we opened the files and read them, everything had arrived. And a health check that was pointed at the wrong place ran nothing at all, while the computer still reported that it had finished without a problem.
So we changed how that check decides. It no longer trusts what the sync says about itself. It compares the actual file on both sides, and only calls it a match when the contents match.
Note what the tool says happened, but do not stop there.
Look at the file, page or record the job was meant to change.
Check what is inside, not the size and not the status line.
Call it done, or not done, from what you actually saw.
Case Three: The Check That Cried Wolf
The third case is the one that looks harmless and is not. A status check had been written on one computer and looked for systems at fixed locations there. Run on a second computer, where those systems had never been installed, it lit up red for each one.
Why does that matter if nothing was broken? Because a check that shows red for things that are fine teaches the person reading it to skim past red. That is exactly how the real problem gets missed on the day there is one.
A false alarm is not harmless. It slowly wears down the one signal you rely on to tell you something is wrong.
The fix was to give the check a third answer besides "fine" and "broken": "not installed on this computer". If the system it looks for is not there, it says so instead of raising an alarm. On the original computer nothing changed, because there everything is installed and every check still runs exactly as before. The false reds on the second computer went to zero without a single check being made weaker.
The One Habit That Catches All Three
All three cases have the same shape: a tool reporting on its own work, and a person believing the report. The answer is the same each time. Check by content, not by status. Open the thing the job was supposed to change and look.
Where to use it: whenever a program rewrites files, whenever you are judging whether a background job really did its work, and any time a status board shows a problem that is based only on a file size or a byte count.
Common Questions
Can I trust what my software says it did?
Not on its word alone. In one week we saw a sync say it failed when it had worked, a health check say it succeeded when it had run nothing, and a status check raise red alerts about systems that were never on that computer. The habit that catches all three is to check the result itself, not the message about it.
Why would two copies of the same file look different when nothing changed?
On Windows, a program that rewrites a file can quietly change the invisible character at the end of every line. The words stay the same but the file gets bigger. If you compare files by size alone, that looks like missing content. Before deciding two files really differ, make the line endings match and compare again.
Are false alarms really a problem if nothing is broken?
Yes. A check that shows red for things that are fine teaches people to skim past red. That is exactly how a real problem gets missed. A false alarm is not harmless. It slowly wears down the one signal you rely on.
Key Takeaways
- Software can say it failed when it worked, and say it worked when it did nothing.
- A difference in file size is not proof that content is missing. Line endings alone can change it.
- A check that raises false alarms trains people to ignore real ones. Give it an honest "not here" answer instead.
- Check by content, not by status: open the result and look before calling anything done.