DEV Community: Cfir Aguston

A Date That Never Existed

Cfir Aguston — Sat, 14 Mar 2026 22:00:00 +0000

If you enter February 29, 1900 into Microsoft Excel, the program will accept it without complaint.

It will sort it, compare it with other dates, and use it in calculations just like any other value.

There is only one problem.

That day never existed.

According to the Gregorian calendar, 1900 was not a leap year. Century years are leap years only if they are divisible by 400. The year 2000 qualifies. The year 1900 does not. The calendar moved directly from February 28 to March 1.

Yet inside Excel, February 29, 1900 exists as a valid day.

So how did this happen?

The Original Spreadsheet Mistake

Early spreadsheets needed an efficient way to handle dates. Instead of storing them as text, they stored them as numbers representing days since a starting point.

This made calculations simple:

Adding days became addition
Finding differences became subtraction
Sorting dates became numeric sorting

When Lotus 1–2–3, the dominant spreadsheet of the early 1980s, implemented this system, it made a small mistake.

It treated 1900 as a leap year. That meant its internal calendar included a day that never existed.

When Compatibility Beats Correctness

When Microsoft later created Excel, Lotus 1–2–3 already dominated the spreadsheet world.

Businesses had enormous numbers of spreadsheets built with Lotus. Models, templates and financial calculations all depended on Lotus behavior.

If Excel had fixed the leap-year logic, imported spreadsheets would produce different results. Dates would shift. Calculations might silently change.

So Microsoft made a deliberate decision: Excel would reproduce the Lotus bug exactly.

The result is a strange artifact that still exists today: a phantom day in February 1900 that only exists inside spreadsheets.

The Real Lesson

This story is not really about calendars. It is about how software evolves.

A small implementation decision in the early 1980s became:

a compatibility requirement.
a permanent behavior.
a contract that millions of spreadsheets depend on.

Software remembers its past, even when that past includes mistakes.

Sometimes the safest fix is not fixing it at all.

You can read the full story, including technical details and lessons, here:
A Date That Never Existed

How “Reliable” Systems Almost Started a Nuclear War

Cfir Aguston — Sat, 14 Mar 2026 05:58:26 +0000

In June 1980, shortly after midnight, computers at a U.S. strategic command center suddenly showed something terrifying: incoming nuclear missiles.

More launches kept appearing on the screen. Crews rushed to their B-52 bombers. Missile units were placed on higher alert.

For a few tense minutes, the early steps of nuclear war had already begun.

But at NORAD, the central warning hub, radar and satellites saw nothing.

After comparing the data, commanders realized: the attack did not exist.

The Real Cause

The problem turned out to be a failed integrated circuit in a Data General computer that handled communication between command centers.

To keep links healthy, the system constantly sent test messages that mimicked real alerts but always reported zero missiles detected.

When the chip failed, those zeros became random numbers. The system interpreted them as incoming missiles.

Worse, the messages had no error checks, so the corrupted data was accepted as valid.

When “Reliable” Systems Fail

What makes this story interesting is that the system wasn’t broken in the usual sense. It was working exactly according to its specification.

But the real world did not match the assumptions the system was built on.

And in systems where decisions must happen in less than a second, that gap can become dangerous.

You can read the full story, including technical details and lessons, here:
How “Reliable” Systems Almost Started a Nuclear War

How Developers Really Learn: 10 Lessons Backed by Science

Cfir Aguston — Sat, 15 Nov 2025 09:03:46 +0000

As developers we often assume learning means “look it up → copy → done”. But real learning is deeper and science shows how we learn best. Here are 10 evidence-based lessons tailored for developers.

1. Human Memory Is Not Made Of Bits
Unlike a computer’s memory, our brains don’t simply store and retrieve fixed chunks. When we recall something, memory can change (“reconsolidation”). Also, memories are connected in networks (“spreading activation”) so recall isn’t isolated.

2. Human Memory Is Composed Of One Limited And One Unlimited System
We have working memory (small capacity) and long-term memory (effectively huge). Experts free up working memory by “chunking” knowledge (e.g., recognizing patterns).

3. Experts Recognise, Beginners Reason
Beginners often step through code line-by-line. Experts recognise patterns and jump straight to solutions.

