DEV Community: Javeed Shaik

Three times this week a tool said it worked, and it had not

Javeed Shaik — Tue, 04 Aug 2026 10:27:05 +0000

Three times this week a tool told me it had done something, and it had not. Not one of them threw an error. Each looked exactly like success, and each was caught only because I went and checked the actual artefact afterwards.

I maintain a set of calculators and a small formula library, so most of my week is arithmetic and DOM. None of these bugs were exotic. That is the point — they are the ordinary kind, the kind that ships.

1. Grepping HTML for a word is not reading a page

I needed to know whether a set of pages had been updated to a new standard. The obvious move: fetch each page, search the HTML for the marker string.

curl -s "$url" | grep -c "0.55"

Twelve of them came back positive. Great — except several of those pages plainly did not mention the standard anywhere in their text.

0.55 was matching inline CSS. opacity: 0.55, rgba(0,0,0,0.55), a transition duration. My "is this page updated" check was counting stylesheet values.

Worse, the failure was silent and confident. I did not get an error or an empty result — I got a plausible number that led to a wrong conclusion, and the conclusion was about to go out in an email to someone who would check it.

The same class of bug had bitten me a month earlier, testing whether an account was verified with 'verified' in html.lower(). That matched the word "verified" in unrelated page furniture and returned true for everything.

What actually works: match a structural marker, not a bare string — a class name, an element, an attribute:

'badge-verified' in html          # a class the page only emits when true

Or skip the HTML entirely and read the rendered text. Raw HTML contains CSS, JSON blobs, script bodies, nav boilerplate and comments. Any word or number you search for lives in all of them.

2. Setting `.value` is not filling in a form

I needed to update a bio on a site built with a modern JS framework. Set the textarea's value, click save, done:

textarea.value = NEW_BIO;
saveButton.click();

The tool reported success. The editor showed my new text. I clicked save. The page said it saved.

The live profile still had the old bio.

Assigning to .value mutates the DOM node, but React keeps its own copy of the state and never notices. On submit it serialises its state — the old value — and posts that. Nothing errors, because from the framework's perspective nothing happened.

The fix is to go through the native setter so the framework's synthetic onChange actually fires:

const setter = Object.getOwnPropertyDescriptor(
  window.HTMLTextAreaElement.prototype, 'value'
).set;
setter.call(textarea, NEW_BIO);
textarea.dispatchEvent(new Event('input',  { bubbles: true }));
textarea.dispatchEvent(new Event('change', { bubbles: true }));

React patches value on the element instance, so calling the prototype's setter writes the real value underneath and the subsequent input event makes React pick it up.

I have now hit this on four different sites. Every time, the tooling said it worked.

3. A backgrounded tab gets zero animation frames

This one was a phantom. I was testing a calculator whose result counts up to its final value with a small requestAnimationFrame tween. Every automated check reported the headline number as 0.0. The supporting rows underneath were all correct. It looked like a real bug in exactly one code path.

It was not a bug. The tab was not visible, and browsers do not run requestAnimationFrame callbacks in a backgrounded tab. The tween's first frame fires synchronously — at t = 0, so it renders the starting value — and the next frame never comes. The readout freezes at zero and looks broken.

document.visibilityState  // "hidden"  <- that was the whole story

My next move made it much worse. I patched requestAnimationFrame to a setTimeout so the tween would complete. Something else on the page ran a perpetual animation loop, that loop was now a tight timer loop, and the renderer froze hard enough to need a reload.

The lesson is narrower than "don't patch globals": if a value only renders during animation, do not try to force the animation. Read something that is not animated. The un-tweened rows were right there, computed by the same function, and they told me the arithmetic was fine.

The thing they have in common

None of these were logic errors. In all three, the code I wrote did exactly what I told it to. What failed was the signal I used to decide it had worked:

grep said "found it" — it had found something else
the DOM said "value set" — the framework disagreed
the readout said 0.0 — the environment could not render anything else

