Software is Way Less Performant Today

Here are detailed notes from the transcript:

---

Detailed Notes: The Decline of Software Performance

Main Topic: The phenomenon of modern software becoming increasingly slow, bloated, and less performant, and the underlying cultural and educational reasons within the programming community.

Key Points and Arguments:

1. Software Degradation is a Real Problem:

   • Many modern software applications are significantly slower than their counterparts from decades ago, despite vastly superior hardware.
   • This isn't due to increased features necessarily, but often due to poor programming practices.
   • There's a cultural acceptance among developers that "more features just means everything is slower," which is a flawed understanding of how programs work.
   • The speaker has observed this trend over decades and has evidence to back it up.

2. Examples of Performance Decline:

   • Microsoft Visual Studio (IDE/Debugger):
     • Circa 2004: Loaded "pretty much instantly." Projects loaded instantly. Watch window updated instantly when stepping through code.
     • Circa 2017: A Visual Studio team feedback questionnaire listed "less than 10 seconds" as the minimum acceptable project load time, implying 10+ seconds is expected.
     • Current: Still "extremely slow." The host mentions 20 seconds for a simple project, the speaker mentions 20 minutes (likely for a complex project or initial setup).
     • Proof: The speaker created a video demonstrating a 2004 machine (with embarrassingly low specs) running 2004 Visual Studio faster than a modern machine runs modern Visual Studio on the same project files. This showed that "bad code" and "bad programming practices" are the cause, not inherent complexity or hardware limitations.
   • Microsoft Teams (Chat Client):
     • Underwent a rewrite to "massively speed up" boot time.
     • Improved from ~20 seconds to ~10 seconds.
     • Speaker's argument: For a chat client, 10 seconds is still unacceptably long.
     • Common excuses like "checking credentials" are dismissed, as credentials should be cached or checked asynchronously, and 10 seconds for a modern internet connection is excessive. The likely cause is "serial dependency chain server round trips" due to lack of thought in startup design.

3. The Root Cause: Culture and Education, Not Laziness:

   • The primary driver for slow software is a "lack of education" or "lack of culture" within programming.
   • It's not primarily due to individual programmers being lazy or not caring.
   • Programmers readily learn highly complex topics like Docker, React.js, or intricate CSS layouts (which the speaker argues is harder than assembly language). This proves they are not too lazy to learn challenging concepts.
   • The problem is a prevailing culture where it's "virtuous to not know how a computer works."

Important Facts or Data Mentioned:

• Year 2004: Reference point for "instant" software performance (Visual Studio).
• Year 2017: Visual Studio team's feedback questionnaire setting "less than 10 seconds" as the minimum acceptable project load time.
• Microsoft Teams Boot Time: ~20 seconds down to ~10 seconds after a rewrite/optimization effort.
• Modern Internet Ping Times: Described as "millisecond," highlighting the absurdity of 10-second credential checks.
• Hardware Comparison: A machine from 2004 (embarrassingly low specs) vs. modern hardware, demonstrating software bloat is not due to insufficient hardware.

Conclusions or Recommendations:

1. Fundamental Cultural Shift Needed: The core issue is cultural. The programming community needs to shift away from the belief that not knowing how a computer works is acceptable or even "virtuous."
2. Universal Knowledge of Computer Functionality: Every person who programs for a living "should know how a computer works."
3. Care for Hardware Performance Utilization: Programmers should "care whether the thing that they're shipping is living up to some reasonable percentage of the performance of the hardware that they're given."
4. Avoid Wasteful Squandering: While 100% optimization isn't necessary due to diminishing returns, the "wasteful squandering of computation power" should have been culturally eradicated long ago.
5. Performance is Not an Afterthought: The "million really bad decisions" that lead to slow code are hard to undo, suggesting performance needs to be considered from the outset, not as a "hot spot" optimization later. (This point is a teaser for future discussion).