First Principles: How NVIDIA's Pursuit of the Speed of Light Can Inspire Access Developers
To achieve greatness, you need to measure yourself against the right limits.
In 1992, Jensen Huang sketched out a business idea at a roadside Denny's.
Today, NVIDIA's current market cap is greater than the GDP of all but 3 nations:
If you Lex Fridman were to ask Huang how he did it, he would tell him it's all about "first principles."
"I force everybody to think about what’s the first principles, the physical limits for everything before we do anything. And we test everything against that."
lexteam
First Principles
So what does Huang mean by "first principles"? I think the concept is easiest to understand with a specific example:
"The speed of light is my shorthand for what’s the limit of what physics can do. And so every single thing that we do is compared against the speed of light. Memory speed, math speed, power, cost, time, effort, number of people, manufacturing cycle time."
Contrast this with the more common MBA approach of "incremental improvement", of which Huang is not a fan:
"I don’t love the other methods, which is continuous improvement. ... I don’t like going into a problem and somebody says, 'Hey, you know, it takes 74 days to do this today. ... And we can do it for you in 72 days.'
"You know, I’d rather strip it all back to zero and say, 'First of all, explain to me why 74 days in the first place. ... If I were to build it completely from scratch, how long would it take?'
Oftentimes, you’d be surprised. It might come to six days. Now, the rest of the six days, the 74, could be very well-reasoned and compromises, and, you know, cost reductions, and all kinds of different things. But at least you know what they are. And then now that you know that six days is possible, then the conversation from 74 to six, surprisingly much more effective."
Extreme Co-design: First Principles in Action
In the interview, Huang talks about how the demands of AI required a complete reimagining of computer processing infrastructure.
At some point, GPU improvements alone reached a point of diminishing returns for his enterprise customers. The bottlenecks lived in other parts of the system. To achieve the business outcome his customers wanted, he needed to rethink the product he was selling.
And so, Huang took a page out of Stanley McChrystal's playbook and instituted a concept that he coined Extreme Co-design.
Here's Lex Fridman laying out the concept:
"I think it’s fair to say that winning for NVIDIA for a long time used to be about building the best GPU possible, and you still do, but now you’ve expanded that to extreme co-design of GPU, CPU memory, networking, storage, power cooling, software, the rack itself, the pod that you’ve announced, and even the data center. So let’s talk about extreme co-design. What is the hardest part of co-designing a system with that many complex components and design variables?"
Rather than sell GPUs in isolation to his enterprise customers, Huang's team would assemble entire self-contained racks of hardware.
Big.
Large.
Massive.
Self-contained.
Racks of components.
Just how many components?
"Each rack is 1.3, one and a half million components."
"...distributed computing at the scale that we do, the CPU is a problem, the GPU is a problem, the networking is a problem, the switching is a problem. And distributing the workload across all these computers is a problem."
The underlying motivator of the Extreme Co-design method was the pursuit of first principles: how close could NVIDIA get to processing at the speed of light?
First Principles in Software Consulting
Let's bring it back to Microsoft Access. How does this concept apply to us?
At the end of the day, I am NOT in the software development business; I'm in the value creation business.
My clients don't care if I use proper referential integrity. They don't care if I use Option Explicit at the top of every module. They don't care if I set all my objects to Nothing when I'm done with them.
They only care that my software helps them run their business.
What is a Business Application?
Now, that's not a particularly helpful definition for our purposes. I like to think of it like this: a business application is a piece of software that:
Captures inputs to produce outputs that support business outcomes.
At the end of the day, that's our whole job.
Mike Wolfe
And the key to building great business software is to start from the end of that sentence and work your way back:
- Identify the desired business outcomes
- Identify the minimum outputs needed to deliver those outcomes
- Identify the minimum inputs needed to produce those outputs
Everything else is just noise.