Every one of them was caught the same way: by looking at the finished artefact instead of the report about the artefact. Read the live page, not the editor. Read the rendered text, not the HTML. Read the value that is not being animated.

That sounds obvious written down. It is much less obvious at the moment you are doing it, because a tool returning success is genuinely good evidence most of the time — which is exactly what makes the exceptions expensive. A test that reports success while testing nothing is worse than no test at all.

The habit I have landed on is small: after any write I cannot see the effect of, fetch the thing fresh and assert on it. It costs a few seconds. All three of these would have shipped without it, and one of them nearly went out in an email.

The calculators this came out of are at Healthy Calculator Hub, and the formula library is health-fitness-formulas if you want the tested implementations.

A formula can be implemented perfectly and still give the wrong answer

Javeed Shaik — Tue, 04 Aug 2026 09:14:31 +0000

I spent a while this year writing a small zero-dependency library of health and fitness formulas — BMI, Mifflin-St Jeor, the US Navy body-fat equation, FFMI, Epley and Brzycki, Karvonen. Thirty-odd functions, no dependencies, ESM, one file.

It should have been a boring job. It mostly was. But three things came out of it that I think generalise well beyond fitness maths, and one of them genuinely changed how I think about what "correct" means in a library.

The boring part: these equations get reimplemented constantly, and quietly wrong

Search for any of these formulas and you will find dozens of implementations. A lot of them are subtly broken, in ways that never throw and never look wrong:

The wrong coefficient set. The Navy body-fat equation has separate male and female forms, and separate metric and imperial constants. Four combinations, and three of them are wrong for any given call.
The imperial equation fed metric input. Nothing errors. You just get a number that is wrong by a believable margin, which is the worst kind of wrong.
Rounding in the middle. More on this below, because it turned out to be the interesting one.

None of these produce a NaN or a stack trace. They produce a plausible number. That is the entire problem: there is no failure signal, so the bug survives indefinitely.

My response was unremarkable — every function names the paper it came from in a docblock, and nothing is rounded inside the library. You round for display, because only you know how many decimal places your UI has room for.

The interesting part: rounding order is observable, so it has to be pinned

Total daily energy expenditure is BMR times an activity multiplier. Trivial. Except: do you round the BMR before multiplying, or round only the final figure?

It matters, and it is measurable:

const args = { sex: 'female', kg: 70.5, cm: 167, age: 41 };
const raw = bmrMifflinStJeor(args);   // 1382.75

Math.round(Math.round(raw) * 1.725);  // 2386  <- round first
Math.round(raw * 1.725);              // 2385  <- round last

One kilocalorie. Utterly meaningless physiologically — nobody's diet is sensitive to 1 kcal, and the underlying equation has a standard error hundreds of times larger.

But it is not meaningless as a library contract. Two callers doing "the same" calculation get different numbers, and neither can tell why. Someone comparing my output against another tool finds an off-by-one and reasonably concludes one of us has a bug. So the order is pinned and there is a test that fails if anyone changes it:

test('tdee — rounding order is observable, so it is pinned', () => {
  // 70.5 kg gives a fractional BMR; rounding first vs last must differ here.
  const args = { sex: 'female', kg: 70.5, cm: 167, age: 41 };
  const raw = bmrMifflinStJeor(args);
  assert.notEqual(Math.round(raw), raw, 'test input must produce a fractional BMR');
  const r = tdee({ ...args, activity: 'active' });
  assert.equal(r.tdee, Math.round(Math.round(raw) * 1.725));
});

Note the second assertion. The test asserts its own premise — that this input actually produces a fractional BMR. Without it, someone tweaking the Mifflin-St Jeor constants could make the input round cleanly, and the test would keep passing while testing nothing at all. A test whose premise can silently evaporate is worse than no test, because it reports success.

