𝗧𝗵𝗲 𝗪𝗼𝗿𝗸𝗲𝗱 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 𝗧𝗵𝗮𝘁 𝗗𝗶𝘀𝗮𝗴𝗿𝗲𝗲𝗱 𝗪𝗶𝘁𝗵 𝗜𝘁𝘀 𝗢𝘄𝗻 𝗖𝗮𝗹𝗰𝘂𝗹𝗮𝘁𝗼𝗿
I run a website with home improvement cost calculators.
Each page shows the same cost in four different places:
- An interactive widget.
- A static reference table.
- Written prose examples.
- An FAQ section.
I found a bug. A written example said a project cost $62,300. The calculator widget said the same project cost $56,779.
The gap was $5,500.
The error happened because I wrote the numbers by hand. I used different assumptions for the text than I used for the code. The text assumed a new HVAC unit. The code assumed an existing system. Both were valid, but they did not match.
This is a common failure. When you store the same fact in two places, they drift apart.
I fixed this with two rules.
Rule 1: Source-first logic.
The calculator function is the only place a number is born. I no longer type numbers into tables or paragraphs. Instead, I use the function to generate the tables and examples at build time.
If the function changes, the entire page changes. The table and the widget will always agree because they use the same logic.
Rule 2: Add provenance.
A number is only useful if you know where it came from. Every calculation now includes:
- The specific scenario used.
- The data source.
- The date it was accessed.
- An expiration date for the data.
Cost data is not a permanent fact. It is a perishable fact. Adding a review date reminds me to update the data before it becomes wrong.
A single source of truth makes you consistent. Adding provenance makes you honest.
If you show the same number in two places, do not retype it. Import it. Let your build process handle the duplication.
Source: https://dev.to/mark_b5f4ffdd8e7cd58/the-worked-example-that-disagreed-with-its-own-calculator-4cp9