Learning from Giants #40

Floating point numbers from scratch, Availability and what is means and doesn't mean in distributed systems, and Jacob Kaplan-Moss's estimation technique. Only personal blogs this week!

👋 Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies.

Did a friend send this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.

---

Floating point numbers from first principles

"Never use floating point numbers for X, Y, Z." is a lesson we've all learned the hard way or were taught in our careers. And while it leads us to question every use of that type, now may be the right time to learn more about them.

Why now? Large Language Models. Guess what these models manipulate? Floating point vectors.

"We'll begin with the very basics of writing numeric values. The initial steps may seem trivial, but starting from the first principles will help us build a working model of floating point numbers."

The most straightforward introduction to floats is through scientific notation.

“Floating points numbers are just numbers in base-2 scientific notation with the following two restrictions:

• limited number of digits in the significand

• limited range of the exponent – it can't be greater than some maximum limit and also can't be less than some minimum limit"

That explains why some numbers don't have an exact floating-point notation. The exponent limitation (e.g. [-126,+127] for floats) bounds the overall possible precision.

By diving deeper into the binary format, we learn that some boundary values can be represented as floating point numbers too.

"A float number with maximum biased exponent value and all zeros in significand is interpreted as positive or negative infinity depending on the value of the sign bit"

"A float number with maximum biased exponent value and non-zero significand is interpreted as NaN – Not a Number."

The binary space of floating point numbers. Source: ciechanow.ski

📗 Bartosz Ciechanowski's Exposing Floating Point is one more of Bartosz's masterclasses. You'll go from 0 to proficiency in one article. Beyond what I quote above, the article explores conversions, printing formats, and operations.

---

Availability vs. availability in distributed systems

Meaning uppercase vs. lowercase availability. Got it? Let's start with definitions:

"[Big A- availability is defined in the CAP theorem as] every request received by a non-failing node in the system must result in a response."

"Most users of distributed systems, on the other hand, define availability as the percentage of requests that their clients see as successful."

Theoretically, these two sentences are equivalent, but what about the real world? That's the main criticism made to the CAP theorem: it's different in practice because the real world is a lot messier.

"Some [workloads] are messier, and require pulling data from many different shards of different databases, or from other services." There is no theoretical guarantee that two Available systems can stay Available when combined.

"[For clients in failure scenarii] They're also likely to be some cost to continuing, requiring the system to detect the problem, and shift from happy mode into failure handling mode." During failure recovery periods, nodes of Available system don't always guarantee availability.

📗 Marc Brooker's Availability and availability is an informative read for anyone interested in distributed systems, especially for those seeking to make the Consistency versus Availability trade-off when choosing or designing a system.

---

A (good) software estimation technique

Time estimates are software engineers' biggest enemy (or are they their managers’? ;) ).

And many are tempted to say F*** it and not estimate anything. I'd argue that while sometimes the best strategy is to just ship it, you should still do estimates.

So here's one of the best, most actionable articles to get your estimation game to the next level: Jacob Kaplan-Moss's Software Estimation Technique.

"My system does have one critical characteristic that I believe any effective estimation technique should have: it captures both time and uncertainty."

Here's the high-level technique:

1. Break down the work into less complex tasks. I recommend not going too much below 1-day tasks, but from there, the more granular, the better.

2. Estimate the actual wall time that shipping these tasks will take. That means not hours in a parallel universe where the software engineer has 10 hours of focus time per day. But also not overly pessimistic.

3. For each task, estimate the uncertainty level. Does this task need additional framing or is it crystal clear? Any risks or ambiguity?

4. Combine time and uncertainty into two numbers: expected (the sum of times) and worst-case (sum of time x uncertainty) times. This gives you a time range for completion.

5. Refine. If the range is larger than expected for your project, put your product hat on and refine. In most situations, you can cut out some parts by assessing if they're worth the effort or time-box a few hours or days to de-risk to riskiest parts.

📗 Jacob Kaplan-Moss's My Software Estimation Technique gives more details about the technique and ways to be successful with it. It's a read that will stick, and you will return to it regularly. A must-have in your engineering leader toolbox!