That is the pattern I would take to any numeric library: when a choice is arbitrary but observable, pin it in a test, and make the test verify that its own scenario is still meaningful.

The part that actually changed my mind: correct is not the same as current

Here is the one I did not see coming.

The US Navy body-fat equation — Hodgdon & Beckett, 1984 — is the most widely implemented formula in this entire space. My implementation of it is correct. It matches the paper, it matches the reference values, it is tested to one decimal place.

And partway through the year it stopped being the right answer to the question most people are actually asking.

The US Department of Defense moved every service to a waist-to-height ratio screen on 1 January 2026, and the Army implemented it on 7 July 2026 — retiring both the height/weight tables and the circumference tape test that produced a body-fat percentage. Someone calling a function to check whether they meet a service standard is now being measured against something that no longer exists. The arithmetic is still right. The answer is wrong.

Out of curiosity I audited the calculators that rank for this. Of nine pages I could verify, eight were still running the retired method. Several advertise themselves as updated for 2026. One stamps "Last Logic Update: July 2026" in its footer — the month of the change — while running a formula that was superseded in 2023.

I do not think those are careless people. I think it is a structural blind spot in how we test numeric code. My test suite verifies that bodyFatNavy matches Hodgdon & Beckett. There is no test anywhere that could tell me Hodgdon & Beckett stopped being the standard, because that fact does not live in the code, the inputs, or the outputs. It lives in a policy document I had no reason to read.

The best I have come up with is modest: say plainly, in the docs, what a function is for and what it is not, and give the reader the current alternative. So the README now says the Navy equation is named for its origin and not its current use, notes that it remains a sound field estimate, and points at waistToHeightRatio for the standard that actually applies. Whether anyone reads that is another question — but at least the library is no longer silently implying something false.

If you maintain anything that encodes an external standard — tax bands, postal formats, accessibility thresholds, compliance rules — I would ask the same question I had to ask myself: what would have to change in the world for my correct code to start giving wrong answers, and would I ever find out?

Small thing: throw, do not return NaN

Last one, quickly. Every function validates and throws:

bodyFatNavy({ sex: 'male', neckCm: 90, waistCm: 85, heightCm: 175 });
// RangeError — waist must exceed neck

A neck larger than a waist is not a number problem, it is a measurement problem, and NaN propagates silently through arithmetic until it surfaces somewhere unrelated. Throwing at the boundary makes the caller deal with it while they still have the context to understand it.

The library

health-fitness-formulas — MIT, zero dependencies, ESM, Node 18+. 31 tests via node --test, no test framework.

npm install health-fitness-formulas

These are the implementations behind the calculators on Healthy Calculator Hub, and the suite asserts they stay in agreement with what the site serves. If you spot a coefficient I have got wrong, I would genuinely like to know.

One honest caveat, since it is a health topic: every function returns a population-level estimate. None is diagnostic, and body-fat categories in particular are conventions rather than an agreed international standard. It does arithmetic on published formulas and shows its working. That is all it does.

Three things Indian finance code gets wrong (with the numbers)

Javeed Shaik — Tue, 04 Aug 2026 08:55:59 +0000

I maintain a set of finance calculators for India. Every formula ships with a unit test, and the
build fails if a number drifts more than 0.5% from a verified value. That sounds like overkill for
arithmetic until you find out how much published finance code is quietly wrong.

Here are three errors I keep running into, with the actual figures. All three are asserted by tests
in indian-finance-formulas, a
zero-dependency MIT package I extracted from the site.

npm install indian-finance-formulas

1. GST interest is charged on the cash ledger, not the gross bill

This is the most common one, and it is expensive.

Rule 88B(1) of the CGST Rules charges interest on the tax actually debited from your electronic
cash ledger — not on your gross output liability. If part of your liability was settled through
input tax credit, that part does not attract interest.

Plenty of code runs the interest on the whole output tax. The difference is not subtle:

import { gstInterest } from "indian-finance-formulas";