4. Understanding A Concept Goes From Abstract To Concrete And Back
Learning works best when you start with the concept, dive into concrete examples (good & bad), then return to the abstract view.

5. Spaceing And Repetition Matter
Last-minute studying feels productive, but it doesn’t work. Spaced practice plus revisiting topics over time beats marathon sessions.

6. The Internet Has Not Made Learning Obsolete
Just because you “can Google it” doesn’t mean you’ve learned it. Searching is not the same as understanding.

7. Problem-Solving Is Not A Generic Skill
Doing puzzles or “brain teasers” doesn’t necessarily make you better at programming. The domain matters.

8. Expertise Can Be Problematic In Some Situations
What makes you an expert also can blind you (you assume patterns that newcomers don’t see). Teaching beginners or learning new domains can suffer from expert assumptions.

9. The Predictors Of Programming Ability Are Unclear
There’s no reliable shortcut (years of experience, IQ, etc.) that guarantees programming ability. Good practitioners come from diverse paths.

10. Your Mindset Matters
Believing you can improve (growth mindset) helps. But mindset alone isn’t enough, you still need practice, feedback, reflection.

As developers, our learning toolkit should include code reading, active practice, spaced revisits, abstract/concrete toggling, and a realistic view of memory & expertise. The Internet and AI are tools, not shortcuts to understanding. Use them, but don’t rely on them.

The full breakdown, including all lessons and examples, is available here:
How Developers Really Learn: 10 Lessons Backed by Science

When Floating-Point Failed Catastrophically

Cfir Aguston — Sun, 12 Oct 2025 11:10:56 +0000

IEEE-754 gave us a common way to handle decimals on computers. But even with a standard, tiny numeric mistakes can grow into big failures. Here are four famous ones.

1) The Patriot Missile Failure (1991)
A U.S. Patriot missile system failed to intercept an Iraqi Scud missile, killing 28 soldiers. The software tracked time in tenths of a second but stored it as an integer.
To convert it into seconds, the code used a floating-point calculation that wasn’t exact. Over 100 hours of operation, the tiny rounding error accumulated into a 0.34-second drift, enough for the missile to miss its target.

2) The Pentium FDIV Bug (1994)
Intel’s Pentium had a flaw in its floating-point division hardware. A few entries in a lookup table were missing, so certain divisions returned slightly wrong answers (often far out in the decimal places). For most users it was rare, but for scientists and finance it had influence. After public pressure, Intel replaced affected chips and took a huge loss.

3) Ariane 5 Flight 501 (1996)
Ariane 5 reused code from Ariane 4. During flight, a 64-bit floating value (horizontal velocity) was converted to a 16-bit integer and overflowed. The guidance system crashed, the backup did the same, and the rocket self-destructed 37 seconds after launch.

4) Vancouver Stock Exchange Index (1980s)
The index was updated after each trade, but the value was truncated to three decimals every time. Tiny losses stacked up. Over many updates, the index drifted down—far from reality. When they fixed the math and recalculated with more precision, the index jumped back to where it should have been.

What engineers should remember:

Precision, rounding and overflow are design choices, not footnotes.
Long-running systems amplify tiny numeric errors.
Reused code must be re-validated for new data ranges.
In safety-critical and financial systems, prove the math, don’t assume it.

You can read the full story, including technical details and lessons, here:
When Floating-Point Failed Catastrophically

Oops I goto It Again

Cfir Aguston — Sun, 12 Oct 2025 11:07:07 +0000

Back in 2014, Apple’s SSL code had a tiny flaw: just one extra goto fail; line, that broke secure connections. On a public Wi-Fi, your iPhone’s “lock” icon could lie.

That duplicated goto made a security check skip critical steps. Attackers could intercept, tamper with or inject data — a man-in-the-middle attack.

Why this bug was terrifying?

The bug was trivial to miss: very small, very innocent looking.
It bypassed core SSL verification logic.
Because Apple’s SSL was trusted deeply in iOS/macOS, the impact was broad.

What engineers can learn:

Simplicity can be dangerous. Tiny code mistakes may have massive security consequences.
Don’t assume the safety of framework code. Even trusted libraries must be audited.
Be paranoid about branches. Control flow errors are subtle but powerful.
Trust but verify. Always build redundancy and extra validation layers.

You can read the full story, including technical details and lessons, here:
Oops I goto It Again