gstInterest(30000, 30);    // 443.84  — correct: ₹30,000 actually paid in cash
gstInterest(100000, 30);   // 1479.45 — the common error: gross liability

3.33× too high. On a real filing that is the difference between a rounding error and a number
you would argue about.

The fix is a naming discipline as much as a maths one. The parameter is called cashTaxPaid, not
taxAmount, so it is hard to pass the wrong thing without noticing.

2. A step-up SIP does not beat a flat SIP of the same total outlay

Every step-up SIP calculator I have seen shows the step-up winning. It does win — but only because
more money goes in. That is not a strategy insight, it is arithmetic about deposits.

Hold the money constant instead of the starting instalment, and it reverses:

import { stepUpSip, sipFutureValue } from "indian-finance-formulas";

const step = stepUpSip(10000, 12, 20, 10);
// ₹1,98,88,715 on ₹68,73,000 invested — start ₹10k/mo, +10% a year, 12% p.a., 20 years

const flat = sipFutureValue(step.invested / 240, 12, 240);
// ₹2,86,13,098 on the SAME ₹68,73,000

The flat schedule finishes ₹87 lakh ahead on identical money. The reason is simple once you see
it: in a step-up plan, most of the rupees arrive late and compound for fewer years. A flat plan
front-loads the same total, so every rupee gets longer in the market.

Step-up SIPs are still a perfectly good idea — they match rising income, and most people genuinely
cannot invest the flat-equivalent amount in year one. But the reason to use one is behavioural,
not mathematical, and calculators that imply otherwise are selling a free lunch.

This one is a test, not a comment, because it is exactly the kind of thing a well-meaning
"optimisation" would silently break:

assert(flat > step.futureValue);

3. The Section 87A rebate is a cliff, and needs marginal relief

Under India's new tax regime, a rebate takes your tax to zero up to ₹12,00,000 of taxable income.
Implement that naively and earning one rupee more costs you far more than one rupee — the classic
cliff.

Marginal relief caps the tax at the amount of income above the threshold:

import { incomeTaxNewRegime } from "indian-finance-formulas";

incomeTaxNewRegime(1200000).total;   // 0
incomeTaxNewRegime(1200100).total;   // 104     — ₹100 over the line, ₹104 of tax (incl. 4% cess)
incomeTaxNewRegime(1210000).total;   // 10,400
incomeTaxNewRegime(1250000).total;   // 52,000

Without relief, the ₹12,00,100 case would jump to tens of thousands. Also asserted by a test.

The bit that generalises: statutory values are parameters, not constants

Every function that depends on a notified figure takes it as an argument with a documented default:

gratuity(500000, 30);                        // ₹20,00,000 ceiling — most employees
gratuity(500000, 30, { ceiling: 2500000 });  // ₹25,00,000 — Central Govt civil employees

incomeTaxNewRegime(1600000);                 // FY 2026-27 slabs by default
incomeTaxNewRegime(1600000, { slabs: [...] }) // yours, the day they change

Hard-coding a slab table means waiting for a release when the Finance Act moves. Making it an
argument means the person who noticed can fix it that afternoon.

And the failure mode tests cannot catch

Unit tests protect the arithmetic. They cannot protect the inputs.

I hit a clean example of this today. I was building a table of India's 7th Pay Commission pay
matrix and went to the primary source — the Commission's own report — rather than trusting my
notes. It lists Level 13 entry pay as ₹1,18,500.

That figure is wrong today. The CCS (Revised Pay) (Amendment) Rules, 2017 re-based Level 13 and the
correct figure is ₹1,23,100. The number printed in the primary source has been superseded for
years.

No test catches that. The arithmetic stays perfectly correct while the answer is wrong, and
"I checked the official source" is exactly the reasoning that gets you there. The only defence is
citing and dating each statutory figure, so a human can re-check what a machine cannot.

That is why the calculators carry a source list and a date rather than a vague "updated recently".