The Car That Would Not Stop

Cfir Aguston — Sun, 12 Oct 2025 11:06:08 +0000

In 2009, a Lexus suddenly started speeding on a California highway. The driver, off-duty police officer Mark Saylor, called 911.

“We can’t stop… we’re going 120…”

Moments later, the car crashed. Everyone inside was killed.

At first, Toyota blamed floor mats and driver error. But more reports came in: cars that accelerated by themselves, brakes that didn’t respond, and no clear signs of failure in the data.

The reality was more complicated. Inside modern cars, computers control almost everything: speed, brakes and sensors. A small software bug in one system can affect the others.

Investigators found that even tiny faults in Toyota’s code could cause dangerous results. One mistake could lock up the CPU, disable safety checks, and make the car ignore brake commands.

This wasn’t just a mechanical problem. It was a software failure, one that showed how invisible code can turn deadly when design, testing, and safety don’t align.

What engineers can learn:

Hardware isn’t perfect, software must be ready for it to fail.
Safety systems need multiple layers, not just one check.
Testing culture is important as much as the code itself.
Small logic bugs can lead to big real-world disasters.

You can read the full story, including technical details, investigations and lessons, here:
The Car That Would Not Stop

The Forbidden Intel Opcode That Melts CPUs

Cfir Aguston — Sun, 12 Oct 2025 11:04:21 +0000

In the 1990s, a strange bug in Intel’s Pentium processors caused real panic. A few bytes of machine code, F0 0F C7 C8, could completely freeze the CPU. No error message. No reboot. No recovery. The system just died.

This flaw became known as the F00F bug, named after its hexadecimal pattern. It wasn’t a normal software crash. The CPU itself stopped responding, leaving even the operating system helpless.

What it revealed:

Hardware bugs can be just as dangerous as software ones.
Intel and OS developers had to rethink how they handle “impossible” instructions.
Even one line of code can bring everything down.

Even today, we rely on billions of assumptions inside our chips. When one of them fails, the results can be catastrophic. The F00F bug shows that undefined behavior isn’t just a programming issue, it’s a hardware story too.

You can read the full story, including technical details and how engineers found it and fixed it, here:
The Forbidden Intel Opcode That Melts CPUs

Statement Coverage Is Not Enough

Cfir Aguston — Fri, 10 Oct 2025 16:04:15 +0000

Every now and then, I see someone say they’ve stopped caring about coverage metrics or that “50% coverage is good enough” (or other arbitrary number).

But I think a major point is being missed.

Coverage isn’t just a number. It’s a way to understand how much of your software’s behavior you actually know.

If your coverage is 50%, it doesn’t mean your tests are “half decent”. It means that half of your code has never been executed while testing: its logic and behavior are unknown. And if we take that idea one step further, in safety-critical applications, that’s unacceptable.

This is where Modified Condition / Decision Coverage (MC/DC) comes in. It ensures that every individual condition within a decision can independently affect the outcome. It’s not just about hitting lines or branches, it’s about proving that each logical factor has influence and is verified on its own. Whenever you stack conditions, combine flags or write complex if statements, you’re dealing with logic that can hide high-impact bugs.

Code coverage itself includes several levels of criteria, while statement coverage and MC/DC (together with brute force) are on the opposite sides of the scale. In between, each level gives you a different depth of assurance:
1. Statement Coverage: ensures every line of code executes at least once. Good for catching dead code, but blind to logic paths.
2. Decision (or Branch) Coverage: checks that every branch (if, else, switch) is taken both true and false. Reveals untested decision outcomes, but still misses compound logic.
3. Condition Coverage: verifies that each Boolean condition inside a decision is evaluated both true and false. Tests the individual pieces, but not their combinations.
4. Decision/Condition Coverage: merges both: every decision outcome and each individual condition must be tested true and false. Better visibility, but doesn’t guarantee that each condition’s influence is isolated.
5. Modified Condition / Decision Coverage (MC/DC): goes one step further by requiring proof that each condition can independently change the decision’s outcome. This is the level demanded, for example, in avionics and other critical systems because it provides meaningful assurance of logical completeness.

You can see a full article that walks through different coverage methods, practical examples, why MC/DC is needed and how it ties into requirements coverage here:
MC/DC and the Logic of Safer Software